이미 소장하고 있다면 판매해 보세요.
|
들어가며 서문 - 이봐, 스크럼이 통했어!
1들어가는 글 주의 이 책을 쓴 이유 그런데 스크럼이 뭐지? 2제품 백로그 만들기 추가 스토리 항목들 제품 백로그를 비즈니스 수준으로 유지하기 3스프린트 계획회의 준비하기 4스프린트 계획 수립하기 왜 제품 책임자가 참석해야만 하는가? 왜 품질은 협상의 대상이 아닌가? 질질 늘어지는 스프린트 계획회의 스프린트 계획회의 시간표 스프린트 길이 결정하기 스프린트 목표 결정하기 스프린트에 구현할 스토리 고르기 제품 책임자가 스프린트에 포함시킬 스토리 결정에 어떻게 영향을 미치는가? 팀은 스프린트에 포함시킬 스토리를 어떻게 결정하는가? 우리가 인덱스 카드를 사용하는 이유 완료의 정의 플래닝 포커를 사용하여 시간 추정하기 스토리 명확히 하기 스토리를 작은 스토리로 분해하기 스토리를 작업 단위로 나누기 일일 스크럼의 시간과 장소 결정하기 어디에 선을 그을까 기술 스토리 버그 추적 시스템과 제품 백로그 스프린트 계획회의가 마침내 끝나다 5스프린트를 알리는 방법 6스프린트 백로그 만들기 스프린트 백로그 형식 작업 현황판의 원리 예제1 ? 첫 번째 일일 스크럼을 마치고 예제2 - 며칠이 지나고 소멸 차트의 원리 업 현황판의 경고 신호 이봐, 이력 관리는 어떻게 해?! 날짜로 추정하기와 시간으로 추정하기 7팀방 꾸미기 설계 구역 팀을 한자리에 모아라 제품 책임자 떨어뜨려 놓기 관리자와 코치 떨어뜨려 놓기 8일일 스크럼 진행하기 작업 현황판 업데이트하기 지각자 다루기 '오늘 할 일을 모르겠어요' 문제 다루기 9스프린트 데모하기 모든 스프린트가 데모로 끝나야 하는 이유 스프린트 데모 체크리스트 데모 불가' 항목 처리하기 10스프린트 회고하기 모든 팀이 회고를 해야 한다고 주장하는 이유 회고 구성하기 팀 간 교훈 전파하기 바꿀 것인가 바꾸지 않을 것인가 회고 중에 드러날 수 있는 사례들 11스프린트 사이의 휴식 시간 12고정 가격 계약 하에서 릴리스 계획하기 허용 기준 정의하기 가장 중요한 항목들의 시간 추정하기 속도 추정하기 전부 합쳐 릴리스 계획 만들기 릴리스 계획을 현실에 맞추기 13스크럼과 XP 결합하기 짝 프로그래밍 테스트 주도 개발(TDD) 점증적 설계 지속적 통합 코드 공동 소유 정보가 가득한 작업 공간 코딩 표준 지속 가능한 속도/ 활기 넘치는 작업 14테스트하기 인수 테스트 단계를 없앨 수는 없다 인수 테스트 단계 최소화하기 스크럼 팀에 테스터를 포함시켜 품질 향상시키기 스프린트 작업량을 줄여 품질 향상시키기 인수 테스트가 스프린트의 일부여야 하는가? 스프린트 주기와 인수 테스트 주기 가장 느린 연결고리에서 무리하자 마라 현실로 돌아가기 15여러 스크럼 팀 다루기 팀을 몇 개 만들어야 하는가 스프린트를 동기화할 것인가, 말 것인가? 팀 리드' 역할을 도입한 이유 팀에 인원 할당하기 특화 팀을 둘 것인가 말 것인가? 스프린트 사이에 팀을 재구성하는 문제 비상근 팀원 스크럼들의 스크럼 진행하기 일일 스크럼 회의 엇갈리게 배치하기 소방수 팀 제품 백로그를 나눌 것인가 말 것인가? 코드 가지치기 여러 팀 회고 16지리적으로 분산되어 있는 팀 다루기 오프쇼어링 재택근무하는 팀원 17스크럼 마스터 체크리스트 스프린트 초기 매일 스프린트 종료 18글을 마치며 추천 도서 지은이 소개 부록1: 스크럼 입문 부록2: 노키아 체크리스트 부록3: 플래닝 포커 사용법 찾기 |
|
이 책은 저자가 스웨덴의 한 회사에서 약 40여 명으로 구성된 팀과 함께 일 년여 기간에 걸쳐 진행한 프로젝트 과정을 기록한 이야기이다. 여기서 어떻게 스크럼과 XP를 구현했는지, 어떻게 지속적으로 자신의 프로세스를 개선했는지에 관해 상세하고 실제적인 이야기를 들려준다. 이 이야기를 읽음으로 해서 우리는 스크럼을 시작하는 데 많은 도움을 얻을 것이다.
스크럼(Scrum)과 익스트림 프로그래밍(eXtreme Programming)은 팀에게 매 반복의 종료 시점마다 출시할 만한 명확한 작업 결과물을 완성할 것을 요구한다. 짧은 시간 내에 동작하는 코드를 전달하는 데 집중해야 하므로 스크럼 팀과 XP 팀은 이론만 논하고 있을 시간이 없다. CASE 도구를 사용하여 완벽한 UML 모델을 그리는 데 매달릴 시간도 없다. 그리고 완벽한 요구사항 문서를 작성하지도, 미래에 있을지 없을지도 모를 변경사항을 수용하려는 코드를 작성하지도 않는다. 이렇게 스크럼 팀과 XP 팀은 어떻게든 실제로 일이 되도록 하는 것에 집중한다. 또한 스크럼 팀은 일하는 도중에 발생할 수 있는 실수를 받아들인다. 하지만 그들은 그러한 실수를 발견하는 최선의 방법이 분석과 설계라는 ‘이론적 차원에서 소프트웨어 바라보기’가 아니라, 그 안으로 뛰어들어 직접 손을 더럽혀가며 제품을 개발하는 데 있음도 분명 깨닫고 있다. 이 책은 이론보다는 실행에 초점을 맞추고 있다는 점에서 다른 책들과는 차별화된다. 스크럼이 무엇인지 장황하게 설명하지 않는다. 그저 간단한 웹 사이트를 몇 개 알려주고는 곧바로 본론으로 들어가 그의 팀이 제품 백로그를 어떻게 관리하고 활용했는지를 설명한다. 계속해서 잘 돌아가는 애자일 프로젝트의 다른 요소와 기법들을 하나하나 다루어 간다. 이 책에서는 고리타분한 이론도 참고문헌도 각주도 없다. 스크럼이 왜 통하는지, 스크럼이나 다른 기법을 왜 시도하려는지 철학적인 설명도 하지 않습니다. 잘 굴러가는 애자일 팀이 어떻게 일하는지만이 설명될 뿐이다. * 스크럼과 XP 실천법에 대한 실무적인 팁과 요령 * 전형적인 함정과 그 함정들에 대한 대처 방법 * 진행했던 일들을 묘사하는 다이어그램과 사진들 * 테스팅과 테스트 주도 개발 * 여러 팀으로의 확장과 팀 간 조율 * 팀 내외부의 저항 다루기 * 계획 수립과 시간 추정 기법 |