상세정보

개발자와 프로젝트 관리자를 위해 집필된 이 책은 소프트웨어 개발을 “게임”에 비유하고 있다. 팀 구성원들은 게임의 최종 목표가 이기는 것임을 알고 게임에 참여한다 - 게임을 하면서 그들은 배운 것을 항상 기억하고, 다시는 그와 같은 방식으로 게임하지 않겠다고 다짐하기도 한다.

개발자들은 다양한 방법론에 대해 개방적인 태도를 갖고 있어야 하고, 짧은 시간 내에 좋은 품질의 소프트웨어를 개발하려는 목표에 전념해야 한다. 10년간의 작업과 연구, 소프트웨어 프로젝트 팀과의 인터뷰를 기초로 한 이 책은 최소한의 노력으로 다양한 프로젝트에서 성공적인 결과를 만들어 낼 수 있는 효과적인 방법을 제시한다.

다음 내용들을 담고 있다.

Agile 소프트웨어 개발 선언문

정보제공 :

목차
소개 : 알 수 없는 그리고 불가능한 커뮤니케이션 = 1
 분석 경험의 문제 = 3
 커뮤니케이션의 불가능성 = 10
 듣기의 3단계 = 17
 이제부터 내가 할 일은? = 24
1장 창조와 커뮤니케이션의 상호 협력적 게임 = 27
 소프트웨어와 시 = 29
 소프트웨어와 게임 = 31
 협력적 게임의 재고찰 = 40
 이 장이 내게 의미하는 바는 무엇인가? = 49
2장 개인 = 53
 기상천외한 사람들 = 55
 실패 방식 극복하기 = 61
 다른 사람보다 효과적으로 일하는 방법 = 71
 성공 방식 만들기 = 87
 이제부터 내가 할 일은? = 94
3장 대화와 협력의 팀 = 97
 정보 전달 흐름 = 99
 커뮤니케이션의 차이 극복하기 = 120
 공동체로서의 팀 = 131
 생태 시스템으로서의 팀 = 144
 이제부터 내가 할 일은? = 146
4장 방법론 = 149
 소프트웨어를 탑재한 생태 시스템 = 151
 방법론의 개념 = 151
 방법론 설계의 원칙 = 183
 XP under Glass = 217
 왜 결국 방법론인가? = 222
 이제부터 내가 할 일은? = 225
5장 Agile과 스스로 적응하기 = 227
 가볍지만 충분한 = 229
 Agile = 233
 스스로 적응하기 = 241
 이제부터 내가 할 일은? = 257
6장 Crystal 방법론 = 259
 Crystal군의 형성 = 261
 Crystal Clear = 265
 Crystal Orange = 268
 Crystal Orange Web = 271
 이제부터 내가 할일은? = 277
부록 A. Agile 소프트웨어 개발 선언문 = 279
 Agile 연합 = 281
 선언문 = 283
 가치의 지지 = 286
부록 B. Naur, Ehn, Musashi = 293
 Peter Naur, 이론 구축으로서의 프로그래밍 = 295
 Pelle Ehn, Wittgenstein의 언어 게임 = 310
 Musashi = 327
부록 C. 참고 문헌 = 335
찾아보기 = 347
소개 알 수 없는 그리고 불가능한 커뮤니케이션 = 1
 그림 i-1 하나의 호와 한 쌍의 호 = 4
 그림 i-2 얼굴 형태를 만든 호 = 5
 그림 i-3 사과를 반으로 자른 단면? = 5
 그림 i-4 복잡한 원 = 5
 그림 i-5 태극 무늬 = 6
1장 창조와 커뮤니케이션의 상호 협력적 게임 = 27
 그림 1-1 다양한 게임의 종류 = 32
