추가 적립 안내

『Specification by Example』은 소규모 웹 스타트업에서 거대한 금융기관까지, XP, 스크럼, 칸반을 비롯한 다양한 프로세스를 활용한 팀들의 사례 연구를 담은 책이다. 훌륭한 소프트웨어를 제작하기 위해 함께 일하는 개발자, 테스터, 분석가, 비즈니스 이해관계자 모두를 위한 지침서로 재작업을 줄이고 개발팀과 비즈니스 이해관계자가 만들어진 소프트웨어가 올바르게 목적을 달성할 수 있도록 이끌어준다.

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

- 옮긴이 서문 중에서