스크럼 및 요구 사항

Question

사용자 스토리를 어떻게 든 가질 수는 없지만 프로그램의 기능을 문서화해야합니다. 당신은 스크럼이있는 명세 문서로 끝나나요? 당신이 그렇게한다면, 당신은이 작업을 수행 할 시간을 할당 받게됩니까?

예를 들어 복잡한 워크 플로가 있습니다.
또 다른 예는 팀에 오는 새로운 회원입니다.

Answer 1

각 사용자 스토리의 작업으로 "문서화"를 추가하는 것이 확실히 목표 달성에 많은 도움이 될 수 있습니다.

Answer 2

제임스 콜팩 (James Kolpack)이 말한 것 외에도 프로젝트가 완료된 후에도 사용자 스토리 맵은 문서 형식이기 때문에 유지되어야합니다. 나는 우리가 위키에있는 모든 문서를 어떻게 바꾸어야 하는지를 생각합니다.

이 문서는 사용자의 관점을 이해할 수 있기 때문에 향후 시스템을 유지 관리하거나 기능을 추가해야하는 사람들에게 유용 할 것입니다.

Answer 3

이 질문에 많은 아이디어가 추가됩니다. 내 개인적인 경험은 저에게 다음과 같이 가르쳐 줬습니다 :

1 ~ 작동하는 제품은 문서 자체의 형식입니다. 제품이 허용된다고 가정하면 특정 조건에서해야 할 일을 묻는 것은 그것들이 실제로 무엇을하는지 묻는 것과 같습니다. 조건 - 로그인하여 답을 얻으려고 시도하십시오.

