원제 : Agile Estimating and Planning

마이크 콘 지음

---

아래는 11/17 기획팀 스터디로부터 나온 이야기..

애자일은 뭐가 조은가? 시간이 덜 걸리나? no. 하기 쉬운가? no. 그저, 변화에 적절히 대응하기에 좋은 방법론이다. 그리고 병목을 줄여서 효율화하고, 직군간의 협업을 장려하여 좀더 좋은 프로덕트를 만들 수 있다는 믿음. 하지만 후자에 대한 설득 논리는 믿음에서, 지혜로부터 나오는 것이기에...

 

애자일 방법론은 소프트웨어 개발자들만 있나? 기획이나 디자인에서도 애자일한 방법론을 찾아내야 한다. 더더군다나 RIA 시대에 이런 니즈는 갈수록 커지고 있따능. - Alankang

 

아래는 저자의 서문에서 발췌...

애자일 개발자들은 이렇게 말하는 사람들이다.

우리는 바로 지금 우리가 알고 있는 사실에 근거하여 계획을 내놓습니다. 우리는 고객이 가장 중요하다고 생각하는 목적에 맞추어 계획을 수정합니다. 우리는 고객과 우리가 함께 배우고 성장할 수 있도록 계획을 수정합니다.  우리는 고객 여러분도 우리와 마찬가지로 '애초의 계획에 부합하도록 프로젝트를 진행하는 것'과 '계속 변화할 수 밖에 없는 비즈니스 상황에 유연하게 대처하도록 하는 것'이 서로 양립하기 힘든 상반된 입장이라는 것을 이해할 수 있었으면 합니다.

 

문제는 계획주도와 애자일이라는 용어를 대립시키다 보니 애자일 팀이 계획이라는 것을 전혀 세우지 않는 집단인 것으로 느껴지게 되었다는 점이다. (중략..) 계획(Planning)은 애자일 프로젝트의 엄연한 일부로서 존재한다는 것. ...(중략)
1. 애자일 팀은 굉장히 많은 계획을 수립하고, 그 수립과정은 프로젝트 과정 전반에 균등하게 배분되어있다.
2. 애자일 팀은 비-애자일 팀이 무시하곤 하는 결정적인 문제, 즉 불확실성에 정면으로 도전한다.
프로젝트 초기에 비정상적으로 빨리 수립된 계획이 무너지는 것은 용인하면서도, 불확실성에 맞서기 위한 좀더 현실적인 대안들을 내놓는 사람들을 '계획에 적응하지 못하는'사람이나, '팀플레이 정신이 없는'사람으로 매도하는 조직들을 수도 없이 보아왔다.

 

애자일 추정법과 계획법은 가치 전달의 문제에 집중할 뿐만 아니라, 개발 팀과 사업 담당자들 간의 신뢰를 구축하는 방법을 제시한다.

문제, 그리고 목표^#

무엇을 위해 계획하는가?^#

불확실성 원추의 지름은 시간이 지날수록 줄어든다.

• 왜? 어차피 불확실성은 어쩔 수 없는 거라면, 추정이나 계획은 왜 해야하는것일까?
  계획을 한다는 것은 - 점진적으로 계획을 만들고 개선시켜나가는 그 과정은 - 가치를 창조하는 과정이다. 질문에 대한 최적의 해답을 찾으려는 시도이다.

  • 기능, 자원, 일정의 세가지 요소를 고려해야

  • 바람직한 계획 프로세스의 요건

    1. 위험성을 감소시킨다
    2. 불확실성을 감소시킨다
    3. 의사결정과정을 지원한다
    4. 신뢰를 구축한다
    5. 정보를 전달한다
• 좋은 계획을 만드는 요소 : 프로젝트 개발기간의 추정이 불확실할 수록 좋은 계획의 유용성이 떨어진다.

• 계획 과정을 애자일하게 만드는 것

  • 계획 자체보다 과정에 집중할 것
  • 변화를 장려할 것
  • 변경이 쉬운 계획을 만들어낼 것
  • 프로젝트 전 과정에 걸쳐 균등하고 지속적으로 적용될 것

이런 계획법은 실패한다.^#

전통적인 계획법의 문제 :

• 2/3가량의 프로젝트는 추정된 비용 이상으로 많은 돈이 든다. (Lederer와 Prasad, 1992)
• 최종 제품에 포함된 기능들 중 64% 가량은 거의 혹은 결코 쓰이지 않는다 (Johnson, 2002)
• 평균적인 프로젝트는 계획된 일정을 두 배 정도 초과한다. (Standish, 2001)

• 활동이냐 기능이냐 : 전통적 계획법은 고객에게 가치를 전달하는 단위인 기능이 아니라, 활동에 집중한다.

  • 활동이 일정보다 일찍 끝나지 않는다. : 파킨슨의 법칙. 시간이 주어진 만큼 다른 일을 하게 되는데, 문제는 이 다른일은 고객에게 아무런 가치를 주지 못한다는 점.
  • 한 활동의 지연은 뒤이은 활동에 영향을 준다.

  • 활동들은 서로 독립적이지 않다

    • 비슷한 일거리 여러개를 놓고 그중 하나를 하다가 늦어진 경우 보통 우리는 이렇게 말한다. '네, 이번엔 늦었습니다. 하지만 나머지는 더 빨리 할 수 있을테니, 곧 따라잡을 수 있습니다.' 왜 나머지를 더 빨리할 수 있단 말인가? 첫 번째 작업을 하면서 나머지 작업들을 처리하는데 필요한 지식을 얻었기 때문이다. 그러나 이런 상황에서 진짜 중요한 지식은, 어떤 활동을 마치는데 드는 시간이 예상보다 길어질 경우, 비슷한 다른 활동들도 예상보다 오래 걸리게 될 가능성이 높아진다는 것이다.

