Software Survival Guide

Steve McConnel이라고 한다면 <Code Comeplete>, <Rapid Development>, <Software Project Survival Guide>, <Professional Software Development>의 저자이자 그가 주장했던 소프트웨어 개발 방법론은 Artifact(산출물) 많기로 유명하다. Joel Spolsky도 자신의 저서 <Joel on Software>에서 그것을 다시 언급했다. McConnel의, 혹은 그가 다닌 회사인 CxOne에서 제안하는 Artifact의 가지수는 엄청나지만 사실 CxOne에서 혹은 책이나 문서를 통해 제시되는 가이드에 보면 중요하다고 생각되는 부분은 따로 문서를 별도로 작성해야 겠지만 반대로 쓸모없는 것들은 상위 문서에 "필요 없는 것 같애"라고 적고 생략해 버리라도고 한다. 하지만 일부 몇가지 항목 들은 필수적인 것들이라고 한다. 이보다 이전의 개발방법론에서도 존재했었지만 McConnel이든 아니면 이후의 개발방법론들은 그것들을 좀더 명확하게 정의를 해 주거나 문서쓰기 정말 귀찮아 하는 사람들을 위해 효과적으로 그리는 법이나, 다른 방법으로 쓰는 법 등으로 가이드하였다고 생각한다. 사람에 따라서는 다른 소프트웨어 엔지니어링의 역사를 읊겠지만 개인적인 경험상으로는 Steve McConnel의 책들을 읽게 됨으로서 기존 프로젝트에 어떤 문제들이 있었고 결과를 해석함에 있어 나름대로의 분석이 가능하게 되었다. 물론 그 이후 다른 책들이나, 특히 최근의 "Agile"에 관련된 책 혹은 <The Art of Prject>가 다시 그 이후의 변화를 주긴 했다. 아무튼 새로운 주장이나 책은 기존의 문제점을 계속 개선하기 위한 작업이었으며 마일스톤급의 책들이 나올때 마다 기존의 어떤 문제들을 해결하려고 하였는지 흥미가 간다.

최신의 책들을 계속 읽어 보지만 그래도 아직 사용하고 있는 구닥다리 문서가 하나 있다면 바로 이것이다.

Software Survival Test

영어로 되어 있다고 머리가 아프시다면 <소프트웨어 프로젝트 생존 전략>(원저:Software Project Survival Guide, Steve McConnel, Insight 출판사)에 번역된 내용이 들어 있다. 프로젝트를 진행중이거나 막바지, 혹은 구원 투수로 들어갈때 적용해 보기 편하지만 시작단계에서도 사용할 수 있다. 항목들을 프로젝트 막바지에 다시 점수를 적는다고 했을때를 예상해 보면서 채점하면 된다.

저 Test에서 요구하는 항목들은 McConnel의 개발 방법론에서 요구하는 Artifact들이라 다른 방법론과 약간 충돌이 일어날 수 있다. 하지만 정확히 대응되는 다른 Artifact가 없을지라도 몇개로 나누어져 분명 고려되어야 하는 항목들일 것이다. 더불어 Project가 끝난 후 Review 경험이 있다면 각 항목들이 없음으로 해서 어떤 상황이 발생하였는지 되짚어 볼 수도 있을 것이다. 저 테스트에 0점 맞은 프로젝트도 몇명이 닝겔맞으면서도 수행해서 나름 성공을 시킬 수도 있고 100점 맞아도 회사에 불나서 망한 프로젝트도 있겠지만 나름 몸값 비싼 사람의 노하우랄까. 그래도 실제 회사에서 사용하는 개발방법론과의 차이가 클테니 점수로 판단하기 보다는 어떤 부분들을 놓치고 있는지를 확인해 보는 점검표로 사용하는 것이 좋을 것이다.


PS.
헌데.. 저거 처음본지 몇년 되지도 않았는데;;; 정말 오래된 문서가 되버렸다. 약간 물음표가 드는 항목들도 생겨버렸고 등등.

PS2.
"Artifact"를 한때는 "산출물"로 사용했지만 최근에 다시 "Artifact"로 돌아가게 되었다. 한때는 끽해야 문서나 그림정도였는데 이제는 비디오/오디오나 화이트보드의 포스트잇도 포함하니 "산출물"이라고 해봐야 느낌이 확 오지 않는다. 현황판용 화이트 보드에서 포스트잇이 달리기 하는 것을 "산출물"이라고 하기엔 느낌이 약하지 않은가.