[5부 프로세스의 일부] Chapter21 얼마나 걸릴까?

얼마나 걸릴까?

 

소프트웨어 소요 시간 추정이라는 마술

 

이 장의 내용

 

• 소요 시간의 추정이 필요한 이유는?
• 추정이 어려운 이유는?
• 실무적인 추정 방법
• 일정 지키기

 

복잡하지만 소프트웨어 개발 프로세스에 필수적으로 필요한 일부이고, 모든 프로그래머들이 반드시 배워야 하는 것

 

소프트웨어 회사의 경비 대부분은 인적 자원에 들어가기 때문에 시간을 추정하는 것은 중요하다

상업적으로 성공적인 소프트웨어를 만들어내기 위해서는 엄청난 통찰력과 계획이 필요고 배짱도 필요하다.

우리가 계획을 하지 않으면 의도한 대로 제품을 만들게 되는 것이 아니라, 되는 대로 만들게 될것이다.

추정은 프로젝트 계획 과정의 필수적인 일부이다.

소요 시간에 관한 정보를 제공할 수 있는 유일한 사람은 그 일을 해야 하는 프로그래머이다

 

눈감고 찍기

소요 시간을 추정한다는 것은 근거 있는 짐작을 하는 것 이상이 아니다.

 

추정의 품질은 당신이 그 일을 얼마나 잘 알고 있는지에 따라 가장 많이 결정된다

추정을 할 시간이 얼마나 있는지, 그 시간동안 실질적인 설계나 실현 가능성의 검토를 얼마나 많이 할 수 잇는지에 따라서도 달라질 것이다.

아주 정확한 규격서가 있으면 짧은 시간 안에 추정을 할 수 있지만, 규격서가 모호하면 몇 년이 걸릴 수 도 있다.

시간이 충분히 없다면 최악의 예상 수치를 만들어서, 실제로 개발을 하다가 그 시간을 넘기는 일이 없도록 만들어야 할 필요가 있을 것이다. 소요 시간의 추정에 공을 덜 들일수록 당신은 그 수치에 확신을 덜 가지게 될 것이고, 현실과의 편차는 커질 것이다.

 

프로그램 작성에 대한 추정은 굉장히 어려운 일은 아니고, 정말 어려운 일일 뿐이다

 

추정이 그렇게 어려운 이유는?

소프트웨어 소요 시간 추정은 필자가 가족들이 사는 곳에 가는 데 얼마나 많은 시간이 걸릴지를 추정하는 것과 비슷하다

 

소프트웨어 계획을 세울 때는 예상 할 수 있는 잠재적인 문제점들을 계산에 넣어야 하고, 써드파티에 대한 의존을 관리해야 하고, 예기치 못했던 일에 대처하기 위해 비상 계획을 세워야 할 필요가 있다

잘못된 추측으로 인해 일어날 수 있는 결과는 프로젝트의 성공과 실패, 회사의 부채 상환 능력에도 영향이 미칠 것이다

 

추정을 까다롭게 만드는 방해 요소

• 우리가 고려해야 할 변수들이 많다. 본래의 복잡성, 코드 설계가 내포하는 의미, 새로운 시스템이 들어갈 기존 소프트웨어 생태계와 관련이 있다
• 새로운 문제점과 사용자 요구사항
• 관련된 일에 대해 모두 알지 못할 때
• 기존 시스템에 대해서 배워야 시간이 얼마나 걸릴지 추정할 수 있다
• 사전 경험이 없을 때
• 써드파티에 의존하고 있을 때

 

추정은 어렵다. 하지만 그렇다고 해서 안 해도 되는 것은 아니다

 

추정 결과를 받아들이는 것

• 추정치가 계약의 일부가 되도록
• 다른 사람이 해 놓은 추정치에 맞춰서 일하는 것은 힘들다
• 개발 도중에 발견되는 새로운 일은 추정에 영향을 미친다
• 미리 알 수 없는 문제점으로 인해 일정을 혼란에 빠뜨린다
• 추정치는 우리에게 부과되는 또 다른 책임이다 : 코드 설계를 잘하고, 유지보수가 쉬운 훌륭한 코드를 만들어 낼 책임만 있는 것이 아니다: 약속된 시간에 맞춰서 코드를 납품해야 한다

 

압력 속에서

희망적인 이상이 아니라 현실에 기반을 두고 추정을 해야 한다

이상적인 세상에서는 타당한 시간 안에 프로젝트가 수행 가능할지 증명하는 실현 가능성 리뷰를 한 다음에 프로젝트 데드라인이 확정된다.

하지만 현실 세계에서는 이런 일이 거의 없다

데드라인을 부여받고 어떻게 납품을 할지 생각을 해야만 한다.

 

실무적인 추정 방법