3장 대화와 협력의 팀 = 97
 그림 3-1 두 사람이 pair programming하기 = 100
 그림 3-2 두 사람이 한 방에서 등지고 앉아 프로그래밍하기 = 101
 그림 3-3 pair programming과 파티션이 있는 작업 환경. 어느 쪽이 정보를 빨리 발견 할 수 있을까? = 102
 그림 3-4 복잡한 장애물을 거쳐가는 정보와 에너지의 이동 = 103
 그림 3-5 3종류의 자리 배치에서 기체 이동의 여과 상태 = 104
 그림 3-6 정보 라디에이터가 게시된 복도 = 111
 그림 3-7 상태 표시기는 완성 단계와 구현된 user story의 품질을 보여 주고 있다 = 111
 그림 3-8 반복 계획을 나타내는 정보 라디에이터가 게시된 벽. user story당 하나의 플립 차트 = 112
 그림 3-9 XP 업무 참가 명세와 반복의 상태("Mary Ann"이라 불리는 반복) = 113
 그림 3-10 검토 워크숍의 결론 = 114
 그림 3-11 성장 달성을 보여 주는 그래프 = 115
 그림 3-12 업무 중인 RoleModel Software사의 한 팀 = 118
 그림 3-13 RoleModel Software사가 사용하는 caves and common 배치 = 118
 그림 3-14 여러 커뮤니케이션 양상의 효율성 = 125
 그림 3-15 벽에 게시된 정보 라디에이터를 함께 사용하여 작업하는 두 사람 = 128
 그림 3-16 작업에 사용하는 동적 및 정적 정보 라디에이터 = 128
 그림 3-17 목표에 다가가기 위해 노력하는 보통의 팀 = 132
 그림 3-18 약간의 조절을 한 팀 = 132
 그림 3-19 4가지 조직의 예 = 139
4장 방법론 = 149
 그림 4-1 방법론의 구성 요소 = 152
 그림 4-2 범위의 3가지 차원. 하나의 방법론은 이 3가지 모두의 부분 집합이다. = 159
 그림 4-3 XP의 범위 = 160
 그림 4-4 Constantine과 Lockwood의 Design for Use 방법론의 단편 = 161
 그림 4-5 project map : project plan의 하위 수준 정밀도 = 164
 그림 4-6 actor-goal 리스트 : 행위 요구 사항의 최하위 수준의 정밀도 = 165
 그림 4-7 Responsibility-Collaborations 다이어그램 : 객체 지향 설계의 하위 수준 정밀도 = 166
 그림 4-8 다른 활동을 자극하기 위한 하위 수준의 사용 = 167
 그림 4-9 정밀도 수준이 높아질수록 작업도 늘어난다(유스케이스를 보여 줌.) = 168
 그림 4-10 프로젝트 과정 중 불안정성 줄이기 = 169
 그림 4-11 성공적인 순차적 개발(serial development)은 동시 개발(concurrent development)과 비교해서 장기간(작업일보다는 적게)을 요한다. = 170
 그림 4-12 순차 개발. 각 작업 그룹은 상위 작업 그룹이 안정될 때까지 작업을 시작 하지 않는다. = 171
 그림 4-13 동시 개발. 각 작업 그룹은 커뮤니케이션 및 재작업 가능성이 알려지자마자 작업을 시작한다. 작업이 진행됨에 따라 상위 그룹은 업데이트 정보를 계속적으로 하위 그룹에 전달한다(화살표). = 172
 그림 4-14 상위 작업이 하위 작업보다 더 안정적이도록 유지함. 이 곡선은 요구 사항 및 설계상에서 작업 산출물의 불안정성을 나타낸다. 바람직한 경우(왼쪽), 변화가 동시에 일어나지만 요구 사항의 변화가 설계보다 작다. 바람직하지 않은 경우(오른쪽), 설계가 요구 사항이 결정되기도 전에 안정되었다. = 173
 그림 4-15 방법론의 역할-산출물-표시 도표 = 175
 그림 4-16 다양한 커뮤니케이션 채널의 효율성(그림 3-14 반복) = 194
 그림 4-17 방법론의 무게 증가가 작은 팀에 미치는 영향 = 196
 그림 4-18 규모가 큰 팀에 방법론을 추가하는 것에 대한 효과 = 197
 그림 4-19 문서화는 이해가 아니고, 프로세스는 규율이 아니며, 형식은 기술이 아니다. = 202
 그림 4-20 5명의 Smalltalk 프로그래머가 한 DBA에게 업무를 전달한다. = 204
 그림 4-21 병목 부서는 비병목 부서보다 더 안정적이고 완벽한 상태에서 일을 시작해야 한다. = 205
 그림 4-22 커뮤니케이션의 필요가 증가할수록 효율성은 떨어진다(방법론 규모). = 209
 그림 4-23 커뮤니케이션 부하, 치명성, 우선순위별로 특성화한 프로젝트 = 213
 그림 4-24 효과가 떨어지지 않는 한 작은 방법론이 좋다. = 215
5장 Agile과 스스로 적응하기 = 227
 그림 5-1 검토 워크숍의 샘플 플립 차트 = 255
6장 Crystal 방법론 = 259
 그림 6-1 Crystal 방법론은 색에 의해 명명된다. = 263
