소프트웨어 개발의 진주
60개의 레슨으로 배우는 소프트웨어 개발의 핵심 지식과 실전 경험
$28.35
SKU
9791192987682
[Free shipping over $100]
Standard Shipping estimated by Thu 05/23 - Wed 05/29 (주문일로부 10-14 영업일)
Express Shipping estimated by Mon 05/20 - Wed 05/22 (주문일로부 7-9 영업일)
* 안내되는 배송 완료 예상일은 유통사/배송사의 상황에 따라 예고 없이 변동될 수 있습니다.
| Publication Date | 2024/03/06 |
| Pages/Weight/Size | 188*245*18mm |
| ISBN | 9791192987682 |
| Categories | IT 모바일 > 컴퓨터 공학 |
Description
요구사항부터 설계, 프로젝트 관리, 문화와 팀워크, 품질, 프로세스 개선까지
소프트웨어 개발 실무 능력 향상을 위한 모든 것을 담았다
경험은 좋은 스승이지만 느리고 고통스럽기도 하다. 조개가 모래알과 같은 이물질에 자극되어 값진 진주를 만들듯이, 저자는 50여 년 동안의 소프트웨어 개발 경력에서 마주친 장애물들로부터 요구사항, 설계, 프로젝트 관리, 문화와 팀워크, 품질, 프로세스 개선 등에 대한 60개의 레슨을 이끌어냈다. 이를 통해 각자의 역할, 업종, 기술 또는 방법론에 관계없이 앞으로 프로젝트를 진행하면서 겪게 될 고통스러운 시간과 시행착오를 줄일 수 있을 것이다.
소프트웨어 개발 실무 능력 향상을 위한 모든 것을 담았다
경험은 좋은 스승이지만 느리고 고통스럽기도 하다. 조개가 모래알과 같은 이물질에 자극되어 값진 진주를 만들듯이, 저자는 50여 년 동안의 소프트웨어 개발 경력에서 마주친 장애물들로부터 요구사항, 설계, 프로젝트 관리, 문화와 팀워크, 품질, 프로세스 개선 등에 대한 60개의 레슨을 이끌어냈다. 이를 통해 각자의 역할, 업종, 기술 또는 방법론에 관계없이 앞으로 프로젝트를 진행하면서 겪게 될 고통스러운 시간과 시행착오를 줄일 수 있을 것이다.
Contents
옮긴이 머리말 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
추천사 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