--- title: Scrum guide tags: classting, scrum description: Classting scrum --- # Scrum guide <!-- Put the link to this slide here so people can follow --> Junheon Lee https://hackmd.io/p/ZR3j5xPjS72KW5PsttqqtA --- # Scrum --- ## Scrum (rugby) ![scrum-lugby](https://i.imgur.com/VRCzGYT.jpg) > 출처: Wikipedia --- ## Scrum (rugby) - 럭비에서 플레이를 다시 시작하는 방법 - 가운데로 공을 넣고 선수들은 몸을 부딧치며 - 볼의 소유권을 얻기 위해 시도 --- ## Scrum - 1986 - The new new product development game / Harvard business review / 노나카 이쿠지로, 타케우지 히로타가 - 1995 - Ken Schwaber, Jeff Sutherland 고안 --- ## Scrum - 팀이 함께 목표를 달성하기 위한 프레임워크 - 팀이 목표를 향해 달려가며 - 문제를 함께 해결하기 위해 머리를 맞대고 - 문제 해결 경험을 통해 배우고 - 성공과 실패를 프로세스에 반영하여 - 점진적/지속적 개선하도록 --- ## Scrum & lean 거창한 제품보단 고객에게 가장 중요한 가치를 전달 --- ## Scrum ![scrum-process](https://i.imgur.com/JccLzoU.jpg) --- ## Scrum roles Scrum roles != Job titles --- ## Scrum roles - 스크럼 구성원의 역할에 따른 책임 - 직군/직책과 역할은 다른것 - 어떤 직군이던 하나의 역할을 수행 --- ## Scrum roles - Product owner - Scrum master - Development team members --- ## Scrum roles - 스크럼은 - 경험주의 - 자기 조직화 - 점진적 개선 - 역할은 - 최소한의 역할 - 역할간 긴밀한 상호작용 --- ## Scrum roles ### Product owner ![product-owner](https://i.imgur.com/VQCkjR5.png) --- ## Scrum roles ### Product owner - 제품의 비전 - 제품의 로드맵, 릴리즈 관리 - 백로그 관리 - 비즈니와의 소통 --- ## Scrum roles ### Scrum master ![scrum-master](https://i.imgur.com/FGJoP2M.png) --- ## Scrum roles ### Scrum master - 스크럼 리더 - 퍼실리테이터 - 애자일 코칭 - 방법을 개선하고 적용 --- ## Scrum roles ### Development team members ![scrum-dev-team-members](https://i.imgur.com/SXvI7kh.png) --- ## Scrum roles ### Development team members - 제품 디자이너 / 프로그래머 / QA엔지니어 등 - 스프린트를 통해 목표 달성을 위한 제품 개발 - 데일리 스크럼을 통해 작업의 투명성 보장 --- ## Scrum process ![scrum-process](https://i.imgur.com/JccLzoU.jpg) --- 시작해봅시다! --- ## Scrum process - Sprint planning - Sprint - Sprint review - Sprint retrospective --- ## Backlogs ### User story ![](https://i.imgur.com/0uI1iw2.jpg) --- ## Backlogs ### User story ![](https://i.imgur.com/PiRPEl0.png) --- ## Backlogs ### User story - 작업보단 결과에 집중 - 고객에 전달할 가치를 고객 입장에서 정의 - 앞장에는 고객 입장의 가치 - 뒷장에는 고객 입장의 행동을 통한 테스트 --- ### Tips. 너무 구체적이지 않도록, 결과물을 사용자 관점에서 정의합니다. 테스트 케이스를 A-Z까지 정의하면 그것은 유즈케이스 스펙이에요. --- ## Sprint planning - Backlogs를 우선순위별로 정렬 - 디자인 결과물 설명 - 사용자 스토리 - 테스크 플로우 - 프로토타입 - 스토리 포인트 예측 --- ## Sprint planning ### Planning poker - 스크럼 마스터가 진행자 역할 - 프로덕트 오너가 목표와 사용자 스토리를 설명 - 디자이너가 부가 설명이나 질의 응답 - 이때, 뒷장의 인수 테스트를 참고 - 대화를 통해 인수 테스트를 보충 --- ## Sprint planning ### Planning poker ![](https://i.imgur.com/APATw7F.jpg) --- ## Sprint planning ### Planning poker - Developer team 멤버 각자 한장의 카드 제출 - 모두의 예측이 같을 때까지 반복 - 예측이 다르다면 가장 적은, 가장 많은 예측을 한 멤버가 설명 --- ## Sprint planning ### Planning poker - 3 이상이라면 스토리가 너무 비대하다는 신호 - 이때, 스토리를 그자리에서 더 작은 단위로 분리 - 1~2 포인트가 최적 - 최대 3을 넘지 않도록 구성 --- ## Sprint planning - Developer team 멤버가 스프린트간 가능한 작업일 조사 - 조사를 바탕으로 인원당 가용 가능한 포인트를 50~70% 사이로 조정 - 사용자 스토리를 리뷰하며 각 멤버에게 할당 - 스프린트 골 확정 --- ![](https://i.imgur.com/2YxE35V.jpg) --- ### Tips. 처음에는 4시간을 목표로 시작하세요. --- ### Tips. 백로그가 잘 관리되고 경험이 쌓이기 시작하면 2시간 이내에 끝낼 수 있도록 목표를 재조정합니다. --- ### Tips. 가능한 종이로 스토리 카드를 준비해주세요. 주위가 분산되지 않고 집중도를 높히는데 좋습니다. (바로바로 메모하고 쪼개고 재정렬하기 좋아요.) --- ## Sprint 고객 가치를 전달하기 위해 열심히 달리자! --- ## Sprint ### Daily scrum (daily stand-up) - 했던 일, 할 일, 당면한 이슈 공유하기 - 번다운 차트를 함께 보며 진행 현황 파악 --- ### Burndown ![](https://i.imgur.com/KAFycS2.jpg) [Understanding the Scrum Burndown Chart](http://www.methodsandtools.com/archive/scrumburndown.php) --- ### Tips. 이때, 스크럼 마스터는 당면한 이슈를 파악하기 위해 노력합니다. (a.k.a 블로커) 멤버 모두 당면 이슈 해결을 최우선으로 집중합니다. --- ### Tips. 문제 해결을 위한 자료 조사를 도와줄 수도 있고, 테스트를 도와 현상 파악에 도움을 줄 수 있습니다. 리뷰를 빨리 하도록 독려할 수도 있겠지요. --- ### Tips. 또는 방해자를 제거할 수도 있어요. --- ### Tips. 기억하세요. 블로커 제거가 1순위입니다. (듣고만 넘어가면 안되요.) --- ## Sprint review a.k.a. 스프린트 세레모니 --- ## Sprint review ### 참석자 - 모든 스크럼 멤버 - 이해관계자 - 비즈니스 오너 - 마케터 - 고객 담당 등 --- ## Sprint review 스프린트 목표를 다시 공유하고 결과를 공유합니다. 이때 결과는 눈으로 볼 수 있는 결과물을 말합니다. 제품에 대한 간단한 피드백을 주고받습니다. --- 그리고 2주간 고생한 멤버에게 박수쳐주세요. (처음부터 목표를 달성하기 어렵습니다.) --- ### Tips. 완료 기준을 정해주세요. PR 리뷰 완료를 기준으로 할 수도 있고, 제품 릴리즈를 기준으로 할 수도 있습니다. 제품 특성별로 다릅니다. --- ### Tips. 시간은 30분 ~ 1시간 스크럼 마스터는 미팅이 길어지지 않도록 중재자 역할을 합니다. (모든것을 논의하는 자리가 아니에요.) --- # Sprint retrospective --- ![](https://i.imgur.com/UzVDxOz.jpg) --- ![](https://i.imgur.com/fbfZ4VC.jpg) --- ## Sprint retrospective - 방법에 대한 개선미팅 - 마스터가 퍼실리테이터 역할 - 모든 멤버가 적극적으로 참여할 수 있도록 독려 --- ## Sprint retrospective 2주간 스프린트에 대해 마스터가 공유합니다. 이때, 목표달성/번다운/해결한 이슈 등을 활용합니다. (일종의 기억을 되살리는 방법입니다.) --- ## Sprint retrospective 잘한일, 더 잘 했어야 하는일을 수집합니다. 이때, 포스트잇을 활용하여 자료를 모으는데에 집중하세요. (10~20분간 모으는 것을 권장합니다.) --- ## Sprint retrospective 자료가 모였으면 멤버의 도움을 받아 자료를 재 그룹핑합니다. --- ## Sprint retrospective 먼저 잘한일을 논의해볼까요? 논의를 통해 잘한일의 구체적 방법을 찾도록 노력하세요. --- ## Sprint retrospective 더 잘 했어야 하는일을 논의해봅시다. 이때, 잘 했어야 하는 일의 문제를 구체화하고 개선점을 도출합니다. --- ## Sprint retrospective 마지막으로 다음 스프린트에 적용할 개선점을 1~3개 선정합니다. --- ### Tips. 회고전 워밍업을 해주세요. 멤버의 컨디션을 5점 만점으로 파악하고 스프린트를 통한 현재 컨디션을 공유하는것으로 시작합니다. --- ### Tips. 마스터는 회의 방향이 어긋나지 않도록 퍼실리테이터 역할을 수행합니다. --- ### Tips. 잘한 일, 더 잘했어야 하는 일은 스프린트와 연관성이 있어야 합니다. 회고는 프로세스를 개선하는 자리입니다. --- ### Tips. 실제로 7명의 멤버면 약 1시간 ~ 1시간 30분 가까이 소요됩니다. 시간을 30분 단위로 쪼개어 진행하고 시간을 연장할 수 있도록 하세요. 목표는 1시간 내에 끝내는 것입니다. --- ![scrum-lugby](https://i.imgur.com/VRCzGYT.jpg) > 출처: Wikipedia --- 우리는 더 나아질 수 있습니다. --- 끝. QnA