Head First Software Development 리뷰
2009/01/29 17:21 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
RSS Feed
"더 쉽고 재미있게 소프트웨어를 개발하는 방법"
이 책의 한글 부제입니다.
확실히 재미는 있겠더군요. 책도 재미있게 구성되어 있고요.
책의 전반적이 내용이 소프트웨어를 개발하는 과정을 재미있고, 쉽게 접근할 수 있도록 잘 작성되어 있습니다.
하지만 상당히 부족한 점이 발견됩니다. 그건 바로 "스펙"이죠.
이 책에서 소개하는 사용자 스토리와 태스크는 "스펙"을 대신할 수 있는 수준은 아닙니다. 사실 내용도 좀 다르죠.
이 세상에는 수많은 종류의 소프트웨어가 있는데, 그 중에서 일부는 이 책에서 소개하는 방법이 적당할 수도 있다는 생각이 듭니다. 예를 들어서 간단한 쇼핑몰 사이트를 구축하거나 그리 복잡하지 않는 비즈니스 시스템을 만들 때 좋을 것도 같습니다. 그 외에도 더 있겠죠.
하지만 사용자 스토리와 태스크를 기반으로 소프트웨어를 개발하게 되면 개발 후에 뭐가 남나 생각해보면 남는 것이 별로 없습니다. "스펙"은 단순히 소프트웨어를 개발할 때만 쓰이는 것이 아니고 유지보수 기간에도 계속 필요하며 차기 업그레이드에서도 필요합니다. 또 그 내용은 사용자 스토리와는 비교가 안될 만큼 다양한 내용이 포함됩니다. 결국 그러한 스펙의 필수 내용들은 무시된 채 개발이 될 수도 있고 개발자가 경험이 많고 재수가 좋으면 큰 문제가 없을 수도 있겠죠. 또 너무 단순한 사용자 스토리는 결국 러프한 요구사항을 가지고 개발하는 것과 큰 차이가 없습니다. 결국 개발자의 취향이나 능력에 따라서 기능이 달라지는 일이 발생하게 됩니다.
대부분의 소프트웨어 프로젝트에서 "스펙"은 매우 중요하며 꼭 필요합니다. "스펙"은 프로젝트의 커뮤니케이션의 중심이며 일정과 비용 산정의 기준이 됩니다. 이 책을 읽는 독자가 자신의 소프트웨어 프로젝트에 이 방법을 직접 적용하고 싶다면 "스펙"에 대해서는 큰 기대를 하면 안됩니다. 그리고 자신의 프로젝트에 적당한 방법인가도 생각을 해봐야 겠습니다. 또한, 이터레이션도 모든 소프트웨어 개발에 적당한 방법이 아닙니다. 이터레이션이 적합한 소프트웨어가 있죠.
물론 이 책은 쉽고 재미있게 잘 쓰여진 책입니다. 단, 이 방법이 모든 소프트웨어 개발에 적용되는 것이 적당하지 않다는 것을 알아야 할 것 같습니다. 하나의 좋은 방법을 소개한 것으로 보면 적당할 것 같습니다. 결국 원리를 깨우치고 자신의 개발팀에 알맞은 방법을 찾아나가는 것이 올바른 방법입니다.
어디에도 끝내주게 좋은 방법은 없으니까요.
'소프트웨어이야기' 카테고리의 다른 글
| 최고가 되지 마라 (11) | 2009/01/31 |
|---|---|
| 소프트웨어를 개발하는 끝내주게 좋은 방법 (0) | 2009/01/31 |
| Head First Software Development 리뷰 (3) | 2009/01/29 |
| 닭이 먼저일까? 달걀이 먼저일까? (0) | 2009/01/28 |
| 소프트웨어 공학이 뭔가? (6) | 2009/01/15 |
| 잔말 말고 시키는 대로 해 (6) | 2009/01/13 |
Trackback Address: http://allofsoftware.net/trackback/62
-
2009/02/03 12:08올바른 커뮤니케이션 방법, 그리고 누리엔! Tracked from Nurien Blog
Agile 방법론은 Software Requirements Specification 에 대해 어느 정도 비판적인 입장이라고 생각됩니다. 이에 관한 것은 Agile 방법론 관련 논쟁의 중심에 있는 BUFD(Big Up Front Design) 관련 논쟁에서 많이 언급되었다고 생각되고요.
책의 입장에서 방어적으로 얘기하자면 이 책은 다양한 방법론 중 Agile 방법론에 기반해서 소프트웨어 개발 프로세스에 대해 전반적으로 다루고 있으며 그러다 보니 '스펙'에 관한 내용이 당연히(?) 다루지 않았다고 봐야 될 것 같습니다.
요는 '스펙'에 대한 내용이 빠진 것이 이 책의 단점으로 로 지적될 수는 없으며 그보다는 Ray님 글에 직.간접적으로 표현되었듯 기타의 개발 방법론에 대한 추가적인 학습을 통해 균형(?)잡힌 시각을 세워나가려는 독자 자신의 노력이 필요할 듯 합니다.
tzara님 안녕하세요. 좋은 의견 감사합니다.
Agile 방법론에서 주장하는 바 계속 변하는 스펙과 초기에 고객의 요구사항을 다 파악하기 어려렵다는 것도 다 일리 있는 주장이죠. 물론 모든 프로젝트에 동일하게 적용하기 어려운 것이고 프로젝트마다 특성이 다르긴 합니다. 또한 SRS는 요구사항 분석의 어려움에 더해서 잘 작성하기가 어렵다는 것도 있습니다. 여기에 또 SRS에 대한 오해가 존재하는 것도 사실입니다.
국내에서 Agile 방법론을 접하는 수많은 개발자들이 요구사항 분석에 대한 기본 지식과 경험없이 바로 Agile을 적용하다보니 또 공허함이 존재하는 측면도 있습니다. Agile에서는 스펙이 없는 것이 아니고 다른 측면으로 접근하는 것인 것 뿐인데도 말입니다.
아무튼 여러 경험을 통해서 원리에 접근해 나가는 것이 현재 하고 있는 프로젝트에 가장 적합한 방법을 찾는 지름길이라고 생각합니다.
저도 SI 현장에서 애자일 적용을 통해 이익을 맛보았고, 전체적으로 애자일 접근을 선호하지만... Ray님 견해가 국내 현실에선 합당하다 생각합니다.
기민하긴 전이 있어야 애자일 할 수 있고, 묵직한 시절이 있어야 Lean 할 수 있는데...
상당히 많은 비중을 차지하는 개발인력이 방법론이나 프로세스의 필요성을 모르는 채로 비단 산출물의 많고 적음이나 추적성 내지는 형식성의 강약으로 "애자일" 운운하기도 하니까요.