명세서
면책 조항
- 순수 방어적인 내용.
이 명세서는 완벽하지 않습니다.
저자
- 저자는 1명이다.
- 큰 제품일 경우 모듈로 쪼개서 담당 모듈 별 1명의 저자.
- 자신이 명세한 사항에 대해 책임감과 소유 의식을 느껴야 함.
시나리오
- 제품 설계시 사용 방법에 대한 생생한 시나리오를 염두에 둬야 한다.
회피 목표
- 구현 하지 않을 기능을 명세
- 쓸모 없는 기능이 많이지고, 시간도, 돈도 무한정 드는 경우를 방지하기 위함.
- 현재 실제 구동까지만 구현하고, v2에서 성능을 최적화 한다,
개괄
- 들어가기 전에
세부사항
- 세부 사항, 세부 사항, 세부 사항, 결정을 미루지 말자.
- 세부에 세부까지 파고들어 의사 결정을 내리자.
- 이러한 결정을 문서화할 필요가 있다.
미해결 문제
방주
- 테스팅 노트, 마케팅 노트, 문서화 노트, 기술 노트 등등 각 기술 담당이 관심을 가질만한 항목 표
명세는 지속적으로 개정해야 한다.
- 폭포수 사고방식은 명세서에 적이다.
- 주기적으로 개정해 변화하는 현실에 소프트웨어와 같이 발맞춰 명세서도 개정하자.
9장 손쉬운 소프트웨어 일정 관리
- 과업은 일단위, 주단위 보다 세부적으로 시간 단위로 나누라.
- 시간 단위로 나누다 보면, 과업을 더 자세하게 쪼개어서 생각하게 되고, 이런 생각의 흐름은 망할 명세서를 작성하게 한다.
초기 예측과 현재 예측을 동시에 유지하라
- 초기 예측과 현재 예측을 동시에 유지하다 보면, 일정을 관리하고 측정하는 방법을 배우게 된다.
경과 ( elapsed ) 열은 매일 갱신하라
일정에 휴가나 휴일 같은 항목을 넣으라
일정에 디버깅 시간을 포함하라
- 코드 버그는 항상 최대한 낮게 유지해야 한다.
코드를 작성한 당일 버그를 수정하는 작업이 훨씬 쉽기 때문이다. 정확한 코드 동작 원리를 까먹은 한달 뒤엔 버그 수정이 어려워 진다. 버그를 찾아 해결하는 시간은 예측이 불가능하다.
일정에 통합 시간을 포함하라.
일정에 여유 기간을 포함하라.
관리자가 프로그래머에게 일정을 단축하도록 강요하지 마라.
10장 일일 빌드는 당신의 친구
일일 빌드의 장점
- 버그 수정 후 테스터는 버그를 수정했는지 확인하기 위해 재테스트에 들어간다.
- 개발자는 직접 테스트를 하지 않고 테스트 가능하다.
- 미완성 제품을 테스트 하거나 마케팅, 베타 고객 사이트 등 외부 그룹은 안정적인 빌드를 이용해 테스트가 가능하다.
- 일일 빌드 모음을 유지하면, 추적 가능하다.
- 빌드 번호를 통해 테스터와 소통 가능
일일 빌드 팁
- 일일 빌드는 새로 체크아웃 하며 깨끗한 일일 빌드로 만들어낸 코드만 외부로 내보낸다.
- 코드 퀄리티, 커버리지 등 모든 요소 검사를 최대로 키고 경고를 발생 시킨 후 빌드를 멈추게 해 수정을 도모한다.
- 일일 빌드가 깨졌다면 문제점을 해결할 때 가지 빌드를 멈추고 수정 작업을 진행한다.
- 실패는 반드시 모든 팀원에게 통보 한다.
11장 고리타분한 버그 수정
- 버그 수정은 버그 가치가 수정 비용을 넘어설 때만 그 의미가 있다.
12장 다섯가지 세계
- 상품, 사내용, 임베디드, 게임, 일회성 소프트웨어