이미 소장하고 있다면 판매해 보세요.
|
Chapter1 소개 1
스크럼이란? 2 스크럼의 기원 3 왜 스크럼인가? 4 제노미카 결과 5 당신에게도 스크럼이 도움이 될까? 6 복합 영역 9 복잡 영역 9 단순 영역 10 혼돈 영역 10 무질서 10 인터럽트 주도 방식 11 마무리 12 제1부 주요 개념 Chapter2 스크럼 프레임워크 15 개요 15 스크럼 역할 16 제품 책임자 17 스크럼마스터 18 개발 팀 18 스크럼 활동과 산출물 19 제품 백로그 21 스프린트 23 스프린트 계획 24 스프린트 실행 25 일일 스크럼 26 완료 28 스프린트 리뷰 29 스프린트 회고 30 마무리 31 Chapter3 애자일 원칙 33 개요 33 가변성과 불확실성 35 유용한 가변성 활용 37 반복적이고 점진적인 개발 이용 37 점검, 적응, 투명성을 통해 가변성을 조정 40 모든 형태의 불확실성을 동시에 줄임 41 예측 및 적응 42 선택지를 열어 둠 42 미리 할 수 없다는 것을 받아들임 44 적응적, 탐구적인 접근법 선호 45 변화를 경제적이고 합리적인 방식으로 수용 46 앞으로 예상되는 일과 현재 필요한 적응적인 일의 균형 49 유효한 학습 50 중요한 가정을 빠르게 확인 50 동시다발적인 학습 루프의 영향력 51 빠른 피드백을 위해 일의 흐름 조직 52 진행 중인 일 53 경제적이고 합리적인 일괄 작업 크기 사용 54 좋은 흐름을 유지하기 위한 재고 관리 55 놀고 있는 직원들이 아니라 놀리고 있는 일에 주목 57 지연 비용 고려 59 진행 60 실시간 정보에 따라 조정 및 재계획 60 동작하는 산출물을 확인하여 진행 정도를 측정 61 가치 중심적 출시에 초점 61 실행 62 빠르게, 하지만 절대 서두르지 않음 62 좋은 품질로 만듦 63 의식 최소화 63 마무리 65 Chapter4 스프린트 67 개요 67 타임박스 68 진행 중인 일에 제한 설정 69 우선순위의 결정 69 진행 상황 명시 70 불필요한 완벽주의 방지 70 마무리 장려 70 예측 가능성 증진 70 짧은 기간 71 쉬운 계획 71 빠른 피드백 71 투자 수익률 증진 72 오류 제한 72 흥미를 되찾음 72 빈번한 체크포인트 73 일정한 기간 74 리듬이 주는 이득 75 계획 간소화 75 변경 없는 목표 76 스프린트 목표란? 76 상호 약속 77 변화와 명확성 77 변화의 대가 78 실용적으로 생각하기 79 비정상적 종료 80 완료의 정의 82 완료의 정의는 무엇인가? 82 완료의 정의는 시간이 지남에 따라 진화할 수 있다 84 완료의 정의와 인수 조건 86 완료와 완전 종료 86 마무리 87 Chapter5 요구 사항과 사용자 스토리 89 개요 89 대화 사용 92 점진적인 개선 93 사용자 스토리란 무엇인가? 93 카드 94 대화 95 확인 96 세부 사항 수준 97 좋은 스토리의 기준, INVEST 100 독립성 100 협상 가능성 101 가치 102 추정 104 (작은) 사이즈 적합성 104 테스트 105 비기능적 요구 사항 105 지식 습득 스토리 106 스토리 수집 108 사용자 스토리 작성 워크숍 109 스토리 매핑 110 마무리 111 Chapter6 제품 백로그 113 개요 113 제품 백로그 항목 114 좋은 제품 백로그의 특징 116 적절한 세부 사항 116 발생적 117 추정 117 우선순위 118 그루밍 119 그루밍이란? 120 그루밍은 누가 하는가? 121 언제 그루밍이 일어나는가? 122 준비의 정의 124 흐름 관리 125 출시 흐름 관리 126 스프린트 흐름 관리 127 어떤 그리고 얼마나 많은 제품 백로그가 있어야 하는가? 128 제품이란 무엇인가? 129 큰 제품 - 계층적인 백로그 130 여러 팀 - 한 제품 백로그 132 한 팀 - 여러 제품 133 마무리 134 Chapter7 추정 및 속도 137 개요 137 무엇을 언제 추정하는가 139 포트폴리오 백로그 항목 추정 140 제품 백로그 추정 140 작업 추정 141 제품 백로그 항목 추정 개념 142 팀으로서 추정 142 추정치는 약속이 아니다 143 정확도 대 정밀도 144 상대적 크기 추정 144 제품 백로그 항목 추정 단위 147 스토리 포인트 147 이상적 날짜 148 플래닝 포커 149 추정 등급 149 플래닝 포커 방법 150 이익 153 속도란 무엇인가? 153 속도 범위 계산 154 속도 예측 155 속도에 영향을 미치는 것 156 속도의 잘못된 사용 158 마무리 159 Chapter8 기술적 채무 161 개요 161 기술적 채무의 결과 163 티핑 포인트 예상 불가 164 전달 시간 증가 165 많은 결함 165 개발 및 지원 비용 증가 165 제품 위축 166 예상 가능성 감소 166 낮은 성과 166 전반적인 좌절감 167 고객 만족 감소 167 기술적 채무의 원인 167 마감일을 지켜야 한다는 압박감 168 거짓으로 속도를 증가시키려는 시도 168 테스트를 줄이면 속도가 빨라진다는 미신 169 채무 위에 쌓는 채무 170 기술적 채무는 반드시 관리되어야 한다 172 기술적 채무의 축적 관리 173 좋은 기술적 관습 사용 173 강력한 완료의 정의 사용 174 기술적 채무의 경제학 이해하기 174 기술적 채무 가시화 177 비즈니스 수준에서 기술적 채무 가시화 177 기술 수준에서 기술적 채무 가시화 179 기술적 채무의 이자 상환 180 모든 기술적 채무를 갚아야 하는 것은 아님 182 보이 스카우트 규칙 적용 (채무를 발견하면 이자를 갚아라) 183 기술적 채무를 점진적으로 갚음 184 이자율이 높은 기술적 채무를 먼저 갚음 185 고객 가치가 있는 작업을 실행하면서 기술적 채무를 갚음 186 마무리 187 제2부 역할 Chapter9 제품 책임자 191 개요 191 주요 책임 192 경제 관리 192 계획에 참여 195 제품 백로그 그루밍 195 인수 기준의 정의와 이들이 충족되었는지 결정 196 개발 팀과 협력 196 이해관계자들과 협력 198 특징/ 기술 198 전문 영역에 대한 기술 198 대인 기술 200 의사결정 200 책임감 201 제품 책임자의 일상 201 누가 제품 책임자가 되어야 하는가? 204 내부 개발 204 상업적 개발 205 외주 개발 프로젝트 208 부품 개발 208 다른 역할과 합쳐진 제품 책임자 209 제품 책임자 팀 210 제품 책임자 대리인 211 총 제품 책임자 212 마무리 213 Chapter10 스크럼마스터 215 개요 215 주요 의무 215 코치 216 서번트 리더 217 프로세스 지휘자 217 방해 보호막 217 장애물 제거자 218 변화 촉진자 218 특징/기술 218 지식 219 질문 219 인내심 220 협력 220 보호 220 투명성 221 스크럼마스터의 일상 221 역할 충족 222 누가 스크럼마스터가 되어야 할까? 223 스크럼마스터는 상근직인가? 223 다른 역할과 합쳐진 스크럼마스터 224 마무리 225 Chapter11 개발 팀 227 개요 227 역할별 팀 228 주요 책임 228 스프린트 시행 228 검토 및 적응 매일하기 229 제품 백로그 그루밍 229 스프린트 계획 230 제품 검토와 프로세스 개선 230 특징/기술 230 자기조직화 230 교차기능적으로 다양하고 충분한 팀 233 T자형 기술 235 삼총사의 자세 237 넓은 범위의 소통 238 투명한 의사소통 239 적절한 크기 240 집중 및 헌신 241 지속 가능한 속도로 일함 243 팀을 오래 유지하기 244 마무리 246 Chapter12 스크럼 팀 구조 247 개요 247 제품 기능 팀 vs 부품 팀 248 다수 팀 조직 253 스크럼의 스크럼 253 출시 기차 255 마무리 258 Chapter13 관리자 261 개요 261 팀의 방식을 정함 262 경계 설정 262 분명하고 고무적인 목표 제공 264 팀 형성 264 팀 구성 변경 265 팀에 권한 부여 266 팀 지도 267 사람들의 기운을 돋움 268 경쟁력 개발 268 기능 영역 리더십 제공 269 팀 통합성 유지 270 환경에 맞추고 적응 270 애자일 가치 촉진 270 조직적 장애물 제거 271 내부 그룹 정렬 271 파트너 정렬 272 가치 창출 흐름 관리 272 시스템 관점을 취함 272 경제성 관리 273 측정 및 보고 감시 273 프로젝트 관리자 275 스크럼 팀에서 프로젝트 관리자의 책임 275 별도의 프로젝트 관리자 역할 유지 276 마무리 281 제3부 계획 Chapter14 스크럼 계획 원칙 285 개요 285 선행계획을 세울 수 있다고 가정하지 마라 286 지나치지 않으면 미리 계획하는 것이 도움이 됨 287 마지막 결단의 순간이 되기까지 계획에 대한 선택지를 열어 둠 288 계획을 따르기보다 적응하고 다시 계획하는 데 초점을 맞춤 288 계획 재고의 올바른 관리 291 규모가 더 작고 빈번한 출시를 선호함 292 빠르게 배우고 필요하면 피벗 294 마무리 294 Chapter15 다양한 수준의 계획 295 개요 295 포트폴리오 계획 297 제품 계획(구상) 297 비전 297 상위 수준의 제품 백로그 298 제품 로드맵 298 출시 계획 300 스프린트 계획 302 일일 계획 302 마무리 304 Chapter16 포트폴리오 계획 305 개요 305 타이밍 306 참여자 306 프로세스 306 스케줄 작성 전략 309 생애주기 이익 최적화 309 지연 비용 계산 310 정밀도가 아닌 정확도 추정 313 유입 전략 314 경제적 필터 적용 315 시작과 완성의 균형을 맞춤 316 새로운 기회를 빠르게 수용함 318 더 작고 더 빈번한 출시를 위한 계획 319 유출 전략 320 놀고 있는 직원이 아닌, 놀리고 있는 일에 초점을 맞춘다 321 진행 중인 일에 제한을 설정한다 321 완전한 팀을 위해 기다린다 323 진행 중인 일에 대한 전략 323 한계 경제학 사용하기 324 마무리 326 Chapter17 구상(제품 계획) 327 개요 327 타이밍 328 참여자 329 프로세스 329 예시: 스마트 리뷰 포유 331 비전 332 상위 수준의 제품 백로그 만들기 335 제품 로드맵 정의 336 기타 활동 339 경제적이고 합리적인 구상 341 현실적인 자신감 역치를 목표로 한다 342 멀지 않은 범위에 집중한다 344 빠르게 행동한다 345 유효한 학습을 위해 대가를 지불한다 345 점진적/잠정적 자금 지원을 사용한다 347 빠르게 배우고 피벗한다(일명 빨리 실패하기) 348 마무리 349 Chapter18 출시 계획(장기 계획) 351 개요 351 타이밍 352 참여자 353 프로세스 353 출시 제약 355 모두 고정 356 범위와 날짜 고정 356 범위 고정 358 날짜 고정 358 가변적인 품질 359 제한 사항 업데이트 360 제품 백로그 그루밍 360 최소 출시 가능 제품 기능 정제 361 스프린트 매핑(제품 백로그 항목 슬로팅) 363 날짜 고정 출시 계획 365 범위 고정 출시 계획 370 비용 계산 372 소통 374 범위 고정 출시에서의 소통 374 날짜 고정 출시에서의 소통 376 마무리 378 제4부 스프린트 활동 Chapter19 스프린트 계획 381 개요 381 타이밍 381 참여자 382 프로세스 382 스프린트 계획 접근법 385 두 파트 스프린트 계획 385 한 파트 스프린트 계획 386 역량 확인 387 역량이란? 387 스토리 포인트로 나타낸 역량 389 작업 시간으로 나타낸 역량 389 제품 백로그 항목 선정 390 자신감 얻기 391 스프린트 목표 다듬기 393 약속 최종 결정 393 마무리 394 Chapter20 스프린트 시행 395 개요 395 타이밍 395 참여자 395 프로세스 396 스프린트 시행 계획 397 흐름 관리 398 병행하는 일과 스워밍 398 시작할 일은 어떤 것인가 401 어떻게 업무를 조직하는가 402 무슨 일을 완료해야 하는가? 402 누가 그 일을 하는가? 403 일일 스크럼 404 업무 실행 - 기술적 실천법 404 소통 405 업무 상황판 406 스프린트 번다운 차트 407 스프린트 번업 차트 409 마무리 411 Chapter21 스프린트 리뷰 413 개요 413 참여자 414 선작업 416 누구를 초대할지 결정 416 스프린트 리뷰 스케줄 417 스프린트 완료 작업 확인 417 시연을 위한 준비 419 누가 무엇을 할지 결정 419 접근법 420 요약 421 시연 421 논의 422 적응 422 스프린트 리뷰 쟁점 423 종료 423 산발적 참석 424 규모가 큰 개발 활동 425 마무리 425 Chapter22 스프린트 회고 427 개요 427 참여자 429 준비 작업 430 회고의 초점을 정의 431 실행 방법 선택 432 객관적 데이터 수집 432 회고 구조화 433 접근법 434 분위기 조성 435 상황 공유 436 통찰력 확인 439 행동 결정 441 회고 마무리 445 후속 조치 445 스프린트 회고 문제 446 마무리 449 Chapter23 앞으로 나아갈 길 451 끝은 없다 451 자신만의 길을 발견하라 452 가장 좋은 실천법 공유 452 앞으로 나아갈 길을 발견하기 위한 스크럼 사용 454 시작하라! 455 용어사전 457 그림 목록 479 참고문헌 487 찾아보기 493 |
|
스크럼은 왕도도 마법 치료약도 아니다. 하지만 스크럼은 복합적인 제품 개발 노력(product development eort)에 따르는 변화들을 받아들일 수 있도록 한다. 제노미카를 포함해 소프트웨어를 개발하는 데 맞는 더 나은 방식을 찾고자 한 많은 회사들에게 있어서 스크럼은 옳은 선택이었고 또 다른 회사에도 맞는 방법이 될 수 있다. 비록 스크럼 체계는 단순하지만, 스크럼을 적용하는 것이 쉽고 간편할 것이라고 생각하는 것은 오산이다. 스크럼은 질문에 정해진 답변을 주지 않는 대신에 팀이 스스로 좋은 질문을 떠올리고 답할 수 있는 권한을 부여한다. 조직의 병폐에 요리책 같은 해결책을 주지는 않지만, 조직이 진정한 가능성을 실현하는 것을 막는 비효율적이고 낭비적인 부분을 드러나게 한다.
_12쪽 제품 백로그 항목은 스프린트로 들어올 때 제품 책임자가 명시한 일련의 충족 조건(conditions of satisfaction)(항목별 인수 조건)을 가지고 있어야 한다. 이 인수 조건(acceptance criteria)은 최종적으로 제품 책임자에 의해 백로그 항목이 원하던 대로 작동하는지 확인하는 인수 테스트(acceptance test)에서 인증된다. 예를 들어, 제품 백로그 목록이 “고객이 신용카드 결제가 가능하다”이면 충족 조건은 “아멕스, 비자, 마스터 카드로 결제가 가능하다”가 될 수 있다. 따라서 각 제품 백로그 항목은 각기 적합한 일련의 인수 조건을 가질 것이다. 이 기준들은 ‘완료의 정의(denition-of-done) 체크리스트’에 의해 정해진 ‘완료 기준(the done criteria)’에 추가되어 해당 항목에만 적용되고, 인수 조건이 완료의 정의를 대신하지는 않는다. _86쪽 대부분의 제품 백로그 항목은 제품 기능이다. 이는 사용자나 고객에게 실질적인 가치가 있는 기능 항목을 뜻한다. (스크럼이 제품 백로그 항목을 특정 형태로 작성하라고 정하지는 않지만) 제품 백로그는 종종 사용자 스토리로 작성된다. 제품 기능의 예는 완전히 새로운 것(새로운 웹사이트를 위한 로그인 화면), 혹은 현존하는 제품 기능의 변화(이미 존재하는 웹사이트의 더 나은 사용자 친화적인 로그인 화면)를 포함한다. 그 외의 제품 백로그 항목은 수리가 필요한 결함, 기술적인 개선, 지식 습득을 위한 작업을 비롯해 제품 책임자가 가치 있다고 여기는 것을 포함한 모든 작업들이다. _114쪽 최종적으로 그루밍에서 결정하는 사람은 제품 책임자 단 한 명이다. 하지만 좋은 제품 책임자는 협력적인 그루밍이 모든 참여자 간에 중요한 대화를 조성하고 다양한 그룹에 소속된 개인들의 집단 지성과 관점을 통해 다른 방식으로는 놓칠 수 있는 중요한 정보를 밝혀낸다는 것을 이해한다. 좋은 제품 책임자는 또한 다양한 팀 멤버들을 그루밍에 포함시키면 모두가 제품 백로그에 대해 더 명백하고 공통된 이해를 가지게 되며 따라서 잘못된 소통과 일을 전달하는 데 걸리는 시간 낭비가 줄어든다는 것을 알고 있다. 이러한 공통의 노력은 또한 비즈니스 관계자들과 기술자들의 역사적인 차이를 연결하는 데 많은 도움이 된다. _121쪽 하지만 실제로는 테스트를 줄이면, 빚이 늘어나고 개발 속도가 느려지는 원인이 된다. 나중에 문제를 발견했을 때에는 문제를 고치는 데 시간이 훨씬 더 많이 걸리기 때문이다. 테스트가 근본적으로 개발 과정에 통합되어 있을 때, 숙련된 팀은 더 적은 기술적 채무로 좋은 품질의 결과물을 만들어 낸다. 이런 팀은 테스트 주도 개발(TDD, Test-Driven Development)과 같은 좋은 기술적 실천법을 사용한다. 테스트 주도 개발에서는 제품 코드를 작성하기 전에 작은 단위 테스트를 먼저 작성하고 자동화한 다음 테스트를 통과하게 만든다(Crispin and Gregory 2009). ---p.170 |