'계획'에 해당되는 글 2건

  1. 2011/03/24 글뻥 UML기반 개발강좌 4 - 계획추정
  2. 2009/08/28 글뻥 애자일 경험담 7

지난 시간에 USE CASE를 Activity Diagram으로 전개시키고 이를 다시 세분화하여 추정견적을 냈었다.
그러면서 다음과 같이 규모산정을 하였다.

우리가 산정한 안내를 받는다는 기능은 총 110.9 FP이다.

여기서 잠깐, 위의 챠트는 잠시 잊도록 하자. 먼저 생각해봐야 할 것은 "이 일은 몇명이서 얼마간 일해야 생각했던 기능을 모두 구현할 수 있을까?" 이다.

마치 밥이 한공기 있는데 몇 숟가락 떠먹어야 다 먹을수 있냐?라는 질문과 본질적으로 같은 질문인것 같다.
이를 공식화하면 간단하다

먼저 밥숫갈횟수 = 밥한공기용량/밥숫갈용량, 따라서, 전체 시간은 = 밥숫갈횟수*한숫갈당 씹는시간
물론 소화시간까지 계산한다면 "밥숫갈횟수*한숫갈당씹는시간+소화시간" (이건 잘 기억하자. 다음은 이 단순한 원리로 우리가 알고 있는 상식을 한번 깨보겠다.)

나는 WBS(Work Breakdown Structer)를 협오하는데 그 이유는 바로 Activity와 Due Date, 담당자로만 설정하기 때문이다.
거기다가 2Weeks이상 어떤 Activity 가 길어지면 안된다고 강제하고 있다.
물론 더 쪼게라고 이야기하고 있기는 한데 이거 하나 마음에 든다.
하지만 WBS는 다음과 같은 치명적인 오류가 있다.

첫째, 업무의 규모는 안보인다. 단지 보이는건 업무와 할당된 개발자, 종료일이다. 그게 어렵든, 쉽든 일단 2Weeks이내로 일정을 잡으면 소프트웨어 공학론자 눈에는 합리적으로 일정을 배분한것이 된다.
다시말해 위에서 계산한 "밥한공기의 용량"은 배제되는 것이다. 거기다가 SI 업계는 급하게 모인 개발자의 생산성을 모른다. 따라서, 밥 한숟갈의 용량도 알수가 없다. 즉, 밥한공기의 용량도 모르고 밥한숟갈의 용량도 모르는데 일단 밥먹는 시간은 설정된다.

둘째, WBS는 통제도구이다. "Critical Path"라는게 있다. WBS를 제대로 사용하려면 이 "Critical Path"라는 큰 줄기가 제대로 진척되고 있는지를 살펴야 한다. 그러나, 수 많은 고객을 포함한 감시/감독자들은 WBS의 모든 부분을 가지고 트집잡는다. 논쟁은 논쟁을 낳고 책임은 변명을 낳는 상황이 반복된다. 이말이 사실인지 아닌지를 보려면 WBS를 누가 원하는지를 보거나 기억해 내면 된다. WBS는 고객 또는 PM, 감리가 요청하는 문서이다.

셋째, 몇 개월에 달하는 WBS에 따른 일정 및 업무량을 100% 맞출수 있다면 그 사람에게 1억을 주라. 왜냐하면 그 사람은 로또 번호를 눈감고도 맞출 사람이다. 이말이 와닿지 않다면 이글을 읽는 걸 멈추고 당장 앞으로 10분이후 혹은 1시간 이후 혹은 4시간 이후에 자신이 뭘하고 있을지 상상해보자. 결코 일반 범인들은 10분뒤를 알 수가 없다. 이 포스팅을 시작한게 약 2시간이 흘렀는데 나는 30분 정도 쓰고 말겠다는 생각으로 시작했지만 중간 중간 이벤트가 발생하고 불려다니면서 이미 계획된 일정의 4배를 소모하고도 글을 다 쓰지 못했다. 그런데 몇 개월간의 2Weeks로 쪼게진 업무를 예측하고 계획하라고?