• 멀티태스킹은 또 다른 지연을 발생시킨다. : 2개 이상의 멀티태스킹은 생산성을 떨어뜨린다.

  • 팀원들에게 자신의 능력을 100% 발휘할 것을 주문하고 그에 맞춰 계획을 마련하는 것은 마치 수용 능력에 한계가 있는 고속도로에 100% 꽉 차게 차량을 밀어넣는 것과 마찬가지로 미련하다.

• 우선순위에 따른 기능 개발이 이루어지지 않는다. : 개발팀의 편의대로 하다보면, 일정이 늦어졌을때 고객에게 가치를 전달하기 어렵다..

• 불확실성을 무시한다 :

  • 전통적인 계획법에서는 불확실성을 무시하고, 막연해 보이는 작업에 정량적인 추정치('2주')를 붙여두고는 그대로 일이 진행되어 나갈 것이라고 믿는 척한다. (..중략) 한 방법은, 프로젝트 마감일을 범위 형태로 표현하는 것이다. 6월~8월 사이에 인도한다. 이런 식으로 말이다. (하략)

    불확실성을 제어하는 가장 좋은 방법은, 반복(iteration)이다.

• 추정치가 서약으로 변한다

애자일 접근법^#

Agile Manifesto :

• 프로세스나 도구보다는 개인과 그들 간의 상호작용을 중시
• 포괄적인 문서보다, 제대로 돌아가는 소프트웨어를 만드는것을
• 계약 협상보다는 고객과의 협력을
• 계획을 주어진대로 따르기보다는 변화에 대응하는 쪽을 택한다.

 

다층적인 계획 과정

: 목표를 설정하고 수정할 때에는 우리는 수평선 너머를 볼 수 없으며 그 지점을 넘어서까지 계획을 시도하면 계획의 정확도는 급감하게 된다는 사실을 기억하라.

릴리즈 > 이터레이션 > 오늘

규모 추정^#

스토리 점수를 이용한 규모 추정^#

• 스토리 점수는 상대적이다 :
  스토리 점수는 그 스토리의 규모, 크기를 나타낸다. 규모를 계산하는 공식 따윈 없다. 오히려, 추정치는 그 기능을 개발하기 위해 드는 노력의 양과 개발 복잡도, 그리고 내재된 위험성 등을 한데 모아 표현한 값이다.
  젤 작은 걸 1로, 중간값을 5로 max를 10으로 지정한다.
• 속도
  스토리 점수를 사용한 추정의 미덕은, 노력의 추정과 기간의 추정을 별개의 일로 만들 수 있다는 점이다.

이상적 작업일을 이용한 추정^#

• 이상적 시간과 소프트웨어 개발
• 이상적 작업일을 이용한 규모 추정
• 추정치는 하나만

추정의 기술^#

• 추정치의 공유
• 추정치의 범위와 값
• 추정치 이끌어 내기
• 플래닝 포커
• 플래닝 포커가 효과적인 이유

재추정 **^#

추정하는 값은 sp나 이상적 시간이며, 구현에 드는 시간과 직결되지 않는다. 따라서 특정 스토리의 상대적 규모에 변동이 있는 경우에만 재 추정을 해야 한다.

• SwimsStats 웹 사이트
• 재 추정을 하면 안되는 이유
• 언제 재추정을 해야 하는가
• 부분적으로 완료된 스토리에 대한 재 추정 :
  완료되지 않은 스토리에 대해서는 점수를 해당 이터레이션에서 주지 않는다. 다만 생각보다 너무 크기가 크다거나 한 경우, 해당 스토리만 재추정한 후, 다음 이터레이션에서 달성하게 되면, 점수를 더 많이 획득한다.
• 재 추정의 목적 :
  failure to learn is the only true failure

스토리 점수와 이상적 작업일^#

• 스토리 점수의 장점
• 이상적 작업일의 장점
• 추천

가치 창조를 위한 계획 과정^#

테마 간 우선순위 결정^#

• 우선순위 산정에 고려해야 할 요소들

  1. 가치 : 해당 기능의 사업적/재정적(금전적) 가치 (-> 사용자들의 선호도와 관련있음)
  2. 비용 : 해당 기능을 구현하거나 지원하는데 드는 비용 (-> 시간)
  3. 지식 : 해당 기능을 구현하기 위해 배워야 할 지식이나 구현 과정에서 새롭게 창출되는 지식의 양과 그 중요성
     (제품에 대한 지식:최종 불확실성, 프로젝트에 대한 지식: 수단 불확실성)
     애자일 접근에서는 최종불확실성을 프로젝트 초기에 완전히 제거하기 어렵다는 사실을 인정한다. 제품의 일부를 고객에게 보여준 연후에, 피드백을 받고 의견들을 가다듬어 계획을 조정한다.

  4. 위험 : 해당 기능을 구현함으로 인해 제거되는 위험 요소의 양
     위험이란, '발생할 가능성이 있으나 아직 발생하지는 않았으며, 발생할 경우 프로젝트의 성공을 위협하거나 제한할 가능성이 있는 무엇'
     위험성이 높은 기능과 높은 가치를 갖는 기능들 중 어떤 것에 집중할 것인가를 놓고 많은 고민을 하게 된다.
     위험성이 높은 기능에 집중하면, 아무 필요 없거나 낮은 가치를 지닌 일이 될수도.
     높은 가치를 가진 기능에 집중하면, 최종 제품의 인도 일정을 위협할만한 위험 요소를 프로젝트 막바지에 가서야 발견하게 될수도.
     둘다 고려하라!
     

     • 일정 위험 : 10월까지 못 끝낼 수도 있다.
     • 비용 위험 : 하드웨어를 적정가에 구매 못할 수도 있다. 예산이 딸릴 수도 있다.
     • 기능 위험 : 그 기능을 구현 못할 수도 있다.
     • 기술적 위험 vs. 사업적 위험
• 네가지 요소를 함께 고려하려면

