소프트웨어 개발의 진주

 

요구사항부터 설계, 프로젝트 관리, 문화와 팀워크, 품질, 프로세스 개선까지

소프트웨어 개발 실무 능력 향상을 위한 모든 것을 담았다

 

도서구매 사이트(가나다순)

교보문고 / 도서11번가 / 알라딘 / 예스이십사 / 인터파크 / 쿠팡

 

전자책 구매 사이트(가나다순)

교보문고 / 구글북스 / 리디북스 / 알라딘 / 예스이십사

 

출판사 제이펍
저작권사 Pearson Education
원서명 Software Development Pearls: Lessons from Fifty Years of Software Experience (9780137487776)
도서명 소프트웨어 개발의 진주
부 제 60개의 레슨으로 배우는 소프트웨어 개발의 핵심 지식과 실전 경험
지은이 칼 위거스
옮긴이 심재철
감수자 (없음)
시리즈 (없음)
출판일 2024년 3월 6일
페이지 300쪽
판 형 46배판변형(188*245*17.5)
제 본 무선(soft cover)
정 가 25,000원
ISBN 979-11-92987-68-2 (93000)
키워드 요구사항, 설계, 프로젝트 관리, 팀워크, 품질, 프로세스 개선, 비즈니스 성과
분 야 컴퓨팅 공학 / 프로그래밍 일반

 

관련 사이트
■ 아마존 도서소개 페이지
■ 저작권사 도서소개 페이지

관련 포스트
■ 프레더릭 브룩스의 《Mythical Man-Month》를 읽어봤다면...

 

관련 도서
■ 소프트웨어 요구사항의 정수

 

미리 보기(앞부속, 1장 '고통스러운 경험을 통한 학습', 2장 '요구사항에 관한 레슨' 일부)

 

정오표 페이지
■ (등록되는 대로 링크를 걸겠습니다.)

 

도서구매 사이트(가나다순)

교보문고 / 도서11번가 / 알라딘 / 예스이십사 / 인터파크 / 쿠팡

 

전자책 구매 사이트(가나다순)

교보문고 / 구글북스 / 리디북스 / 알라딘 / 예스이십사

 

도서 소개

프레더릭 브룩스의 고전 《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, “모든 것을 한 번에 바꿀 수는 없다”)을 제공하며, 부록에서는 모든 레슨의 참고자료를 제공한다.

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

 

지은이 소개

칼 위거스(Karl Wiegers)
Process Impact의 수석 컨설턴트로서 150여 개의 조직을 대상으로 소프트웨어 개발 및 요구사항 엔지니어링에 대한 교육과 컨설팅에 50년 이상 몸담아왔다. 저서로는 캔디스 호캔슨과 함께 쓴 《소프트웨어 요구사항의 정수》(제이펍, 2024)가 있고, 조이 비티와 함께 쓴 《소프트웨어 요구사항(제3판)》(위키북스, 2017)으로는 미국 기술커뮤니케이션학회로부터 우수상을 수상했다.

 

옮긴이 소개

심재철 
현재 프리랜서로, 데이터베이스/모바일 시스템 관련 컨설팅과 번역을 하고 있다. 또한, 20년 넘게 데이터베이스와 객체지향 시스템 설계 및 개발 프로젝트와 건설/금융 분야 애플리케이션 개발 등에 참여했다. 새로운 테크놀로지와 다양한 프로그래밍 언어를 사용해서 실무에 활용하고 가르치는 것을 좋아한다. 저서로는 《핵심만 골라 배우는 코틀린 프로그래밍》이 있으며, 번역서로는 《실무에 바로 적용하는 안드로이드 프로그래밍(제4판)》, 《스프링 인 액션(제5판)》, 《카프카 핵심 가이드(제1판)》, 《핵심만 골라 배우는 안드로이드 스튜디오 Arctic Fox & 프로그래밍》, 《실무에 적용하는 안드로이드 프로그래밍(제2판)》, 《Learn Android Studio》, 《SQLite 마스터북(제2판)》, 《프로 오브젝티브-C 디자인 패턴》, 《세븐 데이터베이스: 만들면서 파악하는 NoSQL》, 《UML 사용자 지침서》, 《Thinking in JAVA(제4판)》, 《이펙티브 자바》 등이 있다.

 

차례

 

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

 

제이펍 소식 더 보기(제이펍의 소통 채널에서 더욱 다양한 소식을 확인하세요!)

네이버 포스트 / 유튜브 / 인스타그램 / 트위터 / 페이스북