최근 프로젝트(SI, 연구성과제, 회사내부 등)의 대부분을 애자일 방법(스크럼)으로 진행해 왔다. 요구사항에 해당하는 제품백로그를 수집하고 스프린트백로그를 도출하여 스프린트를 계획하고 일일회의와 스프린트 종료회고 등을 통해 좀더 나은 방향으로 프로젝트를 이끌고자 했다.
언젠가 강의 중에 수강생이 이런 질문을 했다.
"애자일을 기간과 비용, 개발범위가 정해져 있는 SI 프로젝트에도 적용할 수 있나요?"
나의 대답은 당당하게 "네! 부분적으로 고객의 이해를 전제하지 않더라도 적용이 가능합니다." 라고 대답을 했다. 그런데 지금은...
지금 진행하고 있는 프로젝트는 "시장적시성(Time to Market)"이 가장 중요하였으며, 그렇기 때문에 구현하고자 하는 기능의 정의와 더불어 추정과 계획이 정말 중요했다. 고객사는 6개월전부터 이 프로젝트를 진행해왔으나 개발업체가 프로젝트 진행도중 중단을 선언하는 등 프로젝트 진행에 어려움이 많이 있었다. 고객사는 그간 투입된 6개월 동안의 실적으로 요구사항 분석 및 UI설계를 완료된 것으로 판단하였고 그 산출물을 받아서 프로젝트를 계속 진행할 수 있는 개발업체를 찾았다. 그래서 우리회사가 이 프로젝트에 참여하게 되었다.
당시까지 진행된 상황과 고객사의 설명을 들으니 처음 접하는 도메인영역임에도 그렇게 어려워 보이지 않았다. 그래서 요구사항 수집이나 요구사항 분석같은 것은 프로젝트를 진행하면서 점차 범위를 넓혀가자고 고객과 합의를 했다. 추출된 기능목록(제품백로그)과 고객사가 생각하고 있는 서비스일정을 고려해보니 대략 3명이 3개월(9 M/M)이라는 추정치가 나오게 되었다. 그런데 최초 업무정의에 대한 내용을 들었을때 단순 DB에 접근하여 데이터를 보여주는 것으로 착각(?)하는 실수를 범한 것이다.
부사장님이 소프트웨어 개발을 비유한 안개고지전투(http://vizend.tistory.com/38)가 불현듯 생각났다.
프로젝트를 진행하면서 고객의 업무설명을 좀더 깊이있게 이해할수록 "어~~어~~"라는 말이 절로 나왔다. 1주일 걸릴거라고 예상한 것은 2주가 걸렸고 2주가 예상된 것은 4~5주가 걸렸다. 어떤 프로젝트이든 위험요소는 늘 있기마련이다. 그런데 아무리 처음 접하는 도메인이라 하더라도 이렇게 심각하게 과소추정되는 경우는 찾아보기 힘들다.(물론 연구성과제는 한치앞도 보이지 않는 안개속인 경우가 많고 이보다 더 심각한 추정이 나올 수 있으나 연구성과제라는 특징을 모두 인식하므로 크게 문제시 되지 않는듯 하다.) 이제 재추정은 선택이 아닌 필수가 되었다.
먼저 시장적시성을 만족하기 위해서는 시스템오픈을 위한 개발범위와 개발우선순위를 재조정해야 하고 완전한 프로젝트 종료를 위해서는 기간과 비용을 재조정해야만 한다. 이를 위해서 개발팀과 나는 비교적 타당한 추정근거를 제시하기 위하여 스토리점수와 이상적 작업시간 개념을 도입하고 사용자기능에 대해서 고객과 함께 세부적인 추정을 했다. 그 결과는 아주 놀라웠다. 9M/M 이 지난 시점에서 잔여 사용자기능 추정치가 10.5 ~ 14M/M 이 나왔고 관리자 기능도 4 ~ 6M/M이나 나온 것이다. 여기에 관리자 기능은 좀더 추가가 예상되고 있어서 플러스알파의 기간이 더해져야만 한다.[M/M(Man/Month)에 대한 표기는 이해를 돕기위한 것이고 실제로는 스토리점수로 작업규모를 추정하고 이상적작업시간으로 작업기간을 추정했다)
추정과 관련해서 [불확실성과 화해하는 프로젝트 추정과 계획](http://insightbook.springnote.com/pages/1717328) 이라는 책은 다음과 같은 내용을 다루고 있다.
전통적인 규범적 계획법이 실패하는 이유와 애자일 계획법이 먹히는 이유
스토리 점수와 이상적 작업일을 사용해 기능 규모를 추정하는 방법과 그 장단점
재 추정 방법 및 재 추정이 필요한 시기
기능 우선순위를 결정하는 재정적/비 재정적 접근법들
큰 기능을 보다 손쉽게 관리할 수 있게 작은 단위로 분할하는 방법
이터레이션 계획 방법 및 팀의 초기 진도 예측 방법
불확실성이나 일정 관련 위험성이 지나치게 높은 프로젝트의 일정을 계획하는 방법
여러 팀이 함께 작업하는 프로젝트를 추정하는 방법
이제 이 글의 주제인 [프로젝트 추정과 계획의 실패는 누구의 몫인가?]를 생각해 보자.
"[요구사항 수집이나 요구사항 분석같은 것은 프로젝트를 진행하면서 점차 범위를 넓혀가자고 고객과 합의]를 했다."
프로젝트를 진행하는 개발팀 및 개발사의 입장에서 이 말의 의미는 "처음 식별되지 않은 요구사항에 대해서는 추가적인 기간과 비용이 발생할 수 있습니다." 였다. 그런데 고객은 비용에 대한 부분은 고려하지 않고 기간에 대한 부분만을 인식했던것 같다. 즉, 납기를 초과할 수 있다는 것에만 동의했다는 의미이다. 결국 프로젝트 추정과 계획의 실패에 있어 비용은 개발팀 및 개발사가 떠안아야 한다는 결론이다.
이렇게 개발사에게 프로젝트 추정과 계획의 실패를 떠넘기게 되면 개발사는 프로젝트 초반에 아무리 힘들더라도 요구사항을 모두 확정지어서 가려고 할 것이고 추정에도 상당한 시간을 들여 진행할 것이다. 더욱 문제가 되는 것은 요구사항 변경이나 추가에 대해서 개발사는 상당히 비협조적일 것이다.
다시 한번 [안개고지전투]가 생각난다. 고객의 입장에서 아주 먼곳에 있는 최종 목적지를 가려고 할때 바로 앞의 안개속 고지를 점령해가면서 점령방향과 점령방법을 판단하면 길을 잃지도 않을 뿐더러 보다 효율적으로 점령해 나갈 수 있지 않을까?
[고객의 이해를 전제하지 않더라도 애자일 적용가능]이라는 말에 회의가 들었다. 애자일 방법 자체는 적용할 수 있겠으나 추가비용을 고려하지 않는 고객과 과연 요구사항 변경이나 추가를 논의할 수 있을까? 추가비용을 고려하지 않고 해결할 수 있는 방법은 꼭 필요한 요구사항 변경과 추가에 들어가는 기간과 비용만큼 다른 기능(개발범위)을 축소하는 것이다. 그런데 고객은 이마저도 하지 않으려고 한다.
甲乙(갑을)관계를 들이대며 다음 먹거리(프로젝트)를 무기로 프로젝트 추정과 계획의 실패를 모두 개발사에게 책임을 묻는 것은 분명 옳지 않을 것이다. 물론 개발사에게 전혀 책임이 없고 100% 고객사에게만 책임을 묻는 것도 분명 옳지 않다. 마치 주행중 접촉사고에 대한 과실정도를 판가름하여 책임을 묻는 것과 같이 어느 한쪽에만 책임을 묻기보다는 쌍방과실을 인정하고 합의하여 프로젝트를 성공으로 이끄는 것이 중요할 것이다.
- 포데브(ForDev)
언젠가 강의 중에 수강생이 이런 질문을 했다.
"애자일을 기간과 비용, 개발범위가 정해져 있는 SI 프로젝트에도 적용할 수 있나요?"
나의 대답은 당당하게 "네! 부분적으로 고객의 이해를 전제하지 않더라도 적용이 가능합니다." 라고 대답을 했다. 그런데 지금은...
지금 진행하고 있는 프로젝트는 "시장적시성(Time to Market)"이 가장 중요하였으며, 그렇기 때문에 구현하고자 하는 기능의 정의와 더불어 추정과 계획이 정말 중요했다. 고객사는 6개월전부터 이 프로젝트를 진행해왔으나 개발업체가 프로젝트 진행도중 중단을 선언하는 등 프로젝트 진행에 어려움이 많이 있었다. 고객사는 그간 투입된 6개월 동안의 실적으로 요구사항 분석 및 UI설계를 완료된 것으로 판단하였고 그 산출물을 받아서 프로젝트를 계속 진행할 수 있는 개발업체를 찾았다. 그래서 우리회사가 이 프로젝트에 참여하게 되었다.
당시까지 진행된 상황과 고객사의 설명을 들으니 처음 접하는 도메인영역임에도 그렇게 어려워 보이지 않았다. 그래서 요구사항 수집이나 요구사항 분석같은 것은 프로젝트를 진행하면서 점차 범위를 넓혀가자고 고객과 합의를 했다. 추출된 기능목록(제품백로그)과 고객사가 생각하고 있는 서비스일정을 고려해보니 대략 3명이 3개월(9 M/M)이라는 추정치가 나오게 되었다. 그런데 최초 업무정의에 대한 내용을 들었을때 단순 DB에 접근하여 데이터를 보여주는 것으로 착각(?)하는 실수를 범한 것이다.
부사장님이 소프트웨어 개발을 비유한 안개고지전투(http://vizend.tistory.com/38)가 불현듯 생각났다.
소프트웨어 개발은 안개고지전투(Foggy Hills Battle)다.
- 고지는 요구사항 그룹이다. 어떤 산이든 작은 산으로 이루어지듯 요구사항도 마찬가지이다.
- 고지는 요구사항 그룹이다. 어떤 산이든 작은 산으로 이루어지듯 요구사항도 마찬가지이다.
- 안개 자욱하여 앞이 보이지 않듯이 우리의 요구사항은 언제나 안개 속이다.
- 하나의 고지를 점령하면 다음 고지가 더 잘 보일 뿐만 아니라, 경험을 활용할 수 있다.
- 고지는 언제나 서로 다르며, 지도는 단순한 참조일 뿐이다.
- 고지로 이르는 길은 고지를 점령하고 의미가 없다. 고지만이 의미가 있다.
- 하나의 고지를 점령하면 다음 고지가 더 잘 보일 뿐만 아니라, 경험을 활용할 수 있다.
- 고지는 언제나 서로 다르며, 지도는 단순한 참조일 뿐이다.
- 고지로 이르는 길은 고지를 점령하고 의미가 없다. 고지만이 의미가 있다.
프로젝트를 진행하면서 고객의 업무설명을 좀더 깊이있게 이해할수록 "어~~어~~"라는 말이 절로 나왔다. 1주일 걸릴거라고 예상한 것은 2주가 걸렸고 2주가 예상된 것은 4~5주가 걸렸다. 어떤 프로젝트이든 위험요소는 늘 있기마련이다. 그런데 아무리 처음 접하는 도메인이라 하더라도 이렇게 심각하게 과소추정되는 경우는 찾아보기 힘들다.(물론 연구성과제는 한치앞도 보이지 않는 안개속인 경우가 많고 이보다 더 심각한 추정이 나올 수 있으나 연구성과제라는 특징을 모두 인식하므로 크게 문제시 되지 않는듯 하다.) 이제 재추정은 선택이 아닌 필수가 되었다.
먼저 시장적시성을 만족하기 위해서는 시스템오픈을 위한 개발범위와 개발우선순위를 재조정해야 하고 완전한 프로젝트 종료를 위해서는 기간과 비용을 재조정해야만 한다. 이를 위해서 개발팀과 나는 비교적 타당한 추정근거를 제시하기 위하여 스토리점수와 이상적 작업시간 개념을 도입하고 사용자기능에 대해서 고객과 함께 세부적인 추정을 했다. 그 결과는 아주 놀라웠다. 9M/M 이 지난 시점에서 잔여 사용자기능 추정치가 10.5 ~ 14M/M 이 나왔고 관리자 기능도 4 ~ 6M/M이나 나온 것이다. 여기에 관리자 기능은 좀더 추가가 예상되고 있어서 플러스알파의 기간이 더해져야만 한다.[M/M(Man/Month)에 대한 표기는 이해를 돕기위한 것이고 실제로는 스토리점수로 작업규모를 추정하고 이상적작업시간으로 작업기간을 추정했다)
추정과 관련해서 [불확실성과 화해하는 프로젝트 추정과 계획](http://insightbook.springnote.com/pages/1717328) 이라는 책은 다음과 같은 내용을 다루고 있다.
이제 이 글의 주제인 [프로젝트 추정과 계획의 실패는 누구의 몫인가?]를 생각해 보자.
"[요구사항 수집이나 요구사항 분석같은 것은 프로젝트를 진행하면서 점차 범위를 넓혀가자고 고객과 합의]를 했다."
프로젝트를 진행하는 개발팀 및 개발사의 입장에서 이 말의 의미는 "처음 식별되지 않은 요구사항에 대해서는 추가적인 기간과 비용이 발생할 수 있습니다." 였다. 그런데 고객은 비용에 대한 부분은 고려하지 않고 기간에 대한 부분만을 인식했던것 같다. 즉, 납기를 초과할 수 있다는 것에만 동의했다는 의미이다. 결국 프로젝트 추정과 계획의 실패에 있어 비용은 개발팀 및 개발사가 떠안아야 한다는 결론이다.
이렇게 개발사에게 프로젝트 추정과 계획의 실패를 떠넘기게 되면 개발사는 프로젝트 초반에 아무리 힘들더라도 요구사항을 모두 확정지어서 가려고 할 것이고 추정에도 상당한 시간을 들여 진행할 것이다. 더욱 문제가 되는 것은 요구사항 변경이나 추가에 대해서 개발사는 상당히 비협조적일 것이다.
다시 한번 [안개고지전투]가 생각난다. 고객의 입장에서 아주 먼곳에 있는 최종 목적지를 가려고 할때 바로 앞의 안개속 고지를 점령해가면서 점령방향과 점령방법을 판단하면 길을 잃지도 않을 뿐더러 보다 효율적으로 점령해 나갈 수 있지 않을까?
[고객의 이해를 전제하지 않더라도 애자일 적용가능]이라는 말에 회의가 들었다. 애자일 방법 자체는 적용할 수 있겠으나 추가비용을 고려하지 않는 고객과 과연 요구사항 변경이나 추가를 논의할 수 있을까? 추가비용을 고려하지 않고 해결할 수 있는 방법은 꼭 필요한 요구사항 변경과 추가에 들어가는 기간과 비용만큼 다른 기능(개발범위)을 축소하는 것이다. 그런데 고객은 이마저도 하지 않으려고 한다.
甲乙(갑을)관계를 들이대며 다음 먹거리(프로젝트)를 무기로 프로젝트 추정과 계획의 실패를 모두 개발사에게 책임을 묻는 것은 분명 옳지 않을 것이다. 물론 개발사에게 전혀 책임이 없고 100% 고객사에게만 책임을 묻는 것도 분명 옳지 않다. 마치 주행중 접촉사고에 대한 과실정도를 판가름하여 책임을 묻는 것과 같이 어느 한쪽에만 책임을 묻기보다는 쌍방과실을 인정하고 합의하여 프로젝트를 성공으로 이끄는 것이 중요할 것이다.
- 포데브(ForDev)