Deadline Driven Development
일명 일정(or 마감일)-driven 개발 방법론.. ^^
바로 과거부터 현재까지 소프트웨어 업계에서 가장 신봉하는 개발 방법론이다.
Test-driven, Unified Process, XP 기타 등등..의 모든 개발 방법론은 Deadline-Driven의 발밑에 존재한다.이 개발 방법론에 따르면..
모든 개발은 Deadline을 정함으로써 시작된다.
제품의 범위를 규정하고, 가용 인력을 조사하는 행위는 모두 이 Deadline을 정하기 위한 극히 형식적인 사전 준비활동에 지나지 않는다.가장 이상적인 경우는 마케팅부나 운영, 영업부에서 Deadline을 못밖아 개발팀의 고민을 덜어주는 것이다.
일단 Deadline이 정해지면..
프로젝트에 문제가 생길 때마다 모든 계획은 Deadline에 맞춰 재편성된다.
핵심 인력이 빠져나가건, 핵심 기능이 동작하지 않건.. 그건 크게 중요치 않다.
심지어 Deadline까지 완성이 불가능하다는 인식을 모든 개발자가 공유하더라도
일단 Deadline까지는 밤새워 무언가를 해야한다.
하지만 Deadline이 지나고, 다음 Deadline이 정해지면
언제 그랬냐는 듯이 집에 가서 푹 자고 온다.물론 그날부터 당분간 밤샘은 사라진다.
Deadline-Driven Development의 다음 주기(cycle)가 시작됐음을 상징하는 현상이다.
농담같지만 대부분이 이렇게 한다.
사실 데드라인은 매우 중요한 요소일거지만, 문제는 일을 수행 가능한가
불가능한가에 상관없이 데드라인을 무조건 강압하고 본다는거다.
MDD(Money Driven Development) + DDD(Deadline Driven Development) 정도가 일반론일까?
분명 데드라인은 우리의 사회적인 관계로 인해 적지 않은 중요성이
있다. 디버깅에 실패할 수는 있어도 데드라인에서 실패할 수는 없다.
그런만큼, 일단 DDD 의 데드라인이 잘못되었는 판단이서면 우겨야한다.
특히나 MDD측면에서 무조건 데드라인을 우길경우에도 DDD가 불가능함을
잘 설명하는 것이 중요하다.
불가능한 데드라인을 제시할경우 TDD와 마찬가지로 기능을 과감히 빼버려야 한다.
필요하다면, 미래에대한 투자인 추상성을 과감히 제거한다.
결국, 총은 제 2의 생명이지만 데드라인은 생명이다.
p.s. 호.. wegra말마따나 이거 발전시켜보고 싶은 생각이든다.