문서는 사용자 스토리입니까? [닫은]

지난 몇 번의 스프린트를 위해 작업 한 제품에 대한 사용자 설명서를 작성해야합니다. 우리는 이제 다음 스프린트에서 새로운 프로젝트를 시작하고 있으며 PO는 이전에이 스프린트에 대한 사용자 스토리를 생산 한 제품에 대한 문서를 만들고 있습니다.

이 접근법에 대한 귀하의 의견이 궁금합니다. 개인적으로, 나는 문서가 코드를 생성하지 않기 때문에 Scrum 내의 사용자 스토리라는 것에 동의하지 않습니다.

편집 : 의견을 보내 주셔서 감사합니다. 나는 스프린트가 작동하는 소프트웨어의 증분을 구현하는 것이 아니라고 생각했지만, 당신의 견해는 내 견해를 바꾸었다. 모든 답변에 감사드립니다.

"X 사용자는 X가 어떻게 작동하는지 알아야합니다."는 합법적 인 사용자 이야기처럼 보입니다. 이로 인해 서면 문서 나 온라인 도움말이 제공 될 수 있습니다.

요점은 단순한 코드가 아니라 사용자의 요구 사항을 충족시키는 것입니다.

이상적으로 문서는 모든 사용자 스토리의 일부이며 절대로 구축되지 않습니다. 그러나 실제 세계에서는 종종 발생하지 않습니다. 이 경우 누락 된 특정 설명서를 따라 잡기위한 사용자 스토리를 작성해야합니다.

맞습니다. 코드를 생성하지 않습니다. 그러나 사용자 요구 사항을 충족 시키므로 다른 사용자 요구 사항에 우선 순위를 두어야합니다.

이것이 완료되지 않았다는 것을 의미한다면, 이것과 그 기능이 작동하고 있기 때문에 문서를 필요로하지 않았을 것입니다.

요구 사항, 기술 또는 프로젝트 문서에 대한 pdr의 문서 평가에 동의합니다. 이상적으로는 스프린트 작업에 포함되어야합니다.

제품 문서는 실제 사용자가 인도 물을 요청했으며 사용자에게 직접 가치를 제공하기 때문에 매우 다릅니다. 이는 제품 설명서는 본질적 것을 물론 이해되어야 하지 테크니컬 작업하지만, 기능 작업 및하거나 프로젝트에 대한 기술 자원에 적합한 활동을하지 않을 수 있습니다.

나는 이것이 사용자 스토리라고 생각하지만 비즈니스 요구 사항, 사용자 관점 및 우수한 기술 작성 기술을 제대로 이해 한 프로젝트 리소스에는 이러한 작업이 할당되어야한다고 생각합니다. 가능한 경우 비즈니스 분석가이거나 요구 사항, 사용자 사례 및 우수한 기술 작문 기술을 제대로 이해하고있는 고급 QA 테스터가 이상적입니다. 개발자 일 수도 있지만 개발자가 기술 문서에 너무 가깝기 때문에 개발자가 작성한 제품 문서는 품질이 높거나 유용하지 않은 경향이 있습니다.

조직에서 지속적인 통합 시스템의 유지 관리 및 향상을 담당하는 툴링 팀은 Scrum을 사용하여 작업을 관리하고 있습니다. 그들은 코드를 작성하지 않고 있지만 스크럼을 연습하고 있습니다.

귀하의 질문에 구체적으로 답변하기 위해 팀이 문서가 "정의의 정의"의 일부인지 고려하는지 묻습니다.

팀이 문서가 "완료된 정의"의 일부라고 생각하면 추가 스토리가 필요하지 않으며 문서를 작성하고 검증하지 않으면 스토리를 승인 할 수 없습니다.

팀이 문서가 "완료된 정의"의 일부가 아니라고 생각하면 제품 소유자가 작업을 관리 할 수 ​​있도록 별도의 스토리를 작성합니다.