애자일 프로젝트에서 요구 사항 관리는 장기적으로 어떻게 작동합니까?

애자일 프로젝트의 단기 요구 사항 관리는 해결 된 문제인 것 같습니다.

Scrum 각도에서 새로운 요구 사항 또는 기존 요구 사항에 대한 변경 사항은 사용자 사례를 통해 제공됩니다. 또한 Epic 또는 Feature로 그룹화 된 사용자 스토리는 더 복잡한 요구 사항을보다 쉽게 ​​전달할 수 있습니다.

물론 사용자 스토리는 기술적으로 요구 사항 문서가 아닙니다. 관리가 용이 ​​한 작업 그룹으로, 종종 기능 의 수직 슬라이스 라고하는 것에 매핑됩니다 . 그리고 이러한 이야기의 범위는 AC (Acceptance Criteria)를 사용하여 명확하게 정의 할 수 있습니다.

따라서 사용자 사례는 공식적인 요구 사항은 아니지만이를 탐색하면 기본 요구 사항에 대한 명확한 아이디어를 얻을 수 있습니다. 단기적으로.

프로젝트가 진행됨에 따라 사용자 스토리 수가 증가하기 때문에 단기적으로 말합니다. 따라서 요구 사항을 찾기 위해 계속 증가하는 스토리 목록을 탐색하면 시간이 지남에 따라 효율성이 떨어집니다.

이 문제는 이전 사례를 확장하거나 대체하거나 무효화하는 사용자 사례를 고려할 때 더욱 복잡해집니다.

이제 프로젝트의 개발 반복 (생산 안정성) 사이에 2 년의 간격이 있다고 상상해보십시오. 원래 팀은 사라졌고 모든 지식도 마찬가지입니다.

원래의 팀이 이것이 일어날 것이라는 것을 알고 있다면 (예를 들어, 비즈니스의 특성), 후속 팀을 돕기 위해 어떤 조치를 취할 수 있습니까?

물론 백로 그는 몇 가지 정보를 제공하지만 쉽게 찾아 볼 수없는 형태는 아닙니다.

그럼, 이후 팀을 포함하여 프로젝트의 상태를 이해하는 데 도움이 할 수있는 이유 와 어떻게 거기있어?

내 경험상 다음과 같은 일이 작동하지 않습니다.

• 백 로그 를 요구 사항 문서로 읽을 수 있도록 이전 사용자 스토리를 삭제하거나 업데이트하는 백 로그 정리 .
• 팀 구성원이 시스템의 현재 상태를 문서화하는 작업을 수행하는 스프린트 입니다.
• 행동 테스트를 통한 문서화 . 이 접근법은 내가 일하는 것에 가까이 온 유일한 방법입니다. 불행하게도, 코드 동작 테스트는 이름 지정 문제의 희생자입니다. 테스트는 시스템을 올바르게 문서화 할 수 있지만 변동하는 개발자 팀이 동일한 도메인 용어, 단어 및 스타일에 따라 테스트를 작성하도록하는 것은 거의 불가능합니다.

다시 말하면 :

애자일 프로젝트 요구 사항을 장기적으로 어떻게 관리합니까?

이것은 민첩한 프로젝트가있는 방에서 무언의 코끼리 인 것 같습니다 : 어떻게 혼란에 빠지지 않도록합니까?

애자일 선언문을 잠시 살펴 보자. 민첩한 욕망 :

1. 조기 연속 배송
2. 변화하는 요구 수용
3. 작동하는 소프트웨어를 자주 제공
4. 매일 함께 일하는 개발자와 비즈니스 이해 관계자
5. 동기 부여 된 개인을 중심으로 프로젝트를 구축하고, 필요한 환경과 지원을 제공하며, 업무를 완수하도록 신뢰
6. 의사 소통의 기본 모드 인 대면 대화
7. 진행의 주요 척도로서 작동하는 소프트웨어
8. 지속 가능한 개발
9. 우수한 기술과 우수한 디자인에 대한 지속적인 관심
10. 단순성-수행 할 필요가없는 작업 최대화
11. 팀은 정기적으로보다 효과적인 방법을 반영한 다음 그에 따라 행동을 조정하고 조정합니다.

