요구사항부터 설계, 프로젝트 관리, 문화와 팀워크, 품질, 프로세스 개선까지소프트웨어 개발 실무 능력 향상을 위한 모든 것을 담았다경험은 좋은 스승이지만 느리고 고통스럽기도 하다. 조개가 모래알과 같은 이물질에 자극되어 값진 진주를 만들듯이, 저자는 50여 년 동안의 소프트웨어 개발 경력에서 마주친 장애물들로부터 요구사항, 설계, 프로젝트 관리, 문화와 팀워크, 품질, 프로세스 개선 등에 대한 60개의 레슨을 이끌어냈다. 이를 통해 각자의 역할, 업종, 기술 또는 방법론에 관계없이 앞으로 프로젝트를 진행하면서 겪게 될 고통스러운 시간과 시행착오를 줄일 수 있을 것이다.
Process Impact의 수석 컨설턴트로서 150여 개의 조직을 대상으로 소프트웨어 개발 및 요구사항 엔지니어링에 대한 교육과 컨설팅에 50년 이상 몸담아왔다. 저서로는 캔디스 호캔슨과 함께 쓴 『소프트웨어 요구사항의 정수』(제이펍, 2024)가 있고, 조이 비티와 함께 쓴 『소프트웨어 요구사항(제3판)』(위키북스, 2017)으로는 미국 기술커뮤니케이션학회로부터 우수상을 수상했다.
옮긴이 머리말 xi추천사 xvi감사의 글 xxi베타리더 후기 xiii추천 서문 xixCHAPTER 1 고통스러운 경험을 통한 학습 1나의 관점 2이 책에 관하여 3용어 특기사항 5기회 활용 5CHAPTER 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 / 모호한 요구사항 = 모호한 범위 66CHAPTER 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 / 인터페이스 전쟁 97CHAPTER 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 / 사람들이 하는 게임 145CHAPTER 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유연성을 위하여 180CHAPTER 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현재 또는 미래의 품질을 위한 설계 216CHAPTER 7 프로세스 개선에 관한 레슨 218프로세스 개선 개요 218소프트웨어 프로세스 개선이란? 218 / 프로세스를 두려워하지 말자 219SPI를 정착시키기 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 / 사고의 장점 252CHAPTER 8 다음에 할 일 254레슨 60 | 모든 것을 한 번에 바꿀 수는 없다 255변화 우선순위 지정 256현실 점검 257실행 계획 258나만의 레슨 260부록: 레슨 요약 261요구사항 261 / 설계 262 / 프로젝트 관리 262문화와 팀워크 262 / 품질 263 / 프로세스 개선 263다음에 할 일 264찾아보기 266
