"더 쉽고 재미있게 소프트웨어를 개발하는 방법"
이 책의 한글 부제입니다.
확실히 재미는 있겠더군요. 책도 재미있게 구성되어 있고요.
책의 전반적이 내용이 소프트웨어를 개발하는 과정을 재미있고, 쉽게 접근할 수 있도록 잘 작성되어 있습니다.
하지만 상당히 부족한 점이 발견됩니다. 그건 바로 "스펙"이죠.
이 책에서 소개하는 사용자 스토리와 태스크는 "스펙"을 대신할 수 있는 수준은 아닙니다. 사실 내용도 좀 다르죠.
이 세상에는 수많은 종류의 소프트웨어가 있는데, 그 중에서 일부는 이 책에서 소개하는 방법이 적당할 수도 있다는 생각이 듭니다. 예를 들어서 간단한 쇼핑몰 사이트를 구축하거나 그리 복잡하지 않는 비즈니스 시스템을 만들 때 좋을 것도 같습니다. 그 외에도 더 있겠죠.
하지만 사용자 스토리와 태스크를 기반으로 소프트웨어를 개발하게 되면 개발 후에 뭐가 남나 생각해보면 남는 것이 별로 없습니다. "스펙"은 단순히 소프트웨어를 개발할 때만 쓰이는 것이 아니고 유지보수 기간에도 계속 필요하며 차기 업그레이드에서도 필요합니다. 또 그 내용은 사용자 스토리와는 비교가 안될 만큼 다양한 내용이 포함됩니다. 결국 그러한 스펙의 필수 내용들은 무시된 채 개발이 될 수도 있고 개발자가 경험이 많고 재수가 좋으면 큰 문제가 없을 수도 있겠죠. 또 너무 단순한 사용자 스토리는 결국 러프한 요구사항을 가지고 개발하는 것과 큰 차이가 없습니다. 결국 개발자의 취향이나 능력에 따라서 기능이 달라지는 일이 발생하게 됩니다.
대부분의 소프트웨어 프로젝트에서 "스펙"은 매우 중요하며 꼭 필요합니다. "스펙"은 프로젝트의 커뮤니케이션의 중심이며 일정과 비용 산정의 기준이 됩니다. 이 책을 읽는 독자가 자신의 소프트웨어 프로젝트에 이 방법을 직접 적용하고 싶다면 "스펙"에 대해서는 큰 기대를 하면 안됩니다. 그리고 자신의 프로젝트에 적당한 방법인가도 생각을 해봐야 겠습니다. 또한, 이터레이션도 모든 소프트웨어 개발에 적당한 방법이 아닙니다. 이터레이션이 적합한 소프트웨어가 있죠.
물론 이 책은 쉽고 재미있게 잘 쓰여진 책입니다. 단, 이 방법이 모든 소프트웨어 개발에 적용되는 것이 적당하지 않다는 것을 알아야 할 것 같습니다. 하나의 좋은 방법을 소개한 것으로 보면 적당할 것 같습니다. 결국 원리를 깨우치고 자신의 개발팀에 알맞은 방법을 찾아나가는 것이 올바른 방법입니다.
어디에도 끝내주게 좋은 방법은 없으니까요.
