테스팅 히치하이커를 위한 안내서

테스팅 프로젝트의 추정은 누가 하고 계신가요? 테스팅 팀장님이 하시나요? 음.. 그런곳도 있을 것 같습니다. 하지만 전 아직 들어보지 못했습니다. 제가 겪어 보고 일반적으로 들어서 알고 있는 테스팅 프로젝트의 일정은 아래와 같은 상황입니다. 몇몇의 경영자와 기획자 그리고 마케터들이 모여서 제품 출시일을 논합니다. 물론 개발자 분들도 있습니다. 잠시 열띤 토론 끝에 마케터 분들이나 경영자의 한마디로 회의가 끝납니다. 이 제품은 6개월 후에 출시합니다. 그 이후로는 전쟁입니다. Gantt 차트나 기타 여러가지 방법으로 척척 아름다운 추정들이 쏟아져 나와서 MS 프로젝트나 엑셀로 멋지게 그려집니다. 그리고 그걸로 끝입니다. 해당 일정은 가끔 기획자나 경영자들이 들여다보면서 이러면 안돼~~ 라는 외마디 비명을 지를때 외에는 다른 사람들은 그다지 관심이 없습니다. 우선 한 2달간 열심히 기획을 하면서 개발이 시작됩니다. 그리고 출시 한달 전까지 죽어라 개발만 합니다. 그리고 출시 한달을 앞두고 어느 정도 모양이 잡힌 실행을 할 수 있을 만한 제품이 테스트 팀으로 넘어옵니다. 하지만 곧바로 테스트를 할 수가 없습니다. 제품이 정상적으로 구동되지 않거나 환경이 제대로 갖춰지지 않은 경우가 많습니다. 개발팀에서 테스트를 요청할 때는 그냥 언제까지 끝내달라고만 말합니다. 야근과 철야로 어떻게든 일정에 맞춰주면 그 뒤로 수정되었다는 소식은 함흥차사입니다. 출시일은 제꺽 제꺽 다가오고 한달 정도 전쟁과 같은 테스트와 수정을 하던 제품은 우선 출시일에 출시가 됩니다. 그리고 나서 또 몇달 간의 전쟁과 같은 수정과 테스팅이 반복이 됩니다. 위 상황에서 누구도 테스트 팀에게 테스트 일정을 물어보지 않습니다. 테스트 팀의 일정은 전체 개발 기간에서 남는 시간동안 진행하는 것이거나 개발팀이나 다른 부서에서 정해준 시간까지인 경우가 제가 듣고 겪어본 일정 추정 방법입니다. 여러분은 어떠신가요? 이게 과연 제대로 된 일정 추정인가요? 추정이라는 것이 현실적이라고 생각하는 사람은 많지 않습니다...

일전의 포스팅 에서 프로젝트가 지연되는 이유에 대해서 1. 머피의 법칙 2. 학생 증후군 3. 멀티 태스킹 4. 파킨슨 법칙 4가지를 설명한 적이 있다. 많은 프로세스 방법론에서는 추정과 계획에서 위와 같은 4가지 상황을 해결하기 위해 다양한 솔루션을 제공하고 있다. 이번에는 그 중에서 TOC 에서 제공하는 CCPM에 대해 설명해 보고자 한다. 우선 다음과 같은 상황을 가정해보자. 여섯 고객에게 각각 6MM씩 투입되어야 하는 개발프로젝트가 있다. 각각 설계엔지니어가 2MM, 구현에 개발엔지니어가 4MM씩 소요된다 고객에게 최종산출물을 인도하면 기성급을 수령할 수 있다. 각 프로젝트의 가치는 1200만원이다. 회사가 보유하고 있는 자원은 설계엔지니어가 2명(가,나), 개발엔지니어가 4명(다,라,마,바)이고, 이들의 노임은 모두 월 100만원/MM이다. 노임은 매월 말일에 지급한다 위와 같은 멀티 프로젝트 환경에 대해 각자 추정과 계획을 수립해 보자. 일정은 얼마나 걸릴 것인가? 언제 프로젝트를 통해 이익을 얻을 수 있는가? 고객은 언제 제품을 인도받을 수 있는가? 그에 따른 고객 만족도는 어떨것인가? 그 외에도 고려할 수 있는 요소는 모두 고려해서 추정과 계획을 수립해 보시기 바란다. 펼쳐두기.. 먼저 식별하기 쉽게 설계 엔지니어와 개발 엔지니어를 아래와 같이 표현하도록 하겠다. 일반적인 일정 계획은 아래와 같이 프로젝트 단위로 계획을 수립한다. 위와 같은 일정 계획에 전혀 문제가 없어 보이는가? 위의 일정 계획에서 놓치고 있는 가장 큰 것은 바로 자원이다. 각 작업을 진행할 사람이 한번에 하나의 프로젝트만 할 수 있다라고 할 때 위의 계획은 한사람이 동시에 무려 6개의 프로젝트에 배정되어 있다. 이것은 절대로 불가능하고 이루어질 수 없는 계획이다. 지금은 단순화되어 있는 계획이기 때문에 이러한 모순이 쉽게 발견되지만 실제 프로젝트에서는 각 작업 단위와 그것을 수행할 사람의 관계가 명확히 드러나는 경우가...