마지막 4 개를 강조했습니다. 왜? 그것들은 자체 무게로 프로젝트가 붕괴되는 것을 막을 수 있기 때문입니다.

지속 가능한 개발이란 전체 개발 프로세스를 감독하는 사람, 소프트웨어를 한 번에 조금씩 성장시키는 것 이상으로 배를 조종 할 수있는 사람, 전체 프로젝트에 대한 전반적인 비전을 가진 사람, 예리한 지식을 가진 사람이 있음을 의미합니다. 소프트웨어 아키텍처, 시스템 설계, 비즈니스 로직 원칙 및 UI 인체 공학 다시 말해, 건축가.

건축가는 "여러분이 요청한 것을 알고 있습니다. 그러나이 다른 것을 만들면 혼란스럽고 핵심 요구 사항에 중점을 둔 다른 세 가지 기능을 피할 수 있습니다."라고 말합니다. 그는 팀에게 기술 부채를 줄일 시간을주는 사람입니다. 그는 프로젝트에 중요한 구조와 조직을 제공하는 사람입니다. 그는 팀이 모이는 회의를 소집하고 "어떻게 더 잘할 수 있습니까?"

그리고 그는 마스터 요구 사항 문서를 유지 관리하는 사람입니다.

요구 사항 프로세스 마스터 링 책 에서 저자는 토끼, 말 및 코끼리와 같은 세 종류의 고객, 세 종류의 소프트웨어 프로젝트가 있다고 주장합니다 . 토끼는 비공식적 인 요구 사항 만 필요한 소규모 소프트웨어 프로젝트입니다. 소규모 스프린트에서 고객과 직접 작업하고 프로젝트의 범위가 합리적으로 제한되며 소프트웨어가 비교적 짧은 시간 내에 완료됩니다. 코끼리는 많은 사전 계획, 엄청난 양의 문서 및 오랜 시간이 필요한 거대한 프로젝트입니다. 민첩하게 구축 할 수있는 소규모 프로젝트로 분리 할 수는 있지만 민첩하지는 않습니다.

민첩한 관점에서 다소 혼란스러운 말 프로젝트입니다. 그것들은 여전히 ​​반복적으로 구축 될 수 있으며 짧은 스프린트를 계속 사용할 수 있지만 요구 사항 수집 및 계획 프로세스에 약간의 규칙이 없으면 레일에서 쉽게 벗어날 수 있습니다. 이들은 규율 된 요구 사항 수집 프로세스를 통해 혜택을 얻을 수 있고 프로젝트가 진행됨에 따라 요구 사항을 신중하게 조정 및 수정하면서도 전체 프로젝트에 대한 전반적인 비전을 유지하는 프로젝트입니다.

개인적 관점에서 저는 약 12 ​​명의 개발자로 구성된 소규모 팀과 협력합니다. 어느 시점에서든 우리는 수천 줄의 코드에서 100,000 개가 넘는 3 개의 소프트웨어 프로젝트를 동시에 진행하고있을 것입니다. 고객은 자신이 토끼라고 생각하지만 실제로는 말입니다. 고객이 참여하고 있지만 매일 참여하지는 않습니다.

지금까지 가장 취약한 영역은 구체적이고 테스트 가능하며 측정 가능한 요구 사항을 수집하고 프로젝트 범위와 관련된 고객의 기대를 관리하는 것입니다. 그러나 우리는 그 일을하고 있습니다.

이 질문은 완전히 명확하지는 않지만 요구 사항 추적 가능성에 관심이있는 것 같습니다 . 내 경험에서 Agile에서 길을 잃는 경향이있는 한 가지 아이디어는 비즈니스 요구 사항 은 고객이 원하는 시스템 요구 사항 이며, 사용자 사례 는 실제로 시스템 작동 방식을 나타내는 기능적 요구 사항 입니다 . "사용자로서 X를 할 수 있기를 원합니다." 그러나 이는 사용자 사례에서 손실 될 수있는 요구 사항을 충족시키기 위해 수행됩니다.