추정도 다른 스킬과 마찬가지로 경험을 하면 더 잘 할 수 있게 된다

추정의 정확성을 향상시킬 수 있는 간단한 스텝

1. 일을 가능한 한 가장 작은 덩어리로 나누자. 시스템 설계의 실질적인 첫 번째 패스(pass)에 해당한다
2. 이해하기 쉬운 적당한 크기의 구성요소들로 잘게 나누었으면, 각각의 덩어리에 대해 맨아워(man-hours)또는 맨데이(man-days) 단위로 소요 시간을 추정
3. 각각의 소요 시간을 모두 추정하고 난 다음에는 그것을 연속해서 늘어놓고, 기간을 합산하자.

 

소프트웨어을 납품하는 데 필요한 모든 활동을 고려하는 것은 극히 중요하다

• 충분한 생각을 거친 설계 수행하기
• 필요한 탐구 작업 또는 프로토타이핑 모두
• 실질적인 코드 구현 작업
• 디버깅
• 단위 테스트 코드 작성
• 통합 테스트
• 문서 작성하기
• 프로젝트 수행 기간 동안 착수할 모든 연구와 훈련

 

추정은 반드시 현실주의적이어야 한다

하지만 간단하게 처리할 수 있는 일에 대해 실패할 수 있는 천가지 방법을 발명해서 추정치를 부풀리는 근거로 삼지 마라

 예) 하는 일을 숨기기, 게임을 하면서 보낼 시간을 더 갖기 위해 과도한 추정을 하기

위험은 프로젝트 수준에서 관리되어야 한다; 일정을 짜는 사람이 우리가 만든 추정치를 가져다가 적당힌 비상 계획이 포함된 합리적인 계획서 안에 집어 넣을 것이다

더 정확한 추정을 위해서는 다음과 같은 중요 문제들을 생각해보자

• 프로젝트가 확실하고 구체적일수록 추정을 하기는 더 쉬워진다. 바람직한 규격서를 받았는가?

규격사가 없으면 당신이 하나 작성해서 이해당사자들에게 승인을 받아라

• 요구되는 기능이 많을수록 추정은 더 어려워진다. 불필요한 작업은 모두 깎아내려고 노력하라

추정에 관한 정보를 위로 피드백하고 프로젝트의 의사결정자는 요구사항 각각의 중요성과 기술적인 어려움의 균형을 맞출 수 있다

• 전체적인 문제를 완전히 이해하지 못하면 잘못된 추정을 하게 될 것이다 - 추정치의 정당성을 입증할 수 없다면 제출하지 마라
• 해야 할 일이 써드파티의 입력에 의존한다면 추정은 더 어려워진다
• 사람들은 똑같은 일을 하더라도 일하는 속도가 서로 다를 것이다
• 위로부터 낙관적인 추정을 하라는 압력이 들어와도 받아들이지 마라
• 가장 중요한 것은 초과 근무를 할 계획을 미리 잡아놓으면 절대 안된다

 

제임스 셔로위키(james Surowiecki)는 대중의 지혜(The Wisdom of Crowds)

 

격리된 상태에서 추정을 하지 마라. 다른 사람들의 의견을 구해서 추정치의 품질 향상에 도움을 받아라

 

계획 세우기

연결되지 않은 개개의 소요 시간 추정치들은 일정 관리가 가능한 프로젝트 계획으로 변환 시켜야 한다

간트 차트 (Gantt chart) - 찾기

 

정말 중요한 부분은 위험 관리(risk management) 부분이다

 

최고로 안전한 프로젝트 계획

• 크리티컬 패스를 줄인다
• 크리티컬 패스 (critical path)란 프로젝트의 시작부터 끝까지 추적되는 한 줄로 연속된 일들을 말한다
• 계획에는 항상 - 본래부터 크리티칼 패스가 있다
• 우리는 가장 적은(또는 가장 덜 위험한) 크리티컬 패스를 제공하면서 최적으로 병렬화 하는 것을 목표로 삼아야 한다
• 지나치게 병렬화 하지 않는다
• 프로젝트 계획을 지나치게 병렬화하는 일이 절대 없어야 하고, 개발자 각자가 일을 병행해서 하게 하지도 말아야한다
• 너무 길게 잡지 않는다
• 긴 프로젝트 계획은 지나치게 모호하다
• 반복적이고 점증적인 개발로 이득을 볼 수 있다; 커다란 개발 일정을 더 작고, 덜 위험하고, 더 쉽게 관리할 수 있는 작은 개발들로 되풀이되게 함으로써 가능하다

훌륭한 계획은 다음과 같은 것들이 계산에 들어간다

