각 기능의 추정치 잡기

너무 추정치가 큰 스토리는 쪼개야 하고, 너무 추정치가 작은 스토리들은 합쳐야 한다. 전체 팀이 구현하는 데 사나흘보다 더 걸리는 스토리는 없어야 한다. 마찬가지로 전체 팀이 구현하는 데 채 반나절이 안 걸리는 스토리도 없어야 한다. 너무 짧은 스토리는 과대평가하기 쉽고, 너무 긴 스토리는 과소평가하기 쉽다. 그러므로 스토리를 자르고 합쳐서 정확한 추정치 근처에 고루 분포되도록 해야 한다. 1

코드를 새로 짜기보다 기존 코드를 활용하자

  • 조엘 스폴스키 인터뷰 중에서

조엘: 찰스 퍼거슨이 쓴 멋진 책 [High St@kes, No Prisoners]에서 제가 배운 교훈은 기업의 비즈니스 목표를 이해하는 프로그래머를 고용해야 한다는 점입니다. "다시 구현할 경우에 회사가 치루는 진짜 비용은 얼마인가?", "제품 출시가 몇 달이나 늦어질까?", "시간 손실과 시장 점유율 하락을 만회할 정도로 제품 매출이 상승할까?" 등과 같은 질문에 답할 수 있는 사람들 말입니다. 그래도 다시 짜야 한다고 우긴다면, 필경 회사 재무나 경쟁 상황을 이해하지 못하는 탓입니다. 잘 설명해 주십시오 그런 다음 재구현에 들어가는 노력을 정직하게 예측해 달라고 요청하십시오. 비용 대 편익을 상세하게 분석하여 대조표를 만들라고 요구하십시오.

솔루션: 아, 그것도 괜찮은 생각입니다만, 믿거나 말거나, 프로그래머들이 이런 문제에 부닥치면, 흠 뭐랄까, "진실을 축소"한다고 하죠.

조엘: 프로그래머가 사용하는 유명한 개발 꼼수 말이군요. 내가 구현하고픈 기능은 모두 1시간 짜리이고, 내가 싫어하는 기능은 모두 99년짜리다. 프로그래머가 거짓말 한다 싶으면 단도직입적으로 정곡을 찌르십시오. 개월이 아니라 시간 단위로 일정을 쪼개라고 하십시오. 각 항목이 이틀 미만이어야 한다고 요구하십시오. 이틀이 넘게 걸리는 업무는 작게 나누어야 합니다. 그렇지 않으면 현실적인 일정을 얻기가 어렵습니다.

솔루션: 코드를 뒤엎고 다시 짜기가 올바른 선택일 경우는 없습니까?

조엘: 거의 없다고 봅니다. 굳이 들자면 새 플랫폼으로 옮겨가는 동시에 코드 아키텍처를 완전히 뜯어고치는 정도가 아마 가장 극단적인 예겠지요. 하지만 이런 경우라도 대개는 코드를 새로 짜기보다 기존 코드를 활용하는 편이 낫습니다. 2

참고문헌

  • [Martin] - UML, 실전에서는 이것만 쓴다 / 로버트 C. 마틴 (지은이), 이용원, 정지호 (옮긴이) / 인사이트 / 초판 2쇄 2004년 10월 5일 / 원제: UML for Java Programmers
  • [Chapman] - 초난감 기업의 조건 / 릭 채프먼 지음 / 박재호 역 / 에이콘출판사 / 발행 2007년 11월 20일 / 원제: In Search of Stupidity

주석

  1. [Martin] 7장. 150쪽. 

  2. [Chapman] 523쪽.