5장, 손쉬운 기능명세 작성법
- 명세서 없이 코딩에 뛰어드는 짓은 하지말자
- 명세서 작성에서 얻을수 있는 결실은 프로그램 설계이다.
- 작성한 설계서를 바탕으로 고객이 원하는 바를 파악하고 다시 설계서를 수정함으로써 삽질을 줄일수 있다.
- 시간을 절약할 수 있다.
- 명세서를 바탕으로 팀의 협업이 원활히 진행될 수 있다.
- 명세서는 전지전능하며 모든 업무의 기본이다.
6장, 명세서가 뭡니까?
- 기술 명세와 기능 명세는 명백히 다르다.
기술 명세 ( functional specification )
완전히 사용자 관점에서 제품이 어떻게 동작할지를 기술한다. 어떻게 구현했는지는
신경 쓰지 않는다. 기능에 대해 이야기하고, 화면, 메뉴, 대화상자와 같은 사용자
인터페이스 부품을 명세한다.
기능 명세 ( technical specification )
프로그램의 내부 구현을 기술한다. 자료구조와 관계형 데이터베이스 모델과
프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 다룬다.- 명세 단골 항목
1. 면책 조항 : 이 명세는 완벽하지 않다.
2. 저자 : 저자는 1명으로 책임을 단일화 한다.
3. 시나리오 : 제품 사용 방법에 대한 시나리오 작성
4. 회피 목표 : non-goal -> 쓸모 없는 기능을 제외시키는 항목
5. 개괄 : 목차와 유사
6. 세부 사항, 세부 사항, 세부 사항 : 너무나도 자세해 못 견딜 만큼 따분한 세부 사항
7. 미해결 문제 : open-issue -> 토론의 장을 열어놓기
8. 방주 : 명세서를 읽는 사람은 테스터, 마케터, 팀원 등 다양하다. 따라서 자세한 기술을 원할때는 기술 노트, 테스팅 노트, 마케팅 노트 등등 각주를 포함한다.- 명세는 지속적으로 개정해야 한다.
7장, 누가 명세를 작성하나?
- PM
- 코드 개발자를 프로그램 관리자로 승급시키지 말라
- 마케팅 부서 사람을 프로그램 관리자로 승급시키지 말라
- 프로그래머가 프로그램 관리자에게 보고하는 체제가 되어서는 안된다.
8장, 명세 팁
- 명세서 작성에서 가장 큰 걸림돌은 아무도 명세서를 읽지 않는다는 것이다.
규칙 1: 재미있게 쓰자.
규칙 2: 명세를 쓰는 작업은 머리가 돌아가도록 코드를 쓰는 작업과 유사하다.
규칙 3: 최대한 단순하게 작성하라.
규칙 4: 여러 차례에 걸쳐 검토하고 다시 읽어라.
규칙 5: 표준 양식은 해롭다고 간주한다.
9장, 손쉬운 소프트웨어 일정관리법
- 마이크로소프트 엑셀을 사용합시다.
- 단순하게 만듭시다.
- 각 기능은 과업 여러개를 포함해야만 한다.
- 담당 프로그래머만이 제대로 일정을 짤 수 있다.
- 과업을 세부적으로 나누자.
- 초기 예측과 현재 예측을 동시에 유지하자.
- 경과 열은 매일 갱신하자.
- 일정에 휴가나 휴일 같은 항목을 넣자.
- 일정에 디버깅 시간을 넣자.
- 일정에 통합 시간을 넣자.
- 일정에 여유 기간을 두자.
- 관리자가 프로그래머에게 일정을 단축하도록 절대 강요하지 못하게 하자.
- 일정은 장난감 블록과도 같다.
엑셀에 대해 꼭 알아둬야 할 사항들
공유 목록 : 동시에 여러 사람이 편집이 가능하다.
자동 필터 : 해당 과업, 담당자 별 필터링이 가능하다.
피벗 테이블 : 개발자 마다 남아있는 시간을 보여줄수 있는 차트를 만든다던가.. 등등10장, 일일 빌드는 당신의 친구
- 빌드 체크와 코드 퀄리티 게이트를 적용해 해당 빌드 패스 및 버그 수정을 그날그날 수행하자.
11장, 고리타분한 버그 수정
- 찾아낸 버그를 모두 확인하자.
- 경제적인 피드백을 확인하자.
- 버그를 모두 수정하는 작업이 어떤 값어치가 있는지 계산하자. ( 릴리즈와 버그 수정 중 어떤 일이 먼저인지 판단하자는 것 )
12장, 다섯 가지 세계
- 상품 소프트웨어
- 사내용 소프트웨어
- 임베디드 소프트웨어
- 게임 소프트웨어
- 일회성 소프트웨어
각 세계는 모두 다른 특성과 이해관계가 얽혀있다.
13장, 종이 프로토타이핑
연필로 슥슥 갈긴 프로토타입으로 회의 시간을 단축하자.
14장, 화성인 아키텍트를 조심하세요.
다음에…