소개 알 수 없는 그리고 불가능한 커뮤니케이션 = 1
 와인 라벨 = 3
 스테이크 맛보기 = 4
 가게 점원의 찌푸린 얼굴 = 14
 러시아 프로그래머 = 16
 1708 카드 판독기 = 17
 CRC 카드를 사용한 단계 혼합하기 = 19
1장 창조와 커뮤니케이션의 상호 협력적 게임 = 27
 소프트웨어 설계에서의 균형 = 30
 협력적 게임의 원리 = 40
 레이저 프린터의 실물 모형 만들기 = 42
 이익 줄이기 = 43
 회의에서의 충분함 = 43
 작업물의 충분함 = 44
 크라이슬러의 매우 가벼움 속에서의 충분함 = 45
 계속되는 문서 작업 = 47
 일체 존재하지 않는 문서화 = 47
2장 개인 = 53
 문화 극복하기 = 58
 자료를 교환하지 않는 컨설턴트들 = 60
 소품 가게 = 61
 C3 문화 전환 = 62
 선택의 환상 = 64
 책상을 잘 정리하는 기술 = 67
 PSP 보고서 = 69
 대강의 아키텍처 구성 = 73
 TalkingParrot 프로그램 = 75
 Line-of-Sight 설계 학습 = 76
 지나치게 사교적인 관리자 = 78
 대화가 통하지 않는 팀 리더 = 78
 구체적으로 사고하는 객체 지향 설계자 = 78
 eBucks.com = 79
 민들레 없애기 = 80
 코드 라인 수에 따른 지불 = 81
 금 도금하기 = 81
 위임 실현 = 84
 Seymour Cray Fiddles의 피드백 = 86
 Offshore Oil 플랫폼 설계 = 88
 Dee Hock의 VISA 이야기 = 92
 PC 보드에서 오류 찾기 = 93
3장 대화와 협력의 팀 = 97
 정보가 잘 흐르는 작은 방 = 108
 화면으로 보고 화면으로 인식하기 = 109
 자동화된 구축 보고서 = 110
 진도 라디에이터 = 112
 작업 종료 표시 = 113
 시스템 상태 표시 = 115
 작업 진도 보여주기 = 116
 설계 토론 수정하기 = 116
 Crystal Un-Clear = 117
 Skunk Works 팀의 사무실 = 119
 반드시 그곳에 있어야 한다 = 123
 비디오테이프로 보관된 문서 = 126
 냉정한 커뮤니케이션의 필요성 = 127
 생각을 벽에 고정시키기 = 130
 충돌이 없어서 = 134
 고의적인 충돌 = 135
 업무에서의 조화 문화 = 140
 노르웨이 중앙은행의 시간 외 근무용 전등 = 141
 도마뱀과 펭귄 = 145
4장 방법론 = 149
 선언 발견하기 = 157
 16명의 Smalltalk 프로그래머와 2명의 데이터베이스 설계자 = 174
 흥미를 끌지 못하는 그림 차트 = 176
 프로세스 미니어처 사례 = 182
 방법론의 장식 = 185
 "하는 게 좋겠다."의 발견 = 186
 프로세스 노출의 지름길 = 187
 개인 변수 배제 = 192
 프로젝트의 포트폴리오 = 198
 Winifred와 원칙 7 = 207
 eBuck.com과 원칙 7 = 208
 Udall과 원칙 7 = 208
 The mythical Man-Mouth 재고찰하기 = 210
 6∼24명의 프로그래머 = 210
 "더 적게"와 "더 많이" = 212
 프로젝트 도중의 Grid Cell 변경 = 214
 서랍 속의 방법론 = 223
 직무에서의 방법론 = 223
5장 Agile과 스스로 적응하기 = 227
 문서화의 요구 = 229
 일체 존재하지 않는 문서화(다시 소개한다) = 231
 생각을 벽에 고정시키기 = 231
 Offshore 코딩 테스트하기 = 238
 사방으로 흩어짐 = 239
 성공적인 분산 개발 = 239
 작업 산출물의 중복성 = 244
 증가적 개발의 발견 = 244
 함께 술에 취하기 = 245
 커뮤니케이션 주제 = 247
 작업 중 커뮤니케이션의 주제 = 247
 문화적 차이 = 247
 프로젝트 도중의 구조 변경 = 253
 검토 워크숍 = 254
부록 A.s Agile 소프트웨어 개발 선언문 = 279
 기술 부채의 운영 = 290