• 사례들

  • 인프라스트럭쳐 : 가치면에서는 그닥 이지만, 비용면에서는 나중에 하는것보다 비용이 절감된다.

  • 사용자 인터페이스 설계  : 애자일 관점에서는 UI설계는 이터레이션 안에서 이루어져야한다고 이야기하지만, UI전반을 프로젝트 초기에 생각해둔다면, 사용성이 향상된다는 반론도 있다.

    • 지식관점 : UI를 초기에 설계하는 것은 제품에 대한 새로운 지식을 창출한다. 이 지식은 다시 팀으로 하여금 높은 가치를 갖는 제품을 만들수있게 해준다.
    • 위험성 관점 : UI를 초기부터 설계하면, 엉뚱한 제품을 만들게 될 위험성이 감소하게 되는 일이 많다. 중요한UI기능의 우선순위를 높게 조정하면, 유용한 사용자 피드백을 좀더 일찍 수집할 수 있게 된다.
    • 비용 : 대부분의 경우 비용은 줄지 않는다.
    • 따라서, UI중 중요한 유저피드백을 빨리 얻을 수 있는 주요기능에 대해서는 좀더 우선순위를 높여두는 것이 좋다.

    • 애 자일 관점을 따를 경우, 사용자 인터페이스 설계는 그에 관련된 기능들이 구현될 이터레이션 안에서 이루어져야 한다고 이야기하곤 한다. 반면, 설계자가 사용자 인터페이스 전반을 프로젝트 초기에 미리 생각해 볼 경우 시스템의 사용성이 향상된다는 반론도 있다.

      우 선 지식 관점에서 먼저 생각해보자. 사용자 인터페이스를 설계하고 구현하는 작업이 새로운 지식을 창출하는가? 그렇다면 관련 작업 중 일부를 앞쪽에 배치하는 것이 좋을 것이다. 핵심적인 사용자 인터페이스 컴포넌트나 사용자의 작업 흐름 모델(navigational model)과 관련된 부분의 경우에는 분명 제품에 대한 새로운 지식을 창출한다고 말할 수 있다. (...omitted...)

      이번에는 위험성 관점에서 생각해보자. 사용자 인터페이스를 개발하는 과정이 위험을 감소시키는가? 아마 기술적인 측면에서는 그렇지 않을 것이다(Ajax 등 현대적인 RIA 기술을 사용한다면 그럴 수 있다. --AlanKang, Year2008). 하지만 사용자 인터페이스와 관계된 기능들을 우선적으로 개발하다 보면 프로젝트를 위협하는 가장 심각한 위험 요소인 엉뚱한 제품을 만들게 될 위험성이 감소하게 되는 일이 많다. 중요한 사용자 인터페이스 기능을 부각시킬 기능들의 우선순위를 높게 조정하면, 사용자 피드백을 좀 더 일찍 수집할 수 있게 된다.

      마지막으로 비용을 고려해보자. 비용이 상당 수준 감소된다면 사용자 인터페이스 구현 일정을 앞당기는 것이 가능할 것이다. 하지만 대부분의 경우 사용자 인터페이스의 구현 일정을 앞당긴다고 비용이 줄어들거나 하지는 않는다.

      --p128~129

재정적 우선순위^#

경험에 비추어 보건데, 정량화할 수 없는 이득은 아예 없는 셈 쳐야 한다. - Tom DeMarco, Timothy Lister (peopleware의 저자)

비용 대비 이익에 근거하여 우선순위를 매기는 방법

미팅 참석자들끼리 아래의 표와 같이, 향후 2년 동안의 분기별 수익을 추정해본다.

분기	개발 비용 (하단 참고)	신규수익	증분수익	유보수익	운영효율성	순 현금 수지
1	- 87,750	0	0	2,000	0	-85,750
2
3
4
5
6
7
8
(추정방법)		분기별 신규 고객의 수를 추정 --> 고객 한명당 예상 수익을 추정	기존 서비스를 이용하던 고객 중, 새로운 기능을 이용하게 될 고객 X명을 분기별로 목표치를 정하고, 이들이 유발하는 수익을 추정한다.	분기당 몇명 정도의 서비스 해지(이탈)를 막을 수 있을 것인지 추정	고용하지 않아도 되는 직원의 수 * 통상노동비용(급여+기타비용)	분기별 현금 잔액
합계

• 수익의 원천

  • 신규 수익 : New Revenue. 새로운 고객으로부터 오는 완전히 새로운 수익

    • 분기별 신규 고객의 수를 추정 --> 고객 한명당 예상 수익을 추정

  • 증분 수익 : Incremental revenue. 기존 고객으로부터 얻는 새로운 수익

    • 기존 서비스를 이용하던 고객 중, 새로운 기능을 이용하게 될 고객 X명을 분기별로 목표치를 정하고, 이들이 유발하는 수익을 추정한다.

  • 유보 수익 : Retained Revenue.  고객 이탈을 막아 생기는 수익. 프로젝트 혹은 테마에 대한 개발이 이루어지지 않을 때 발생하는 수익상의 손실. 안하면 손해인경우.

    • 분기당 몇명 정도의 서비스 해지(이탈)를 막을 수 있을 것인지 추정한다.

  • 운영 효율성 : 비효율성을 개선하여, 생산성을 증가시킨다. 예) 이직률 감소 프로그램, 부서간 통합이나 의사소통 문제, 규모가 커지면 오래걸리는 부분. 등

    • 고용하지 않아도 되는 직원의 수에 통상노동비용(급여+복지,하드웨어,공간등의 비용=50%)을 곱하여 매 분기당 운영 효율성을 구할 수 있다.

