애자일 팀의 요구 사항 문서를 어떻게 추적합니까?


22

User Stories가 민첩한 세계를 지배한다는 것을 알고 있지만 이러한 아티팩트는 어떻게 저장되어 팀에 합류하는 새로운 개발자가 요구 사항을 신속하게 처리 할 수 ​​있습니까?

사용자 스토리가 나중에 변경되면 어떻게 업데이트되고 이슈로 유지됩니까? 많은 팀이 원래 이야기를 추적하는 대신 새로운 티켓 / 기능 요청 / 버그 보고서를 여는 것을 보았습니다.


1
최고의 문서는 작업 코드입니다
Robert Wagner

답변:


11

첫째, @DXM의 대답에서 Agile에 대한 나의 경험과 특히 Scrum에 대한 나의 경험과 거의 일치하지 않습니다.

애자일 선언문은 포괄적 인 문서가 가치있는 동안, 소프트웨어를 작업하는 더 가치가 있다고 주장한다. 따라서 문서화는 반드시 나쁜 것은 아니지만 실제로 작동하는 소프트웨어를 만드는 데 사용되어야합니다.

프로세스 및 도구에 대한 개인 및 상호 작용

포괄적 인 문서에 대한 작업 소프트웨어

계약 협상을 통한 고객 협업

계획에 따라 변경응답

즉, 오른쪽에있는 항목에는 가치가 있지만 왼쪽에있는 항목은 더 중요하게 생각합니다.

코딩을 시작하기 전에 모든 세부 사항을 정리하는 것이 반복적으로 낭비되는 것으로 입증되었으므로 문서는 일반적으로 JIT (적시에) 처리됩니다. 즉, 실제로 코딩하려는 내용을 문서화합니다.

Scrum을 수행하는 일반적인 방법 중 하나는 제품 소유자가 유지 관리하고 제품 백 로그에 보관되는 사용자 사례를 사용하는 것입니다. 제품 백로 그는 솔루션이 수행해야하는 모든 작업에 대한 상당히 높은 수준의 목록이며 일반적으로 사용자 사례는 목록의 각 항목을 설명 할 수있는 좋은 방법입니다. 사용자 스토리는 필수 사항은 아니지만 세부 정보를 과장하지 않고 공동 작업에 영감을주는 좋은 방법 인 것 같습니다.

어쨌든, 팀이 승인 기준을 충족하는 것을 만들어 테스트하고 배포 한 스토리가 완료되면 스토리는 척박하지 않으며 단순히 백 로그에 표시됩니다. 따라서 백 로그에는 몇 가지 표시가 있습니다. 각 스프린트에서 수행 된 작업-스토리와 관련 포인트. 이것이 속도를 계산할 수있게 해주 며, 그 자체로 중요한 문서입니다.

즉, 사용자 사례는 요구 사항을 이해하는 데 필요한 모든 문서 일 수 있지만 고객과 개발 팀간에 대화를 생성하는 것입니다. 따라서, 그 대화를 위해 할 수있는 일이 많이 있습니다. 대 면적 인 임시 작업 인 경우 분석가 / 개발자는 조직에 따라 결정 사항을 적어 위키 또는 A와 같은 어딘가에 저장할 수 있습니다 (가능하면 조직에 따라) 문서 저장소. 이메일 대화 인 경우 이메일을 저장할 수 있습니다. 화이트 보드 세션 인 경우 모바일로 보드 사진을 찍어 저장하십시오. 요점은 이러한 것들이 코드를 완성하는 데 도움이되는 것이며 나중에 어떻게 또는 왜 그렇게했는지 알아 내야 할 경우 도움이 될 수 있습니다.

요구 사항을 캡처하는 또 다른 방법은 요구 사항을 즉시 테스트 사례에 포함시키는 것입니다 (DXM이 얻은 것입니다). 어쨌든 각 요구 사항을 테스트해야한다는 점에서 이것은 실제로 효율적일 수 있습니다. 이 경우 테스트 툴에 요구 사항을 효과적으로 저장할 수 있습니다.

