반응형
불확실성과 화해하는 프로젝트 추정과 계획(마이크 콘) 이라는 책의 13번째 파트 에 해당하는 내용입니다.
릴리즈 계획이 뭐길래? 왜? <-- 요거 제목으로는 어울리지 않죠? ㅎㅎ 릴리즈에 대해서 다들 알고 있을 건데.. 왜라니.. 쩝. ㅋ
릴리즈 계획 과정은 이터레이션보다 더 긴 기간을 커버하는 아주 높은 수준의 계획을 생성하는 과정이다.
릴리즈를 내놓는 데는 통상 3개월에서 6개월의 기간이 소요되며, 이터레이션 길이가 얼마냐에 따라서 3회에서 12회 이상의 이터레이션이 필요하다.
첫 번째로 릴리스 계획은 제품 책임자와 팀원들로 하여금 릴리스 가능한 제품이 나오려면 얼마나 많은 작업이, 그리고 얼마나 오랜 시간이 필요할지 결정할 수 있도록 해준다. 제품이 더 빨리 릴리스 될수록(그리고 릴리스 시점에 제품의 질이 좋으면 좋을수록), 회사는 프로젝트로부터 더 빨리 수익을 거둘 수 있게 된다.
-- 이런 내용들이 관리자들이 좋아하는 내용이죠? ^^;;
두 번째로 릴리스 계획을 통해 얼마만큼의 기간 동안, 어떤 기능이 개발될 것인지를 예측할 수 있다. 많은 회사들이 이 정보를 사용해 다른 전략적 계획들을 수립한다.
세 번째로 릴리스 계획은 개발팀이 어디로 가야할지를 보여주는 이정표 구실을 한다. 릴리스라는 개념이 없다면, 개발팀은 한 이터레이션에서 다음 이터레이션으로 끝없이 옮겨 다니게 될 것이다. 릴리스 계획 덕에 이터레이션들은 하나의 만족스로운 총체로 결합될 수가 있다. 이는 굳이 애자일 프로세스가 아니더라도, 반복적인 프로세스라면 기본적으로 고려해야할 사항이다.
이런 계획이 없다면 프로젝트가 목적지 없이 표류할 가능 성이 생기고, 또 완료를 하더라도 기대했던 방향이 아닐 수도 있다.
그러므로 릴리스 계획이 필수적이며 이로인해서 프로젝트가 잘못된 길로 가는 걸 막아줄 수 있다.... 랍니다. ㅋ
릴리즈 계획
릴리스 계획 과정에서는 얼마만큼의 작업이 완료 될것인가를 결정해야 한다.
날짜를 정해놓고 얼마만큼의 일을 할 수 있을지 생각해보는 것이 프로젝트의 시작일 수도 있고,사용자 스토리들을 만들어 둔 다음 그것들을 구현하는데 얼마나 오래 걸릴지를 생각해 보는 것으로 프로젝트를 시작할 수도 있다.
개발팀이 최초의 답을 얻고 나면 그 답은 해당 프로젝트에 대한 조직의 목표에 비추어 평가된다.
결국 제품을 개발하고 나면 기대한 만큼의 돈을 벌 수 있을 것인가? 아니면 돈을 절약할 수 있을 것인가? 시장에 성공적으로 진입할 수 있을 것인가? 만일 아니라면, 프로젝트 수행 기간을 더 늘리거나 줄여서 목표를 성취할 수 있을지도 모른다.
릴리스를 내놓기 위해 얼마나 많은 일을 해야 할지, 그리고 어떤 사용자 스토리들을 포함할지를 결정하는 것은 아주 직관적인 프로세스이다. 계획된 이터레이션 숫자에 개발팀의 예상 속도나 알려진 속도를 곱하면 얼마나 많은 일이 필요한지를 결정할 수 있다.
그 수치에 맞춰서 사용자 스토리의 수를 결정하면 된다. 가령 6개월 뒤에 새로운 제품을 내놓아야 한다고 해보자, 두 주짜리 이터레이션을 사용하기로 했다면, 릴리스 시점까지 13번의 이터레이션을 돌아야 할것이다.
개발팀의 속도가 스토리 점수나 이상적인 작업일 기준으로 20이라면, 전체 프로젝트의 규모는 13x20= 260점이 될 것이다. 제품 책임자와 개발팀은 그 점수를 놓고 모든 스토리들을 토론 해 본 다음 그 우선순위를 정해 260이 넘지 않는 한도 내에서 가장 가치 있다고 여겨지는 스토리들을 구현하기 위해 노력할것이다. 릴리스 계획은 보통 프로젝트 기간 동안 개발될 사용자 스토리의 목록 형태로 문서화된다.
여기쯤 읽을때 이런 생각을 해봤습니다.
위에서 개발팀의 속도를 20이라는 결과를 얻기 위해서는 무엇이 필요할까? 라는 것입니다.
이론상으로는 너무나도 쉬운 답을 얻을 수 있습니다. 실제로 팀원들과 스토리 보드 작성과 이터레이션 작성을 한 내용을 가지고 평가를 하면 됩니다.
하지만 제가 진행해본 결과( 전문 프로젝트 메니져가 아니라 너무 미숙 했을 수도 있지만 ) 정확한 추정이 힘들다는 것을 알게 되었습니다.
1. 전체 제품에 들어가야 하는 정확한 스토리를 뽑아 내기가 힘들다는것.
2. 프로젝트를 진행하면서 튀어나오는 이슈들이 발생할때 이것들이 스토리로 들어가기에 문제가 있는 경우들.
3. 스토리나 이터레이션 수행에 거짓이 있을때.( 보고를 위해 빈약한 부분을 채워 넣거나, 혹은 빼먹거나 하는 것들).
1번과 2번은 사실 프로젝트 수행 미숙에 해당하는 내용으로 볼 수도 있습니다.
3번은 너무나도 취약한 부분입니다. 부서내에서 업무 수행 보고를 부풀려 해야 하거나 할 때가 있습니다.
이런 문제들이 개입되다보면, 결국 이 개발팀의 속도 추정치가 불확실 해지고, 이는 전체 프로젝트 스케쥴에 큰 영향을 미치게죠.
그렇다 보니 개발 스케쥴을 신뢰 할 수 없게 되고, 관리자는 임의대로 스케쥴을 조정하게 되는 악 순환이 반복될 가능성이 있습니다.
당연히 개발팀장 역시 자신이 보고한 개발 스케쥴에 대해서도 자신감이 없으니 강력한 주장(?)은 더더욱 힘들게 됩니다.
저 역시 이런 오류들을 격다보니, 정확한 팀의 속도를 추정은 불가능 하더군요.
그래서 향후 새로운 프로젝트를 진행할 시에는 3번과 같은 경우는 없도록 해야겠다는 걸 뼈저리게 느꼈답니다.
위에서 개발팀의 속도를 20이라는 결과를 얻기 위해서는 무엇이 필요할까? 라는 것입니다.
이론상으로는 너무나도 쉬운 답을 얻을 수 있습니다. 실제로 팀원들과 스토리 보드 작성과 이터레이션 작성을 한 내용을 가지고 평가를 하면 됩니다.
하지만 제가 진행해본 결과( 전문 프로젝트 메니져가 아니라 너무 미숙 했을 수도 있지만 ) 정확한 추정이 힘들다는 것을 알게 되었습니다.
1. 전체 제품에 들어가야 하는 정확한 스토리를 뽑아 내기가 힘들다는것.
2. 프로젝트를 진행하면서 튀어나오는 이슈들이 발생할때 이것들이 스토리로 들어가기에 문제가 있는 경우들.
3. 스토리나 이터레이션 수행에 거짓이 있을때.( 보고를 위해 빈약한 부분을 채워 넣거나, 혹은 빼먹거나 하는 것들).
1번과 2번은 사실 프로젝트 수행 미숙에 해당하는 내용으로 볼 수도 있습니다.
3번은 너무나도 취약한 부분입니다. 부서내에서 업무 수행 보고를 부풀려 해야 하거나 할 때가 있습니다.
이런 문제들이 개입되다보면, 결국 이 개발팀의 속도 추정치가 불확실 해지고, 이는 전체 프로젝트 스케쥴에 큰 영향을 미치게죠.
그렇다 보니 개발 스케쥴을 신뢰 할 수 없게 되고, 관리자는 임의대로 스케쥴을 조정하게 되는 악 순환이 반복될 가능성이 있습니다.
당연히 개발팀장 역시 자신이 보고한 개발 스케쥴에 대해서도 자신감이 없으니 강력한 주장(?)은 더더욱 힘들게 됩니다.
저 역시 이런 오류들을 격다보니, 정확한 팀의 속도를 추정은 불가능 하더군요.
그래서 향후 새로운 프로젝트를 진행할 시에는 3번과 같은 경우는 없도록 해야겠다는 걸 뼈저리게 느꼈답니다.
릴리스 계획 과정 동안 어떤 개발자가 어떤 사용자 스토리나 작업을 수행할 것인지 명시하는 계획을 만들거나, 이터레이션 동안 어떤 작업이 어떤 순서대로 이뤄져야 하는지를 명시하는 계획을 만들지는 않는다. 릴리스 계획 과정동안 그 정도로 자세한 계획을 만드는 것은 위험한 일이다. 누가 무슨 일을 어떤 순서대로 할 것이냐 하는 문제는 그 작업을 할 사람이 결정하는 것이 좋고, 가능한 한 뒤로 미뤄두는 것이 좋다. 릴리스 계획에 명시되는 것은 사용자에게 전달될 기능의 명세인 사용자 스토리이지 실제로 수행될 개별적 작업들이 아니다.
그런 것들을 릴리스 계획에 포함시키는 것은 너무 이른 일이다.
사용자 스토리들 가운데에는 개별적인 엔지니어링 작업들로 분할하기에는 충분히 이해되지 않은 스토리들도 있을 수도 있다.
14장[이터레이션 계획 과정] 에서도 살펴보겠지만, 개발팀은 결국 릴리스 계획에 포함된 사용자 스토리들을 개별적인 작업들로 분할하게 된다. 하지만 그러한 분할 작업은 해당 스토리가 속한 이터레이션을 시작할 때까지는 하지 않는다.
핵심이 될만한 키워드라서 강조 했습니다. 사실 프로젝트 계획을 세우다보면 너무 세부 사항까지 들어가게 되는데 이를 막고자 하는 예기 인듯 합니다.
만일 프로젝트나 조직 그리고 작업 환경이 허락한다면 릴리스 계획안에 부가적인 정보들을 당연히 포함시킬 수 있다. 일례로, 계획 이면에 깔려있는 어떤 핵심적인 가정들을 릴리스 계획에 명시해 둘 수도 있다. 그런 가정들로는 누가 개발팀에 포함되어야 하고, 이터레이션 길이는 얼마나 되어야 하고, 첫번째 이터레이션이 언제부터는 시작되어야 하고, 마지막 이터레이션은 언제까지 끝나야 한다는 등의 가정이 있을 수 있겠다. 제 21장 [계획과 소통]에서는 릴리스 계획에 대한 의견을 서로 나눌때 포함 시키면 좋은 부가적인 정보들에 대해서 설명한다.
만족 조건 결정 -> 사용자 스토리 추정 -> 이터레이션 길이 결정 -> 스토리 선정 및 릴리스 날짜 결정
↑ 속도 추정 |
| 사용자 스토리들 간의 우선순위 결정 |
+-----------------------------------------------------------------------------+
만족 조건 결정
릴리스 계획과정을 시작하기 전에 프로젝트의 성패 여부를 판정할 기준을 아는 것이 중요하다.
대부분의 프로젝트의 경우 가장 결정적인 기준은 절감되거나 창출되는 돈의 양이다. 프로젝트가 이런 재정적 목표를 만족할 것인지를 판단하기 위해 대부분의 프로젝트들은 일정과 범위 그리고 자원이라는 3대 기준을 사용한다. 그것은 제품 책임자가 정하는 만족 조건들이라는 것이 일정과 봄위 그리고 자원에 관한 목표들로 정의된다는 것을 의미한다.
제품 책임자는 릴리스 계획 과정에서 행해지는 미팅 때마다 이들 각각에 대한 목표들을 꺼내 보여줄 것이다. 가령 제품 책임자는 네 개의 테마에 대해(스토리 점수 기준으로 200점에 달하는)인원 추가 없이 3개월 안에 개발 완료를 바랄수도 있다. 각자의 기준들에 대해 전부 목표를 정해둘 수도 있지만, 보통은 하나의 기준이 지배적으로 작용한다. 즉, 일반적인 프로젝트들은 날짜를 맞추는 것을 목표로 하거나 아니면 기능을 맞추는 것을 목표로 한다는 것이다. 일정 중심적인 프로젝트는 특정한 날짜까지는 릴리스가 나와야 하는 프로젝트이며, 어떤 기능이 포함되어야 하느냐는 그렇게 중요하지 않다.
기능 중심적인 프로젝트는 가능한한 빨리 릴리스를 내놓고자 하는 프로젝트이긴 하지만, 어떤 기능이 제품에 포함되느냐가 보다 더 중요한 프로젝트이다.
만족 조건 결정이라는 것이 책의 내용으로도 잘 이해가 안되는 부분이군요. 과연 만족할만한 조건이란 것이 위에서 나열한 것들로 결정할 수 있는가? 그럼 일정이 중요하다고 한다면 만족할만한 조건이란 무엇인가? 예가 없으니 너무 막연하군요.
스토리와 릴리즈 날짜 선정
이 시점에는 개발팀의 이터레이션 당 속도를 알고 있는 상태일 것이고, 얼마나 많은 이터레이션이 필요할지에 대한 기본적인 가정은 되어 있는 상태일 것이다. 그렇다면 릴리스가 만족 조건들을 충족하도록 계획될 수 있는지 살펴볼 순서이다.
프로젝트가 기능 중심적이라면 모든 필요 기능들의 추정치를 합한 다음 그 값을 예상 속도로 나눈다. 그렇게 하면 필요한 기능 구현을 완료하는 데 필요한 이터레이션의 횟수를 구할 수 있다.
프로젝트가 일정 중심적이라면 달력을 보고 이터레이션의 횟수를 정한다. 이터레이션의 횟수를 추정된 속도로 곱하면 얼마나 많은 스토리 점수를 릴리스 안에 넣을 수 있을지 알 수 있다. 그리고 그 만큼의 점수나 이상적 작업일을 사용자 스토리의 우선순위 리스트에 적용하여 얼마나 많은 기능을 지정된 시간 안에 구현할 수 있을지를 알아낸다.
그 다음 물어야 할 질문은 릴리스 계획이 얼마나 상세해야 하는가이다.
어떤 팀들은 각 이터레이션 안에 무엇을 개발해야 하는지가 잘 드러나는 릴리스 계획 쪽을 선호한다. 어떤 팀들은 다음 릴리스까지 어떤 기능들을 개발해야 하는지 정도만 간단히 결정하는 쪽을 선호한다. 각 이터레이션 안에서 무엇을 해야 하는가는 나중에 결정하겠다는 것이다. 이 중 어떤 방식을 택할것이냐 하는 것을 릴리스 계획 과정에서 토의하고 결정하여야 한다.
각각의 접근 법에는 나름대로의 장단점이 있다. 분명한 것은, 특정한 기능을 특정한 이터레이션에 배정하는 작업은 더 많은 시간을 필요로 한다는 것인다. 하지만 그정도로 상세하게 작업하게 되면 여러 팀들이 협력하여 일을 진행해야 할 경우 유리하다. 한편,작업을 특정한 이터레이션에 할당하는 과정을 생략하면 상세함은 떨어질지라도 시간은 덜 잡아먹는다. 더욱이 어떤 작업을 어떤 이터레시션에 배정할 것인지를 미리 결정하더라도 이터레이션이 실제로 시작되는 시점보다는 적은 지식을 가진 상태에서 하게되는데, 프로젝트 진행과정에서 더 많은 지식을 축적하다 보면 계획은 변경되게 마련이다. 그사실에 비추어 본다면, 작업을 특정한 이터레이션에 배정하기 위해 시간과 노력을 들이는 것은 바람직하지 않다. 물론 프로젝트에 따라서는 그런 사전 작업을 할만한 가치가 있는 경우도 있다.
필자가 적절한 타협점이라고 생각하는 방법은 , 첫 번째 이터레이션부터 세 번째 이터레이션까지는 각 이터레이션에서 어떤 작업을 수행할지를 미리 정하고, 릴리스 계획의 나머지 부분에 대해서는 하지 않는 것이다. 맨 처음 이터레이션에 작업을 할당해 두는 것은 당연히 의미가 있다. 이터레이션이 곧바로 수행될 것이라면 더더욱 그렇다.
전형적인 릴리스 계획 과정 동안에는 아주 많은 타협적인 질문들과 가정적인 질문들이 제기된다. 그러므로 다음 릴리스와 그 이터레이션동안 무엇을 넣고 무엇을 뺄지를 능숙하게 처리하기 위한 손쉬운 방법이 필요하다. 가장 좋은 방법은 모든 사람들이 배석한다는 가정하에, 사용자 스토리나 기능이 적힌 3x5 인치짜리 카드나 포스트잇 카드를 놓고 작업하는 것이다. 소프트웨어와는 달리 카드는 실체적이며 쉽게 공유될 수 있다.
릴리스를 계획하기 위해서 제품 책임자는 그가 생각하기에 제일 우선순위가 높아서 첫 번째 이터레이션에 들어가야 한다고 생각되는 항목들을 고른다. 카드는 어떤 스토리가 어떤 이터레이션에 들어가야 되는지 명확하게 드러나도록 배열된다.
그림.이터레이션에 들어갈 작업들을 열로 나누어 배열하기.
여기 그림이 이터레이션이 가로로 배열되고, 세로로 스토리들이 배열된 그림이 들어옴
릴리스 계획의 갱신
릴리스 계획을 만들어 두고 어딘가에 처박아 둔 다음 건드리지 않으면 곤란하다. 릴리스 계획은 수시로 점검되어야 하며 주기적으로 갱신되어야 한다. 개발팀의 속도가 일정하게 유지되고 이터레이션 계획 과정에서 뭔가 깜짝 놀랄 만한 사건이 발생하지 않으면 네 주나 여섯 주 정도는 릴리스 계획을 갱신하지 않고 놔두어도 괜찮지 않을까 생각할 수도 있다. 하지만 많은 프로젝트들은 이터레이션이 끝날 때마다 릴리스 계획을 재점검한다는 규칙을 지켜서 좋은 성과를 내고 있다.
사용자 스토리 선정
이번 릴리스에 약 48점 만큼의 스토리를 둘 수 있는 상황에서,
팀원들은 제품 책임자가 가장 낮은 우선순위를 준 "시스템 관리자는 사용자 그룹과 권한을 설정할 수 있다."는 스토리가 시스템에 반드시 필요한 스토리라는 사실을 지적하였다. 이 스토리는 3점짜리이다. 이스토리를 릴리스에 포함시키면 스토리 점수 총합은 49점이 되어 48점을 넘어버린다.
48점이라는 것도 역시 추정이기 때문에 49점을 그대로 수용할 수도 있지만, 49점을 수용하지 않기로 개발팀이 결정했다고 한다면,
1점만큼의 스토리를 릴리스에서 빼야 한다. 그래서 8점짜리 스토리를 빼버리기로 결정하였다. 이로서 41점이 되었는데 남은 자리에 3점짜리 스토리를 추가할 수도 있게 되었다.
하지만, 제품 책임자는 41점으로 줄어든 만큼 개발 팀이 일정을 1점 만큼 앞당길 수 있다면, 추후에 8점짜리 스토리를 제품일정에 추가할 수 있을 거라 생각하여 추가로 3점짜리 스토리를 포함하지 않고 놔두었다.
여기서 41점 짜리로 그대로 놔둔것은 매우 좋은 선택인것 같군요.
첫번째로, 48점 짜리 릴리스를 41점으로 줄이고 일정을 당길 수 있다면, 계획보다 많은 리소스를 줄일 수 있을것입니다.
두번째로, 41점 짜리 릴리스가 되어 7점이 아깝다고 생각 할 수도 있겠지만, 사실 새로 추가하려는 3점 짜리는 이미 우선순위에서 밀린 3점짜리 스토리라는 것입니다. 즉, 프로젝트상 8점 짜리 스토리보다 우선순위가 밀리는 것인데, 그다지 중요하지 않은 3점 짜리가 이번 릴리스에 들어감으로 해서 8점짜리 스토리가 들어간 다음 릴리즈 시기를 앞당길 수 있는 기회를 없애버릴 수 있기 때문이죠.
첫번째로, 48점 짜리 릴리스를 41점으로 줄이고 일정을 당길 수 있다면, 계획보다 많은 리소스를 줄일 수 있을것입니다.
두번째로, 41점 짜리 릴리스가 되어 7점이 아깝다고 생각 할 수도 있겠지만, 사실 새로 추가하려는 3점 짜리는 이미 우선순위에서 밀린 3점짜리 스토리라는 것입니다. 즉, 프로젝트상 8점 짜리 스토리보다 우선순위가 밀리는 것인데, 그다지 중요하지 않은 3점 짜리가 이번 릴리스에 들어감으로 해서 8점짜리 스토리가 들어간 다음 릴리즈 시기를 앞당길 수 있는 기회를 없애버릴 수 있기 때문이죠.
이 글을 읽기 전까지는 저도 스토리와 이터레이션과의 관계에만 몰두해서 프로젝트를 진행하면서 스토리와 이터레이션을 단지 TODO 관리 정도로 밖에 사용을 못했는데( 사실 이것도 굉장히 효과가 있었습니다.)
프로젝트 전반적인 흐름과 어떻게 매칭을 해나가야 하는지에 대해 좀더 깊게 생각해보게 되었습니다.
'개발 Note > UI Framework 개발하기' 카테고리의 다른 글
| CoreAnimation in iOS (0) | 2011.07.13 |
|---|---|
| key - value 관리 (0) | 2011.06.08 |
| Binary 호환성을 위해 알아야 할것 - ABI, EABI (0) | 2010.06.01 |
| Conway’s Law - 조직과 소프트웨어 (0) | 2010.06.01 |
| [에자일]불확실성과 화해하는 프로젝트 추정과 계획 (0) | 2009.07.24 |