• 사례: WebPayroll

  • Webpayroll의 예상 신규 수익 명세표

  • 분기	신규고객	고객 한명당 수익	신규 수익
    1	0	0	0
    2	50	50	2500
    3
    ...(보통 2년간)...

  • 개발 비용의 추정

    • WebPayroll 프로젝트 개발팀의 급여 현황을 바탕으로 이터레이션 당 실제 노동 비용을 구한다.

      직함	연간 급여	노동 비용	이터레이션 당 노동 비용	참여율	이터레이션 당 실제 노동 비용
      PM
      기획자
      개발자
      합계...

    • WebPayroll 팀에 대한 비용 요약 : 스토리 점수 1점당 비용을 구하면, 100점짜리 스토리 구현에 드는 비용을 추정할 수 있어 좋다.

      단위	비용
      스토리 점수 당 비용
      주당 비용
      이터레이션 당 비용

• 재무 지표 (**추후 다시 보기)

  • 돈의 시간 가치
  • 순 현재 가치
  • 내부 수익률
  • 투자 회수 기간
  • 할인된 투자 회수기간

• 수익 비교
  프로젝트 테마 각각의 평가표

  테마	스토리 점수	비용	NPV(순 현재 가치)	ROI	할인된 투자 회수기간
  1일 서비스	150	101,250	46,312	45%	7분기
  사용자 정의 레포트	90
  협력 업체와 통합	60

선호도에 따른 우선순위^#

• 고객 만족에 대한 카노 모델
  제품 기능을 세가지 범주로 구분하여 고객 만족도를 줄세우는 방법 (Noriaki Kano가 만듬)
  

  1. Basic : 필수적으로 있어야 하는 것, 우선순위는 높게 매겨져야.
  2. Linear : 더 많을 수록 좋은 것. 그 다음 우선순위.
  3. Exciter : 마음을 끄는 것 (=unknown needs, 직접 보기 전에는 그런 것들이 필요한지 사용자들은 알지 못함)

  • 카노모델에 따른 테마 평가 방법
    20~30명이면 충분. 기능설문항(이 기능이 있다면?)과 비기능설문항(이 기능이 없다면?)의 두가지 질문을 통해 기능의 범주를 결정한다.

    • 만족한다 / 그럴 것이라고 예상했다. / 중립 / 그래도 쓸 수는 있다 / 불만이다.

  • 답변 분류하기

    • 

• 또 다른 방법: 상대적 가중치

  • 칼 위거스는 기능의 긍정적인 측면과 부정적인 측면을 동시에 평가한다는 점에서 카노와 유사한 방법을 제안. (Karl Wiegers, 1999) 사용자의 의견이 아니라, 전문가의 판단에 의존.
  • 각각의 기능이 구현여부에 따라 발생할 이득과 손해 관점에서 1~9까지 상대적인 점수를 매겨, 제품 책임자의 주도 하에 팀원들이 평가하는 방식

  • 특징	상대적 이득	상대적 손해	가치 (이득+손해)	가치% (가치/가치의 총합)	추정치 (스토리추정치)	비용% (추정치/추정치의합)	우선순위 (가치%/비용%)
    경기 결과를 그래프로 시각화하는 기능	8	6	14	42	32	53	0.79
    합계							(클수록 우선순위 높음)

  • 상대적 손해를 함께 고려하는 것이 중요한 이유 :
    상대적 이득 점수는 1점에 불과하지만, 상대적 손해가 9점쯤 되는 기능도 있다. 예) 정부 규정을 만족시키기 위한 기능..

사용자 스토리 분할^#

• 언제 사용자 스토리를 나눌 것인가

  1. 스토리 크기가 한 이터레이션에(혹은 남은 이터레이션 공간에) 들어가기엔 너무 클 때 쪼갠다.
  2. 좀더 정확한 추정이 필요한 경우
• 데이터의 경계에 따라 나누기 : 종류에 따라 나눈다.
• 작업 경계에 따라 나누기 : CRUD 연산 중 어디에 해당하는지에 따라 스토리를 나누라.
• 횡적인 연관성(cross-cutting concern)을 갖는 문제들을 제거하라. : 횡적인 연관성을 갖는 문제들(보안이나 오류 처리, 로깅 등에 관련된 기능)을 스토리에서 제거하여 두가지 서로 다른 버전의 스토리를 만드는 것을 고려해보라. 한 스토리에는 횡적연관성을 갖는 문제가 포함되어 있어야 하고, 다른 한 버전에는 포함되지 않는다. 예)일단은 안전하지 않게 패스워드넣고 로그인하게 구현 후, 이후 이터레이션에서 안전한 형태로 변경.
• 성능에 관계된 제약사항을 무시하라 : 우선은 돌아가게 만든 다음에 성능을 개선하라. 기능적 그리고 비 기능적 측면을 고려하여 스토리를 나누라(? 뭥미?)
• 그 안에 포함된 작은 스토리들이 우선순위가 다르다면 잘게 나누라
• 해야 할 일에 따라 스토리를 나누지 말라 대신, 스토리를 종적인 방향으로 쪼갤 수 있는 방법을 찾아보라
  ex)UI를 구현한다. 미들티어를 구현한다. (X)
  시스템을 언제나 종적인 방향으로 구현하는 것이다. 총알로 비유하자면, 총알이 모든 계층의 기능들을 관통하여 지나가도록.
• 연관된 일들을 함께 처리하고 싶은 유혹을 피하라
  : 이미 스토리의 크기가 적당해졌다면, 우선순위가 같지 않은 한 다른 연관된 문제들을 더하여 일을 복잡하게 만들지 말라.
• 스토리 합치기 :
  가능한 한 잘게 쪼개기 가 아니라!, 2~5일 사이에 구현이 끝날 정도로 기능을 분할하는 것이 좋다.
  연관된 유저스토리는 한데 합치면, 우선순위 매기기가 더 쉽다.

일정 배치^#

릴리즈 계획 과정에서 가장 중요한 것들^#

