옮긴이 머리말 xi
추천사 xvi
감사의 글 xxi
베타리더 후기 xiii
추천 서문 xix

CHAPTER 1 고통스러운 경험을 통한 학습 1

나의 관점 2
이 책에 관하여 3
용어 특기사항 5
기회 활용 5

CHAPTER 2 요구사항에 관한 레슨 7

요구사항 개요 7
다양한 유형의 요구사항 7 / 요구사항 엔지니어링의 하위 도메인 9
비즈니스 분석가의 역할 10 / 요구사항은 프로젝트의 기반이다 10
레슨 1 | 요구사항을 정확하게 알아내지 못하면 프로젝트의 나머지 부분을 잘해도 소용없다 12
정확한 요구사항, 그러나 언제? 13 / 정확한 요구사항, 그러나 어떻게? 13
레슨 2 | 요구사항 개발에 따른 핵심 결과물은 공유된 비전과 이해다 14
레슨 3 | 요구사항에는 모든 프로젝트 이해 당사자의 관심사가 있다 17
이해 당사자 분석 18 / 누가 결정하는가? 20 / 우리는 모두 같은 편이다 21
레슨 4 | 요구사항 관련해서는 용도 중심의 접근법이 기능 중심의 접근법보다 더 좋게 고객의 요구를 충족한다 21
왜 과잉 기능을? 21 / 용도를 우선하기 22
사용자 스토리의 우려 사항 23 / 용도가 지배한다! 25
레슨 5 | 요구사항 개발은 반복을 필요로 한다 25
점진적인 세부 사항 개선 26 / 새로 부각된 기능적 요구사항 27
새로 부각된 비기능적 요구사항 28
레슨 6 | 애자일 요구사항은 그 밖의 요구사항과 다르지 않다 28
역할과 책임 29 / 용어 29 / 문서의 상세함 29 / 활동 시기 30
결과물의 형태 31 / 우선순위 결정 시기 31 / 실제로 차이가 있을까? 32
레슨 7 | 지식을 기록하는 데 따르는 비용은 지식을 습득하는 비용에 비해 적다 33
기록에 대한 두려움 33 / 문서로 기록된 의사소통의 장점 34 / 올바른 균형 36
레슨 8 | 요구사항 개발의 가장 중요한 목적은 명확하고 효율적인 의사소통이다 37
다수의 독자, 다수의 요구 38 / 표현 기법 선택하기 39 / 대화할 수 있을까? 41
레슨 9 | 요구사항 품질은 보는 사람의 관점에 따라 다르다 41
많은 요구사항 독자들 42 / 요구사항 품질 체크리스트 43
레슨 10 | 요구사항은 허용 가능한 위험 수준 범위에서 구축이 진행되는 데 충분한 것이어야 한다 44
세부 사항의 관점 44 / 어느 정도면 충분할까? 45
레슨 11 | 요구사항은 단순히 수집하는 것이 아니다 46
수집하기 vs. 도출하기 46 / 요구사항 도출 시기 47 / 도출 컨텍스트 48
도출 방법 48 / 기반 만들기 50
레슨 12 | 요구사항 도출은 고객의 음성이 개발자의 귀에 잘 들릴 정도로 가까운 거리에서 해야 한다 50
의사소통 경로 51 / 제품 대변인 52 / 요구사항 의사소통의 다른 경로 52
괴리 해소하기 53
레슨 13 | 흔히 사용되는 두 가지 요구사항 도출 관례가 텔레파시와 투시력이다. 이 방법들은 효과가 없다 54
요구사항을 알아내자! 54 / 명시적인 표현 55 / 텔레파시가 실패하다 56
레슨 14 | 많은 사람들이 모이면 요구사항을 정확히 어떻게 표현할지 합의하기는커녕 방에 불이 나서 탈출하는 데도 동의할 수 없다 57
주목하세요! 57 / 구조에 나서는 진행자 58 / 집중, 집중, 집중 59
그룹 외부에서 도움받기 60
레슨 15 | 포함될 기능을 결정할 때 데시벨 우선순위를 정하지 말자 61
우선순위 지정 방법 61 / 우선순위 지정 기준 62 / 목소리 크기를 넘어서는 분석 63
레슨 16 | 문서화되고 합의된 프로젝트 범위 없이 어떻게 범위 증가를 알 수 있을까? 63
유령 같은 범위 증가 64 / 범위를 기록하는 방법 65
이것은 범위 내에 있나요? 66 / 모호한 요구사항 = 모호한 범위 66

