Akashic Records

User Stories Applied : Chapter 8 릴리즈 계획 본문

오래된글/소프트웨어공학

User Stories Applied : Chapter 8 릴리즈 계획

Andrew's Akashic Records 2018. 4. 18. 13:38
728x90

대부분의 소프트웨어 프로젝트에서는 달에서 여섯 달마다 새로운 릴리즈를 내놓는 것이 가장 좋다. 웹사이트 프로젝트 같은 경우는 이보다 자주 릴리즈하는 경우도 있다. 향후 차례의 릴리즈에 포함될 주용 내용을 정리한 제품 개발 로드맵이 있다면 그것을 바탕으로 릴리즈 계획을 시작할 있을 것이다.


스토리 우선순위 매기기

기술적인 요인보다는 고객과 사용자요구에 의한 내용이 우선시된다.


기술적 요인에 의한 정렬 기준

- 스토리 미완성에 대한 리스크

- 스토리 구현을 늦췄을 다른 스토리에 미치는 영향

고객과 사용자요구에 의한 정렬 기준

- 사용자나 고객 다수가 원하는 정도

- 다수는 아니지만 중요한 사용자나 고객이 바라는 정도

- 다른 스토리와의 응집성

고객이 우선순위를 매기는 것을 어려워한다면, 그것은 스토리를 나눌 필요가 있음을 의미할지도 모른다. 스토리를 나누면 고객은 나뉜 스토리에 우선순위를 다르게 매길 있게 된다.


리스크 높은 스토리

애자일 접근법은 수지에 맞는 부분을 먼저 개발하는 쪽에 속한다. 애자일 프로젝트는 너무 빨리 리스크를 해결하려는 시도를 피하고, 필요하지 않을지도 모를 기반구조 코드를 작성하는 것을 미루도록 한다. 또한 수지에 맞는 부분을 선호하는 것은 프로젝트에서 가장 가치가 높은 기능이 준비되자마자 바로 릴리즈하는 것을 가능하게 한다.

수지에 맞는 부분을 먼저 개발한다 하더라도, 여전히 스토리의 우선순위를 결정할 리스트를 고려해야 한다. 일반적으로 개발자들은 가장 리스크가 높은 스토리를 먼저 개발하고자 하는 경향을 보인다. 가끔은 이렇게 하는 것이 적절하지만, 결정은 고객이 내려야 한다. 그리고 고객은 우선순위를 매길 개발자들에게 얻는 정보를 고려한다.


이터레이션 길이 선택

  • 이터레이션 길이는 대체로 1주에서 4 정도가 적당하다.

  • 이터레이션이 짧으면 프로젝트의 방향을 자주 수정할 있고, 진척 상황에 대한 가시성도 확보하기 쉽다. 하지만 이터레이션마다 오버헤드가 조심 발생하게 된다.

  • 너무 이터레이션보다는 너무 짦은 이터레이션이 낫다.

  • 가능하면 프로젝트를 진행하는 동안 이터레이션 길이를 일정하게 유지하도록 한다. 이터레이션 길이를 일정하게 유지함으로써, 프로젝트는 자연스러운 리듬을 있으며, 이러한 리듬은 팀이 개발 페이스를 지속하는데 도움이 된다.


초기 속도

  • 이전 프로젝트에서 사용한 속도를 사용하는 것이 가장 좋은 선택이다.

  • 이터레이션을 진행하여 속도를 구하는 방법은 차선이다.

  • 이전 프로젝트도 없고, 이터레이션을 진행해볼 없는 경우 스토리 점수 1점이 이상적 작업일 1일로 정의되어 있다고 , 이상적인 작업일 1일분의 작업을 하는데 실제로 며칠이 걸리는지 추정하여 본다. 여러 방해요소들을 감안하여 보면 대략, 1/3~1/2 사이에서 속도를 선택하게 된다.


릴리즈 계획 생성하기

스토리 점수가 모두 100점인 프로젝트에서 이터레이션당 20점의 속도를 추정하였다면 다음과 같이 릴리즈 계획을 생성한다.

  1. 고객과 개발자가 함께 우선순위가 가장 높은 스토리부터 선택하여 스토리 점수 합계가 20점이 되도록 한다.

  2. 선택한 스토리들을 이터레이션에 할당한다.

  3. 다음 20점은 번째 이터레이션에 할당하고 다음 이터레이션에도 같은 방법으로 할당한다.


728x90
Comments