이야기가 완성되고 받아 들여지고 사용자가 자신의 필요를 바꾸면 새로운 이야기를 만들어야 할 것입니다. 문서에 위키를 사용하는 경우 새 스토리를 원본에 다시 연결하고 원래 스토리를 새 항목에 연결하여보고있는 사람이 변경 사항을 알 수 있습니다. Wiki의 좋은 점입니다. 링크를 쉽고 간단하게 연결할 수 있습니다. 테스트 중심 접근 방식을 수행하는 경우 변경 사항을 처리하기 위해 테스트 사례를 업데이트하거나 새 스토리와 기존 스토리가 상호 배타적이지 않은 경우 새 스토리에 대한 새 테스트 케이스를 작성합니다.

결국, 그것은 당신의 필요에 달려 있습니다. 가장 중요한 것은 사람들이 빠르게 속도를내는 것이라면 누군가를 돕기 위해 온 보딩 문서를 작성하는 것이 좋습니다. 누군가 그렇게하도록하세요. 앞에서 언급했듯이 Wiki는 이러한 종류의 작업을 유지하는 데 유용한 도구이므로 Confluence Wiki를 Jira 및 Greenhopper와 통합하여 스토리 / 작업 / 결함을 추적하고 프로젝트를 일반적으로 관리 할 수있는 Atlassian 솔루션 을 고려할 수 있습니다. 선택할 수있는 다른 도구들도 많이 있습니다.


답을 정확하게 인용하면 도움이 될 것입니다.
EL Yusubov

@ElYusubov 어떤 정확한 인용문? 민첩한 선언?
Matthew Flynn

@Mathew, 나는 언급 된 따옴표를 추가했습니다.
EL Yusubov December

@ MatthewFlynn : 내 정보의 대부분은 개인적인 경험에서 나온 것이 아니라 민첩한 개발에 관한 책과 블로그를 모두 읽은 것입니다. 노트를 비교할 수 있습니다. 저의 개인적인 경험도 스크럼되었습니다. 이전 회사에서는 스크럼을 사용하여 5 개의 릴리스를 수행했으며 그 중 4 개는 전혀 효과가 없었습니다. 단순히 "스크럼을하는"회사의 위험은 대부분의 장소가 "스 크럼프"또는 "카고 컬트"애자일을하게된다는 것입니다. 우리 그룹은 확실히 꽤 오랫동안 그렇게했습니다. 그리고 네, 우리는 ... 잔고가 있었다
DXM

1
@DXM-나는 또한 Scrum과 혼합 된 결과를 얻었지만 전통적인 SDLC보다 결코 나쁘지 않고 몇 번 훌륭하게 작동했습니다.
Matthew Flynn

8

[업데이트 # 1] @MatthewFlynn이 지적했듯이, 민첩성에 대한 그의 경험과 많은 다른 사람들 (나 자신을 포함하여)은 내가 여기서 제공하는 답변과는 매우 다릅니다. 여기에 대한 대답은 과거에 내 팀에서 작동하지 않았던 것과 작동하지 않은 것에 대한 관찰 결과, 주제에 대해 읽은 많은 책과 블로그와 결합한 것입니다 ...

민첩한 개발을 향한 추진의 대부분은 구체적으로 요구 사항 문서를 제거하는 것을 목표로합니다.

애자일은 대부분의 문서를 없애려고 노력하지만 나는 그들의 아이디어에 동의하지만 모든 문서에서 요구 사항은 가장 큰 황소의 눈으로 그려져 있습니다. 그 이유 (IMO)는 요구 사항 문서가 실제 작업 코드와 모든 문서에서 가장 멀리 떨어져 있기 때문에 요구 사항이 발생하기 때문입니다.

  • 가장 정확한
  • 유지하기 어려운
  • 가장 유용한

팀이 다음에 개발해야 할 사항을 안내하기 위해 애자일은 요구 사항 문서를 다음 우선 순위가 높은 항목에 대해 작업해야 할 작업을 식별하는 스토리 백 로그로 대체합니다. 그 목록에서.

그러나 백 로그를 요구 사항 문서와 혼동해서는 안됩니다.

  • 백 로그에서 N 개의 스토리 만 상세하게 채워야합니다. 스토리를 더 많이 내릴수록 상세하게 적어야합니다 (즉, 반년 동안 일어나지 않을 무언가를 정의하는 데 시간을 낭비하지 마십시오) ).
  • 특정 시점을 넘어서서, "요구 사항"품목이 2 회 이상의 릴리스주기 (일명 잠재적 선적 가능 증분 (PSI)) 이상인 경우 백 로그에 배치해서는 안됩니다. 요구 사항이 중요하고 어느 시점에 완료되어야한다는 것을 알고 있더라도이를 백 로그에 추가하려는 유혹에 저항하십시오. 그것이 정말로 중요하다면, 누군가 다음 릴리스에서 그것을 기억할 것입니다. 아무도 그것을 기억하지 않는다면, 아마도 그렇게 중요하지 않았기 때문일 것입니다.