2 ~ 테스트는 수동 또는 자동 (또는 혼합) 테스트 일 수 있으며 문서 형식입니다. 단위 테스트는 기술적으로 기울지 않는 팀 구성원이 말하는 도메인 언어 (예 : '비즈니스 전문가'또는 고객)와 너무 멀 수 있습니다. 합격 판정은 '중도'에 가깝습니다. 확실히 BDD 스타일의 테스트는 모두가 이해할 수있는 유비쿼터스 언어를 구축 할 수있는 가장 좋은 기회입니다 (이와 관련하여 Gojko's Bridging the Communication Gap 참조). 그럼에도 불구하고 이러한 형태의 테스트는 모두 제품이 수행해야 할 작업을 결정하는 데 사용할 수있는 문서 형식입니다.

3 ~ 스펙트럼에 해당하는 프로젝트에 따라 문서 (일반적으로 모든 보조 산출물)에 더 높은 또는 더 낮은 수준의 의식이 필요할 수 있습니다. 시장 출시가 중요한 소형 제품, 소규모 팀은 요구 사항에 대한 공식적인 문서가 추가 된 가치에 비해 너무 비싸다는 것을 알 수 있습니다. 다른 한편으로는 여러 팀과 개발 기간에 걸쳐있는 매우 큰 프로젝트는 정식 문서의 ROI가 아주 다른 것을 알 수 있습니다.

4 ~ 완벽한 세계에서 우리는 작업 코드 (아이보리 타워에서는 자체 설명이 가능) 및 테스트 (주로 회귀 테스트, 새로운 기능의 개발을 유도하기 위해) 따라서 요구 사항 문서의 질문은 Perfect World/Ivory Tower와 Real World/Trenches간에 다른 점에 대한 질문입니다. 대답은 프로젝트와 팀에 따라 상황에 따라 다릅니다. 예를 들어, "모든 요구 사항은이 위키에 보관되고 최대한의주의를 기울여 유지되어야합니다."라고 말할 수 있습니다. 그러나 팀이 익숙하지 않고 위키에 익숙하지 않은 경우에는 작동하지 않습니다.

5 ~ 결국 이해 관계자는 사용자가 알아야 할 사람들입니다. 팀의 모든 구성원이 프로젝트 전체에서 요구 사항과 상호 작용해야하므로 이해 관계자의 요구를 충족시키는 문서 형식을 찾아야하기 때문에 공동 작업 방식으로 주제에 접근해야합니다.그렇게 말되는 모든

, 여기 스크럼을 적용하는 동안 내가 요구 사항을 볼 수 문서화 한 일부 지역의 (내가 왜이 단어는 항상 다음에 별표해야처럼 생각하세요?) :

• PDF 문서
• 게시판
• 위키
• 위키 + 자동 입학 시험 (읽기 : FitNesse를)
• 는 단위
• 수동 테스트 테스트 (읽기 : 엔터프라이즈 설계자 모델)
• 사용자 스토리, 사용 사례 다이어그램을 계획 솔직히
이
• 포스트 - 그것

노트 그리고

화이트 보드를 사무실 주위에

이메일, 그럴 수 없어 어떤 시스템이 다른 프로젝트보다 성공적인 프로젝트와 지속적으로 높은 상관 관계가 있다고 가정 해보십시오. 실제로, 우리는은 총알이 없다고 생각합니다.

HTH, 생각을 자극하는 질문에 감사드립니다!

Answer 4

질문에 대한 제 이해가 완전히 틀렸을 수도 있지만 이해할 수있는 것은 OP가 사용자 이야기와 요구 사항의 불일치로 인해 불편하다는 것입니다. 이유가 있다고 말하고 싶습니다.

제 생각에는 사용자 스토리는 제품 소유자에게 기능의 덩어리가 어떻게 시연되는지 알려줍니다. 이야기의 언어는 제품 소유자가 이해할 수 있지만 주로 개발자가 이해할 수있는 내용입니다. 주인이 직접 요구하지도 않는 것들을 묘사하는 이야기를 들었을 수도 있지만, 실제로있는 것의 고장입니다.

요구 사항은 다른 한편으로는 시스템이 유효하기 위해 수행해야하는 도메인 사용자의 언어로 된 세부 사양입니다. 대부분의 경우 요구 사항 문서는 선택 사항이 아닙니다 (예 : 고정 가격 프로젝트).

내가하는 일은 두 가지를 혼합 한 것입니다. 필자는 요구 사항 문서를 가지고 있으며, 대부분의 스크럼 이야기에서 필자는 하나 이상의 요구 사항 항목과 해당 이야기를 연결하는 메모에 메모를 가지고 있습니다. "FR-042 및 FR-45 참조"(예 : 기능적 요구 사항에 대해서는 FR)와 같이 간단합니다.

Answer 5

스크럼은 필요할 때 필요한 것을 문서화해야한다고 말합니다. 그것은 당신에게 문서가 없어야한다고 말하지 않습니다.

따라서 완제품 (예 : 도움말 문서) 또는 완제품 (예 : 요구 사항 문서)이 필요한 경우 제품 백 로그에 문서 작업/사용자 스토리가 있어야합니다.

그런 다음 해당 작업에 적절한 우선 순위를 지정해야합니다.

주요 내용은 다음과 같습니다.

• 문서 만 무엇 필요, 만 당신이 그것을 필요로 할 때.

Answer 6

당신은 어떻게 든 프로그램의 기능은 문서화되어야한다 사용자 스토리를 가질 수 없습니다. 은 스크럼과 함께 사양 문서로 끝나나요? 그래야만 작업에 시간을 할당 할 수 있습니까?

왜 사용자 스토리가 없습니까? 이 사양 문서는 어떤 용도로 사용됩니까? 이 문서를 만들 때 투자 한 것은 어떤 가치가 있습니까? 이득은 비용을 나가는가? 그렇지 않다면,이 문서를 낭비하고 더 중요한 것은 이러한 문서를 낭비하는 데 소요되는 시간이 아닙니까?

저는 답변을 제공하는 것보다 더 많은 질문을하고 있습니다.하지만 스크럼과 다른 애자일 방식이 기울여야 할 부분이 현재의 사례를 다시 검토하고 여전히 의미가 있는지 확인해야한다고 생각합니다.

사양이있는 경우 기능이 출시되면 누가이 문서를 업데이트하고 유지 관리합니까? 필자가 근무한 대부분의 회사에서 설명서가 희박하거나 오래되었거나 거의 참조되지 않았습니다.

대신 실행 가능 테스트 또는 BDD를 사용하여 설명서가 코드의 일부가되어 실행 가능하도록하십시오. 예를 들어 Ben Mabey's talk on Cucumber

을 참조하십시오. 법규 준수를 위해 특정 유형의 문서가 필요한 경우 팀의 "완료"정의에 항상 추가 할 수 있지만 대부분의 경우 이야기와 테스트는 충분한 문서 형식 이상의 것입니다.

Answer 7

대부분 Todd와 동의하지만, 팀 팀의 업무 중 일부가 문서를 생성하는 경우가있었습니다. 문서는 사용자 스토리 자체 인 PO가 배달되도록 요청되었습니다.

• 우리는 실제 작업 코드 (데이터 구조 또는 구성 파일 내부 건물 모두 사용을 읽을 일반적으로 어떤 문서 생성 프로그램에서 문서를 추출 할 수있는만큼 시도 : 이러한 경우
  우리는 다음과 같은 지침을 따라 실제 프로그램 및 빌드 문서). 독자를
  • 그가 그 문서를 읽고 달성 할 수 있어야합니다
  • 있어야하는데 :
  • 미국이 목표 문서의이 문서에 정의합니다. 쓰기 및 테스트의 일종 수 있도록 쉽게 문서를 만들어 내 경험에

은 (당신이 문서를 읽고는 목표를 고려 ​​OK인지 말을, 일반적으로 사람에게 PO 문의).

Answer 8

시스템의 유효성을 검사하기 위해 문서를 작성합니다. 사용자 스토리는 시스템과의 사용자 상호 작용을 반영하는 형식으로 올바르게 작성된 경우 동일한 목적을 수행합니다. BDD를 사용하고 Gherkin 구문을 사용하여 스토리를 작성하는 것이 좋습니다. 결과적으로 시나리오는 시스템이 올바르게 작동하는지 여부를 확인하는 데 도움이되는 허용 기준이됩니다.

Answer 9

Google 제품에 대한 '사용 설명서'를 작성한 docs 팀이 있습니다. 이 설명서는 제품의 주요 기능과 사용자가 해당 기능에서 수행 할 수있는 작업을 중심으로 구성되어 있습니다.

각 스프린트, 스크럼 팀은 제품 기능에 기능을 추가하는 사용자 스토리에 대해 작업합니다.

스프린트 계획을 마친 후에는 문서 팀이 스크럼 팀과 만나서이 스프린트를 개발할 사용자 스토리를 확인한다. 문서 팀은 초기 문서를 작성하여 지침 설명서를 개선하기 시작합니다. 스프린트가 진행되는 동안 문서 팀은 사용자 스토리의 진행 과정을 따라 테스트 환경에 배포 된 제품을 사용할 수 있습니다. 스프린트가 끝나면 문서 팀은 업데이트 된 사용 설명서를 마무리하고 최종 스크린 샷을 추가합니다.

각 스프린트의 일부로 사용 설명서가 배송됩니다.

Answer 10

여기 몇 가지 다른 것들을 요청할 것입니다. 새 팀 구성원을 추가하는 경우 시스템의 설명서는 온보드 프로세스의 일부로 팀에서의 역할에 맞춰야합니다.

시스템 기능을 문서화하는 경우 우리 조직의 교육 팀은 릴리스의 일부로 기능을 문서화합니다. Sprint Review (데모) 기간 동안 (이해 관계자로서) 참여한 후 발표하기 전에 교육 자료를 준비 할 수있는 새로운 기능을 갖춘 교육 환경을 제공합니다.

당신이 다루기 쉬운 문서를 제공하는 것에 대해 이야기하고 있다면, 귀하의 백 로그는 적절한 프로세스 & 컨트롤이 추가 된 상태로 제공 될 수 있습니다.

이러한 각기 다른 항목은 팀의 요구 사항을 효과적으로 충족시키고 충족시키기 위해 계획 및 신중한 프로세스 개발을 필요로합니다. 문제를 확인하고 시간이 지남에 따라 프로세스를 개발할 때 우리는 회귀 분석에 이러한 항목 각각을 포함 시켰습니다.