![Specification by Example [한국어판]](https://image.yes24.com/Goods/12737205/S)
![Specification by Example [한국어판]](https://image.yes24.com/goods/12737205/XL)
소득공제
- 베스트
- IT 모바일 top100 2주
이미 소장하고 있다면 판매해 보세요.
- 해외배송 가능?
- 문화비소득공제 가능
이 분야의 이벤트
위키북스 IT Leaders 시리즈
책소개
목차
|
▣ 0장: 서문
_예제를 활용한 명세 _현실 세계에서는 _대상 독자 _이 책에서 다루는 내용 _기초를 넘어서 _이 책에는 소스코드가 없으며 어떤 도구도 설명하지 않는다 _용어에 관한 몇 가지 생각 _왜 예제를 활용한 명세인가? _프로세스 패턴 [1부] 시작하기 ▣ 01장: 핵심 이점 __변경 작업의 효율화 __높은 제품 품질 __재작업 감소 __더 나은 업무 배치 __정리 ▣ 02장: 주요 프로세스 패턴 __목표에서 범위 도출하기 __협업을 통해 명세 만들기 __예제를 활용해 설명하기 __명세 정제하기 __명세의 변경 없이 검증 자동화하기 __자주 검증하기 __문서 시스템 발전시키기 __실무 사례 ___비즈니스 목표 ___범위 ___주요 예제 ___예제가 포함된 명세 ___실행 가능한 명세 ___리빙 도큐멘테이션 __정리 ▣ 03장: 리빙 도큐멘테이션 __믿을 만한 문서가 필요한 이유 ___테스트는 좋은 문서가 될 수 있다 __실행 가능한 명세로부터 문서 만들기 __문서 중심 모델의 이점 __정리 ▣ 04장: 변화의 시작 __프로세스 변경을 시작하는 법 __팀 문화를 바꾸는 방법 __팀을 업무 흐름과 이터레이션으로 협업하도록 통합하는 방법 ___얼티밋 소프트웨어의 글로벌 탤런트 매니지먼트 팀 ___BNP 파리바의 시에라 팀 ___스카이 네트워크 서비스 __승인 및 추적성 다루기 __경고 신호 ___자주 변경되는 테스트에 유의하라 ___부메랑에 유의하라 ___조직의 불일치에 유의하라 ___대비성 코드에 유의하라 ___산탄총 수술에 유의하라 __정리 [2부] 주요 프로세스 패턴 ▣ 05장: 목표에서 범위 도출하기 __올바른 범위 설정하기 __상위 수준의 권한 없이 범위에 대해 협업하기 __추가 정보 __정리 ▣ 06장: 협업을 통해 명세 만들기 __왜 협업을 통해 명세를 작성해야 하는가? __가장 인기 있는 협업 모델 __협업 준비하기 __협업 모델 선택하기 __정리 ▣ 07장: 예제를 활용해 설명하기 __예제를 활용해 설명하기: 예제 __예제는 명확해야 한다 __예제는 완전해야 한다 __예제는 현실적이어야 한다 __예제는 이해하기 쉬워야 한다 __비기능 요구사항 기술하기 __정리 ▣ 08장: 명세 정제하기 __좋은 명세의 예 ___무료 배송 ___예제 __나쁜 명세의 예 __명세를 정제할 때 중점을 둬야 할 사항 ___예제는 명확하고 테스트할 수 있어야 한다 ___스크립트는 명세가 아니다 ___명세는 소프트웨어 설계가 아닌 비즈니스 기능에 대한 것이어야 한다 ___명세는 설명이 필요 없을 만큼 자명해야 한다 ___명세는 한곳에 집중해야 한다 ___명세는 도메인 언어로 작성해야 한다 __정제하기 연습 __정리 ▣ 09장: 명세의 변경 없이 검증 자동화하기 __자동화가 정말 필요한가? __자동화 시작하기 __자동화 계층 관리하기 __사용자 인터페이스 자동화하기 __테스트 데이터 관리 __정리 ▣ 10장: 자주 검증하기 __신뢰성이 떨어지는 부분 줄이기 __빠른 피드백 얻기 __실패하는 테스트 관리하기 __정리 ▣ 11장: 문서 시스템 발전시키기 __리빙 도큐멘테이션은 이해하기 쉬워야 한다 __리빙 도큐멘테이션은 일관성이 있어야 한다 __리빙 도큐멘테이션은 접근하기 쉽게 구성해야 한다 __리빙 도큐멘테이션에 귀 기울여라 __정리 [3부] 사례 연구 ▣ 12장: 유스위치 __프로세스 변화 시작하기 __프로세스 최적화하기 __현재 프로세스 __결과 __핵심 교훈 ▣ 13장: 레인스토 __프로세스 변화시키기 __현재 프로세스 __핵심 교훈 ▣ 14장: 아이오와 학자금 대출 __프로세스 변화시키기 __프로세스 최적화하기 __경쟁우위로서의 리빙 도큐멘테이션 __핵심 교훈 ▣ 15장: 사브르 에어라인 솔루션스 __프로세스 변화시키기 __협업 개선하기 __결과 __핵심 교훈 ▣ 16장: 이플랜 서비스 __프로세스 변화시키기 __리빙 도큐멘테이션 __현재 프로세스 __핵심 교훈 ▣ 17장: 송킥 __프로세스 변화시키기 __현재 프로세스 __핵심 교훈 ▣ 18장: 결론 __요구사항에 대한 협업은 이해관계자와 개발팀원 간의 신뢰를 쌓이게 한다 __협업은 준비가 필요하다 __협업하는 방법에는 여러 가지가 있다 __최종 목표를 비즈니스 프로세스 문서화로 하는 것은 유용한 모델이다 __장기적 가치는 리빙 도큐멘테이션에서 나온다 __부록 __참고자료 ___책 ___온라인 참고자료 |
저자 소개
저자 : 고코 아지치
영국을 기반으로 컨설턴트로 활동 중인 고코 아지치는 전 세계의 팀들이 '예제를 활용한 명세(Specification by Example)'와 애자일 테스트 실천법을 적용할 수 있게 돕고 있다.
역 자 소 개
이종화
매일 생각해야 할 것, 알아야 할 것, 도전해야 할 것, 그리고 미소 짓게 할 것을 소중하게 생각한다. 그리고 생각의 흔적을 지속적으로 되새기기 위해 메모하고 정리하는 것을 좋아한다. 현재는 올바른 방법으로 올바른 소프트웨어를 만들기 위해 고군분투 중이다.
최윤상
소프트웨어 개발에서도 '의도'와 '결과'를 일치시키는 것 가장 중요하다고 믿는 개발자.
그래서 테스트 코드 및 코드 품질, 조직 문화, 커뮤니케이션 방법 등 '의도'를 제대로 전달할 수 있는 방법에 관심이 많다. NHN에서 지도개발팀, 네이버QA, 생산성혁신랩에 근무했고 현재는 재충전을 위해 겨울잠을 자고 있다.
정성민
NHN 과 NBP(NHN Business Platform) 에서 2년 반 가량 윈도우 클라이언트를 개발하였고 현재는 NHN Entertainment 에서 유니티를 사용하여 게임 클라이언트를 개발하고 있다. 이해하기 쉽고 변경하기도 쉬운 코드를 작성하는 방법에 대해 매일 고민하며 열심히 일하고 있다.
매일 생각해야 할 것, 알아야 할 것, 도전해야 할 것, 그리고 미소 짓게 할 것을 소중하게 생각한다. 그리고 생각의 흔적을 지속적으로 되새기기 위해 메모하고 정리하는 것을 좋아한다. 현재는 올바른 방법으로 올바른 소프트웨어를 만들기 위해 고군분투 중이다.
최윤상
소프트웨어 개발에서도 '의도'와 '결과'를 일치시키는 것 가장 중요하다고 믿는 개발자.
그래서 테스트 코드 및 코드 품질, 조직 문화, 커뮤니케이션 방법 등 '의도'를 제대로 전달할 수 있는 방법에 관심이 많다. NHN에서 지도개발팀, 네이버QA, 생산성혁신랩에 근무했고 현재는 재충전을 위해 겨울잠을 자고 있다.
정성민
NHN 과 NBP(NHN Business Platform) 에서 2년 반 가량 윈도우 클라이언트를 개발하였고 현재는 NHN Entertainment 에서 유니티를 사용하여 게임 클라이언트를 개발하고 있다. 이해하기 쉽고 변경하기도 쉬운 코드를 작성하는 방법에 대해 매일 고민하며 열심히 일하고 있다.
품목정보
- 발행일
- 2014년 04월 24일
- 쪽수, 무게, 크기
- 332쪽 | 767g | 188*240*30mm
- ISBN13
- 9788998139490
책 속으로
|
개발자에게 중요한 자질은 무엇일까?
코드에 대한 장인정신, 기술적인 측면에 대한 오덕력, 철야를 두려워하지 않는 용기, 새벽까지 술을 마실 수 있는 체력 등등 각자 지나온 지옥의 종류에 따라 나름의 기준이 있을 것이다. 나는 언젠가부터 프로젝트를 진행하면서 기술적인 난관을 극복하는 일보다 사람들 간의 문제 인식의 차이를 줄이는 것이 훨씬 더 어렵고 중요하다는 사실을 깨닫기 시작했다. 그래서 나는 개발자에게 중요한 능력 중 하나가 ‘의도를 정확히 이해하는 능력’이라고 생각한다. 프로젝트 초기에는 모든 사람들이 '장님이 코끼리 만지듯' 정제되지 않은 아이디어를 자신만의 언어로 이야기한다. 그렇게 짙은 안개 속을 헤매다가 프로젝트의 막판 즈음에서야 우리가 무엇을 만들려고 하는지 깨닫게 된다. 심지어는 기획자(혹은 고객)조차도 그렇다. 어떤 면에서 소프트웨어 개발은 단순히 제품을 코드로 구체화시키는 과정이 아니라 프로젝트에 관련된 개개인의 '의도'가 서로 충돌하고 상호작용하면서 만들어지는 종합 예술에 가깝다. (기획, 작가, 연출, 배우의 충돌 과정을 통해서 만들어지는 연극이 소프트웨어 개발과 유사하다고 얘기하면 너무 억지스러운가?) 이 책은 기획, 개발, 디자인, UX, QA 등 다양한 역할의 사람들이 함께하는 소프트웨어 개발 현장에서 서로의 '의도를 효과적으로 소통할 수 있는' 방법에 대해 얘기해 줄 것이다. '구체적인 예제'는 소프트웨어 개발 현장에서 사람들이 의사소통할 수 있는 가장 좋은 방법이며, 개발자들이 TDD에서 배운 가장 중요한 교훈이라 생각한다. ATDD/BDD를 실무에 적용할 생각을 가진 독자라면 이 책은 '그 지옥을 건너본' 선배들의 알짜배기 경험을 전해 줄 수 있을 것이다. ---옮긴이 서문 중에서 |
출판사 리뷰
|
'예제를 활용한 명세(Specification by example)'는 요구 사항과 테스트를 명세화하는 협업 방법이다. 이 책에서 상세히 분석된 7가지 패턴은 이 방법을 효율적으로 만들기 위한 열쇠이다. 이 방법은 4가지 이점이 있다. 신뢰할 수 있는 리빙 도큐멘테이션 시스템을 만든다. 기대치를 명확하게 정의하고 효과적으로 검증할 수 있게 한다. 재작업을 줄이고, 무엇보다도, 개발팀과 비즈니스 이해관계자가 만들어진 소프트웨어가 올바르게 목적을 달성할 수 있도록 보장한다.
이 책은 짧고, 반복적인 개발 주기를 통해 효율적인 방법으로 소프트웨어를 명세, 테스트, 그리고 출시하는 전세계의 앞서가는 팀들의 경험으로부터 정제됐다. 이 책은 소규모 웹 스타트업에서 거대한 금융 기관까지 XP, 스크럼, 그리고 칸반과 같은 많은 프로세스를 사용하는 사례 연구들을 포함한다. |
리뷰/한줄평0
27,000원
총 1개
27,000원