내 경험에서 잘 작동하는 것은 비즈니스 요구 사항과 사용자 스토리를 양방향으로 연결하는 것입니다. BR # 1은 스토리 A와 B로 실현 될 수 있습니다. 스토리 C는 BR # 2와 # 3을 포괄 할 수 있습니다. 사용중인 모든 것을 프로젝트 트래커, 스프레드 시트에 넣습니다.

이는 장기적으로 고객이 요구하는 사항 (BR)을 시스템이 수행하는 내용 (이야기)과 연결하여 해당 요구 사항을 달성하는 데 도움이됩니다. 이 문서는 누구에게도 필요하지 않은 최신 문서를 작성하지 않는 애자일 마인드를 유지하면서 유지하기가 쉽지 않은 최소한의 문서 여야합니다.

또한 새로운 프로젝트 참여자들이 소프트웨어가 왜 그 일을하는 지에 대한 역사를 얻기 위해 검토 할 것이 있기 때문에 속도를 높일 수있는 방법을 제공합니다 .

실제로 원래 개발자가 더 이상 사용할 수없는 큰 웹 상점의 간반 유지 관리 프로젝트에서 일하고 있습니다.

모든 userstory / requirement / bugfix에는 ticketnumber가 있으며 모든 sourcecode-change는 sourcecontrol-comment-field 필드의 ticketnumber에 연결됩니다.

sourcecontrol-checkin-s (svn)는 코어 응답 티켓을 비정상적으로 업데이트하여 티켓에 모든 sourceconrtol-changesets에 대한 링크가 있습니다.

모듈 / 함수가 새로 구현되면 소스 코드에도 티켓 번호가 있습니다.

티켓 시스템 (redmine)에서 티켓은 (중복, 버그, 개선 등) 서로 연결되어 있습니다.

따라서 티켓을 따라 가면서 시간이 지남에 따라 요구 사항이 변경되는 것을 볼 수 있습니다.

예 : "orderConfirmation-Web-page"에서 무언가를 변경해야합니다. 페이지의 소스 코드에서 ''4747 '에 대해 생성 된'주석이 표시되므로 새 티켓을 이전 티켓 "4711"또는 후속 티켓 중 하나에 연결할 수 있습니다.

개인적으로, 나는 사용자 스토리를 시스템이 할 수있는 것에 대한 문서 소스로 버립니다. 문서를 작성하기위한 적극적인 단계를 거치지 않은 경우 (우리는 일부 기존 클라이언트에 대해 수행 한) 응용 프로그램 기반은 실제로 가장 좋은 문서입니다.

그러나 그것은 새로운 것이 아닙니다.

보다 규모가 큰 Agile 버전 (예 : SAFe )을 사용하는 경우 구현 백 로그가 아닌 다른 백 로그가 있습니다. 기본적으로 다음과 같습니다.

1. 포트폴리오 잔고 (소설 및 예산의 전략적 계획)
2. 프로그램 / 릴리스 백 로그 (기능 및 에픽)
3. 프로젝트 / 팀 백 로그 (스토리, 스파이크, 버그)

팀 백 로그 수준의 문서화는 권장하지 않습니다. 너무 세밀하고 아무도 그 수준의 세부 사항으로 가고 싶어하지 않습니다. 팀 백 로그의 이전 스토리와 모순되는 릴리스 내에 스토리가있을 수 있습니다.

대신 릴리스 백 로그 레벨에서 릴리스 레벨 문서를 제공하는 것이 좋습니다. 이러한 이야기는 특정 릴리스에 할당 된 후에는 거의 발생하지 않으며, 특정 릴리스에서 진행중인 작업을 안정적이고 빠르게 검토 할 수 있습니다.