목차
4. 프로세스에 대한 오해
프로세스에 대한 오해
소프트웨어 프로세스는 소프트웨어 개발을 위한 생산적인 절차이다.
이 소프트웨어 프로세스에는 요구사항의 문서화, 요구사항에 대한 변경추적, 버전관리 툴을 통한 소스코드 관리, 결함 추적 등이 있을 수 있다.
흔히 프로세스에 대한 오해, 즉 프로세스가 실제 개발을 위한 생산적인 업무를 저해한다는 생각을 갖기 쉬우나, 프로젝트가 진행될수록 프로세스의 중요성을 사건이 터질 때 마다 한번씩은 느끼게 된다.
예컨대, 소스코드의 정기적인 백업, 버전관리 툴을 통한 소스코드 관리 등의 프로세스 부재로 인해, 열심히 작업했던 소스코드를 누군가 엎어 쓰면서 재작업을 해야만 했던 가슴 아픈 추억은 누구에게나 있을 것이다.
그림 15에서 처럼 프로젝트 초기, 프로세스를 제대로 계획하지 못하면 프로젝트가 끝날 무렵이면 갖가지 문제로 인해 허비하는 시간은 늘어나고, 이를 방지하기 위한 프로세스도 늘게 된다.
그림 15 프로세스에 무신경한 프로젝트의 실 사례 (McConnel, Software Project Survival Guide , 2003, p. 51)
따라서 프로젝트 초기, 프로세스에 대한 계획과 이에 대한 프로젝트 팀원들의 충분한 교육 및 공감대를 형성하도록 노력해야 한다.
그림 16 프로세스에 관심을 기울인 프로젝트의 실 사례 (McConnel, Software Project Survival Guide , 2003, p. 53)
앞서 소프트웨어 프로세스를 "생산적인" 절차라고 했음에 유념해야 한다. 결코 불필요한 산출물을 많이 만들거나, 복잡한 절차를 따르는 것이 생산적인 것은 아니다. 산출물은 프로젝트팀과 고객과의 의사소통 수단을 목적으로 하여야 하지 프로젝트팀의 최종 목적물이 되어선 안 된다. 프로세스는 프로젝트 팀이 쉽게 이해하고 실천할 수 있는 수준에서 정립이 되어야 한다. 복잡하게 여러 단계를 거쳐야 하는 프로세스는 프로젝트 팀의 큰 부담이 되며 신속한 진행을 가로막는 요인이 되기 쉽다.
고객과 산출물에 대해서 얘기를 하는 중에 특정 산출물이 꼭 필요하다고 얘기를 했다. 이러저러한 이유를 들어 문서를 만드는 것이 이번 프로젝트에는 맞지 않는다고 얘기를 하니,
“전문가가 와서 보면 시스템에 대해서 쉽게 이해할 수 있는 좋은 문서라 하던데요.”
다 뻥이다.
아마 무슨 교육에선가 이 문서의 중요성에 대해서 들었나 보다. 프로젝트팀에서 이해치 못하고 운영자가 이해치 못하는 문서는 쓸 때가 아무 곳에도 없다. 프로젝트팀이 그 시스템의 최고 전문가다. 보여주기 위한 문서가 아니라 정말 필요하고 사용하기 위한 문서를 만들어야 한다.
Agile Software 개발을 주창했던 Martin Fowler, Kent Beck, Ron Jeffries1 등이 그들의 저서와 애자일 소프트웨어 개발 선언2을 통해 고객의 책장을 장식하는 두꺼운 문서보다 제대로 돌아가는 프로그램의 중요성에 대해서 역설했다.
이러한 그들의 주장이 정작 필수적인 문서마저도 쓰기 싫어하는 프로젝트팀의 이론적 기반이 되기도 하는 데, 그러나 소프트웨어 개발에 있어, 요구사항의 문서화 등은 반드시 이뤄져야 하며, 이에 대해Ron Jeffries가 Extreme Programming Uninstalled3 라는 글에서 다음과 같이 밝혔다.
사람들이 글쓰기에 어려움을 느낀다는 것은 사실이며, 쓰여진 말은 오해를 일으키기도 한다. 그러나 적어도 이것은 변화하지는 않으며, 사람들에게 이해를 위한 많은 시간을 준다. 우리가 이해할 수 있는 문서를 가지고 있지 않으면, 우리는 동작하는 Software를 새로 만들 수 없을 지 모른다
프로젝트의 문서작업은 필수불가결한 것이며, 프로젝트팀과 고객과의 의사소통을 위한 수단으로써 합리적인 방법으로 작성되어야 한다.
특히 요구사항을 꼼꼼히 문서화 하도록 하자. 이 문서가 프로젝트의 양을 줄여주지는 못 할지라도, 우리 고객의 얼마나 변덕스러웠으며, 그로 인해 프로젝트 팀이 얼마나 힘들어 하고 있는지를 증명할 것이다.
목차
4. 프로세스에 대한 오해
