[서평] Head First Software Development

Head First Software Development
2011-11-02
댄 필로네 지음,  황상철 옮김, 한빛미디어

Head First는 Design Patterns 보고, 두번째 입니다. Head First Java는 구매만 하고 보질 않았네요. Head First는 설명이 필요 없을 정도로 유명하고, 좋은 시리즈입니다. HFSD도 명성에 걸맞는 내용입니다.

Software Development는 사실 한권에 담기 어려운 큰 주제입니다. 이 책은 Agail 방법론에 기반해 소프트웨어 개발을 어떻게 관리할 것인가에 대한 전체적인 그림과 세세한 사항을 짚어줍니다. 자바때문에 약간 덜그럭 거리는 부분은 있지만, 분량도 그리 많지 않아 가벼운 마음으로 빠르게 읽기 좋습니다.

이렇게 함부로 정리해도 될지 모르겠지만, 내용을 간단히 요약하면 1) 사용자의 요구사항을 수집해서, 2) 사용자 스토리로 정리합니다. 3) 이를 태스크로 만들고 4) "충분히" 좋은 설계를 한 후에 5) 버전 관리, 6) 빌드 관리, 7) 테스트 관리 등의 기법을 사용해 8) 개발을 합니다. 그리고 이 모든 것은 9) 20일, 한달 가량의 이터레이션으로 묶어 계속 반복한다는 내용입니다^^
저는 "커다란 현황판"이 가장 마음에 와 닿네요.

* 이터레이션으로 목표 달성하기
- 이터레이션이 없는 경우 : 문제와 가정이 생길때마다 프로젝트는 점점 목표와 멀어져 고객이 바라는 모습이 아닌 결과물이 나옵니다.
- 이터레이션이 있는 경우 : 문제가 생겨도, 고객의 생각이 바뀌어도, 중간중간에 고객의 피드백을 받아 수정해가면서 진행하기 때문에 고객이 원하는 결과를 만듭니다.

* 각 이터레이션은 작은 프로젝트와 같고, 요구사항 > 설계 > 코드 > 테스트 > 피드백을 계속 반복합니다. 즉 각 이터레이션은 품질 좋은 소프트웨어입니다.

* 고객 요구사항을 알기 위해서는 크게 생각해야 합니다. 개별적으로 브레인스토밍을 한 다음 모여서 다시 좀 더 브레인스토밍을 합니다. 떨어져서 무슨 일이 일어날지 생각해 보고 돌아와서 다 같이 두번째 미팅을 합니다. 혹은 역할극을 하고, 사용자들 관찰하는 방법으로 고객의 요구사항을 알아냅니다.
하늘은 한계가 없기 때문에 요구사항을 받을 때도 블루스카이를 한다고 생각하세요. 그렇게 고객에게 더 많은 정보를 달라고 말합니다.

* 사용자 스토리가 정리되면 계획 포커 게임을 합니다. 개발자들이 각 스토리에 대해 예상되는 일수를 카드로 제시하고, 그렇게 생각한 이유를 설명하면서 서로간의 합의 가능한 추정치를 찾아갑니다.
너무 동떨어진 추정치에서 많은 사람이 놓치고 있는 가정이 나올 수도 있습니다. 또, 모두의 추정치가 비슷해도 서로가 생각하는 바를 이야기합니다. 추정치가 너무 크다면, 스토리를 나눌 수 있는지 확인합니다.
가정에 대해 가정을 하지 마세요. 모든 것을 이야기해야 합니다.

* 스토리에 우선순위를 부여하고, 선행 작업을 확인합니다. 이렇게 스토리에 우선순위와 추정치가 결정되면, 20일 기준으로 팀에서 할 수 있는 만큼의 스토리를 선택해 이터레이션들을 구성합니다. 그리고 첫번째 이터레이션을 진행합니다. 이때 팀의 개발 속도는 0.7로 고려해서 시행착오에 대비합니다.

* 이터레이션으로 계획이 세워지면, "피곤하게 하는" 혹은 "동정의 여지가 없는" 고객을 다루어야 합니다. 이터레이션 계획을 설명하고, 범위를 벗어나는 사용자 스토리는 없어지는 게 아니라 연기하는 것뿐임을 설명합니다. 구체적으로 수치가 어떻게 나왔는지를 설명합니다.

* 벽에 "커다란 현황판"을 만드세요.(이건 정말 해 보고 싶어요!!!)
한쪽에는 처리할 사용자 스토리가, 가운데는 처리 중인 스토리의 태스크가, 다른 한쪽에는 소멸 그래프와, 다음 이터레이션으로 넘어갈 스토리, 그리고 완료된 스토리를 놓은 큰 현황판입니다. 
현황판을 직접 적용해서 친절하게 사진까지 올려주신 블로거가 있습니다. 꼭 한번 방문해 보세요.
커다란 현황판 : http://mckdh.net/353

* 일은 스토리에서 태스크를 확정하는 것으로 시작합니다. 태스크는 개발자에게 할당되어 개발이 시작됩니다. 그리고 매일 간단한 미팅을 위해 "스탠드업" 미팅을 진행합니다.
이 모든 작업이 일을 줄여주지는 않습니다. 하지만 우리가 어디에 있는지를 "정확히" 알고 있습니다. 더욱이 고객도 우리가 어디에 있는지 알고 있습니다.

* 충분히 구현 가능한 좋은 설계와 안전한 개발을 위한 버전 관리, 작성한 코드 빌드하기, 그리고 테스트와 지속적인 통합은 가볍게(?) 넘어갑니다.

* 이터레이션에서 위의 방법을 통해 할 수 있는 일은 고객 주도적 기능, 코드 컴파일, 감시되는 빌드, 지속적으로 테스트된 코드, 견고한 테스트 커버리지, 믿을 수 있는 진행상태 추적, 팀에 알맞는 속도로 나아가기 등입니다. 이제는 테스트팀의 테스트와 여기서 발견된 버그를 수정합니다.
버그까지 마무리가되면 이터레이션을 마무리하고, 첫번째 버전을 정식으로 배포합니다. 그리고 이터레이션 마지막날 이터레이션 리뷰를 진행합니다. 이번 이터레이션이 어떻게 진행되어 왔는지를 느낀 점을 서로 전달하는 시간입니다. 진취적인 자세를 취하고, 속도와 범위를 파악해서 지표를 계산합니다. 이제 잠시 휴식을 취하며, 훈련이나 교육을 위한 시간을 갖거나, 다음 이터레이션을 위한 프로토타입을 만들어 보세요.

* 작동하는 소프트웨어는 이터레이션을 마쳐야 하고, 테스트를 다 통과해야 하며, 고객이 만족해야 합니다.
우리가 개발하지 않은 코드, 라이브러리, 혹은 프로그램이 만약 그것이 우리의 소프트웨어에 적용된다면 이제는 우리의 책임입니다. 외부 업체와 다른 사람이 우리의 프로세스를 따르리라고 가정하면 안 됩니다. 적용된 코드, 라이브러리, 프로그램을 우리의 시스템에 넣고, 우리가 코드를 만든 방식 그대로 관리합니다.

* 소프트웨어 개발 프로세스를 명확히 합니다. 좋은 프로세스가 좋은 소프트웨어를 만듭니다.
현황판, 사용자 스토리, 버전 관리, 지속적인 통합, 테스트 주도 개발, 테스트 커버리지를 사용합니다.