<div id="readability-page-1" class="page"><div role="banner"> <div>  <h4>06 Apr 2023</h4> <p> <i></i> Reading time ~6 minutes </p> </div> <h2 id="스크럼-101"><strong>스크럼 101</strong></h2>   <p><a href="http://www.yes24.com/Product/Goods/115632480">출근했더니 스크럼 마스터가 된 건에 관하여 - 니시무라 나오토</a></p> <hr> <h2 id="애자일-소프트웨어">애자일 소프트웨어</h2> <h3 id="애자일-선언문"><a href="https://agilemanifesto.org/iso/ko/manifesto.html">애자일 선언문</a></h3> <ul> <li>목적을 달성하기 위해 모든 관계자가 긴밀하게 협조</li> <li>한번에 전체를 완성하기 보다 조금씩 만들되, 조기에 동작시켜 피드백 받음</li> <li>사용자나 관계자의 피드백을 바탕으로 결과물과 계획을 지속적으로 보완</li> </ul> <hr> <h2 id="스크럼">스크럼</h2> <ul> <li>가치와 위험도, 필요성을 기준으로 요구사항을 정렬</li> <li>순서대로 구현하며 성과를 극대화</li> <li>정해진 시간 안에 작업을 완료 - 타임박스(timebox)</li> <li>현재 상태와 문제점을 명확하게 밝힘 - 투명성(transparency)</li> <li>개발할 제품과 진척에 이상은 없는지 수시로 확인 - 점검(inspection)</li> <li>더 나은 방법으로 작업 방식 개선 - 보완(adaptation)</li> </ul> <hr> <h2 id="3가지-역할-5가지-활동-3가지-산출물">3가지 역할, 5가지 활동, 3가지 산출물</h2> <p>스크럼을 프레임워크라고 부르는 특징</p> <h3 id="스크럼가이드--한글pdf"><a href="https://scrumguides.org/scrum-guide.html">스크럼가이드</a> :: <a href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Korean.pdf">한글PDF</a></h3> <hr> <h2 id="산출물-1-프로덕트-백로그">산출물 #1 프로덕트 백로그</h2> <ul> <li>구현하고 싶은 것을 목록으로 만듦</li> <li>항목은 언제든지 추가, 삭제 가능</li> <li>우선순위에 맞춰 정렬</li> <li>우선순위가 높은 항목부터 작업량을 추정</li> <li>정기적으로 항목의 순서나 내용, 작업량을 보완</li> </ul> <h4 id="사용자-스토리">사용자 스토리</h4> <p>제품의 요구 사항을 <code>사용자</code> 관점에서 <code>누가</code>, <code>어떤 목적으로</code>, <code>무엇을 하길 원한다</code>와 같은 형식으로 작성</p> <hr> <h2 id="역할-1-프로덕트-오너">역할 #1 프로덕트 오너</h2> <ul> <li>제품의 What을 담당</li> <li>제품의 가치 극대화</li> <li>1개의 제품에 1명의 프로덕트 오너</li> <li>프로덕트 백로그 관리(우선순위, 완료)</li> <li>개발자와 상의하되 간섭 X</li> <li>이해관계자와 협업</li> </ul> <hr> <h2 id="프로덕트-오너-업무">프로덕트 오너 업무</h2> <ul> <li>거시적 관점 계획</li> <li>제품의 비전 명확히 하고 주변과 공유</li> <li>제품을 만드는데 소요되는 예산 관리</li> <li>프로덕트 백로그 최신 상태 업데이트</li> <li>다른 사람이 프로덕트 백로그를 이해할 수 있도록 설명</li> <li>이해관계자와 프로덕트 백로그를 검토하고, 납기나 구현 순서 상의</li> <li>프로덕트 백로그의 각 항목이 완료 되었는지 점검</li> </ul> <hr> <h2 id="역할-2-디밸로퍼">역할 #2 디밸로퍼</h2> <ul> <li>제품의 How를 담당</li> <li>제품을 동작하게 만듦</li> <li>팀원은 3 ~ 9명 정도 적절</li> <li>팀원의 역량이 곧 제품 개발 능력</li> <li>특수 목적의 보조 팀을 두지 않는다.</li> </ul> <hr> <h3 id="기능횡단팀cross-functional-team">기능횡단팀(cross functional team)</h3> <p>스크럼 시 <code>요구 분석팀</code> 이나, <code>테스트 팀</code> 같이 특정 업무만 전담하는 보조팀을 두지 않습니다.</p> <h3 id="자기-관리화self-managing">자기 관리화(self-managing)</h3> <ul> <li>개발자 스스로 책임지고 개발 완료</li> <li>개발팀 내의 의사 결정은 개발자 상호 간의 합의</li> <li>작업 방식에 대한 외부 간섭 X</li> </ul> <hr> <h2 id="활동-1-스프린트">활동 #1 스프린트</h2> <ul> <li>프로젝트를 짧은 주기로 나눠서 진행</li> <li>각 주기는 같은 간격이며 1달을 넘기지 않는다</li> <li>하나의 주기를 스프린트라 부름</li> <li>스크럼의 활동 중 가장 큰 덩어리로 다른 4가지 활동을 포함</li> </ul> <hr> <h2 id="활동-2-스프린트-플래닝">활동 #2 스프린트 플래닝</h2> <blockquote> <p>질주 계획</p> </blockquote> <ul> <li>개발계획 수립을 위한 착수 회의</li> <li>스프린트 기간동안 할 일을 계획</li> <li>Why: 왜 하는지 생각 - <strong>목표</strong></li> <li>What: 무엇을 할지 생각 - <strong>일감 선택 &amp; 구체화</strong></li> <li>How: 어떻게 할지 생각 - <strong>스프린트 백로그</strong></li> </ul> <hr> <h2 id="산출물-2-스프린트-백로그">산출물 #2 스프린트 백로그</h2> <ul> <li>프로덕트 백로그에서 작업 항목 선택</li> <li>실행 가능하게 작업을 구체화</li> <li>작업을 추가하거나 삭제</li> <li><strong>하루안에 끝나는 크기로 분할</strong></li> </ul> <hr> <h2 id="산출물-3-인크리먼트">산출물 #3 인크리먼트</h2> <blockquote> <p>이전 스프린트의 결과물에 이번 스프린트의 작업 결과가 더한 개발의 증가분 의미하며, 결과물은 소프트웨어이고 스프린트 종료 시점에 점검하도록 동작 가능한 상태여야 합니다.</p> </blockquote> <ul> <li>개발자는 백로그를 작업한 결과로 동작하는 제품을 만듦</li> <li>이전 스프린트의 결과물에 이번 스프린트의 결과물이 더해 짐</li> <li>결과물은 릴리스 여부와 상관없이 동작하고 점검받을 수 있어야 함</li> </ul> <hr> <h3 id="완료-조건예제">완료 조건(예제)</h3> <ul> <li>위키 문서에 제품 명세 등록, 위키 문서에 관련 자료 등록</li> <li>리포지터리에 소스 코드 등록</li> <li>모든 public 메소드의 테스트 코드 구현, 모든 테스트 코드 성공</li> <li>소스코드를 빌드하고 시연</li> </ul> <hr> <h2 id="활동-3-데일리-스크럼">활동 #3 데일리 스크럼</h2> <blockquote> <p>진행 상황 점검 활동</p> </blockquote> <ul> <li>목표 달성에 문제가 없는지 진행 사항 점검</li> <li>문제를 해결하기보다는 문제가 발생한 상황에 집중</li> <li>매일 하되, 15분의 타임 박스를 지켜야 함</li> <li>이야기가 길어지면 회의를 따로 잡음</li> </ul> <hr> <h3 id="질문에-답하며-상황-공유">질문에 답하며 상황 공유</h3> <blockquote> <p>스프린트가 순항하고 있는지, 작업의 진척에는 문제가 없는지, 도와줘야 할 일이 무엇인지 점검</p> </blockquote> <ul> <li>스프린트 목표를 달성하기 위해 어제 할 일은 무엇인가?</li> <li>스프린트 목표를 달성하기 위해서 오늘 할 일은 무엇인가?</li> <li>스프린트 목표를 달성하는 데 방해가 되거나 도움이 필요한 일은 무엇인가?</li> </ul> <hr> <h2 id="활동-4-스프린트-리뷰">활동 #4 스프린트 리뷰</h2> <blockquote> <p>스프린트 리뷰를 할 때, 제품의 이해관계자인 <code>스테이크홀더</code>가 초대되며, 작업된 결과물을 점검하면서 그에 대한 피드백을 얻음</p> </blockquote> <ul> <li>프로덕트 오너가 주관하고 이해관계자가 참석</li> <li>개발자가 만든 결과물을 이해관계자에게 시연</li> <li>피드백을 받고 프로덕트 백로그를 재점검</li> <li>완성된 것과 완성되지 않은 것을 구분</li> <li>전체 진행 상황과 남을 작업을 점검</li> </ul> <hr> <h3 id="시연과-피드백-이외에-해야-할-일">시연과 피드백 이외에 해야 할 일</h3> <ul> <li>제품과 비즈니스 환경에 대해 설명</li> <li>스프린트 중에 완료하지 못한 것을 설명</li> <li>스프린트 중에 직면했던 어려움과 해결 과정 설명</li> <li>프로덕트 백로그에 새로 추가할 게 있는지 논의</li> <li>예상되는 잠재위험에 대해 논의</li> <li>현재 진척 상황을 감안하여 작업 완료 시점이나 릴리즈 날짜를 예측</li> </ul> <hr> <h2 id="활동-5-스프린트-레트로스펙티브회고">활동 #5 스프린트 레트로스펙티브(회고)</h2> <ul> <li>일하는 방식을 개선</li> <li>사람, 관계, 프로세스, 툴의 관점에서 스프린트 점검</li> <li>버그를 고치기보다 버그를 유발하는 작업 방식에 집중</li> <li>한 번에 너무 많은 것을 고치려 하지 않음</li> <li>잘된 점과 안된 점을 정리</li> <li>다음 스프린트에서 실천할 항목을 뽑음</li> </ul> <hr> <h2 id="역할-3-스크럼-마스터">역할 #3 스크럼 마스터</h2> <ul> <li>스크럼이라는 프레임워크가 자리 잡게 도움</li> <li>일하는 데 방해되는 요소 제거</li> <li>봉사하는 마음으로 팀을 지원(<a href="https://ko.wikipedia.org/wiki/%EC%84%9C%EB%B2%88%ED%8A%B8_%EB%A6%AC%EB%8D%94%EC%8B%AD">서번트 리더쉽</a>)</li> <li>퍼실리테이터와 코치 역할 겸비</li> <li><strong>업무 할당이나 진척 관리 하지 않음</strong></li> </ul> <hr> <h3 id="스크럼-마스터가-하는-추가적인-일">스크럼 마스터가 하는 추가적인 일</h3> <ul> <li>프로덕트 오너와 개발자에게 애자일 개발과 스크럼을 알려줌</li> <li>스프린트 플래닝이나 스프린트 회고 진행을 도움</li> <li>프로덕트 오너와 개발자의 커뮤니케이션 도움</li> <li>프로덕트 오너와 개발자의 생산성이 높아지도록 변화를 꾀함</li> <li>프로덕트 백로그와 스프린트 백로그를 잘 쓰는 방법을 알려줌</li> <li>프로덕트 백로그와 스프린트 백로그를 잘 관리하는 방법을 알려줌</li> </ul> <hr> <h2 id="스크럼의-5가지-가치">스크럼의 5가지 가치</h2> <ul> <li>확약 : 목표를 달성하기 위해 전력을 다할 것을 굳게 약속</li> <li>전념 : 목표를 달성하기 위해 각자가 맡은 일에 집중</li> <li>공개 : 모든 상황과 문제를 투명하게 공유</li> <li>존중 : 팀원의 역량과 존재 가치를 존중</li> <li>용기 : 옳은 일을 한다는 용기로 어려움 극복</li> </ul> <hr> <h2 id="qa">Q&amp;A</h2> <p>토론해보아요~</p> <hr> <h2 id="스크럼은-종착지를-알아야-달릴-수-있다">스크럼은 종착지를 알아야 달릴 수 있다.</h2> <ul> <li>목표 : 실현해 주기를 바라는 것은 무엇인가?</li> <li>과제 : 달성해 주기를 바르는 것은 무엇인가?</li> </ul> <hr> <h2 id="엘리베이터-피치-인셉션-덱">엘리베이터 피치 <a href="https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/">인셉션 덱</a></h2> <blockquote> <p>투자자가 엘리베이터에서 내리기 전의 아주 짧은 시간(15 ~ 30초) 안에 제품을 설명하는 기법</p> </blockquote> <ul> <li>[영업의 달인]은 (projectNm)</li> <li>[실시간으로 고객 정보를 확인] 하고 싶은 (need, oppertunity)</li> <li>[영업 사원]을 위한 (target customer)</li> <li>[업무 지원 앱]입니다. (product category)</li> <li>이 제품은 [외근 중에도 업무]를 할 수 있는데 (key benefit, reason to buy)</li> <li>[이전 영업 지원 시스템]과는 달리 (competitive, alternative)</li> <li>[최신 정보 알림 기능]이 차별화 포인트 입니다. (primary differentiation)</li> </ul> <hr> <h2 id="프로덕트-백로그-1-요구-사항-열거">프로덕트 백로그 #1 요구 사항 열거</h2> <blockquote> <p>제품의 <code>각종 요구 사항</code>과 <code>개선 사항</code>, 개발에 필요한 <code>단순 작업</code></p> </blockquote> <table> <thead> <tr> <th>기능</th> <th>목적</th> <th>설명</th> <th>예상견적</th> </tr> </thead> <tbody> <tr> <td>일일보고</td> <td>최신 정보를 수집하여 영업 전략을 세움</td> <td>일별로 방문 고객, 일시, 담당자, 제안 정보 입력</td> <td>5</td> </tr> <tr> <td>로그인</td> <td>대외비 정보 보호를 위함</td> <td>사원번호와 비밀번호로 인증</td> <td>3</td> </tr> <tr> <td>…</td> <td>…</td> <td>…</td> <td>…</td> </tr> </tbody> </table> <hr> <h2 id="프로덕트-백로그-2-사용자-스토리">프로덕트 백로그 #2 사용자 스토리</h2> <table> <thead> <tr> <th>스토리</th> <th>시연방법</th> <th>견적</th> </tr> </thead> <tbody> <tr> <td>난 영업사원인데 / 고객의 상황을 일일 보고로 기록하는 기능이 필요해 / 그건 최신 정보를 수집하여 영업 전략을 세우기 위해서야</td> <td>고객 정보 화면에서 방문 일시와 방문자, 상담 내용, 보고 내용을 등록한다. 확인 화면에서는…</td> <td>5</td> </tr> <tr> <td>난 보안관리자 인데 / 사용자 제한 하는 기능이 필요해. / 그건 대외비 정보가 외부로…</td> <td>인증 전에 업무 화면에 들어가면 로그인 화면이 표시..</td> <td>3</td> </tr> </tbody> </table> <hr> <h3 id="사용자-스토리-1">사용자 스토리</h3> <p>누가(who), 무엇을(what), 왜(why) 하고 싶은지를 쓰면 되는데, <code>난 [어떤 사용자]인데 / [어떤 기능]이 필요해 / 그건 [어떤 일을 달성] 하기 위해서야.</code> 와 같은 표현 합니다.</p> <h3 id="일감-분류">일감 분류</h3> <ul> <li>진짜 중요함</li> <li>좀 중요함</li> <li>필요함</li> <li>있으면 좋고 없어도 그만</li> </ul> <hr> <h2 id="일감-기준-작업량-추정">일감 기준 작업량 추정</h2> <ul> <li>쉽게 끝낼 수 있을 것 같다 ( 소 )</li> <li>손이 많이 갈 것 같다 ( 중 )</li> <li>꽤 애를 먹을 것 같다 ( 대 )</li> </ul> <h3 id="작업량-가늠-방안스토리-포인트-활용">작업량 가늠 방안(스토리 포인트 활용)</h3> <p>1,2,3,4,8,13,21,34… 과 같은 <code>피보나치 수</code>를 활용</p> <hr> <h3 id="벨로시티velocity">벨로시티(velocity)</h3> <blockquote> <p>한 스프린트에서 끝낼 수 있는 포인트 수</p> </blockquote> <h4 id="언제-끝나는가">언제 끝나는가</h4> <blockquote> <p>구현할 기능의 포인트 총합 / 벨로시티 = 필요한 스프린트 횟수</p> </blockquote> <h4 id="어떤-결과물이-나오는가">어떤 결과물이 나오는가</h4> <blockquote> <p>벨로시트 * 스프린트 횟수 = 구현할 수 있는 포인트의 총합</p> </blockquote> <hr> <p>### 스크럼의 3가지 역할 스크럼 오너, 스크럼 마스터, 개발자</p> <h3 id="5가지-활동">5가지 활동</h3> <p>스프린트, 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고</p> <h3 id="3가지-산출물">3가지 산출물</h3> <p>프로덕트 백로그, 스프린트 백로그, 증가분</p> <h2 id="참고자료">참고자료</h2> <ul> <li><a href="http://www.yes24.com/Product/Goods/115632480">출근했더니 스크럼 마스터가 된 건에 관하여 - 니시무라 나오토</a></li> </ul>  </div></div>