• 릴리즈 계획 = Roadmap.
  언제까지 얼마만큼의 작업이 완료될 것인지 정하는 일
  

  1. 만족 조건 결정 : 날짜를 맞추거나, 기능을 맞추는 등의 프로젝트 성패 여부를 판정할 기준 마련
  2. 사용자 스토리들에 대한 추정 : 다 하지 말라! 다음 릴리즈에 포함될 후보에 대한 추정이면 충분하다!
  3. 이터레이션 길이 선정 : 2~4주 정도
  4. 속도 추정 : 가장 최근에 그 팀이 보여준 속도
  5. 사용자 스토리 우선순위 결정 : 가치, 비용, 지식, 위험등의 요소에 따라 결정
  6. 스토리 선정 및 릴리즈 날짜 결정 :
     기능 중심적 프로젝트에서는 모든 필요기능의 추정치를 합한 후 그 값을 예상 속도로 나눈다.
     일정 중심적 프로젝트에서는 달력을 보고 이터레이션 횟수를 정한다. (이터레이션*추정된 속도=스토리점수양)
• 릴리즈 계획은 얼마나 상세해야 하는가?
  각 이터레이션에서 뭘 해야 하는지 미리 정하는 경우 vs. 나중에 정하는 경우
  프로젝트 진행과정에서 더 많은 지식을 축적하다보며 계획은 변경되기 마련이니, 작업을 특정 이터레이션에 배치하기 위해 너무 많은 시간과 노력을 들이는 것은 바람직하지 않다.
  필자의 추천 : 1~3이터레이션까지는 어떤 작업을 할지 정하고, 나머지는 안하는 것. 특히 1번 이터레이션에서 뭘할지 정하는 것은, 이터레이션을 바로 시작하게 될 경우 큰 의미가 있다.
  
• 릴리즈 계획의 갱신
  : 릴리즈 계획은 수시로 재점검되어야 하며 주기적으로 갱신되어야 한다. 이터레이션이 끝날때마다 재점검하는 프랙티스가 효과적이다.
  위와 같은 표를 벽에 붙여놓고, 주기적으로 재점검할 것!
• 사례

이터레이션 계획 과정^#

• 작업은 이터레이션 계획 과정 동안에 할당되지 않는다.

• 이터레이션 계획 과정과 릴리즈 계획 과정은 어떻게 다른가? :

  • 	릴리즈 계획	이터레이션 계획
    대상 기간	3-9개월	1-4주
    계획에 포함되는 항목	사용자 스토리	작업
    추정 단위	스토리 점수나 이상적 작업일	이상적 시간

• 속도 중심의 이터레이션 계획 과정 : 이터레이션 검토 회의는 보통 30~1시간 소요. 이터레이션이 끝나기 이틀 전 쯤 우선순위 검토 회의를 잡는다.
  그럼 해당 이터레이션에서 완료 못할 작업이 선명해지고, 이를 다음 이터레이션에 끝낼 수 있도록 우선순위를 높일지를 결정할 수 있게 된다.
  [속도 중심적 이터레이션 계획 과정의 각 단계] push방식

  1. 우선순위 조정
     : 가장 가치있는 것 순으로 진행할 수도 있겠지만, 사업과 프로젝트의 상황에 따라 언제나 우선순위를 빨리 검토해보는 것이 좋다.
     우선순위를 재조정하는 방법은 이터레이션 검토회의를 갖는 것. (이터레이션이 끝난 다음에 진행)
     ※이터레이션 검토 회의(iteration review meeting)에서 새 기능을 시연하고, 그 과정을 통해 가치있는 피드백을 얻는다. 제품 책임자 외의 다른 사람들이 이터레이션의 결과물을 처음 보고 이전에 우선순위였던 항목들을 제낄만한 더 좋은 새 아이디어들을 내놓는 일이 많다. 이번 이터레이션에서 뭘 만든 것인지 완벽하게 알지 못한 상태에서는 다음 이터레이션에서 해야할 일의 우선순위를 정하기 쉽지 않다는 점을 인정하라.
     필자는 많은 조직에서 우선순위 검토 회의를 새 이터레이션이 시작되기 며칠 전에 열어 효과를 보았다. (이터레이션 검토 회의와 이터레이션 계획 회의를 같은날 반나절/반나절 가질 것)
  2. 목표 속도 결정 :
     어제의 날씨에 기반. 처음 하는 경우에는 속도를 추측할 것.
  3. 이터레이션 목표 결정 :
     이터레이션 기간에 성취될 것들을 통합된 관점에서 기술하는 문장으로 아주 상세할 필요 없다.
  4. 사용자 스토리 선정 :
     우선순위를 고려할 것

  5. 사용자 스토리를 작업 단위로 분할

     • ex) 정책을 정한다. UI를 구현한다. 등..
     • 테스트나 문서화에 관련된 작업들도 포함할 것.
     • 현재 프로젝트에 가치를 주는 작업만 넣을 것 (not 이메일을 읽는다..)
     • 회의도 꽤 중요하다
     • 버그 : 해당 이터레이션에 나온 버그는 해당 이터레이션 내에서 수정하라.
     • 의존성 처리 :
       의존성 방향에 따라 추정도 그 순서에 맞추어 한다.

     • 나누기 힘든 작업은 spike를 활용한다. 스파이크란? 어떤 질문에 대한 답이나 지식을 얻기 위해 이터레이션 계획에 포함된 작업.

       • ex) 어떤 부분이 영향을 받는지 살펴본다 - 2시간
       • 코드를 수정한다. -10시간..

  6. 작업 각각에 대한 추정
     : 이상적 시간으로 추정. 가장 좋은 추정치는 실제로 그 작업을 할 사람으로부터 나온다. 하지만 팀 전첵다 함께 추정하는 게 좋다. 이유는

     1. 아직 누가 무슨 일을 할지 알 수 없다.
     2. 제일 잘 아는 사람이라고 하더라도 다른 사람들이 손 놓고 있어도 된다는 뜻은 아니다.
     3. 무슨 일이 얼마나 오래 걸릴지를 듣는 과정에서 팀은 유저스토리나 작업에 대한 잘못된 이해를 바로잡을 기회를 갖게 된다.
     4. 실제로 작업을 담당할 사람이 추정치를 내놓게 되면 그 사람의 자존심과 아집이 커져서 나중엔 추정치가 잘못되었다는 사실을 인정하지 않으려할수도 있음.
  7. 설계도 어느 정도까지는 OK
     추정하기 위해 토론을 하다보면 설계에 대한 내용이 어느 정도까지는 나오게 되어있다. 
  8. 작업의 최적 크기 : 한명의 개발자가 하루 정도에 끝낼 수 있는 크기가 적당

