프로젝트 시작시 복잡한 스토리 분석

나는 민첩한 프로젝트 관리 (Pivotal Tracker 사용)를 다루려고 노력하고 있지만 프로젝트의 처음 몇 가지 이야기를 정의하려고 할 때 계속 벽에 빠져 있습니다. 이 간단한 이야기를 예로 들어 보겠습니다.

"사용자는 제품에 태그를 지정할 수 있어야합니다"

내가 이미 "제품"을 다른 곳에 정의했다고 가정하면,이 이야기는 아마도 시스템 ID가 완성되면 제품에 태그를 달 수있는 능력을 추가 할 수있는 다형성 태깅 시스템을 작성하는 것과 관련이있을 것입니다.

내 문제는이 이야기에 숨겨져있는 일의 양에 관한 것입니다. 나는 이야기를 끝내기 위해 과제를 정의 할 수 있지만 전체적으로 이야기는 1-2 일 일로되어 있습니까? 나는 빙산의 일각을 드러내는 이야기에 대해서는 옳지 않다. 그러나 그것은 사용자와 관련된 유일한 부분이다.

이런 종류의 것을 어떻게 극복합니까? 모범 사례는 무엇입니까?

UPDATE 25/08 여러분의지도에 감사합니다. 이야기를 정의하는 방법에 대한 모든 조언을 얻었습니다. 이제 스프린트가 시작되면 스토리 내의 과제 (할당, 견적 등)와 개발 과제 추적을 더 잘 지원하는 Jira Grasshopper로 전환하고 있습니다.

당신이 개발자 일 각의 1 ~ 2 일이 될 당신의 이야기를해야 할 경우, 아마 당신은 특정 사용자의 작업으로 각각의 이야기를 중단해야 된다 개발자의 작업 1 ~ 2 일.

다음 "사용자 스토리"를 고려하십시오.

사용자는 구매 한 제품에서 송장을받을 수 있어야합니다.

사용자에게이 기능을 제공 할 때 데이터베이스 디자인과 관련된 내용을 고려하십시오. 고객 테이블, 송장 헤더 테이블 및 송장 개별 항목 테이블이 필요하며 아직 지불 수락에 대해서는 언급하지 않았습니다.

실제로 사용자 스토리는 이처럼 간단하지 않습니다. 완전한 사용자 스토리에는 관련된 사용자 단계에 대한 연습이 포함됩니다.

• 사용자가 장바구니에 제품을 넣음
• 사용자는 수량을 지정합니다
• 사용자는 배송 유형을 지정합니다

등등. 간단히 말해, 사용자 스토리를보다 세밀하게 분류해야합니다.

이야기는 "1-2 일"이어서는 안됩니다. 스크럼에서 스토리는 일반적으로 상대 크기 조정 시스템 인 스토리 포인트를 사용하여 추정됩니다. 당신이 계획 포커 스토리 를 사용 하는 경우 포인트 값이 주어집니다-스토리를 구현하는 데 걸리는 시간은 팀이 설정 한 속도에 따라 다릅니다.

스토리가 복잡성을 숨기고 있다고 생각되면 ( 에픽 스토리 라고 부를 수 있음 ) 스토리를 더 작은 스토리로 나누어야합니다. 새로운 스토리가 INVEST 기준을 준수하는지 확인하십시오 .

그러나 당신은 이것을 지나치게 설계하고 있을지도 모릅니다. YAGNI 의 XP 원칙이 여기에 적용됩니다. 명확하게하기 위해, 실제로 필요한 경우가 아니면 "후드 아래의 다형성 태깅 시스템"을 구현해서는 안됩니다. 그렇더라도 기존 시스템을 개선하여 우수한 테스트 세트로 개발 한 시스템을 설계해야합니다.

이 복잡한 태깅 시스템이 필요하다고 확신한다면 별도의 스토리에서 복잡성을 불러 내야합니다. Mike Cohn은 " 고의적이지만 아직 등장한 " 디자인 방식을 설명합니다.

혼란스러운 이야기와 작업 인 것 같습니다.

사용자 스토리

사용자 스토리는 제품에 추가 될 때 제품에 더 많은 가치를 제공하는 완전한 "기능"입니다.

사용자 스토리는 스프린트 동안 구현할 수있는 것보다 크지 않아야합니다 . 스프린트 계획의 첫 번째 부분에서는 스프린트 중에 작업 할 사용자 스토리를 결정합니다. 스프린트의 목표는 이러한 사용자 스토리를 완성하여 제품에 더 많은 가치를 부여하는 것입니다.