lahuman

Daniel Lim

스크럼 101
 
  스크럼 101  from Daniel Lim 
출근했더니 스크럼 마스터가 된 건에 관하여 - 니시무라 나오토
애자일 소프트웨어
애자일 선언문
목적을 달성하기 위해 모든 관계자가 긴밀하게 협조
한번에 전체를 완성하기 보다 조금씩 만들되, 조기에 동작시켜 피드백 받음
사용자나 관계자의 피드백을 바탕으로 결과물과 계획을 지속적으로 보완
스크럼
가치와 위험도, 필요성을 기준으로 요구사항을 정렬
순서대로 구현하며 성과를 극대화
정해진 시간 안에 작업을 완료 - 타임박스(timebox)
현재 상태와 문제점을 명확하게 밝힘 - 투명성(transparency)
개발할 제품과 진척에 이상은 없는지 수시로 확인 - 점검(inspection)
더 나은 방법으로 작업 방식 개선 - 보완(adaptation)
3가지 역할, 5가지 활동, 3가지 산출물
스크럼을 프레임워크라고 부르는 특징
스크럼가이드 :: 한글PDF
산출물 #1 프로덕트 백로그
구현하고 싶은 것을 목록으로 만듦
항목은 언제든지 추가, 삭제 가능
우선순위에 맞춰 정렬
우선순위가 높은 항목부터 작업량을 추정
정기적으로 항목의 순서나 내용, 작업량을 보완
사용자 스토리
제품의 요구 사항을 사용자 관점에서 누가, 어떤 목적으로, 무엇을 하길 원한다와 같은 형식으로 작성
역할 #1 프로덕트 오너
제품의 What을 담당
제품의 가치 극대화
1개의 제품에 1명의 프로덕트 오너
프로덕트 백로그 관리(우선순위, 완료)
개발자와 상의하되 간섭 X
이해관계자와 협업
프로덕트 오너 업무
거시적 관점 계획
제품의 비전 명확히 하고 주변과 공유
제품을 만드는데 소요되는 예산 관리
프로덕트 백로그 최신 상태 업데이트
다른 사람이 프로덕트 백로그를 이해할 수 있도록 설명
이해관계자와 프로덕트 백로그를 검토하고, 납기나 구현 순서 상의
프로덕트 백로그의 각 항목이 완료 되었는지 점검
역할 #2 디밸로퍼
제품의 How를 담당
제품을 동작하게 만듦
팀원은 3 ~ 9명 정도 적절
팀원의 역량이 곧 제품 개발 능력
특수 목적의 보조 팀을 두지 않는다.
기능횡단팀(cross functional team)
스크럼 시 요구 분석팀 이나, 테스트 팀 같이 특정 업무만 전담하는 보조팀을 두지 않습니다.
자기 관리화(self-managing)
개발자 스스로 책임지고 개발 완료
개발팀 내의 의사 결정은 개발자 상호 간의 합의
작업 방식에 대한 외부 간섭 X
활동 #1 스프린트
프로젝트를 짧은 주기로 나눠서 진행
각 주기는 같은 간격이며 1달을 넘기지 않는다
하나의 주기를 스프린트라 부름
스크럼의 활동 중 가장 큰 덩어리로 다른 4가지 활동을 포함
활동 #2 스프린트 플래닝
질주 계획
개발계획 수립을 위한 착수 회의
스프린트 기간동안 할 일을 계획
Why: 왜 하는지 생각 - 목표
What: 무엇을 할지 생각 - 일감 선택 & 구체화
How: 어떻게 할지 생각 - 스프린트 백로그
산출물 #2 스프린트 백로그
프로덕트 백로그에서 작업 항목 선택
실행 가능하게 작업을 구체화
작업을 추가하거나 삭제
하루안에 끝나는 크기로 분할
산출물 #3 인크리먼트
이전 스프린트의 결과물에 이번 스프린트의 작업 결과가 더한 개발의 증가분 의미하며, 결과물은 소프트웨어이고 스프린트 종료 시점에 점검하도록 동작 가능한 상태여야 합니다.
개발자는 백로그를 작업한 결과로 동작하는 제품을 만듦
이전 스프린트의 결과물에 이번 스프린트의 결과물이 더해 짐
결과물은 릴리스 여부와 상관없이 동작하고 점검받을 수 있어야 함
완료 조건(예제)
위키 문서에 제품 명세 등록, 위키 문서에 관련 자료 등록
리포지터리에 소스 코드 등록
모든 public 메소드의 테스트 코드 구현, 모든 테스트 코드 성공
소스코드를 빌드하고 시연
활동 #3 데일리 스크럼
진행 상황 점검 활동
목표 달성에 문제가 없는지 진행 사항 점검
문제를 해결하기보다는 문제가 발생한 상황에 집중
매일 하되, 15분의 타임 박스를 지켜야 함
이야기가 길어지면 회의를 따로 잡음
질문에 답하며 상황 공유
스프린트가 순항하고 있는지, 작업의 진척에는 문제가 없는지, 도와줘야 할 일이 무엇인지 점검
스프린트 목표를 달성하기 위해 어제 할 일은 무엇인가?
스프린트 목표를 달성하기 위해서 오늘 할 일은 무엇인가?
스프린트 목표를 달성하는 데 방해가 되거나 도움이 필요한 일은 무엇인가?
활동 #4 스프린트 리뷰
스프린트 리뷰를 할 때, 제품의 이해관계자인 스테이크홀더가 초대되며, 작업된 결과물을 점검하면서 그에 대한 피드백을 얻음
프로덕트 오너가 주관하고 이해관계자가 참석
개발자가 만든 결과물을 이해관계자에게 시연
피드백을 받고 프로덕트 백로그를 재점검
완성된 것과 완성되지 않은 것을 구분
전체 진행 상황과 남을 작업을 점검
시연과 피드백 이외에 해야 할 일
제품과 비즈니스 환경에 대해 설명
스프린트 중에 완료하지 못한 것을 설명
스프린트 중에 직면했던 어려움과 해결 과정 설명
프로덕트 백로그에 새로 추가할 게 있는지 논의
예상되는 잠재위험에 대해 논의
현재 진척 상황을 감안하여 작업 완료 시점이나 릴리즈 날짜를 예측
활동 #5 스프린트 레트로스펙티브(회고)
일하는 방식을 개선
사람, 관계, 프로세스, 툴의 관점에서 스프린트 점검
버그를 고치기보다 버그를 유발하는 작업 방식에 집중
한 번에 너무 많은 것을 고치려 하지 않음
잘된 점과 안된  점을 정리
다음 스프린트에서 실천할 항목을 뽑음
역할 #3 스크럼 마스터
스크럼이라는 프레임워크가 자리 잡게 도움
일하는 데 방해되는  요소 제거
봉사하는 마음으로 팀을 지원(서번트 리더쉽)
퍼실리테이터와 코치 역할 겸비
업무 할당이나 진척 관리 하지 않음
스크럼 마스터가 하는 추가적인 일
프로덕트 오너와 개발자에게 애자일 개발과 스크럼을 알려줌
스프린트 플래닝이나 스프린트 회고 진행을 도움
프로덕트 오너와 개발자의 커뮤니케이션 도움
프로덕트 오너와 개발자의 생산성이 높아지도록 변화를 꾀함
프로덕트 백로그와 스프린트 백로그를 잘 쓰는 방법을 알려줌
프로덕트 백로그와 스프린트 백로그를 잘 관리하는 방법을 알려줌
스크럼의 5가지 가치
확약 : 목표를 달성하기 위해 전력을 다할 것을 굳게 약속
전념 : 목표를 달성하기 위해 각자가 맡은 일에 집중
공개 : 모든 상황과 문제를 투명하게 공유
존중 : 팀원의 역량과 존재 가치를 존중
용기 : 옳은 일을 한다는 용기로 어려움 극복
Q&A
토론해보아요~
스크럼은 종착지를 알아야 달릴 수 있다.
목표 : 실현해 주기를 바라는 것은 무엇인가?
과제 : 달성해 주기를 바르는 것은 무엇인가?
엘리베이터 피치 인셉션 덱
투자자가 엘리베이터에서 내리기 전의 아주 짧은 시간(15 ~ 30초) 안에 제품을 설명하는 기법
[영업의 달인]은 (projectNm)
[실시간으로 고객 정보를 확인] 하고 싶은 (need, oppertunity)
[영업 사원]을 위한 (target customer)
[업무 지원 앱]입니다. (product category)
이 제품은 [외근 중에도 업무]를 할 수 있는데 (key benefit, reason to buy)
[이전 영업 지원 시스템]과는 달리 (competitive, alternative)
[최신 정보 알림 기능]이 차별화 포인트 입니다. (primary differentiation)
프로덕트 백로그 #1 요구 사항 열거
제품의 각종 요구 사항과 개선 사항, 개발에 필요한 단순 작업
기능
      목적
      설명
      예상견적
    
