▣ 졸트 상 올해 최고의 책(2012)에 빛나는 'Specification by Example(예제를 활용한 명세)'! 예제를 활용한 명세(Specification by Example)는 현실적인 예제를 기반으로 비즈니스 이해관계자와 개발 팀 간의 의사소통의 차이를 극복할 수 있는 최신 실천법이다. 이 책은 전 세계의 성공적인 소프트웨어 개발팀과 인터뷰한 결과를 정제한 것으로서, 짧고 반복적인 개발 주기에서 결함 없이 소프트웨어의 명세 작성을 비롯해 소프트웨어를 개발하고 출시하는 효과적인 방법들을 알려준다. 이 책에는 소규모 웹 스타트업에서 거대한 금융기관까지, XP, 스크럼, 칸반을 비롯한 다양한 프로세스를 활용한 팀들의 사례 연구가 담겨 있다. 이 책은 훌륭한 소프트웨어를 제작하기 위해 함께 일하는 개발자, 테스터, 분석가, 비즈니스 이해관계자 모두를 위한 책이다. ★ 이 책에서 다루는 내용 ★ ◎ 일반적인 프로세스 패턴 ◎ 잘못된 실천법을 피하는 방법 ◎ 프로세스에 '예제를 활용한 명세'를 적용하는 방법 ◎ 50개 이상의 사례 연구 '예제를 활용한 명세(Specification by example)'는 요구 사항과 테스트를 명세화하는 협업 방법이다. 이 책에서 상세히 분석된 7가지 패턴은 이 방법을 효율적으로 만들기 위한 열쇠이다. 이 방법은 4가지 이점이 있다. 신뢰할 수 있는 리빙 도큐멘테이션 시스템을 만든다. 기대치를 명확하게 정의하고 효과적으로 검증할 수 있게 한다. 재작업을 줄이고, 무엇보다도, 개발팀과 비즈니스 이해관계자가 만들어진 소프트웨어가 올바르게 목적을 달성할 수 있도록 보장한다. 이 책은 짧고, 반복적인 개발 주기를 통해 효율적인 방법으로 소프트웨어를 명세, 테스트, 그리고 출시하는 전세계의 앞서가는 팀들의 경험으로부터 정제됐다. 이 책은 소규모 웹 스타트업에서 거대한 금융 기관까지 XP, 스크럼, 그리고 칸반과 같은 많은 프로세스를 사용하는 사례 연구들을 포함한다. 추천사 “광범위한 업계 연구를 통해 얻은 고유하고 정제된 지식입니다.” - Mike Stockdale, Syterra Software “나는 이 책을 사랑합니다. 이것이야말로 올바르게 테스트하는 방법입니다.” - Craig Smith, Suncorp “이 책은 우리가 테스트에 대해 이야기하고 생각하는 방법을 변화시킬 것입니다.” - David Evans, ThinkAlike Consulting “요구사항 수집과 유지보수에 관한 최고의 책입니다.” - Oleksandr Alesinskyy, NAVTEQ “오랜만에 읽은 최고의 책입니다.” - John Stevenson “이 책은 많은 팀의 경험을 토대로 작성되었기 때문에 테스트 자동화 시스템의 가치를 두 배로 향상시켜줄 것입니다.” - Rick Mugridge, Rimu Research

▣ 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를 실무에 적용할 생각을 가진 독자라면 이 책은 '그 지옥을 건너본' 선배들의 알짜배기 경험을 전해 줄 수 있을 것이다. - 옮긴이 서문 중에서