추가 적립 안내

요구사항부터 설계, 프로젝트 관리, 문화와 팀워크, 품질, 프로세스 개선까지 소프트웨어 개발 실무 능력 향상을 위한 모든 것을 담았다

경험은 좋은 스승이지만 느리고 고통스럽기도 하다. 조개가 모래알과 같은 이물질에 자극되어 값진 진주를 만들듯이, 저자는 50여 년 동안의 소프트웨어 개발 경력에서 마주친 장애물들로부터 요구사항, 설계, 프로젝트 관리, 문화와 팀워크, 품질, 프로세스 개선 등에 대한 60개의 레슨을 이끌어냈다. 이를 통해 각자의 역할, 업종, 기술 또는 방법론에 관계없이 앞으로 프로젝트를 진행하면서 겪게 될 고통스러운 시간과 시행착오를 줄일 수 있을 것이다.

프레더릭 브룩스의 고전 《Mythical Man-Month》와 견줄 만하다!

칼 위거스의 이 책은 엄청난 통찰력을 준 《Mythical Man-Month》와 비슷한 맥락이지만, 범위가 더 넓고 최근 기술까지 포함하고 있다.
-Meilir Page-Jones, Wayland Systems Inc. 수석 비즈니스 분석가

저자가 이 책을 쓴 이유는, 이 책에 수록된 것과 동일한 레슨들을 독자가 따로 힘들게 축적할 필요 없도록 하기 위해서다. 이 책의 레슨들을 읽었던 경험 많은 소프트웨어 엔지니어는 이렇게 논평하였다.
“여기 수록된 모든 레슨은 하나하나마다 해당 레슨과 관련된 고통의 흔적이 담겨 있다.”

이 책에는 소프트웨어 개발과 관리에 관한 59개의 레슨이 포함되어 있다. 모든 레슨은 6개 부문으로 분류되어 있고 각 부문은 한 챕터(2장부터 7장까지)로 구성되었다.
2장. 요구사항(requirement)
3장. 설계(design)
4장. 프로젝트 관리(project management)
5장. 문화와 팀워크(culture and teamwork)
6장. 품질(quality)
7장. 프로세스 개선(process improvement)
마지막으로 8장에서는 일반적인 레슨(레슨 60, “모든 것을 한 번에 바꿀 수는 없다”)을 제공하며, 부록에서는 모든 레슨의 참고자료를 제공한다.

주요 내용
■ 현실 문제에 대한 공유된 비전과 이해를 얻기 위해 요구사항을 명확히 한다.
■ 올바른 기능과 품질 속성을 구현하고 진화할 수 있도록 견고하게 설계한다.
■ 흔히 접하는 프로젝트 관리의 함정을 예측하고 방지한다.
■ 처음부터 품질을 일순위로 고려하여 현실적으로 계획한다.
■ 프로세스 개선을 통해 원하는 비즈니스 성과를 달성한다.

Jim Brosseau(Clarrus)
이 레슨들은 정말로 주옥같은 지혜로서, 영원하게 우리의 역할과 관계없이 훌륭한 소프트웨어를 더 잘 개발할 수 있도록 해주는 변치 않을 핵심이다. 자신을 위한 책 한 권과 팀의 다른 사람들을 위한 한 권을 더해 두 권을 구매해도 좋을 것이다.

Joy Beatty(Seilevel의 부사장)
이 책은 수년간의 실제 프로젝트에서 얻은 실제 경험에 뿌리를 두고 있으며, 레슨들을 뒷받침하는 철저한 연구가 적절히 담겨 있다. 칼의 모든 책과 마찬가지로, 그는 관련된 이야기와 몇 가지 재미있는 논평으로 가득 찬 가볍고 매력적인 책을 고수한다. 앞에서 뒤로 읽거나 현재 개선하고자 하는 영역과 관련된 특정 레슨만 읽을 수도 있다. 재미있는 읽기에 더한 실용적인 조언. 잘못될 수가 없다!

Meilir Page-Jones(Wayland Systems Inc. 수석 비즈니스 분석가)
서툴러 생긴 실수에 대한 대가를 치르지 않으면서 성공한 선배로부터 평생의 경험을 얻는 것은 정말 멋진 일이다. 칼 위거스는 비즈니스 분석, 소프트웨어 공학 및 프로젝트 관리의 핵심 기술에 정통하다. 처음부터 장애를 피하는 방법뿐만 아니라 장애를 극복하는 방법에 대해 간결하면서도 중요한 통찰력을 얻을 수 있을 것이다.