CHAPTER 3 설계에 관한 레슨 69

설계 개요 69
설계의 다른 측면들 70 / 좋은 설계 72
레슨 17 | 설계에는 반복이 필요하다 74
프로토타입의 위력 75 / 개념-증명 75 / 실물 모형 76
레슨 18 | 더 높은 추상화 수준에서 반복하는 것이 더 저렴하다 77
상세한 것으로부터 한 걸음 물러나기 78 / 빠른 시각적 반복 79 / 쉬운 반복 81
레슨 19 | 올바르게 사용하기는 쉽지만 잘못 사용하기는 어렵게 제품을 만들자 82
사용자가 실수할 수 없도록 만들자 83 / 사용자가 실수하기 어렵게 하자 84
오류를 쉽게 복구하게 하자 84 / 그런 일이 생기게 내버려 두자 84
레슨 20 | 모든 바람직한 품질 속성을 최적화할 수는 없다 85
품질의 관점 85 / 품질 속성 명시하기 87
품질을 위한 설계 88 / 아키텍처 속성과 품질 속성 89
레슨 21 | 힘들게 재코딩하는 것보다 조금이라도 설계하는 것이 가치가 있다 89
기술 부채와 리팩토링 90 / 아키텍처 결함 91
레슨 22 | 대부분의 시스템 문제는 인터페이스에서 생긴다 92
기술적인 인터페이스 문제들 93 / 입력 데이터 검증 95
사용자 인터페이스 문제들 96 / 인터페이스 전쟁 97

CHAPTER 4 프로젝트 관리에 관한 레슨 98

프로젝트 관리 개요 98
인력 관리 99 / 요구사항 관리 99 / 기대 관리 99 / 작업 관리 100
약속 관리 100 / 위험 관리 100 / 의사소통 관리 100 / 변경 관리 101
자원 관리 101 / 의존성 관리 101 / 계약 관리 101 / 공급자 관리 102
장벽 제거 관리하기 102
레슨 23 | 작업 계획은 마찰을 고려해야 한다 103
작업 전환과 몰입 104 / 유효 시간 106
프로젝트 마찰의 다른 원인 107 / 암시적 영향을 예상하기 107
레슨 24 | 다른 사람에게 섣불리 추정치를 제시하지 말자 108
성급한 예측 109 / 불확실성에 대한 두려움 110
레슨 25 | 빙산은 항상 처음 보이는 것보다 더 크다 110
컨틴전시 버퍼 111 / 위험한 가정 113 / 빙산 계약 115 / 버퍼의 묘미 115
레슨 26 | 자신의 주장을 뒷받침할 데이터가 있으면 협상에서 유리한 위치에 설 수 있다 116
그 수치는 어디서 구했어요? 116 / 원칙적 협상 118
레슨 27 | 추정치를 기록하고 실제 발생한 것과 비교하지 않으면 추정이 아닌 추측에 그칠 수밖에 없다 118
과거 데이터의 여러 출처 119 / 소프트웨어 메트릭 120
레슨 28 | 받는 사람이 듣고 싶어 하는 말을 근거로 견적을 변경하지 말자 122
목표 대 추정치 122 / 조정 시기 123
레슨 29 | 임계 경로를 피하자 124
임계 경로 정의 124 / 방해되지 않게 하기 125
레슨 30 | 작업은 전체적으로 완료 또는 완료되지 않음 중 하나다. 부분적인 완료는 없다 126
‘완료’는 무엇을 의미할까? 126 / 부분 점수는 없다 128
요구사항 상태별 추적 129 / 완성도가 가치로 이어진다 130
레슨 31 | 프로젝트 팀은 범위, 일정, 예산, 인원, 그리고 품질의 다섯 가지 관점 중 하나 이상에 대해 유연성이 필요하다 130
다섯 가지 프로젝트 관점 130 / 우선순위 협상하기 132
유연성 다이어그램 133 / 다섯 가지 관점 적용하기 134
레슨 32 | 프로젝트의 위험을 통제하지 못하면, 위험이 우리를 통제할 것이다 134
위험 관리란 무엇인가? 135 / 소프트웨어 위험 식별하기 135
위험 관리 활동 137 / 항상 걱정해야 할 것이 있다 139
레슨 33 | 고객이 항상 옳은 것은 아니다 139
‘옳지 않다’는 것 140 / 견해 존중하기 142
레슨 34 | 우리는 소프트웨어에서 너무 많은 가식 행위를 한다 143
상상의 나라에 살기 143 / 비이성적 기대감 144 / 사람들이 하는 게임 145