• 서약 중심적인 이터레이션 계획 과정 :
  '어제의 날씨'에 근거해 스토리점수나 분량을 결정하는 대신, 팀은 더이상 하겠다는 약속을 할 수 없을때까지 유저스토리를 추가한다.
  [서약 중심적인 이터레이션 계획 과정] pull방식 --> 좀더 accountable하고 신뢰할 수 있다!
  속도 중심적인 계획에서는 어제의 날씨에 근거해 스토리들을 다 골라놓은 다음에 작업별로 분할하고 추정하는 과정을 하는 반면,
  서약 중심적인 계획에서는 스토리를 하나씩 골라서, 각각의 스토리를 작업으로 분할하고 추정한다음, 해당 이터레이션 동안 그 스토리를 구현할 것인지를 서약한다.

  1. 우선순위 조정
  2. 이터레이션 목표 식별
  3. 추가할 스토리 선정
     스토리를 작업목록으로 확장
     작업들을 추정
  4. 서약할 수 있는지 몯는다.
  5. 추정치의 합산 :
     이상적인 작업 시간 = 실제 시간이 아니다.
     보통의 팀들은 계획된 작업량(작업카드들의 추정치의 합)이 하루에 4~6시간 정도로 나누어질 수 있을 때 좋은 결과를 보여준다.
     따라서 10명으로 구성된 개발팀이 3주 단위의 이터레이션을 쓰고 있다면, 하루 이상적 작업시간을 5시간으로 환산할 경우, 750시간 정도로 이터레이션계획을 만들 가능성이 높다.
  6. 서약 가능하고 더이상 빈자리 없을때까지 이 과정을 되풀이한 후 이터레이션 계획 완료
• 나의 선택 :
  저자는 속도중심보다는 서약중심 계획법을 더 선호한다는.
  이유는 1. 속도는 이상적 작업일이나 스토리 점수를 통해 계산되는 대강의 추정치일 뿐. 한 이터레이션 안에서 이루어지는 작언 단위의 작업 계획에는 사용하기 어렵다. 2. 스토리들간의 난이도 편차를 상쇄시키기에는 이터레이션 내에서 포함되는 스토리 갯수가 너무 적기 때문에, 이터레이션 계획에서는 속도 개념을 사용하지 않는다. 다만, 릴리즈 계획 과정에서는 속도개념이 유용하다.
• 작업 추정치와 스토리 점수 간의 관계

이터레이션 길이 선정^#

• 이터레이션 길이를 결정하는데 중요한 요소들

  • 릴리즈를 내놓는 시점 사이의 간격 : 작은 프로젝트에는 작은 간격을 쓰는게 좋다.
  • 불확실성의 양 : 불확실성이 큰 편이라면, 이터레이션 길이를 짧게 잡아야 그 속도에 맞추어 진도를 측정하고, 이해당사자/고객/사용자로부터 피드백을 수집할 기회를 더 많이 가질 수 있다.
  • 피드백 수집 용이성 : 조직 내외부에서 받는 피드백의 가치를 극대화할 수 있도록 길이를 잡자.
  • 우선순위를 변경하지 않아도 되는 기간 : 새로운 아이디어가 실제로 구현되는 데 에는 평균적으로 11/2 이터레이션 길이가 걸린다. ex) 스프링노트 사용자 의견을 반영하는 주기를 2주로 하고싶으면, 이터레이션을 1주나 열흘로 하는 것이 좋음
  • 외부 피드백이 없어도 되는 기간 : 외부 피드백을 통해 외부 커뮤니케이션을 안하면 안할수록 프로젝트가 골로갈 위험성은 높아진다. 
  • 이터레이션 오버헤드 : 이터레이션에 수행되는 비용을 줄여야 한다.
  • 긴급하다는 느낌이 얼마나 빨리 찾아오는가 : 팀원들이 느낄 압박이나 스트레스가 이터레이션 기간동안 적절한 수준으로 배포되도록.
  • 꾸준한 리듬 유지하기 : 이터레이션 길이를 안 바꾸고 오랫동안 가다보면, 개발팀은 모종의 리듬감을 느끼게 된다.
• 결정
• 6 X 2 + 1 = 2주길이 이터레이션을 6번 돈 뒤에 1주 길이 이터레이션을 한번 수행하는 방법. 1주동안 부채 탕감 기간
• 사례 연구

속도 추정^#

• 과거의 수치들에 근거하여 보는 방법
  : 사용할 기술, 분야, 같은 팀, PM, 도구, 환경, 사람들의 변화가 없다면 모르겠지만, 있다면 과거 속도를 사용하는 것을 다시 생각해볼 필요가 있다.

• 이터레이션을 실제로 실행해 보는 방법
  : 1~3번의 이터레이션을 실행해보고 관측된 속도를 근거로 추정치를 만든다. 해보기 전까지 속도 추정을 미루는 방법.
  불확실성 원추에 따라 프로젝트 초기에는 속도 추정의 범위를 넓게 잡고, 이터레이션을 3~4번 이상 돌린 후에는 적용하지 않는다.

  • [이터레이션 횟수에 따라 속도 추정치를 계산하기 위해 곱해야할 수치들]

    완결된 이터레이션 수	하한	상한
    1	60%	160%
    2	80%	125%
    3	85%	115%
    4 이상	90%	110%