일일보고
      최신 정보를 수집하여 영업 전략을 세움
      일별로 방문 고객, 일시, 담당자, 제안 정보 입력
      5
    
로그인
      대외비 정보 보호를 위함
      사원번호와 비밀번호로 인증
      3
    
…
      …
      …
      …
    
프로덕트 백로그 #2 사용자 스토리
스토리
      시연방법
      견적
    
난 영업사원인데 / 고객의 상황을 일일 보고로 기록하는 기능이 필요해 / 그건 최신 정보를 수집하여 영업 전략을 세우기 위해서야
      고객 정보 화면에서 방문 일시와 방문자, 상담 내용, 보고 내용을 등록한다. 확인 화면에서는…
      5
    
난 보안관리자 인데 / 사용자 제한 하는 기능이 필요해. / 그건 대외비 정보가 외부로…
      인증 전에 업무 화면에 들어가면 로그인 화면이 표시..
      3
    
사용자 스토리
누가(who), 무엇을(what), 왜(why) 하고 싶은지를 쓰면 되는데, 
난 [어떤 사용자]인데 / [어떤 기능]이 필요해 / 그건 [어떤 일을 달성] 하기 위해서야. 와 같은 표현 합니다.
일감 분류
진짜 중요함
좀 중요함
필요함
있으면 좋고 없어도 그만
일감 기준 작업량 추정
쉽게 끝낼 수 있을 것 같다 ( 소 )
손이 많이 갈 것 같다 ( 중 )
꽤 애를 먹을 것 같다 ( 대 )
작업량 가늠 방안(스토리 포인트 활용)
1,2,3,4,8,13,21,34… 과 같은 피보나치 수를 활용
벨로시티(velocity)
한 스프린트에서 끝낼 수 있는 포인트 수
언제 끝나는가
구현할 기능의 포인트 총합 / 벨로시티 = 필요한 스프린트 횟수
어떤 결과물이 나오는가
벨로시트 * 스프린트 횟수 = 구현할 수 있는 포인트의 총합
### 스크럼의 3가지 역할
스크럼 오너, 스크럼 마스터, 개발자
5가지 활동
스프린트, 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고
3가지 산출물
프로덕트 백로그, 스프린트 백로그, 증가분
참고자료
출근했더니 스크럼 마스터가 된 건에 관하여 - 니시무라 나오토

Scrum 101

댓글