#2 고객 중심의 요구사항 기법 - 사용자스토리: 추정과 계획하기

2부 추정과 계획

 

{나의 현실}

추정과 계획하기는 항상 접할 때마다 어려운 부분이다. 애자일 방법론에서 가장 중요한 것이 자기조직화이다. 이는 구성원 각각이 책임을 지고 행하기에 믿고 진행해야 하는 부분이 꽤 크다. 또한, 문제의 원인을 누군가 개인에 부과하거나 비판을 하는 것이 아니라 팀에 할당하여 팀이 문제해결의 책임을 지고 모두 함께 고민하여 문제를 해결해나가야 한다. 기존 프로젝트 관리 기법에서 프로젝트매니저가 지시자의 역할이 컸다면, 애자일 방법론에서는 조정의 역할이 더 크다. 기존의 프로젝트 관리기법에 익숙하다 보니 자칫 간섭이 되어 자기주도적으로 나아가야 하는 팀을 수동적인 팀을 만들 수 있다는 점에 조심스럽고, 그렇게 믿고 맡기기에 범위 대비 추정일정이 너무 길게 나오는 문제 사이에서 고민이 되기도 한다. 일단 시작 시점이니, 우리 팀의 속도를 아는 것이 중요하다는 점에 최대한 개발자의 의견을 수렴하고 있는 상태다.

 

작은 벤처기업에서는 "고객, 애널리스트, 개발자, 테스터, 프로젝트 관리자, UX 디자이너, 데이터베이스 관리자, 시스템 관리자, 기술문서 담당자, 교육 훈련 전문가로 역할"을 분명히 구분할 만큼 인력 풀이 구성되어 있지 않다. "애자일 관리 기법에서도 제너럴리스트를 찾는 것이 좋은 대안임을 말하고 있기는 하다." 일이 되게끔 여러 역할을 해내면서 속도를 내기 위해서 구성원의 능력과 마인드에 많이 달려 있다는 점에 좋은 제널리스트를 찾아야 하는 어려움은 늘 남아 있는 것 같다. 

 

<글 일부인용 : 애자일마스터 조너선라스무슨 지음/최보나 옮김>

---

사용자스토리 추정

스토리를 추정할 때는 스토리 점수를 이용

스토리 점수는 스토리의 복잡도, 작업량, 혹은 작업 기간에 대한 상대적 추정치

스토리 추정은 팀 전체가 해야 하며, 추정치는 개인이 아닌 팀에 할당

추정치를 다른 추정치들과 비교하는 삼각측량 이용

 

개발 팀이 짝 프로그래밍의 채택여부가 점수 추정에 영향이 없다. 다만, 팀의 속도에 영향을 끼친다.

 

개발자

스토리 점수를 팀에 맞도록 정의할 책임이 있다.

한 번 정의한 내용을 일관되게 적용할 책임이 있다.

정직하게 추정할 책임이 있다.

팀 전체가 함께 추정 작업을 진행할 책임이 있다.

추정치를 일관되게 유지할 책임이 있다. 모든 2점짜리 스토리는 비슷한 크기여야 한다.

 

고객

추정회의에 참여할 책임이 있다. 질문에 답하고, 스토리를 명확하게 하는 것이 목적이다.

추정은 고객이 하는 것이 아니다.

 

릴리즈계획

대부분의 소프트웨어 프로젝트에서는 두 달에서 여섯 달마다 새로운 릴리즈를 내놓는 것이 가장 좋다. 웹 사이트 프로젝트 같은 경우는 이보다 더 자주 릴리즈하는 경우도 있다. 

 

어떤것들을 포함시킬 것인가? - 고객의우선순위 - MoSCoW 규칙(Must-have, Should-have, Could-have, Won't-have)

스토리우선순위 매기기 - 리스크 < 가치, 기반구조에 대한 가치 고려, 1번 2번 3번과 같은 명확한 우선순위 부여

이터레이션길이 선택 - 보통 1~4주

스토리 점수로부터 예상 기간 산정

초기속도 측정 - 이전 프로젝트에서 사용한 값, 첫 이터레이션을 진행하면서 얻은 값, 어림잡은 값

릴리즈계획 생성하기 

 

개발자

고객이 우선순위를 매길 때 필요한 정보를 제공

기반구조, 아키텍처에 필요이상의 우선순위 매기지 않도록 자제

적정 수준의 프로젝트 버퍼를 포함한 현실적 추정치를 근거로 릴리즈 계획

 

고객

사용자 스토리가 명확한 순서를 갖도록 우선순위를 부여 

릴리즈 데드라인에 솔직할 것

이상적 작업 일정과 달력상의 일정의 차이를 이해

우선순위가 다른 내용이 혼합되어 있는 스토리는 나눌 것

속도가 1.0보다 낮은 개발자를 질책하거나 비난해서는 안되는 이유를 알 것 

 

 

이터레이션계획

스토리에 대해 토의하고 작업 나누기

스토리는 작업단위로 나누면 추정이 쉽다.

작업마다 개발자 한 명이 책임을 맡는다.

개발자는 자신이 맡은 업무를 추정함으로써 과도한 이행 약속을 하지 않는지 점검한다.

 

개발자

이터레이션 계획회의에 참여

자신이 맡은 스토리외에도 모든 스토리의 작업단위를 나누는 과정에 참여

자신이 개발할 작업의 책임

적당한 작업량을 맡았음을 확실히 할 책임

이터레이션 동안 자신의 작업량외에 동료의 작업량을 관찰하고 함께 완성할 책임

 

고객

이터레이션에 포함될 스토리들의 우선순위 결정

비즈니스 가치를 이끌어내도록 개발자에게 방향 제시

이터레이션 계획에 참여

 

속도 측정 및 모니터링

속도를 결정할 때는 인수 테스트가 통과된 완료된 스토리만 대상이다.

실제속도와 계획속도의 차이를 모니터링할 수 있는 그래프 작성

한 두번의 이터레이션으로 속도의 경향 예측하지 말 것

스토리를 완료하는데 소요된 실제 시간은 속도와 관계없다.

크고 눈에 띄는 차트를 모두가 볼 수 있는 공간에 붙이기

- 누적 스토리 점수 차트 - 각 이터레이션 종료시점까지 완료된 스토리 총 점수 확인

- 이터레이션 소멸 차트 - 진행상황 및 계획된 스토리 점수 변경 반영

- 일일소멸차트 - 한 이터레이션 진행 중에 매일 남은 작업 시간을 확인

- 스토리 점수당 결함 - 속도 증가로 인해 결함이 늘어나는지 확인

 

개발자

다음 스토리로 넘어가기 전에 현재 스토리를 완료

차트를 읽고 해석하는 방법을 이해

 

고객

차트를 읽고 해석하는 방법을 이해

팀의 속도를 알아야 함

실제 속도와 계획 속도를 비교하고 계획을 언제 수정해야 할지 알아야 함

프로젝트 목적이 주어진 제약 조건에 부합하도록 릴리즈에 스토리를 추가 또는 제외

---

<사용자스토리 마이크 콘 지음/한주영.심우곤.송인철 옮김 책 내용 요약>

1부 사용자스토리 시작하기

2부 추정과 계획

3부 자누 논의하는 주제

4부 예제