스토리가 완료되면 해당 스토리는 백 로그에서 제거되고 CHUCKED (1) 됩니다. 다시 이야기는 요구 사항이 아닙니다. 그들은 팀에게 다음에 무엇을해야 할지를 알려줍니다. 그들은 역사적 기록이 아닙니다.

그러나 적절한 민첩한 프로세스에서 작업을 수행 할 때마다 해당 배달의 일부는 단위 / 통합 / 수락 테스트 여야합니다. 이 테스트는 많은 목적을 가지고 있기 때문에 매우 가치가 있습니다. 전체 목록에 들어가지는 않지만 그 목적 중 하나는 현재 프로덕션 소프트웨어에 대한 설명서입니다.

테스트는 특정 입력 및 전제 조건에서 소프트웨어가 어떻게 동작해야하는지 문서화합니다. 또한 코드의 공개 (및 내부) API를 사용하는 방법도 설명합니다. 또한 새로운 개발자가 팀에 들어와 실수로 무언가를 부 수면 체크인하자마자 오류가 발생하도록 안전망 역할을합니다.

애자일 프로세스는 가능한 한 자동화 된 단위 테스트를 최대한 활용하는 것을 촉진하지만 모든 단일 항목을 자동화 할 수있는 것은 아닙니다. 소프트웨어 제품군에는 항상 수동으로 실행해야하는 일련의 테스트가 있습니다. 그러나 a) 개발자는 가능한 한 많은 자동화 작업을 적극적으로 수행해야합니다. b) QA 팀은 수동으로 일련의 테스트를 정기적으로 실행하여 가능한 빨리 기능 중단을 발견해야합니다.


(1) - "고정 된"부분에 대한 몇 가지 응답을 얻었으므로. 민첩하게 이사 한 지 5 년 만에 팀은 일정을 잡고 연기 한 다음 잊어 버린 이야기의 30 %조차도 한 가지 이야기 만 버리지 않았습니다. 내 상사는 그것들을 "참조"로 유지하고 싶었지만 아무도 그 이야기를 본 적이 없다.

사람들은 일반적으로 자신의 데이터에 첨부되어 있으며 이미 가지고 있으면 무언가를 버리는 것이 어렵다는 것을 알고 있지만 (물리적이든 전자적이든) 인벤토리를 보유하는 것은 무료가 아니며 더 많이 생각할수록 더 동의합니다. "척"으로. 이것은에서이다 "애자일 소프트웨어 요구 사항 : 팀, 프로그램, 및 기업을위한 린 요구 사항의 사례"(p.190) . - "사용자 이야기 안전하게 즉, 경량을 유지 그들에게 친화적 인 팀을 유지 구현 후 폐기 될 수 있으며, 협상을 촉진하지만 응용 프로그램 수명 동안 승인 테스트가 계속됩니다 ... "


요구 사항과 사용자 스토리의 차이점을 OP에 지적한 경우 +1
Frank

나는 단지 내 팀과 이전 팀이 이야기 "척수"가 아니라고 덧붙이고 싶습니다. 우리는 참고 용으로 보관합니다.
Simon Whitehead

@SimonWhitehead : 당신이 그 의견을 말한 유일한 사람이 아니기 때문에 내 대답을 업데이트했습니다. 우리 팀은 결코 하나의 이야기를 버리지 않았습니다. 그렇다면 지난 2 년 동안 과거로 돌아가서 그 오래된 이야기를 참조하기 위해 얼마나 자주해야 했습니까? 그리고 어떤 정보를 얻었습니까? Bob Martin ( books.google.com/… )이 설명한 내용 (특히 사용자 사례 섹션의 세 번째 단락) 과 비교 한 스토리의 세부 사항은 어떻습니까?
DXM December

... 우리 팀은 항상 모든 것을 유지했지만 우리 이야기에는 세부 사항이 없었으므로 여전히 그 이야기가 어떤 가치를 제공했는지 이해하지 못하지만 다른 많은 사람들처럼 내 상사는 아무것도 버리지 않는 것에 대해 매우 단호했습니다.
DXM

