솔루션 위주의 개발은 결국 고객이 원하는 산출물을 제공하는 것을 목표로 하는 프로젝트 수행 과정이다. 세상의 모든 프로젝트가 이 고객만족의 목표를 위해 뛰고 있다. 하지만 과연 성공하고 있을까? 프로젝트 일정 후반기에 고객이 요구사항을 변경하는 것도 그들의 변죽에 의한 것이 아니라 어쩌면 고객이 원하는 solution을 만들고 있지 않기 때문일 것이다. 프로젝트를 하는 mind와 solution을 만드는 mind 사이에는 엄청난 차이가 있다. 프로젝트 자체를 위한 mindset에서는 solution이 나오기가 힘들다.
Agile, TDD, Pair Programming등의 프로세스 수행방법들을 많은 사람들이 들고 나오는 이유는 이런 solution을 더 잘 만들고자 하는 고민에서이지 결코 프로젝트관리를 위해서는 아니다. 즉, 합리적이고 효율적인 프로젝트 관리보다는 고객이 원하는 solution에 접근하기 위한 mindset을 만들기 위한 도구나 아이디어들인 셈이다.
더 깊이 들어가기 전에, waterfall적인 생각을 버리기 위해서...
사전에 치밀한 요구사항의 분석과 기획에 치중하는 것이 고객이 원하는 원하는 solution을 제공할 수 있는 해결책이 될 수 있을까? 물론 이 방법으로는 실패할 확률이 많다라는 통계적인 수치는 가히 압도적이다. 즉, 다른 대안의 절실한 필요성이 있었다라는 것.
누구나 solution 위주의 개발을 하자고 할 때 반대할 사람은 없을 것이다. 고민의 시작은 어떻게 개발을 할 때 solution위주가 되느냐 하는 방법론적인 문제로 결국 돌아온다는 것이다. 이런 프로세스에 대한 고민으로 test driven development라는 것을 먼저 살펴보자.
테스트주도개발: 테스트 주도 개발은 "Test First"라는 의미를 가지고 있다. 그리고 많은 사람들이 깨닫지 못하는 것은 이것이 software design 방법론이란 것이다. Test는 오히려 부차적인 산출물일 뿐 주된 목적은 "실제 쓰일 구현을 직접 test 환경에서 써 봄으로써 그 맹점이나 개선점을 미리 발견하고자"함이다. 테스트주도개발의 의미를 망치는 대부분의 사람들이 실제 구현을 먼저 해놓고 난뒤 그 구현에 제한된 테스트만을 만드는 이들이다. 테스트없이는 구현도 없는 test first가 되어야만 한다.
이렇게 작성된 테스트들은 기획자들이 만드는 wireframe과 마찬가지로 앞으로 내가 만들 실제 solution의 구현 wireframe이 된다는 것이다. 왜냐하면 테스트들이 결국은 고객의 요구사항을 테스트하는 것이기 때문이다.
앞으로 다룰 주제;
acceptance test = replacement of prototype methodology
mock objects = domain modeling and interface design
Pair Programming:우선 one engineer + one engineer = two engineers 란 명제는 거짓이다. more than two engineers의 역량이 창출된다는 것이다. 이런 synergy가 solution 위주의 개발 방법의 발전에 지속적으로 공헌할 것이라는 아이디어는 거의 믿음이다. 하지만 기획자와 개발자의 pair는 가공할 만한 조합이라고 본다. 그리고 pair programming을 굳이 프로그래밍만 국한시키지 말라. proposal, schedule, documents 모든 것을 pair로 할 수 있다.
Continuous Integrationsolution에 가장 근접한 형태의 system을 지속적으로 테스트해나가자는 의미이지만 이또한 테스트에 중점을 두기보다는 초기에 solution의 시스템을 구축해봄으로 미래에 생길 수 있는 문제점을 빨리 발견하고 지속적으로 해결해나가자는 취지가 더 크다. 이 개념을 조금 더 push하게 되면 prototype에 가까운 의미가 될 수 있지만. 지금 구축하고 있는 시스템이 실제 산출물일 것이기 때문에 사실상 prototype은 아니다. key는 바로 가장 중요한 main 이나 baseline product을 제한된 기능으로 구축한 뒤 iterative하게 evolve시켜나가는 것이다.
이 baseline solution이 필요한 가장 큰 이유는 고객과의 communication이다. 즉, 실제 solution을 기획자와 개발자 그리고 고객이 같이 보면서 이야기를 해보자는 것이다. 최대한 빨리 실제 solution을 고객에게 보여줌으로써 그들이 생각하지 못했던 요구사항을 프로젝트 초기에 발견해 내자는 것이다. 고객이 원하는 solution에 대한 feedback도 항상 그 실체를 보고 스스로 작동해 볼때 더 풍부해지기 때문이다.
Agile하지만 이렇게 solution centric을 위해서 baseline product을 미리 만들고 evolve시킨다는 것은 말처럼 그렇게 쉽지 않다. 우선 이런 목표를 달성하기 위해서는 agility 즉, 빨라야 한다는 것이다. 빨리 개발초기에 prototype으로 쓰일 실제 system을 구현하고 그것을 통해서 지속적인 refactoring과 iteration을 하기위해서는 프로젝트 수행과정이 유연하며 기민해야 한다. 그래서 agile 방법론이란 말이 나온 것이다. 하지만 agile이란 교과서에 나오는 step by step 절차가 아니라 팀의 mindset 변화에 의해서 내재화되는 자기들만의 프로세스여야 한다. 어느 교과서에도 모든 팀에게 맞는 절차는 없다. 그러나 한가지 확실한 것은 mind가 변할 때 자기들에게 맞는 프로세스에 대한 아이디어로 생긴다는 것이다.
앞으로 다룰 주제;
agile modeling
agile domain modeling
refactoring by layer = MVC pattern
즉, 고객만족의 궁극적인 목표를 가지고 나온 대안들이라면 기획자던 개발자던 프로젝트 매니저던 한번쯤 믿고 따라올 만하지 않을까? 많은 사람들이 snap judgment란 것을 통해서 이 방법론의 potential을 보았고 실제 프로젝트에 적용하면서 성공적인 사례도 많다.