• 휴가
• 일정에 반드시 포함한다
• 업무 부하
• 정상적인 방해 요소(회의, 훈련, 질병 등)를 반드시 계산에 넣어야 한다
• 뜻밖의 사고
• 위험 요소는 각각의 소요 시간을 추정하면서 관리하는 것보다, 프로젝트 수준에서 관리하는 것이 가장 좋다
• 백만불짜리 질문: 뜻밖의 사고에 대한 비상 계획을 얼마나 포함시켜야 할까? 바람직한 전략은 각 업무에 확신치를 부여한다. 이것을 기초로 해서 아무 위험한 업무에는 계획에 가업무?를 추가해서 "위험 시간"으로 삼아라 그리고 그것을 원래 업무 길이의 일부분으로 만들어라
• 통합
• 전체 시스템이 기대했던 대로 작동하는지 테스트할 시간을 예약해 둬라. 디버긴을 해야 할 필요가 있을것이고, 컴포넌트들이 만났을 때만 드러나는 문제가 있을 것이다.
• 지원 업무
• 업무 부하의 일부분으로 만들어라
• 총정리
• 계획의 마지막 부분에 깔끔하게 정리할 시간을 둬라
• 데드라인에 맞추기 위해 귀퉁이가 잘려져 나가는 일이 종종 있다. = 기술적인 빚(technical debt) 축적

 

기초 원리를 알아두는 것은 중요하다. 계획에 맞춰서 소프트웨어를 개발 할 수 있어야 하고, 하도록 요청된 것이 정말 무엇인지 알기 위해 계획 뒤에 있는 근본적인 원리를 알아야 한다

 

계획모델 종류

퍼트 PERT(Program Evaluation and Review Technique: 프로그램 추정 및 리뷰 테크닉)

각각의 업무에 대해서 납품 일자에 맞출 수 있는 세 가지 가능성을 추정한다: 최선의 경우, 최악의 경우, 적당한 경우

보엠(Boehm)의 COCOMO(Constructive Cost Model: 건설적인 비용 모델) -> COCOMO II

PRINCE(Projects in Controlled Environments: 제어된 환경 하에서의 프로젝트) -> PRINCE2

 

뒤처지지 마라!

일정을 지키고 압박을 예방할 수 있는 방법

• 새로운 일을 시작할 때는 할당된 소요 시간이 정말로 실무적인지 체크하라
• 일정표를 참조하라 : 스스로 데드라인을 맞출 수 없을 것이라는 걸 알게 되면, 가능한 한 빨리 알려서 계획을 조정할 수 있게 하라, 진행 상황이 계획과 맞지 않는지 계속 모니터링 하라
• 필요한 만큼만 일을 하고, 그 이상은 하지 마라 : 중요한 추가 작업은 당장 필요할 경우를 제외하고 나중 일정에 추가되도록 요청 하라
• 모듈화를 활용한 신중한 설계는 컴포넌트 간의 의존을 줄이기 쉽고, 그래서 일이 잘못되었을 때의 악영향을 줄이고, 일정에서 여러 일들이 뭉치는 현상을 줄인다, 스터브 컴포넌트(stub component)
• 훌륭한 코드를 작성하고, 철저한 단위 테스트 코드도 함께 작성하라
• 요구사항과 규격서가 변경되는지 지켜보고, 개발 소요 시간에 어떻게 영향을 미칠지 추적해라
• 계획이 포함되어 있지 않은 다른 일은 하지 마라
• 긍정적이고 낙천적인 접근 태도를 유지하라

 

간추림

추정 테크닉을 발전시키는 것을 목표로 삼아라!

깔끔한 일정의 개발 계획을 망칠 수 있는 잠재적인 문제점들을 조심하고, 일정에 맞춰서 일하는 방법과 일정이 비실용적인 때를 식별하는 방법을 배워라

 

좋은 프로그래머는…

• 개발 프로세스의 모든 부분에 대해 잘 생각하고, 건실한 컴포넌트 분할에 기초해서 훌륭한 소요시간 추정치를 만들어 낸다
• 예상 소요 시간 안에 완전히 문서화되고 테스트된 코드를 만들어내고, 올바르게 통합시키려고 노력한다
• 소요 시간의 문제점을 일찍 부각시켜서 처리 될 수 있게 한다

나쁜 프로그래머는…

• 오로지 육감과 직관에 기초한 자기가 희망하는 추정치를 만들어 낸다
• 추정된 소요 시간 안에 약간의 코드를 해킹하듯이 만들어내기는 하지만, 높은 품질의 제품과 버그 없는 코드를 만들어내지는 못한다
• 소요 시간의 문제점을 받아들이는 것을 약함의 표시라고 생각하고, 바고 같이 그것을 따라잡으려고 애쓴다 - 실패했을 때는 바보 같아 보이고 지쳐 보인다