직무

스프린트 계획 단계의 두 번째 부분에서 개발자는 스토리를 작업 으로 나눕니다 . 작업은 개발 작업입니다. "데이터베이스에 열 추가", "서비스 x 확장"등과 같은 작업이 될 수 있습니다. 작업은 하루에 완료 할 수있는 것보다 크지 않아야합니다.

일일 스크럼 동안 이러한 작업의 진행 상황을 평가합니다. 하나 이상의 일일 스크럼에 대한 작업이 진행중인 경우 시간이 너무 오래 걸리며 팀으로서 해당 상황을 해결할 책임이 있습니다.

사용자 스토리는 이해 관계자의 비즈니스 가치를 나타냅니다. 스테이크 보유자는 작업이 아닌 사용자 스토리의 완성에 관심을 가져야합니다.

작업 부서는 개발 팀이 스프린트를 관리하고 스프린트 동안 사용자 스토리의 진행 상황을 모니터링하고 잠재적 인 문제를 시각화하는 도구입니다.

이해 관계자는 이러한 개발 작업에 관심을 가져서는 안됩니다. 불행히도, 특히 애자일 개발에 익숙하지 않은 조직의 경우, 그들이 자주하는 경험입니다. 이 상황을 다루는 것은 다른 문제입니다.

서사시

한 번의 스프린트로 완료 할 수 있다고 생각하는 것보다 사용자 스토리가 더 큰 경우이를 서사시라고합니다. 팀이 작업을 시작하기 전에 여러 개의 작은 사용자 스토리로 나누어야합니다.

사용자 스토리는 최종 사용자에게 가치를 부가하므로 서사시를 "프런트 엔드"와 "백엔드"스토리로 나누는 것은 올바른 방법이 아닙니다. 새 기능에 백엔드를 추가한다고해서 최종 사용자에게 가치가있는 것은 아닙니다.

스프린트 기간 내에 관리 할 수있는 사용자 스토리로 서사시를 나누는 것이 경험이 없을 때 항상 쉬운 것은 아닙니다.

피벗 추적기 사용

Pivotal Tracker는 사용자 스토리를 추적하는 데 유용한 도구라고 생각합니다. 그러나 이것은 스크럼 도구가 아니며 스크럼이 스토리를 작업으로 나누도록 가르치는 방법은 피벗 추적기로 쉽게 처리 할 수 ​​없습니다. 사용자 스토리에 작업을 추가 할 수 있습니다. 그러나 스크럼을 사용하여 프로젝트를 실행하는 경우 스프린트 중 작업 진행 상황을 추적하기 위해 화이트 보드와 스티커 메모를 사용하는 것이 좋습니다.

다형성 태깅 시스템을 구현하려는 설계 목표를 갖는 것은 좋지만 고객이 원하는 기능을 구현하는 데 여전히 중점을 두어야합니다. 이는 세분화 된 사용자 스토리에 의한 세분화 된 사용자 스토리가 시스템이 시간이 지남에 따라 다형성 태깅 시스템을 갖도록 진화되었음을 의미 할 수 있습니다. 그러나 그 여정의 어느 시점에서나 구현 한 User Stories 모음으로 설명되는 작고 테스트 가능한 많은 기능으로 구성된 시스템이 있어야합니다.

이 경우 시스템의 "제품 태깅"처럼 들릴 수 있습니다. 즉, 하나의 사용자 스토리보다 훨씬 크고 약간의 노력으로 몇 개의 작은 스토리로 나눌 수 있습니다. 상당한 양의 예술 라이센스를 취득한 후, 귀하의 요구 사항에 대략 적용 할 수있는 다음과 같은 사용자 스토리를 생각할 수 있습니다.

• 시스템 관리자는 태그 기능을 처음 사용할 때 선택할 수있는 값을 갖도록 유효한 태그가있는 시스템을 시드하려고합니다.
• 시스템 사용자로서 나중에 태그를 지정할 수 있도록 이름으로 제품을 검색 할 수 있기를 원합니다.
• 시스템 사용자는 어떤 태그를 가지고 있는지 결정할 수 있도록 제품 설명을 읽을 수 있기를 원합니다.
• 시스템 사용자는 어떤 태그를 가지고 있는지 결정할 수 있도록 제품 사진을 볼 수 있기를 원합니다.
• 시스템 사용자로서 단일 태그를 단일 제품에 첨부 할 수 있기를 원합니다.
• 시스템 사용자로서 단일 제품에서 단일 태그를 제거 할 수 있기를 원합니다.
• 시스템 사용자로서 단일 태그를 여러 제품에 첨부 할 수 있기를 원합니다.
• 시스템 사용자로서 하나의 제품에 여러 태그를 첨부 할 수 있기를 원합니다.
• 시스템 관리자는 시스템에서 사용중인 고유 한 태그 목록을보고 중복 여부를 결정할 수 있습니다.
• 시스템 관리자는 중복 된 태그를 통합하려고합니다.