• 예측하는 방법 (why? 이터레이션을 실제로 돌려볼 수도, 과거 데이터도 없기 때문!)
  : 스토리들을 작업 수준으로 쪼개어 소요시간을 추정하고 이터레이션안에서 속도를 계산하는 것 (이터레이션 계획 과정과 유사)

  1. 프로젝트에 참가하는 각 팀원이 매일 작업에 투여할 수 있는 시간을 추정한다
  2. 이터레이션 동안 프로젝트에 투여할 수 있는 시간의 총합을 계산한다
  3. 사용자 스토리들을 다소 임의로 고른다음 그 작업을 필요한 작업까지 확장한다. 이전 단계에서 계산한 시간을 모두 채우기에 충분한 개수의 작업들을 찾아낼 때까지 반복한다

  4. 앞선 단계에서 구한 속도를 범위 형태로 변환한다 예)25라는 추정치 --> 15~40으로 변경 (불확실성 원추에 따라 60%와 160%를 곱)

     프로젝트에 더 많은 시간을 할애하기 위한 프랙티스

     : 포모도로

     팀이 고도의 집중된 상태를 유지하면서 삼십분 단위로 작업한다. 25분은 철저히 일에만 몰두하고, 5분은 쉰다. (타이머 활용)

     예를 들어 우리 팀은 매일 열번의 포모도리(5시간)를 수행하겠다고 계획한다.

     • ▼스토리들에 대한 작업시간과 점수
       : 이런식으로 스토리들을 작업으로 쪼개고 작업시간을 추정한다. 하다보면, 스토리점수가 같은 카드라도 작업시간이 다르게 추정될 수 있음을 이해할 것이다.

       스토리	작업	스토리 점수	작업시간
       사용자는 자신의 신상정보를 업데이트할 수 있다	UI개발 기획 미팅 스파이크... 테스트	3	24
       선수는 자신의 경기순위를 파이차트 형태로 조회할 수 있다	어쩌구 저쩌구	3	30
       전체			합...

     • ▼파트 타임 멤버를 고려한 가용 시간 계산표 :
       현재 수행중인 프로젝트에 대해 이런 테이블을 만들어 보고, 어떻게 하면 각각의 팀원이 프로젝트에 투여하는 시간을 늘릴 수 있을지 생각해보라.

     • 사람	하루당 가용 시간	이터레이션 당 가용 시간
       라면	4	40
       규영	6	60
       인동	2	20
       합		120

• 어떤 접근법을 취할 것인가

  1. 속도 추정치를 내놓아야 하는 시점 전에 한 번 이상의 이터레이션을 돌릴 기회가 있다면 반드시 그렇게 한다. 실제 값에 필적하는 추정치란 있을 수 없다
  2. 이 팀이 수행했던 관련 프로젝트가 있다면 실제 산출 속도를 이용
  3. 주어진 시간안에 어떤 작업들이 들어맞는지 보고 그에 따라 속도를 추정한다.

불확실성에 대한 버퍼링 계획 ^#

불확실하면 불편하다. 하지만 확실하려다보면 우스워진다. -중국속담

애자일 계획 과정이 잘 안들어맞는다고 흔히 거론되는 상황들 : 부가적 불확실성이 높거나, 프로젝트 결과가 잘못되었을때 입게될 피해의 정도가 크다.

• 먼 미래에 수행될 프로젝트를 계획
• 데드라인 변경이 힘들고, 프로젝트 기간동안 구현해야 할 기능들도 고정적일 때
• 한 조직에서 다른 조직으로 수주된 프로젝트일 때
• 요구사항들이 피상적인 수준으로만 이해되고 있을 때
• 프로젝트 데드라인이나 결과물 형태에 심한 제약을 두지는 않지만, 그렇다고 프로젝트 일정을 지나치게 탄력적으로 운용할 수는 없을 때

이런 경우에는, 버퍼를 두면 좋다. 위험성을 적절히 관리해나가는 좋은 방법.