수락 테스트는 문서화 된 테스트 사례처럼 들립니다. 내가 맞습니까, 아니면 실제 실행 가능한 테스트입니까?
Didier A.

1

사용자 스토리가 나중에 변경되면 어떻게 업데이트되고 이슈로 유지됩니까? 많은 팀이 원래 이야기를 추적하는 대신 새로운 티켓 / 기능 요청 / 버그 보고서를 여는 것을 보았습니다.

민첩한 스토리를 사용하든 큰 선행 문서를 사용하든 관계없이 모든 문서를 관리 하는 것은 어려울 수 있으며, 부담을 줄이려면 테스트 및 구현에 대한 노력과 일치하도록 문서를 최소화하고 업데이트해야합니다. 그러나 OP가 암시 한 것처럼 단순히 문서를 업데이트하면 소프트웨어가 시간이 지남에 따라 어떻게 진화했는지에 대한 기록을 잃을 위험이 있습니다.

이것이 정말로 중요합니까? 때때로 가능할 수도 있습니다. 대부분의 경우 현재의 테스트 및 코드 자체와 함께 스토리 / UML / 무엇을보고 싶습니까?하지만 기능이 특정 방식으로 구현 된 이유에 대한 질문이 제기 될 때 종종 옵션 Y 대신 구현 옵션 X 가 선택된 이유에 대한 명확한 그림을 그리기 위해 시간이 지남에 따라 기능이 어떻게 변경되었는지 확인하기 위해 기록을 보는 데 유용합니다 .

이러한 아티팩트를 추적 할 수있는 몇 가지 방법이 있습니다. 더 나은 옵션 중 하나는 스토리를 소스 코드의 버전 관리와 유사한 방식으로 스토리 텍스트를 버전화할 수있는 도구로 스토리를 유지하는 것입니다. Wiki는 이것에 매우 능숙하며 Trac 또는 Redmine 과 같은 프로젝트 / 문제 관리 도구도 있습니다.이 시스템 내 위키 페이지뿐만 아니라 이슈 자체에 대한 변경 이력을 유지합니다. 그러나 새로운 스토리 나 이슈가 오래된 관련 이슈 및 스토리와 어떤 방식으로 연결되어 있는지 확인함으로써 이슈에서 기능으로의 변화를 추적하는 기능을 향상시키기 위해 조금 더 나아가게됩니다. 새로운 이슈 / 스토리의 텍스트에 이전 이슈 / 스토리 ID를 추가하는 것만 큼 간단 할 수 있지만, 버전 관리 시스템을 변경할 때마다 체크인 이슈에 이슈 또는 스토리 ID를 포함시켜 크게 개선 할 수 있습니다. . 그러나 커밋이 빈번하고 단일 스토리 또는 이슈로 제한되는 경우이 방법이 가장 유용합니다.

물론 가장 어려운 점은 이러한 유형의 접근 방식은 모든 팀 구성원이 일관되고 일관성있게 노력하고 커밋을 작고 자주 유지하고 스토리 및 / 또는 이슈 / 프로젝트 추적 시스템을 관리하는 사람들이주의를 기울여야한다는 점입니다. 구현의 현재 상태와 이전에 발생한 모든 변경 사항 사이의 링크를 제공하는 아티팩트 위에.


1

이전에 언급되었지만 그 요점은 다음과 같습니다.

  • 요구 사항은 여러 측면을 포괄 할 수 있으며 일반적으로 둘 이상의 스토리를 초래합니다.

  • 스토리는 스프린트의 시간 범위 내에 맞출 수있을 정도로 작은 덩어리로 팀의 작업을 구성합니다.

  • 특정 기능이 올바르게 작동하기 위해서는 많은 세부 사항이 정의되어야하는 경우가 종종 있습니다. 이는 명확성, 공통 이해 및 나중에 참조 할 수 있도록 이러한 정의를 별도의 요구 사항 문서에 보관하는 것이 유용 해지기 시작한 시점입니다.