... 그리고 나는 갈 수 있었다.

나는 이것들 중 어떤 것이 당신이 그것들을 사용할 정도로 생생하게 될지는 의심하지만, 그들이 당신의 사용자 스토리로 갈 수있는 세부 사항을 보여주기를 바랍니다.

사용자 스토리를 실제로 더 작은 스토리로 세분화 할 수없고 한 번에 구현하기에 너무 큰 것으로 간주되는 경우 수직 스토리로 분할 할 수 있습니다. 이는 각 사용자 스토리에서 기능의 일부만 제공하는 것을 의미하는 기술이지만 각 부분은 기술의 모든 관련 계층을 통해 테스트 가능한 슬라이스입니다 (예 : 웹 사이트의 경우 데이터베이스, 애플리케이션 및 UI 계층 변경). 개별적으로 테스트 할 수 없으므로 데이터베이스 작업에 대한 사용자 스토리, 응용 프로그램에 대한 UI 및 UI에 대한 사용자 스토리를 두지 마십시오.

훨씬 더 예술적인 라이센스를 취하면 "시스템 사용자는 단일 태그를 단일 제품에 첨부 할 수 있기를 원할 것입니다." 다음 세로 조각으로

• 단일 제품을 보는 시스템 사용자는 적용 할 태그를 결정할 수 있도록 태그 목록을 조회 할 수 있기를 원합니다.
• 시스템 사용자가 단일 제품을보고 해당 제품에 적용 할 태그를 결정한 후 적용 할 수 있기를 원합니다.
• 시스템 사용자가 단일 제품을보고 해당 제품에 태그를 적용한 경우 화면에 성공적으로 저장되었음을 알리는 확인 메시지가 필요합니다.

각각의 가치는 테스트 할 수 있습니다.

요구 사항을 설명하고 분류하는 올바른 방법을 찾기위한 목적으로 만 작성된 책이 있습니다. 따라서 쉬운 일이 아닙니다.

종종 개발팀이 가장 간단한 솔루션 대신 복잡한 솔루션을 위해 노력하고 있습니다. 이는 스토리 자체 때문일 수도 있고 팀이이 스토리를 해결할뿐만 아니라 스토리 x, y 및 z의 토대를 마련하는 지나치게 복잡한 솔루션을 원하기 때문일 수 있습니다. 이것은 좋은 의도이지만, 적은 작업으로 동일한 작업을 수행 할 수있는 팽창 범위입니다. 디자인을 망쳐 서 미래 스토리를 망치지 않기 위해 디자인에 얼마나 많은 디자인이 들어가야하는지 판단하는 것은 항상 어려운 일입니다. 이 결정은 팀의 결정입니다.

제품 소유자는 스토리를 더 작은 조각으로 나누는 것에 만 영향을 줄 수 있습니다. 당신은 스스로에게 물어야합니다 : 이야기는 우리가 지금 생각할 수있는 가장 작은 해결책입니까? 언젠가는 "항상 원했던 가장 유연한 태그 시스템"이 될 수있는 기능을 축소 된 기능 세트로 나눌 수 있습니까? 단일 태그에 대한 태그 시스템으로 시작한 다음 사전 선택된 태그 목록을 포함하도록 확장 한 다음 사용자가 태그를 정의 할 수 있도록합니다.

개발자 팀은 다음과 같이 요약합니다. 스토리를 실현하기위한 더 간단한 접근 방법을 찾을 수 있지만 미래의 기능을 손상시키지 않으면서도 오늘날의 작업을 수행하는 견고한 아키텍처를 유지할 수 있습니다.

중간 솔루션을 받아 들일 수 있고 개발 팀이 가장 단순하지만 좋은 솔루션을 제공하려고 시도하면 원하는 스토리의 크기가 적절한 곳 (아주 작을수록 좋음)을 찾을 수 있습니다. . 이것은 당신에게 작은 이야기 만 있다고 말하는 것이 아닙니다. 일부는 다른 것보다 크며, 이는 사실 받아 들여야하거나 너무 큰 경우 이야기를 작은 조각으로 나눕니다.