Steve McConnell(Construx Software 창립자이자 《Code Complete》의 저자)
진주가 생성되는 과정은 모래알과 같은 이물질이 진주조개에 들어 있을 때 시작된다. 그리고 이에 반응하여 진주조개는 이물질로부터 자신을 보호하기 위해 그것을 뒤덮어 점차 키운다. 오랜 시간이 걸리지만 결국 그 이물질은 값진 진주가 된다. 그는 오랜 시간 자신이 접한 접한 소프트웨어 개발에서의 이물질에 대해 깊이 생각했으며, 이 책에는 그의 가장 가치 있는 60개의 응답이 담겨 있다.

옮긴이 머리말 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

레슨 23 작업 계획은 마찰을 고려해야 한다
나는 어느 날 회사에서 다음 대화를 우연히 들었다.
관리자 섀넌: “제이미, 지금 카나리아 프로젝트의 사용성 평가를 하고 있다며? 몇몇 다른 프로젝트에서도 사용성 평가에 관심이 있던데, 평가하는 데 시간이 얼마나 걸리니?”
팀 멤버 제이미: “1주일에 8시간 정도요.”
관리자 섀넌: “아, 그래? 그러면 1주일에 다섯 프로젝트에서 일을 할 수 있겠네.”
여러분은 섀넌의 생각에 어떤 결함이 있는지 알 수 있을 것이다. 8 곱하기 5는 주당 근로 시간인 40이므로 외견상으로는 타당한 것처럼 보인다. 그러나 섀넌은 사람들이 매일 프로젝트 작업에서 사용 가능한 시간을 단축하는 많은 요인들을 고려하지 않았다. 그중에는 프로젝트 마찰이 있다. (103쪽)

레슨 28 받는 사람이 듣고 싶어 하는 말을 근거로 견적을 변경하지 말자
프로젝트의 다음 부분을 완료하는 데 얼마나 걸리는지 고객이 물어본다고 가정해보자. 해당 일에 대한 분석을 바탕으로 “두 달 정도요.”라고 우리가 대답한다. “두 달? 12살짜리 내 딸도 3주 안에 그 일을 할 수 있을 거예요!”라고 고객이 비웃으며 말한다. “그러면 고객님 딸을 고용하시죠.”라고 말하고 싶은 유혹을 우리는 뿌리치고 다시 말한다. “좋습니다, 한 달은 어때요?” 그러면 이 몇 초 동안 무엇이 변했을까? (122쪽)

레슨 30 작업은 전체적으로 완료 또는 완료되지 않음 중 하나다, 부분적인 완료는 없다
“이봐, 필, 그 하위 시스템 구현 잘되고 있어?”
“꽤 좋아요. 90% 정도 했어요.”
“잠깐만. 몇 주 전에 90% 했다고 하지 않았어?”
“네, 하지만 지금은 실제로 90%를 완료했어요!”
소프트웨어 프로젝트와 작업이 90% 완료된 것으로 보고되는 것은 업계에서 오랫동안 농담처럼 통용되어온 개념이다(Wiegers 2019b). (관련 농담에 따르면 소프트웨어 프로젝트의 전반부는 자원의 90%를 소비하고, 후반부는 나머지 90%를 소비한다는 우스갯소리도 있다.) (126쪽)

조직에서 가식적 행위를 하는 것이 있는가? 그렇다면 어떤 영향이 있을까? 그것에 관해 우리가 할 수 있는 일이 있는가?
나는 가식을 별로 좋아하지 않는다. 세상이 실제와 다르기를 바라는 것은 위로가 될 수 있지만 건설적이지는 않다. 현실에 그리 만족하지는 않지만 그것이 내가 가진 전부이므로 감수하고 살아야 한다. 우리 모두 그래야 한다. (145쪽)

학습하고 개선하는 조직을 구축하는 것은 자신의 경험에서 지혜의 진주를 모아서 다른 사람들과 공유하는 가치를 내면화한 개인에게서 시작된다. 이번 기회에 이 책에서 읽은 내용 중 일부라도 실천에 옮기기 바란다. 팀 멤버들을 그 실천에 초대해보자. 즐거운 여정이 될 것이다. (260쪽)