Specification by Example

▣ 0장: 서문
_예제를 활용한 명세
_현실 세계에서는
_대상 독자
_이 책에서 다루는 내용
_기초를 넘어서
_이 책에는 소스코드가 없으며 어떤 도구도 설명하지 않는다
_용어에 관한 몇 가지 생각
_왜 예제를 활용한 명세인가?
_프로세스 패턴

[1부] 시작하기

▣ 01장: 핵심 이점
__변경 작업의 효율화
__높은 제품 품질
__재작업 감소
__더 나은 업무 배치
__정리

▣ 02장: 주요 프로세스 패턴
__목표에서 범위 도출하기
__협업을 통해 명세 만들기
__예제를 활용해 설명하기
__명세 정제하기
__명세의 변경 없이 검증 자동화하기
__자주 검증하기
__문서 시스템 발전시키기
__실무 사례
___비즈니스 목표
___범위
___주요 예제
___예제가 포함된 명세
___실행 가능한 명세
___리빙 도큐멘테이션
__정리

▣ 03장: 리빙 도큐멘테이션
__믿을 만한 문서가 필요한 이유
___테스트는 좋은 문서가 될 수 있다
__실행 가능한 명세로부터 문서 만들기
__문서 중심 모델의 이점
__정리

▣ 04장: 변화의 시작
__프로세스 변경을 시작하는 법
__팀 문화를 바꾸는 방법
__팀을 업무 흐름과 이터레이션으로 협업하도록 통합하는 방법
___얼티밋 소프트웨어의 글로벌 탤런트 매니지먼트 팀
___BNP 파리바의 시에라 팀
___스카이 네트워크 서비스
__승인 및 추적성 다루기
__경고 신호
___자주 변경되는 테스트에 유의하라
___부메랑에 유의하라
___조직의 불일치에 유의하라
___대비성 코드에 유의하라
___산탄총 수술에 유의하라
__정리

[2부] 주요 프로세스 패턴

▣ 05장: 목표에서 범위 도출하기
__올바른 범위 설정하기
__상위 수준의 권한 없이 범위에 대해 협업하기
__추가 정보
__정리

▣ 06장: 협업을 통해 명세 만들기
__왜 협업을 통해 명세를 작성해야 하는가?
__가장 인기 있는 협업 모델
__협업 준비하기
__협업 모델 선택하기
__정리

▣ 07장: 예제를 활용해 설명하기
__예제를 활용해 설명하기: 예제
__예제는 명확해야 한다
__예제는 완전해야 한다
__예제는 현실적이어야 한다
__예제는 이해하기 쉬워야 한다
__비기능 요구사항 기술하기
__정리

▣ 08장: 명세 정제하기
__좋은 명세의 예
___무료 배송
___예제
__나쁜 명세의 예
__명세를 정제할 때 중점을 둬야 할 사항
___예제는 명확하고 테스트할 수 있어야 한다
___스크립트는 명세가 아니다
___명세는 소프트웨어 설계가 아닌 비즈니스 기능에 대한 것이어야 한다
___명세는 설명이 필요 없을 만큼 자명해야 한다
___명세는 한곳에 집중해야 한다
___명세는 도메인 언어로 작성해야 한다
__정제하기 연습
__정리

▣ 09장: 명세의 변경 없이 검증 자동화하기
__자동화가 정말 필요한가?
__자동화 시작하기
__자동화 계층 관리하기
__사용자 인터페이스 자동화하기
__테스트 데이터 관리
__정리

▣ 10장: 자주 검증하기
__신뢰성이 떨어지는 부분 줄이기
__빠른 피드백 얻기
__실패하는 테스트 관리하기
__정리

▣ 11장: 문서 시스템 발전시키기
__리빙 도큐멘테이션은 이해하기 쉬워야 한다
__리빙 도큐멘테이션은 일관성이 있어야 한다
__리빙 도큐멘테이션은 접근하기 쉽게 구성해야 한다
__리빙 도큐멘테이션에 귀 기울여라
__정리

[3부] 사례 연구

▣ 12장: 유스위치
__프로세스 변화 시작하기
__프로세스 최적화하기
__현재 프로세스
__결과
__핵심 교훈

▣ 13장: 레인스토
__프로세스 변화시키기
__현재 프로세스
__핵심 교훈

▣ 14장: 아이오와 학자금 대출
__프로세스 변화시키기
__프로세스 최적화하기
__경쟁우위로서의 리빙 도큐멘테이션
__핵심 교훈

▣ 15장: 사브르 에어라인 솔루션스
__프로세스 변화시키기
__협업 개선하기
__결과
__핵심 교훈

▣ 16장: 이플랜 서비스
__프로세스 변화시키기
__리빙 도큐멘테이션
__현재 프로세스
__핵심 교훈

▣ 17장: 송킥
__프로세스 변화시키기
__현재 프로세스
__핵심 교훈

▣ 18장: 결론
__요구사항에 대한 협업은 이해관계자와 개발팀원 간의 신뢰를 쌓이게 한다
__협업은 준비가 필요하다
__협업하는 방법에는 여러 가지가 있다
__최종 목표를 비즈니스 프로세스 문서화로 하는 것은 유용한 모델이다
__장기적 가치는 리빙 도큐멘테이션에서 나온다
__부록
__참고자료
___책
___온라인 참고자료

개발자에게 중요한 자질은 무엇일까?

코드에 대한 장인정신, 기술적인 측면에 대한 오덕력, 철야를 두려워하지 않는 용기, 새벽까지 술을 마실 수 있는 체력 등등 각자 지나온 지옥의 종류에 따라 나름의 기준이 있을 것이다.

나는 언젠가부터 프로젝트를 진행하면서 기술적인 난관을 극복하는 일보다 사람들 간의 문제 인식의 차이를 줄이는 것이 훨씬 더 어렵고 중요하다는 사실을 깨닫기 시작했다. 그래서 나는 개발자에게 중요한 능력 중 하나가 '의도를 정확히 이해하는 능력'이라고 생각한다.

프로젝트 초기에는 모든 사람들이 '장님이 코끼리 만지듯' 정제되지 않은 아이디어를 자신만의 언어로 이야기한다. 그렇게 짙은 안개 속을 헤매다가 프로젝트의 막판 즈음에서야 우리가 무엇을 만들려고 하는지 깨닫게 된다. 심지어는 기획자(혹은 고객)조차도 그렇다. 어떤 면에서 소프트웨어 개발은 단순히 제품을 코드로 구체화시키는 과정이 아니라 프로젝트에 관련된 개개인의 '의도'가 서로 충돌하고 상호작용하면서 만들어지는 종합 예술에 가깝다. (기획, 작가, 연출, 배우의 충돌 과정을 통해서 만들어지는 연극이 소프트웨어 개발과 유사하다고 얘기하면 너무 억지스러운가?)

이 책은 기획, 개발, 디자인, UX, QA 등 다양한 역할의 사람들이 함께하는 소프트웨어 개발 현장에서 서로의 '의도를 효과적으로 소통할 수 있는' 방법에 대해 얘기해 줄 것이다. '구체적인 예제'는 소프트웨어 개발 현장에서 사람들이 의사소통할 수 있는 가장 좋은 방법이며, 개발자들이 TDD에서 배운 가장 중요한 교훈이라 생각한다. ATDD/BDD를 실무에 적용할 생각을 가진 독자라면 이 책은 '그 지옥을 건너본' 선배들의 알짜배기 경험을 전해 줄 수 있을 것이다.

- 옮긴이 서문 중에서