답변:
첫째, @DXM의 대답에서 Agile에 대한 나의 경험과 특히 Scrum에 대한 나의 경험과 거의 일치하지 않습니다.
애자일 선언문은 포괄적 인 문서가 가치있는 동안, 소프트웨어를 작업하는 더 가치가 있다고 주장한다. 따라서 문서화는 반드시 나쁜 것은 아니지만 실제로 작동하는 소프트웨어를 만드는 데 사용되어야합니다.
프로세스 및 도구에 대한 개인 및 상호 작용
포괄적 인 문서에 대한 작업 소프트웨어
계약 협상을 통한 고객 협업
계획에 따라 변경 에 응답
즉, 오른쪽에있는 항목에는 가치가 있지만 왼쪽에있는 항목은 더 중요하게 생각합니다.
코딩을 시작하기 전에 모든 세부 사항을 정리하는 것이 반복적으로 낭비되는 것으로 입증되었으므로 문서는 일반적으로 JIT (적시에) 처리됩니다. 즉, 실제로 코딩하려는 내용을 문서화합니다.
Scrum을 수행하는 일반적인 방법 중 하나는 제품 소유자가 유지 관리하고 제품 백 로그에 보관되는 사용자 사례를 사용하는 것입니다. 제품 백로 그는 솔루션이 수행해야하는 모든 작업에 대한 상당히 높은 수준의 목록이며 일반적으로 사용자 사례는 목록의 각 항목을 설명 할 수있는 좋은 방법입니다. 사용자 스토리는 필수 사항은 아니지만 세부 정보를 과장하지 않고 공동 작업에 영감을주는 좋은 방법 인 것 같습니다.
어쨌든, 팀이 승인 기준을 충족하는 것을 만들어 테스트하고 배포 한 스토리가 완료되면 스토리는 척박하지 않으며 단순히 백 로그에 표시됩니다. 따라서 백 로그에는 몇 가지 표시가 있습니다. 각 스프린트에서 수행 된 작업-스토리와 관련 포인트. 이것이 속도를 계산할 수있게 해주 며, 그 자체로 중요한 문서입니다.
즉, 사용자 사례는 요구 사항을 이해하는 데 필요한 모든 문서 일 수 있지만 고객과 개발 팀간에 대화를 생성하는 것입니다. 따라서, 그 대화를 위해 할 수있는 일이 많이 있습니다. 대 면적 인 임시 작업 인 경우 분석가 / 개발자는 조직에 따라 결정 사항을 적어 위키 또는 A와 같은 어딘가에 저장할 수 있습니다 (가능하면 조직에 따라) 문서 저장소. 이메일 대화 인 경우 이메일을 저장할 수 있습니다. 화이트 보드 세션 인 경우 모바일로 보드 사진을 찍어 저장하십시오. 요점은 이러한 것들이 코드를 완성하는 데 도움이되는 것이며 나중에 어떻게 또는 왜 그렇게했는지 알아 내야 할 경우 도움이 될 수 있습니다.
요구 사항을 캡처하는 또 다른 방법은 요구 사항을 즉시 테스트 사례에 포함시키는 것입니다 (DXM이 얻은 것입니다). 어쨌든 각 요구 사항을 테스트해야한다는 점에서 이것은 실제로 효율적일 수 있습니다. 이 경우 테스트 툴에 요구 사항을 효과적으로 저장할 수 있습니다.
이야기가 완성되고 받아 들여지고 사용자가 자신의 필요를 바꾸면 새로운 이야기를 만들어야 할 것입니다. 문서에 위키를 사용하는 경우 새 스토리를 원본에 다시 연결하고 원래 스토리를 새 항목에 연결하여보고있는 사람이 변경 사항을 알 수 있습니다. Wiki의 좋은 점입니다. 링크를 쉽고 간단하게 연결할 수 있습니다. 테스트 중심 접근 방식을 수행하는 경우 변경 사항을 처리하기 위해 테스트 사례를 업데이트하거나 새 스토리와 기존 스토리가 상호 배타적이지 않은 경우 새 스토리에 대한 새 테스트 케이스를 작성합니다.
결국, 그것은 당신의 필요에 달려 있습니다. 가장 중요한 것은 사람들이 빠르게 속도를내는 것이라면 누군가를 돕기 위해 온 보딩 문서를 작성하는 것이 좋습니다. 누군가 그렇게하도록하세요. 앞에서 언급했듯이 Wiki는 이러한 종류의 작업을 유지하는 데 유용한 도구이므로 Confluence Wiki를 Jira 및 Greenhopper와 통합하여 스토리 / 작업 / 결함을 추적하고 프로젝트를 일반적으로 관리 할 수있는 Atlassian 솔루션 을 고려할 수 있습니다. 선택할 수있는 다른 도구들도 많이 있습니다.
[업데이트 # 1] @MatthewFlynn이 지적했듯이, 민첩성에 대한 그의 경험과 많은 다른 사람들 (나 자신을 포함하여)은 내가 여기서 제공하는 답변과는 매우 다릅니다. 여기에 대한 대답은 과거에 내 팀에서 작동하지 않았던 것과 작동하지 않은 것에 대한 관찰 결과, 주제에 대해 읽은 많은 책과 블로그와 결합한 것입니다 ...
민첩한 개발을 향한 추진의 대부분은 구체적으로 요구 사항 문서를 제거하는 것을 목표로합니다.
애자일은 대부분의 문서를 없애려고 노력하지만 나는 그들의 아이디어에 동의하지만 모든 문서에서 요구 사항은 가장 큰 황소의 눈으로 그려져 있습니다. 그 이유 (IMO)는 요구 사항 문서가 실제 작업 코드와 모든 문서에서 가장 멀리 떨어져 있기 때문에 요구 사항이 발생하기 때문입니다.
팀이 다음에 개발해야 할 사항을 안내하기 위해 애자일은 요구 사항 문서를 다음 우선 순위가 높은 항목에 대해 작업해야 할 작업을 식별하는 스토리 백 로그로 대체합니다. 그 목록에서.
그러나 백 로그를 요구 사항 문서와 혼동해서는 안됩니다.
스토리가 완료되면 해당 스토리는 백 로그에서 제거되고 CHUCKED (1) 됩니다. 다시 이야기는 요구 사항이 아닙니다. 그들은 팀에게 다음에 무엇을해야 할지를 알려줍니다. 그들은 역사적 기록이 아닙니다.
그러나 적절한 민첩한 프로세스에서 작업을 수행 할 때마다 해당 배달의 일부는 단위 / 통합 / 수락 테스트 여야합니다. 이 테스트는 많은 목적을 가지고 있기 때문에 매우 가치가 있습니다. 전체 목록에 들어가지는 않지만 그 목적 중 하나는 현재 프로덕션 소프트웨어에 대한 설명서입니다.
테스트는 특정 입력 및 전제 조건에서 소프트웨어가 어떻게 동작해야하는지 문서화합니다. 또한 코드의 공개 (및 내부) API를 사용하는 방법도 설명합니다. 또한 새로운 개발자가 팀에 들어와 실수로 무언가를 부 수면 체크인하자마자 오류가 발생하도록 안전망 역할을합니다.
애자일 프로세스는 가능한 한 자동화 된 단위 테스트를 최대한 활용하는 것을 촉진하지만 모든 단일 항목을 자동화 할 수있는 것은 아닙니다. 소프트웨어 제품군에는 항상 수동으로 실행해야하는 일련의 테스트가 있습니다. 그러나 a) 개발자는 가능한 한 많은 자동화 작업을 적극적으로 수행해야합니다. b) QA 팀은 수동으로 일련의 테스트를 정기적으로 실행하여 가능한 빨리 기능 중단을 발견해야합니다.
(1) - "고정 된"부분에 대한 몇 가지 응답을 얻었으므로. 민첩하게 이사 한 지 5 년 만에 팀은 일정을 잡고 연기 한 다음 잊어 버린 이야기의 30 %조차도 한 가지 이야기 만 버리지 않았습니다. 내 상사는 그것들을 "참조"로 유지하고 싶었지만 아무도 그 이야기를 본 적이 없다.
사람들은 일반적으로 자신의 데이터에 첨부되어 있으며 이미 가지고 있으면 무언가를 버리는 것이 어렵다는 것을 알고 있지만 (물리적이든 전자적이든) 인벤토리를 보유하는 것은 무료가 아니며 더 많이 생각할수록 더 동의합니다. "척"으로. 이것은에서이다 "애자일 소프트웨어 요구 사항 : 팀, 프로그램, 및 기업을위한 린 요구 사항의 사례"(p.190) . - "사용자 이야기 안전하게 즉, 경량을 유지 그들에게 친화적 인 팀을 유지 구현 후 폐기 될 수 있으며, 협상을 촉진하지만 응용 프로그램 수명 동안 승인 테스트가 계속됩니다 ... "
사용자 스토리가 나중에 변경되면 어떻게 업데이트되고 이슈로 유지됩니까? 많은 팀이 원래 이야기를 추적하는 대신 새로운 티켓 / 기능 요청 / 버그 보고서를 여는 것을 보았습니다.
민첩한 스토리를 사용하든 큰 선행 문서를 사용하든 관계없이 모든 문서를 관리 하는 것은 어려울 수 있으며, 부담을 줄이려면 테스트 및 구현에 대한 노력과 일치하도록 문서를 최소화하고 업데이트해야합니다. 그러나 OP가 암시 한 것처럼 단순히 문서를 업데이트하면 소프트웨어가 시간이 지남에 따라 어떻게 진화했는지에 대한 기록을 잃을 위험이 있습니다.
이것이 정말로 중요합니까? 때때로 가능할 수도 있습니다. 대부분의 경우 현재의 테스트 및 코드 자체와 함께 스토리 / UML / 무엇을보고 싶습니까?하지만 기능이 특정 방식으로 구현 된 이유에 대한 질문이 제기 될 때 종종 옵션 Y 대신 구현 옵션 X 가 선택된 이유에 대한 명확한 그림을 그리기 위해 시간이 지남에 따라 기능이 어떻게 변경되었는지 확인하기 위해 기록을 보는 데 유용합니다 .
이러한 아티팩트를 추적 할 수있는 몇 가지 방법이 있습니다. 더 나은 옵션 중 하나는 스토리를 소스 코드의 버전 관리와 유사한 방식으로 스토리 텍스트를 버전화할 수있는 도구로 스토리를 유지하는 것입니다. Wiki는 이것에 매우 능숙하며 Trac 또는 Redmine 과 같은 프로젝트 / 문제 관리 도구도 있습니다.이 시스템 내 위키 페이지뿐만 아니라 이슈 자체에 대한 변경 이력을 유지합니다. 그러나 새로운 스토리 나 이슈가 오래된 관련 이슈 및 스토리와 어떤 방식으로 연결되어 있는지 확인함으로써 이슈에서 기능으로의 변화를 추적하는 기능을 향상시키기 위해 조금 더 나아가게됩니다. 새로운 이슈 / 스토리의 텍스트에 이전 이슈 / 스토리 ID를 추가하는 것만 큼 간단 할 수 있지만, 버전 관리 시스템을 변경할 때마다 체크인 이슈에 이슈 또는 스토리 ID를 포함시켜 크게 개선 할 수 있습니다. . 그러나 커밋이 빈번하고 단일 스토리 또는 이슈로 제한되는 경우이 방법이 가장 유용합니다.
물론 가장 어려운 점은 이러한 유형의 접근 방식은 모든 팀 구성원이 일관되고 일관성있게 노력하고 커밋을 작고 자주 유지하고 스토리 및 / 또는 이슈 / 프로젝트 추적 시스템을 관리하는 사람들이주의를 기울여야한다는 점입니다. 구현의 현재 상태와 이전에 발생한 모든 변경 사항 사이의 링크를 제공하는 아티팩트 위에.
이전에 언급되었지만 그 요점은 다음과 같습니다.
요구 사항은 여러 측면을 포괄 할 수 있으며 일반적으로 둘 이상의 스토리를 초래합니다.
스토리는 스프린트의 시간 범위 내에 맞출 수있을 정도로 작은 덩어리로 팀의 작업을 구성합니다.
특정 기능이 올바르게 작동하기 위해서는 많은 세부 사항이 정의되어야하는 경우가 종종 있습니다. 이는 명확성, 공통 이해 및 나중에 참조 할 수 있도록 이러한 정의를 별도의 요구 사항 문서에 보관하는 것이 유용 해지기 시작한 시점입니다.
전설적인 온라인 애완 동물 상점 예를 고려하십시오.
프리 마인드 를 사용 하여 기능 목록을 수집 할 수 있습니다 . 어떻게 완료 되었습니까? 이 자습서를 살펴보십시오 (가운데 어딘가에 있음).
기능 목록이 있으면 사용자 스토리를 작성합니다. 간단한 텍스트 파일이나 워드 문서 또는 민첩한 관리 도구 처럼 복잡한 것을 사용하면됩니다 .
사용자 스토리를 마치면 우선 순위가 높습니다. 나중에 사용자 스토리에서 사람들은 작업을 생성하고 사람들은 작업을 코드로 구현합니다.
이 모든 것은 민첩한 비디오 캐스트 시리즈 의 가을에 처음부터 ac # 프로젝트가 어떻게 관리되는지 볼 수 있습니다 .