결론적으로 이러한 정형화되고 고정된 형태의 계획은 인간을 못살게 구는 압제의 수단이다.
따라서, 계획은 이렇게 세우는 것이 합리적이다.

1. 가장 먼저 해야할 일은 개발팀의 생산성을 측정해야 한다. 만약 이게 안된다면 연구자료를 참조하자.

물론 다른 자료도 만들 수 있겠지만 개발시 Prototype을 만들어 봄으로써 팀의 평균 생산성을 측정기록할 수도 있다.
여기서 중요한것은 최소한 한숟같의 용량을 측정해야 한다는 주장이다.
((절대 개인이 아닌 개발팀이어야 한다. 개인을 측정하고자하면 그건 또하나의 압제의 수단을 만들 뿐이고 팀웤에 도움이 안된다. 예를 축구 선수는 골로만 평가 받지 않는다. 팀의 기여도 등의 평가 기준이 있는 것이고 아무리 골을 잘 넣어도 혼자 11명을 상대로 할 수 있는건 없다. 개발도 마찬가지다. 고객의 숫자는 항상 개발팀의 숫자보다 많다. 급조한 개발팀이 단시간내에 으쌰으쌰해서 고객을 압도할 수 없기 때문이다.)

2. 정보공학에서 이야기하는 2Weeks는 지켜주자. 왜냐? 근거없는 관습이지만 2Weeks가 넘어가면 관리 한계가 드러나는것 또한 사실이다. (물론 내 경우는 1일이 넘어가면 관리한계가 발생한다.)

3. Critical Path를 먼저 설정하자. 흔히 마일스톤이라는 것으로 표현하면 된다.

암튼 다시 원점으로 돌아가 전체 규모는 110.9이므로 첨부된 파일에 있는 2003년 이후의 개인 생산성인 18FP로 나누자.
그러면 총 6.16 이나온다. 즉, 6.16 M/M가 투입되어야 구현이 가능하다는 이야기이다.
물론 사전 공부가 필요없는 전문가에 대한 이야기이다.
프로토타잎도 만들필요가 없는 전문가에 대한 이야기이다.
암튼 왠지 모르겠지만 어디서나 통용되는 2:8법칙을 적용하여 6.16은 개발 최소기간의 80%로 설정하면 6.16의 25%인 1.23을 버퍼로 추가해서 총 개발기간은 7.29가 되고 학습기간을 고려하면 고정 투자비용 1개월+7.29M/M가 투입되어야 개발이 가능하다. (물론 지도데이터나 음성 데이터등 관련 데이터가 모두 존재한다는 가정이다.)

따라서, 계획은 "Activity Diagram을 보며 업무를 Breakdown할 수있다. + 개발계획은 교육 1개월 + 7.29M/M의 투입이 필요하다."는 간단한 진실로 마일스톤을 그릴수 있는 것이다.
* 다음 그림을 다시한번 상기해보자.

기능 구현업무는 다음과 같이 나열하였었다. (3부에서)

- 초기화는 단순 입력만 이니 EI/ILF
- 목적지이름조회, 목적지주소조회는 EQ/ILF
- 주소목록선택, 목적지목록선택은 EI/ILF
- GPS좌표를 획득하는건 외부 시스템 연동으로 EIF
- 경로획득은 ILF
- 현재좌표획득은 EIF
- 음성안내는 EQ/ILF
- 현재지도갱신 EQ/ILF
- 안내종료는 EQ/ILF

이를 다시 정리하면 다음과 같다.

1. Milestone (예제)
- 개발자교육 (1M)
- Prototype (0.5M)
- 개발구현 (7.29/개발자수)
- 배포 (개발구현완료후)

2. 상세일정
- 개발자 교육 내용 및 추정기간
- Prototype 내용 및 추정기간
- 개발구현 내용 및 추정기간
- 배포 내용 및 추정기간

* 개발구현 상세일정 예제
사용자 삽입 이미지

다시말해 추정기간은 시간이라는 자원을 얼마정도 쓸지 예측한다는 의미이다.
이러게 자원소요계획을 수립하고나면 Milestone을 더 짧게 쪼게서 Iteration을 적용할 수 있다.
예를 들어 개발자 교육이 1개월 걸린다면 짧게 1주일씩 나눠서 4번 반복 할 수 있다.

Iteration1 - GPS시스템이해
Iteration2 - 앞 교육과정 요약 및 네비게이션의 이해
Iteration3 - 앞 교육과정 요약 및 경로추출
Iteration4 - 앞 교육과정 요약 및 음성안내

이처럼 가장 중요하다고 생각하는 내용을 앞에 배치하면 전체 교육기간동안 총 4번의 반복을 통해 피교육자의 이해도를 높일수 있는 장점이 있다. 개발도 마찬가지이다. 가장 중요하다고 생각되고 광범위하게 참조되는 부분부터 Iteration1에 넣어두면 Iteration2를 통해 확장할때 Iteration1에서 개발한 핵심 엔진은 기능확장과 안정화를 거치게 된다. 그리고 또 한번 열게됨으로써 개발자가 코드를 더 친숙하게 여길 수 있는 기회를 준다.

아무튼 이렇게까지 Milestone과 시간사용계획을 짜놓았다면 이제 할 일은 각각의 조직의 역할을 정의하는 일만 남았다.
반드시 CASE by CASE로 짜놓자.
예를 들면 다음과 같이 짜놓는 것이 중요하다.

1. 요구사항 수행절차
 가. 요구사항을 JIRA에 등록한다.
 나. 요구사항은 고객과 개발팀의 협의체에서 우선순위를 조정하여 XX기준(일정 또는 범위 또는 업무량 등등) 으로 상위 OO개를 수행한다.

이렇게 개발공정에서 발생할 수 있는 CASE를 예상하고 각각의 조직과 개인이 해야할 일을 명시해놓고 개발 프로세스에 적용하자. 그래야만 혼란을 미리 막을 수 있으며 Prototype 개발 기간동안 의미있는 데이터를 획득할 수 있다.

암튼, 가장중요한 것은 계획은 계획일 뿐이라는 거다.
계획을 함으로써 앞으로 발생할 일에 대한 자원(인력, 돈, 시간 등)의 소모와 만약(if)에 대한 시나리오를 검토할 수 있는 기회를 준다.

마지막으로 각각의 Iteration에 대한 계획은 나중에 다룰 기회가 있으면 또 한번 다뤄보자.

어쩌다 규모산정을 한 김에 달리다보니 계획까지 와버렸다. -_-;;
어쩐지 진도를 다 못나간 느낌이다. 다음에는 다른 영역으로 진도를 나가보자. -_-;;

2011/03/24 13:37 2011/03/24 13:37

애자일 경험담 7

Developer 2009/08/28 22:39
오늘 할이야기는 근무 시간에 대한 이야기이다.
이는 WBS라는 전근대적인 Tool과도 직결되는 이야기이다.
일전에 한번은 개발팀내에서 얼마나 성과를 내는 일에 투자하는지 내 스스로 기록해보았었다.
회사에 나와서 내가 얼마나 주어진 일을 마치는데 투자하는지 스스로 체크해본것이다.

8시 40분~50분 : 출근해서 놋북키고 업무 준비
9시 ~ 9시 10분 : 그룹방송 시청
9시 10분 ~ 10시 : 전날 온 메일 확인 및 커피 뽑아오거나 화장실, 중요내용 체크, 오늘 할 일 정리
10시 ~ 10시 10~20분 : 업무보고 오늘 할 범위 상위관리자와 협의
10시 30분 ~ 11시 : 오늘 할일에 대한 사전 조사 및 어떻게 작성할것인지에 대한 구상
11시 ~ 11시 40분 : 약 40분간 보고서 또는 코드 또는 사업계획서 또는 기타 문서 작성 (40분)
11시 50분정도 ~ 1시 : 점심먹고 쉼
1시 ~ 2시 정도 : 다시 일하는 모드로 체인지하는 시간
2시 ~ 5시 40분정도까지 : 2~3번의 담배 피고 커피마시는 시간 1시간여를 제외한 2시간 30~40분동안 업무집중 (2시간 30분)
5시 40~50분 ~ 7시 : 저녁
7시 ~ 9시 정도 : 밀린 업무 질주 모드 (2시간)
퇴근전 30분 : 마무리 모드로 메일보낼것들 오늘 산출물 보고하고 메일들 답장 쓰고...
9시 30분 ~ 10시 : 퇴근

결과적으로 실재로 내가 부여받은 일을 하는 시간은 하루 일과중 4시간~5시간이 최대치였다.

어떤가? 스스로는 다르다고 생각하는가?
다음은 인크루트와 엠브레인 2군데서 2007년 3월부터 4월까지 직장인 2,036명의 설문 결과였다.
조사결과가 충격적이었다. 일일 평균 업무 집중 시간은 고작 2시간 30분인것으로 나타난 것이다.

스카우트에서는 2007년 5월 직장인 555명을 대상으로 조사한 결과는 이런 결과와 아주 비슷하다.
야근 횟수는 '거의 매일'이라고 응답한 직장인이 30.45%로 가장 많았고, '주 2~3회'가 27.75%, '주 3~4회'는 18.02%였다. 그 외 '월 1~2회 이하' 9.91%, '주 1회' 9.55%, '전혀 없음' 4.32% 순 인것이었고 야근시간은 하루 '평균 2시간~3시간'이라고 응답한 비율이 34.84%로 가장 많았고, '평균 3시간~4시간'도 32.96%나 되었다. '4시간 이상'을 야근한다는 직장인도 21.47%로 조사되었다. 반면 '2시간 미만'은 10.73%였다.

즉, 나는 9시에서 10시에 퇴근하는 32.96%에 속하는 직장인이었던 것이다.

그런데 우리 프로젝트 팀의 WBS는 어떠한가?
하루 근무 8시간을 전재로 계획을 수립한다.

즉, 하나의 업무를 시작하고 끝내는데 8시간이나 주어지는데 왜 못하냐는 것이다.
이 전제 자체가 틀렸다는 것이다.
대한민국 직장인의 업무 집중시간이 고작 2시간 30분인데 이때 회의라도 껴있어보라.
회의 사전 준비에 들어가는 시간 30분 정도에다가 1시간쯤 회의하고 녹초가 되서 나오며 담배한대 피며 회의 참석자들과 회의 결과에 대한 정리하고 회의록 작성하면 2시간 30분정도가 걸린다.
한마디로 하루에 회의 1번하면 끝나는 정도의 집중도 밖에 없는 인간에게 WBS계획은 로봇이 되라고 이야기 하고 있는 것이다.

그러니 매일매일 야근을 밥먹듯이 하는 것이다.

그래서 우리는 고객과 합의하에 WBS를 잡을때 TASK위주로 잡지 않았다.
즉, 언제부터 언제까지 무슨일을 한다라는 TASK가 아니라 언제부터 언제까지 무슨 산출물을 제출한다라는 Product로 설정하였다.

-이전 생략-
*TASK위주의 WBS (편의를 위해 담당자 및 휴일 제외)
프로젝트준비 2009. 5. 1 ~ 10
    +- 프로젝트 사무실준비 2009. 5. 1 ~ 3
    +- 프로젝트 사무실 사무가구 설치 2009. 5. 4
    +- 프로젝트 사무실 랜 설치 2009. 5. 5
    +- 프로젝트 사무실 좌석 배정 2009. 5. 5
    +- 프로젝트 사무실 입주 2009. 5. 6
    +- 개발서버 기동 2009. 5. 6
    +- 개발환경 설명 / 방법 공유 및 교육 2009. 5. 7 ~ 5. 10
요구사항분석
    +- 요구사항 협의 2009. 5. 11 
    +- 요구사항 정의 2009. 5. 12~14
    +- 요구사항 명세작성 2009. 5. 15 ~ 2009. 5. 20
-이하 생략-

이렇게 작성된 TASK의 문제는 전근대적인 관리 방법에서 이런 TASK를 프로젝트 진척도로 설정된다는것에 문제가 있다. 다시말해 TASK가 100개 있었는데 프로젝트 준비가 계획대로 아주 잘 진행됐다고 치면 벌써 8%의 진척을 보이는 것이다!
프로젝트 산출물은 아무것도 하지 않았는데 어떻게 8%라는 경이적인 진척율을 보이는 것인가?

따라서, 위와 다르게 우리가 작성한 계획서는 이런식이었다.
* Product위주의 Milestone
2009. 5. 10 사무실 설정/개발서버기동/개발방법 교육
2009. 5. 20 요구사항분석용 Prototype제출
2009. 5. 24 요구분석설계용 USE CASE제출
-이하 생략-

결과적으로 이렇게 작성된 Milestone위주의 일정계획은 정확하게 현재 내가 어디에 있는지 파악할 수 있도록하고 관련 TASK는 "성과평과 계획 및 결과 보고서"라는 Wiki에 그때 그때 Milestone에 따른 합의를 하였다.

합의과정을 통해 우리가 어느 시점에 있는지 자연스럽게 고객과 개발팀원이 인식할 수 있게 되었고 업무의 산출물을 작성할때도 작성이 완료된 팀원은 일찍 퇴근시키는 정책을 사용했다.
결과적으로 어떻게 해서든 일찍 퇴근하려는 팀원들이 하나둘씩 나타나며 업무의 진척은 빠른속도로 진행되었다.

회고해보면 빨리 자신의 업무를 마치는 팀원들의 업무방식은 이런식이었다.

1. 오전에 출근하자마자 불타는 모드로 돌입 (후에 물어보니 버스타고 오는 시간에 오늘 무슨일을 해야할지 그려본다고 하였다.)
2. 기본 템플릿 작성 및 초안 작성 오전중에 완료
3. 점심먹고 관련 약 30분간의 짧은 회의 소집 (담당자에게는 그에 합당하는 권한을 부여하는 것이 중요)
4. 프로젝터로 자신이 한 초안에 대한 Review 및 다른 사람의 아이디어, 결함 발견
5. inspection 회의록 작성후 자신이 작성한 문서 완료보고
6. 오후 2시 ~ 3시 퇴근

이런 식의 업무에 팀원들이 하나둘씩 1주~2주 사이에 나타나자 그들을 중심으로 2명~3명 단위로 묶어서 그룹별로 과제를 부여하였다.
그룹별로 업무를 부여 받은 사람들은 더 일찍 퇴근하는 방법에 대해 따른다. (이미 그런 방법으로 일찍 퇴근하는 선구자들에 대해 존경심이 충만해진 상태)
물론 처음에는 나이, 경력 등을 들거나 의견이 달라 퇴근 시간이 늦어지는 경향이 있지만 그룹별 퇴근 일찍하기 경쟁이 붙기 시작하면 서로 산출물을 빨리 내놓고 사라졌다.
(물론 이 순간에도 야근하는 그룹은 생기기 마련)

그때 부터는 프로젝트 진척이 굉장히 빨리 이루어진다. 내일 빨리 퇴근하기위해 오늘 일을 다 해버리는 경우도 생기도 했었다.



2009/08/28 22:39 2009/08/28 22:39