CHAPTER 5 문화와 팀워크에 관한 레슨 146

문화와 팀워크 개요 146
믿음 지키기 147 / 문화적 일치 148 / 문화의 구체화 149 / 성장하는 그룹 150
레슨 35 | 지식은 제로섬이 아니다 152
지식 독점 152 / 무지를 바로잡기 153 / 지식 전수 확대 154
건강한 정보 문화 156
레슨 36 | 다른 사람들이 아무리 많은 압력을 가하더라도, 우리가 이행할 수 없는 약속은 절대 하지 말자 156
약속, 약속 157 / 살다 보면 그럴 수 있지 158
레슨 37 | 교육과 더 나은 실무 사례가 없다면 생산성 향상은 꿈도 꾸지 말자 159
무엇이 문제인가? 160 / 몇 가지 가능한 해결책 160
도구 및 교육 162 / 개별 개발자의 성과 차이 162
레슨 38 | 사람들은 그들의 권리에 관해 많이 얘기하지만, 모든 권리의 이면에는 책임이 따른다 164
고객 권리 및 책임 예 165 / 개발자 권리 및 책임 예 165
프로젝트 관리자 또는 스폰서 권리 및 책임 예 166
자율 팀 권리 및 책임 예 166 / 위기 전의 우려 166
레슨 39 | 물리적 분리로 인해 의사소통과 협업이 저해되지는 않는다 167
공간과 시간의 장벽 167 / 가상 팀: 분리의 극치 169
문, 문, 문을 위한 나의 왕국! 169
레슨 40 | 소규모 공동 작업 팀에 적합한 비공식적인 접근 방식은 잘 확장되지 않는다 171
처리 체계와 도구 172 / 전문화의 필요성 172 / 의사소통 충돌 173
레슨 41 | 새로운 업무 방식으로 전환할 때 조직의 문화를 바꾸는 어려움을 과소평가하지 말자 174
가치, 행동, 그리고 실무 사례 174 / 애자일과 문화의 변화 176 / 내면화 177
레슨 42 | 비합리적인 사람들을 대할 때는 어떤 공학이나 관리 기법도 소용이 없다 178
약간의 가르침을 시도해보자 179 / 누가 선을 넘었나요? 179
유연성을 위하여 180

CHAPTER 6 품질에 관한 레슨 182