우선 이 글은 제 개인적인 이해를 적당히 정리한 글입니다. 세부적인 내용은 지금도 학습하는 중으로 물어보신다 하여도 대답해 줄만한 능력은 아니됩니다. 물론 제 개인적인 이해이기 때문에 잘못된 개념이 있을 수도 있으며 그런 부분에 대해 트랙백이나 댓글로 친절하게 알려주었으면 하는 바입니다. 지금부터 하고자 하는 얘기는 일정의 추정에 대한 얘기입니다. PMP 자격증을 취득하셨거나 중비중인 모든 분들은 기본적으로 PERT/CPM에 대해 알고 계실 것입니다. 고로 아래 내용은 다 아실 것이라 생각합니다. 다시 한번 말씀드리면 혹시 틀린 내용이나 이해를 잘 못하고 있는 부분이 있다면 친절히 알려주셨으면 하는 바입니다. 일정을 추산하는데 사용하는 분포는 크게 3가지로 나뉩니다. 베타 분포, 정규 분포, 삼각 분포 가장 먼저 볼 것은 정규 분포입니다. 아래 보는 것과 같은 그래프가 가장 대표적인 정규 분포 곡선이며, 6시그마에서 많이 볼 수 있는 곡선이기도 합니다. 위와 같은 정규분포 곡선에 따라 일정을 추산해 본다면 평균치는 현재 5일입니다. 어떤 작업을 수행할 때 평균적으로 5일을 소요하는 경우가 가장 많다라는 것입니다. 그렇다면 우리는 실제로 일정을 추산할 때 5일로 추산할까요? 절대로 그럴리가 없습니다. 우리는 여러 이유로 안전시간이라는 것을 삽입합니다. 만약 우리가 일정으로 5일로 추산한다면 일정에 맞춰 작업을 완료할 확률은 50%입니다. 때문에 우리는 일정에 맞춰 작업을 완료할 확률이 대략 90% 쯤 되는 날짜를 추산하게 됩니다. 대략 7일쯤을 적는 것이지요. 하지만 이렇게 일정을 추산하고 나면 사람은 역시 게을러지게 됩니다. 추가로 이틀의 시간을 안전시간으로 집어넣었기 때문에 파킨슨 법칙과 학생증후군의 환상 조합에 따라 7일이 다시금 평균값이 되고 일정이 완료되는 것은 9일경이 될 것입니다. 문제는 이러한 것이 각각의 작업 단위마다 발생된다면 전체 일정은 각 작업 단위의 지연이 모두 합쳐지기 때문에 눈덩이처럼 지연된다는 것입니다. 또다른 문제는 이것은 표준정규...

우리가 지금까지 수행한 프로젝트 중 출시 예정일에 정확하게 출시한 소프트웨어가 얼마나 되시나요? 날이면 날마다 야근과 철야를 밥먹듯 하며 회사를 위해 프로젝트를 위해 열심과 노력과 성의를 불살라가며 열심히 일했는데도 프로젝트는 왜 지연되는 것일까요? 물론 어찌 어찌 출시 예정일에 맞춰서 출시되는 경우도 있습니다. 운이 좋고 능력 좋은 회사 중에는 매번 출시 예정일을 칼같이 맞추는 회사들도 있을 수 있겠지만 기존의 연구결과나 통계 결과를 제시하지 않아도 우리는 출시 예정일을 지키지 못하는 많은 경우를 알고 있습니다. 왜? 프로젝트는 지연되는 걸까요? 프로젝트가 지연되는 이유는 매우 많은 원인이 연관되어 있기 때문에 정확히 문제가 무엇이다라고 말하기는 조금 힘든 것이 사실이지만 그 많은 이유 중 하나가 바로 우리가 너무 열심히 일하기 때문입니다. 우리가 열심히 일할 수록 프로젝트가 지연된다는 것이 쉽게 이해가 가시나요? 쉬운 예제를 들어보겠습니다. 여러분이 화장실 앞에서 줄을 서고 있습니다. 만약 화장실을 이용하는 사람들의 평균 시간이 줄서서 기다리는 사람들의 평균 도착속도와 정확히 같다면, 줄은 얼마나 길어지겠습니까? 곰곰히 생각해 보시기 바랍니다. 펼쳐두기.. 많은 사람들이 이런 경우 줄이 생기지 않을 것이라고 대답합니다. 이러한 대답을 하는 가장 큰 원인은 바로 대부분의 사람들이 평균이라는 변동을 직관적으로 이해하지 못하는 인간의 사고 능력때문입니다. 화장실을 이용하는 사람들과 화장실에 도착하는 사람들의 시간이 같은 것이 아니라 평균 시간이 같은 것입니다. 평균이라는 단어는 변동성과 불확실성이라는 의미를 내포하고 있는 것입니다. 결론적으로 줄은 시간이 지남에 따라 무한하게 길어집니다. 물론 줄이 무한히 늘어나려면 시간도 무한히 걸리겠지만, 줄이 놀랄만큼 빠른게 길어질 수 있고, 화장실이 더 늘어나거나 화장실에 오는 사람이 줄어들기 전에는 절대로 줄은 사라지지 않을 것입니다. 아래 그래프는 화장실을 이용하는 사람들의 평균 시간과 줄서서 기다리...