• 기능 버퍼 : 선택적인 기능을 기능 버퍼로 사용한다.

  • 우선, 고객은 기능 중에서 꼭 필요하다고 생각되는 Must-have(필수기능)을 고른다. 그 다음, 그 기능들에 대한 추정치들을 합산한다. 그 값이 릴리즈에 포함될 최소한의 기능 규모이다. 그 다음 고객은 필수기능의 25%~40% 가량의 추가적인 기능들을 선택한다. 이 기능들은 보다 많은 불확실성이 내재된 것들이거나 일정이 제대로 지켜지지 않을 경우 제거될 수 있는 기능 목록이다. 이들에 대한 추정치를 합산하여 최초의 추정치에 더하면 프로젝트 전체에 대한 추정치가 나온다. 그런 다음 그 전체 기능을 고객에게 인도하는 것을 목표로 평상시와 똑같이 계획 과정을 진행하면 된다. 하지만 이들 중 어떤 기능들은 선택적아어서 시간이 허락하는 경우에만 제품에 넣을 수 있다. 그런 기능들은 필수기능의 개발이 완료된 후 젤 마지막에 구현한다.

    예를 들어, 100점 만큼의 Must-have를 찾았다면, 30% 정도의 일거리, 즉 30점만큼의 스토리를 더 고른다. 그럼 전체 프로젝트 크기는 130점이 된다.

  • DSDM (Dynamic Systems Development Process)라는 애자일프로세스

    • 필수 (Must have) : 필수 기능에 투여되는 노력의 비율은 70%를 넘을 수 없다.
    • 권고 (Should have)
    • 선택 (Could have)
    • 불필요 (Won't have)

• 일정 버퍼 :
  공항에 갈 때 늦지 않을 확률을 높이기 위해 걸릴 시간 + 30분이라는 계획을 할 경우.

  • 추정치에 불확실성 반영하기

    1. 모든 작업마다 50% 추정치와 90% 추정치를 구하여 각각 더한다.
       : 계산법 = 제곱 값의 합을 제곱근하여 버퍼의 크기를 계산한다.. (넘 어려워 ㅠㅠ by Ramyon)

    2. 50% 추정치로 모든 작업을 추정하여 합산한 후, 그 값의 50%를 버퍼로 더한다.- 간단하면서도, 장점이 있어.

       각각의 스토리에 대해서 50% 수준으로 추정치를 만든 다음 그 추정치들의 합을 2로 나눈 값을 버퍼 크기로 잡는 것이다. 이 방법을 사용할 때에는 모든 팀원들이 각각의 스토리에 대해 50% 정도의 신뢰성이 있는 추정치를 만들어야 한다는 사실을 인지하고 있어야 한다. --p283

       • 각각의 국지적인 안전장치들을 하나의 프로젝트 버퍼안으로 옮김으로서, 파킨슨 법칙이나 학생 증후군을 피할 수 있다.

         파킨슨의 법칙 : 일을 하는데 드는 시간이 주어진 시간의 양만큼 늘어난다는 법칙

         학생 증후군 : 일을 제대로 끝낼 수 있으리라 예상되는 범위 내에서, 그 시작을 가능한 한 늦추는 습성

    3. 지침

       • 제곱값의 합을 제곱근하여 버퍼의 크기를 계산하는 방법의 신뢰도는 적어도 열개 정도의 유저스토리나 기능을 추정하는 상황에서 가장 높으므로, 10개 미만의 프로젝트에서는 쓰지 않는다.
       • 프로젝트 버퍼는 적어도 전체 프로젝트 기간의 20% 정도의 크기를 가져야 하며, 더 작은 버퍼는 보호하지 못한다.
• 버퍼 조합하기
  
• 일정 버퍼는 완충제가 아니다
  완충제(padding)란 추정치에 임의로 더한 추가의 시간을 다소 경멸적으로 일컫는 용어. 예를 들어 추정 결과 사흘인데, 다른 사람에게 닷새라고 한다던가
  일정버퍼는 국지적 안전장치를 제거한 추정치의 합에, 안전을 기하기 위해 붙이는 시간상의 여유이다.

• 주의해야할 사항들

  • 일정 버퍼를 추가할 때에는 두개의 추정치를 사용하거나, 50% 추정치만을 사용하도록 한다. 90% 추정치는 이미 충분히 비관적인 수치이다. 거기에 일정 버퍼를 덧붙이면 일정이 과도하게 늘어나기만 할 것이다.
  • 많은 프로젝트들은 데드라인이 상세히 고정되어 있지도 않고 인도해야할 기능의 집합도 고정적이지 않다. 그런 프로젝트라면, 버퍼를 추가하느라 시간을 낭비하지 말길 바란다.
  • 충분한 의견 교환을 하라. 버퍼의 존재를 숨겨서도 안되며, 어떻게 사용될지 감추지도 말라.

여러 팀이 참여하는 프로젝트의 계획 과정^#

• 추정치를 내는데 필요한 공통 기초의 확립. 모든 팀이 같은 단위를 사용하고 합의해야 한다.
• 사용자 스토리의 세부사항을 좀더 일찍 찾아낸다. 스토리에 대한 제품 책임자 관점의 만족 조건들을 찾아낸다.
• 미리보기 계획을 만든다. 원형 미리보기 계획은 단순히 가까운 미래에 수행될 몇 번의 이터레이션만을 내다보는 계획들로, 팀들로 하여금 가까운 미래에 수행할 작업을 미리 공유하여 좀더 잘 조율할 수 있게 해준다.
• 급송 버퍼를 계획에 포함시킨다
  팀간 의존도가 높아져, 한 팀의 개발 결과물이 다른 팀으로 늦게 전달되어 그팀의 개발 일정이 지연되지 않게 하는 여분의 시간이다.
• 하지만 일이 너무 많다

추적과 의사소통^#

릴리스 계획 감시 **^#

• 릴리스 추적하기
• 릴리스 소멸 차트
• 주차장 차트

이터레이션 계획 감시 **^#

• 작업 보드

  • 스토리	할 일	테스트 준비 완료	진행 중	확인 필요	(완료)	시간
    (스토리카드)	(작업카드)	V	(작업카드 옮겨 붙임)	(작업카드에서 옮겨 붙임)		잔여시간 (매일 아침 고친다). 작업 카드들의 합

• 이터레이션 소멸 차트
• 투여된 노력의 양을 추적하기
• 개인 속도

계획과 소통^#

• 계획에 대한 의견 교환
• 진도에 관한 의견 교환
• 이터레이션 요약 보고서

애자일 계획 과정이 통하는 이유^#

애자일 계획 과정이 통하는 이유^#

• 계획은 빈번히 수정된다
• 규모 추정치와 기간 추정치는 따로 분리한다 **
• 서로 다른 수준의 계획을 만든다 **
• 작업이 아닌, 기능에 대한 계획을 만든다 **
• 스토리의 크기를 작게 만들어 작업 흐름을 유지한다
• 진행 중인 일들은 다음 이터레이션으로 넘기지 않는다 *
• 개인이 아닌 팀을 추적한다 *
• 불확실성을 인지하고 그에 대비한다
• 애자일 추정과 계획 과정을 위한 열두가지 지침

사례 연구^#

사례 연구 : Bomb Shelter Studio^#

• 첫째 날 - 월요일 아침
• 사용자 스토리에 대한 추정
• 제품 리서치 준비 : 사용자들 카노 설문을 통해, 감동요인(Exciter), 선형기능(Linear), 필수요인(mandatory) 도출
• 이터레이션과 릴리스 계획 과정, 제 1라운드
• 2주 후
• 두번째 이터레이션의 계획과정
• 2주 후
• 릴리즈 계획의 수정
• 변경된 계획 프리젠테이션
• 18주 후

 

See also

• Agile UI Design