품질 개요 182
품질의 정의 182 / 품질 계획 183 / 품질의 다양한 관점 185 / 품질을 내재하기 185
레슨 43 | 소프트웨어 품질에 대해서라면 지금 지불하거나 또는 나중에 더 지불할 수 있다 187
수리 비용 증가 곡선 188 / 발견이 더 어렵다 190 / 초기 품질 조치 190
레슨 44 | 고품질은 자연스럽게 생산성 향상으로 이어진다 193
두 프로젝트 이야기 193 / 재작업의 재앙 195 / 품질 비용 196
레슨 45 | 조직은 소프트웨어를 제대로 구축할 시간이 없지만 나중에 그것을 해결할 수 있는 자원을 찾는다 197
왜 처음이 아닐까? 198 / 1억 달러 신드롬 199 / 균형 잡기 199
레슨 46 | 크랩 갭을 조심하자 200
크랩 갭 예 200 / 소프트웨어의 크랩 갭 시나리오 201
레슨 47 | 상사나 고객이 나쁜 일을 하도록 부추기지 말자 202
권력 행사 203 / 조급한 코드 작성 203 / 지식 부족 203
그늘진 윤리 205 / 절차 회피 205
레슨 48 | 고객이 아닌 동료가 결함을 찾도록 노력하자 206
동료 검토의 이점 206 / 다양한 소프트웨어 검토 207 / 검토의 문화적 영향 209
레슨 49 | 소프트웨어 사람들은 도구를 좋아하지만, 도구를 가진 바보가 더 큰 바보다 210
도구는 가치를 추가해야 한다 211 / 도구는 현명하게 사용해야 한다 212
도구는 프로세스가 아니다 213
레슨 50 | 오늘의 ‘당장 출시해야 하는’ 개발 프로젝트는 내일의 유지보수 악몽이다 214
기술 부채와 예방 유지보수 215 / 의식적인 기술 부채 215
현재 또는 미래의 품질을 위한 설계 216

CHAPTER 7 프로세스 개선에 관한 레슨 218

프로세스 개선 개요 218
소프트웨어 프로세스 개선이란? 218 / 프로세스를 두려워하지 말자 219
SPI를 정착시키기 220
레슨 51 | ‘비즈니스위크를 추종하는 경영’을 주의하자 221
먼저 문제, 그 다음에 해결책 222 / 근본 원인 분석 예 223
진단이 치료로 이어진다 225
레슨 52 | “내게 무슨 득이 되지?”라고 묻지 말고, “우리에게 어떤 이득이 있지?”라고 묻자 226
팀 이득 226 / 개인적 이득 228 / 팀을 위한 희생 229
레슨 53 | 사람들이 일하는 방식을 바꾸는 데
가장 좋은 동기가 되는 것은 고통이다 229
고통은 아프다! 230 / 보이지 않는 고통 231
레슨 54 | 조직을 새로운 작업 방식으로 이끌 때는 부드럽게 압박하되 끊임없이 가하자 232
변화로 이끌기 232 / 상향 관리 234
레슨 55 | 이전의 모든 전문가가 이미 저지른 실수를 일일이 되풀이할 시간은 없다 235
학습 곡선 236 / 모범 실무 사례 237
레슨 56 | 올바른 판단과 경험은 때때로 정해진 프로세스보다 우선한다 238
프로세스와 리듬 239 / 독단주의에 빠지지 않기 240
레슨 57 | 문서 템플릿에 줄여-맞추기 철학을 쓰자 242
레슨 58 | 시간을 들여 배우고 개선하지 않는 한, 다음 프로젝트가 지난 프로젝트보다 더 잘 될 것이라고 기대하지 말자 246
되돌아보기 246 / 회고 구조 248 / 회고 이후 249
레슨 59 | 소프트웨어 업계에서 가장 눈에 띄는 반복성은 비효율적인 일을 반복해서 하는 것이다 250
학습의 장점 251 / 사고의 장점 252

CHAPTER 8 다음에 할 일 254

레슨 60 | 모든 것을 한 번에 바꿀 수는 없다 255
변화 우선순위 지정 256
현실 점검 257
실행 계획 258
나만의 레슨 260

부록: 레슨 요약 261
요구사항 261 / 설계 262 / 프로젝트 관리 262
문화와 팀워크 262 / 품질 263 / 프로세스 개선 263
다음에 할 일 264

찾아보기 266