전설적인 온라인 애완 동물 상점 예를 고려하십시오.

  • 이야기는 "사용자로서 영수증에 부가가치세 (VAT)가 인쇄되기를 원합니다 ..."라고 말할 수 있습니다. 이제 부가가치세 (부가가치세) 계산은 복잡한 문제 일 수 있으며이 이야기에서 제시하는 것보다 더 많은 작업이 필요할 수 있습니다.
  • 부가가치세 계산을 요청하는 추가 사례가있을 수 있지만 (예 : 총 판매액에 부가가치 세율을 곱함 ) 해당 계산의 모든 변형을 포함하지는 않을 것입니다.
  • 처음에 팀은 기본 모듈을 제공하는 데 중점을 두었습니다. 예를 들어 상품 목록과 판매 가격을 가져오고 VAT 금액을 반환하는 것과 같습니다. 그것은 스프린트 시간 내에 팀이 달성 할 수있는 것입니다.
  • 부가가치세 계산의 모든 가능한 경우를 다루는 더 많은 이야기가있을 것입니다.
  • 단일 스프린트 전반에 걸쳐 다양한 VAT 계산 규칙을 ​​계속 표시하려면 VAT를 계산하는 다양한 방법을 모두 나열한 별도의 요구 사항 문서를 유지하는 것이 좋습니다. 이 문서는 시간이 지남에 따라 발전 할 수 있습니다. 사실, 새로운 섹션을 추가하는 것은 이야기를 완성하는 작업의 일부가 될 수 있습니다.

요구 사항 문서가 개발 과정에서 작성되고 코드의 실제 작업에 대한 문서로 사용 된 다음 요구 사항 목록을 제공한다는 점에서 @Matthew Flynn과 일치하는 것처럼 들립니다.
Didier A.

"... 개발에 따라 작성"-나에게 너무 더 시끄러운 소리. 명확히하기 위해 요구 사항은 부산물이 아니며 효율적인 구현을위한 전제 조건입니다. 그러나 민첩한 프로젝트에서는 요구 사항이 다음 개발 라운드를 구현하는 데 필요한 정도로만 작성됩니다. 그렇게하는 형식은 정의에 따라 범위가 제한되어 구현에 필요한 시간이 스프린트에 맞는 사용자 스토리 입니다. 이것을 다음 단계로 진행하기 전에 세부 사항으로 지정된 폭포 형 프로젝트와 대조하십시오.
miraculixx

요구 사항이 내가 동의하는 사용자 사례와 동일하지 않다고 말했기 때문에 확실하지 않습니다. 필자는 요구 사항을 비즈니스 로직의 정확한 세부 사항으로 생각합니다. 이는 사용자 스토리가 원하는 상태이며 이는 더 비슷합니다. 그래서 나는 당신의 의견을 이해하지 못합니까? 귀하의 예에서는 한 번에 하나씩이 아니라 하나씩 VAT 요건이 하나씩 제공 될 것입니다.
Didier A.

IMHO 사용자 스토리와 같은 요구 사항이 원하는 상태를 지정하지 않으면 시작하기에 어떤 이점이 있는지 잘 모르겠습니다. 실제로 부가가치세 (VAT) 예에서, 후속 스프린트에서 여러 사용자 스토리가 연속적으로 지정되고 전달 될 것이다. 확실하게 민첩한 방법으로 팀이 VAT 계산 규칙 전체를 한곳에 문서화하는 것을 막을 수 있습니다. 단지에 대한 완전하고 포괄적 인 요구 사항을 완벽하게 작성하는 데 시간을 앞당기는 데 아무런 소용이 없습니다. 어쨌든 개발자 팀이 한 번에 모든 것을 구현할 수없는 이유.
miraculixx

여전히 혼란 스럽습니다. 답변의 첫 번째 요점은 사용자 스토리가 요구 사항과 동일하지 않다는 것입니다. 다가오는 스프린트에 대한 요구 사항을 캡처하는 모든 스프린트의 시작 부분에 다른 문서가 작성되었다고 말하십니까?
Didier A.

0

프리 마인드 를 사용 하여 기능 목록을 수집 할 수 있습니다 . 어떻게 완료 되었습니까? 이 자습서를 살펴보십시오 (가운데 어딘가에 있음).

기능 목록이 있으면 사용자 스토리를 작성합니다. 간단한 텍스트 파일이나 워드 문서 또는 민첩한 관리 도구 처럼 복잡한 것을 사용하면됩니다 .

사용자 스토리를 마치면 우선 순위가 높습니다. 나중에 사용자 스토리에서 사람들은 작업을 생성하고 사람들은 작업을 코드로 구현합니다.

이 모든 것은 민첩한 비디오 캐스트 시리즈가을에 처음부터 ac # 프로젝트가 어떻게 관리되는지 볼 수 있습니다 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.