프로젝트·개발
애자일 개발 입문 보드: 스크럼의 역할·이벤트·산출물을 이해하고 첫 스프린트를 돌리기
입문 | 화이트보드 2페이지 · 작업 보드 5열 (상위 작업 4개, 하위 작업 12개)
입문: 전문 용어 없이, 화이트보드의 질문과 작성 예시에 따라 답해 나가기만 하면 형태가 갖춰집니다.
애자일 개발을 이제 막 배우기 시작한 분이나 처음 스크럼 팀에 들어간 분이, 세 가지 역할·다섯 가지 이벤트·세 가지 산출물을 이해하고 첫 스프린트를 끝까지 돌려 보기 위한 초보자용 애자일 개발 입문 템플릿입니다. 화이트보드에는 애자일 개발의 사고방식, 2주 스프린트의 다섯 단계, 세 가지 역할의 세 프레임, 세 가지 산출물의 세 프레임, 다섯 가지 이벤트 요약표, MoSCoW로 이번에 넣을 것을 고르는 네 칸, KPT 회고가 차례로 놓여 있습니다. 태스크 보드는 제품 백로그·스프린트 백로그·개발 중·리뷰 대기·완료의 5열이며, 용어 익히기·첫 스프린트 짜기·데일리 스크럼 돌리기·리뷰와 회고라는 상위 태스크 4개와 하위 태스크 12개가 모두 미착수로 들어 있습니다. 스크럼을 모르는 채로 합류하면 용어에서 먼저 뒤처지지만, 이 보드를 위에서부터 따라가며 한 스프린트를 돌려 보면 데일리 스크럼에서 무엇을 말해야 하는지까지 분명해집니다. 애자일 개발을 어떻게 시작하는지, 스크럼 입문을 어디서부터 하는지에 대한 구체적인 답이기도 합니다. 이미 운영 중인 팀이 쓰는 2주 스프린트 운영 보드와 달리, 여기서는 용어의 이해와 첫 한 번의 경험이 주인공입니다.
무료 가입 후 마켓플레이스에서 이 템플릿을 복사해 사용할 수 있습니다
화이트보드 미리보기
화이트보드의 글자를 텍스트로 읽기
애자일 개발 입문 보드
사용법: ① 사고방식을 읽습니다 → ② 2주 스프린트의 흐름을 따라갑니다 → ③ 세 역할과 세 산출물을 확인합니다(보드③〜⑧) → ④ 다섯 이벤트의 일시를 정하고 MoSCoW로 이번에 넣을 것과 미룰 것을 가릅니다(보드⑨⑩) → ⑤ KPT로 되돌아봅니다(보드⑪)
① 애자일 개발이란(짧게 만들어 보여 주고 고치기)
- 한마디로 말하면 2주 정도의 짧은 기간에 동작하는 것을 만들어 보여 주고, 의견을 받아 고칩니다. 이것을 계속 반복하는 방식입니다.
- 지금까지의 방식과 다른 점 예) 사양을 전부 정한 뒤에 만드는 것이 아니라, 먼저 만들 순서를 정하고 위에서부터 조금씩 만듭니다. 순서는 도중에 바꿔도 됩니다.
- 무엇이 좋은가 예) 2주마다 실물을 볼 수 있어 방향이 어긋나도 2주 안에 알아챕니다. 다시 만드는 손해가 한 번 분량으로 끝납니다.
② 2주 스프린트의 흐름(데일리 스크럼은 매일 반복)
- 1. 스프린트 플래닝 스프린트 첫날입니다. 2주 동안 무엇을 만들지 ⑩의 MoSCoW로 가려 고르고 스프린트 백로그를 만듭니다. 최대 4시간. 예) 제품 백로그 위에서 3건·13포인트를 고릅니다.
- 2. 개발(2주) 고른 만큼만 만듭니다. 새 의뢰가 와도 원칙적으로 이번 스프린트에는 넣지 않습니다. 예) 로그인 개선 3건(13포인트)만 진행합니다.
- 3. 데일리 스크럼(매일 15분) 2의 2주 동안 매일 정해진 시각에 15분입니다. 어제 한 일·오늘 할 일·막힌 일을 각자 말합니다. 개발과 나란히 매일 반복합니다. 예) 매일 아침 10시에 선 채로 합니다.
- 4. 스프린트 리뷰 마지막 날입니다. 동작하는 것을 관계자에게 보여 주고 의견을 받습니다. 최대 2시간. 자료가 아니라 화면을 보여 줍니다. 예) 새 로그인 화면을 실제로 조작해 보여 줍니다.
- 5. 스프린트 회고 리뷰 뒤입니다. 만든 것이 아니라 진행 방식 자체를 다시 봅니다. 최대 1시간 30분. ⑪의 KPT로 다음 하나를 정합니다. 예) "끼어드는 의뢰는 스크럼 마스터가 먼저 받는다"를 다음 Try로 삼습니다.
③ 프로덕트 오너
- 무엇을 먼저 만들지 순서를 정하는 사람
- 제품 백로그의 순서에 책임을 지는 사람
- 예) "이번에는 로그인 개선을 먼저"라고 정함
- 만들 내용이 헷갈릴 때 상의할 상대
④ 스크럼 마스터
- 진행 방식이 지켜지는지 살피는 사람
- 막힌 것을 치우고 각 이벤트의 시간을 지킴
- 예) 끼어드는 의뢰를 먼저 받아 두고 조정함
- 지시하는 자리가 아니며 관리자라는 뜻도 아님
⑤ 개발자
- 실제로 만드는 사람들. 설계·구현·테스트를 포함
- 2주에 무엇을 할 수 있는지는 개발자가 직접 산정
- 예) 세 명이 스프린트 백로그를 나눠 맡음
- "개발자"는 직종 이름이 아니라 역할의 이름
⑥ 제품 백로그
- 만들고 싶은 것 전부를 먼저 만들 순서로 늘어놓은 목록
- 위에 있을수록 먼저. 순서는 프로덕트 오너가 정함
- 예) 로그인 개선/알림 설정/관리 화면 검색
- 끝이 없는 목록. 도중에 늘어나도 괜찮음
⑦ 스프린트 백로그
- 이번 2주에 만들기로 정한 만큼만 옮겨 둔 것
- 플래닝에서 고르며 도중에 더하지 않음
- 예) 로그인 개선 3건(합계 13포인트)
- 누가 무엇을 맡았는지도 여기를 보면 알 수 있음
⑧ 인크리먼트
- 2주가 끝났을 때 완성된, 동작하는 것
- 완료의 정의(＝여기까지 되면 완료라고 팀이 미리 정한 조건)를 채우지 못한 것은 넣지 않음
- 예) 테스트와 동작 확인까지 끝난 로그인 개선
- 스프린트 리뷰에서 보여 주는 것이 바로 이것
⑨ 다섯 가지 이벤트 요약표
| 무엇을 하나 | 누가 참여하나 | 시간 기준 | |
|---|---|---|---|
| 스프린트 | 스프린트 나머지 네 가지를 담는 2주짜리 상자. 도중에 기간을 늘리지 않음. | 스크럼 팀 전원 (프로덕트 오너·스크럼 마스터·개발자) | 2주 1개월 이내로 고정 |
| 플래닝 | 스프린트 플래닝 2주 동안 무엇을 만들지 골라 스프린트 백로그를 만듦. | 스크럼 팀 전원 | 최대 4시간 첫날 오전 |
| 데일리 스크럼 | 데일리 스크럼 어제 한 일·오늘 할 일·막힌 일을 말함. | 개발자 (나머지 두 역할은 듣는 쪽) | 15분 매일 같은 시각·같은 장소 |
| 리뷰 | 스프린트 리뷰 동작하는 것을 보여 주고 의견을 받음. 자료가 아니라 화면. | 스크럼 팀＋관계자 (의뢰한 쪽·사용자) | 최대 2시간 마지막 날 |
| 회고 | 스프린트 회고 만든 것이 아니라 진행 방식 자체를 다시 봄. | 스크럼 팀 전원 | 최대 1시간 30분 리뷰 뒤 |
⑩ 이번 2주에 넣을 것을 고르기(MoSCoW)
Must(필수)
- 없으면 스프린트의 목적을 이룰 수 없는 것만 넣습니다. 예) 재설정 메일이 오지 않는 결함 수정
Should(해야 함)
- 중요하지만 이번에 빼도 목적은 이룰 수 있는 것입니다. 예) 알아보기 어려운 오류 문구 개선
Could(가능하면)
- 스프린트에는 넣되 시간이 모자라면 가장 먼저 빼는 것입니다. 이번에 없어도 목적은 이룰 수 있습니다. 예) 로그인 화면의 로고 교체
Won't(이번에는 보류)
- 하지 않기로 정한 것입니다. 지우지 말고 제품 백로그(보드⑥)에 남깁니다. 예) 알림 설정과 관리 화면 검색은 다음 스프린트 이후로 넘깁니다
⑪ 첫 스프린트 회고(KPT)
Keep(계속할 것)
- 데일리 스크럼을 매일 아침 10시로 고정했더니 전원이 모이게 되었습니다
- 막힌 일을 그 자리에서 말할 수 있어 반나절 만에 풀렸습니다
Problem(못 한 것)
- 고른 13포인트 가운데 5포인트가 2주 안에 끝나지 않았습니다
- 도중에 들어온 의뢰를 거절하지 못해 스프린트 백로그가 부풀었습니다
Try(다음에 시험할 것)
- 다음 스프린트는 8포인트로 시작하고 남으면 더합니다
- 끼어드는 의뢰는 스크럼 마스터가 먼저 받아 둡니다
작업 보드 내용
제품 백로그 16건
스크럼 용어 익히기
처음 걸려 넘어지는 곳은 용어입니다. 역할·이벤트·산출물이라는 세 묶음으로 외우면 대화 중에 길을 잃지 않습니다.
세 가지 역할 적어 보기
프로덕트 오너·스크럼 마스터·개발자가 각각 누구인지 실명으로 적습니다. 겸임이면 겸임이라고 적습니다.
다섯 이벤트 나열하기
스프린트/스프린트 플래닝/데일리 스크럼/스프린트 리뷰/스프린트 회고 다섯 가지를 시간 순서로 늘어놓고 날짜와 시각을 넣습니다.
세 가지 산출물 확인
제품 백로그·스프린트 백로그·인크리먼트가 각각 어디에 있고 누가 관리하는지 확인합니다.
첫 스프린트 짜 보기
용어만 외워서는 몸에 붙지 않습니다. 2주라는 틀을 정하고, 그 안에 들어가는 만큼만 고르는 데까지 합니다.
기간과 요일 정하기
시작일·종료일과 각 이벤트의 요일·시각을 정합니다. 도중에 기간은 늘리지 않습니다.
할 일을 첫 열에 내기
만들고 싶은 것을 모두 제품 백로그 열로 꺼낸 뒤 먼저 만들 순서대로 다시 배열합니다. 순서는 프로덕트 오너가 정합니다.
두 주 분량만 고르기
위에서부터 2주 안에 끝나는 만큼만 스프린트 백로그로 옮깁니다. 너무 많으면 보드⑩의 MoSCoW로 Won't(이번에는 보류)를 먼저 정해 덜어냅니다. 망설여지면 적게 잡습니다.
데일리 스크럼 돌리기
스프린트 중 매일의 운영입니다. 진척 보고회로 만들지 말고, 막힌 일을 그 자리에서 꺼내 병목을 없애는 자리로 씁니다.
어제와 오늘 말하기
각자 어제 한 일과 오늘 할 일을 1분 안에 말합니다. 자세한 상의는 데일리 스크럼이 끝난 뒤로 나눕니다.
막힌 일 바로 꺼내기
막혀 있는 일은 반드시 입 밖으로 냅니다. 해결은 스크럼 마스터가 데일리 스크럼 이후에 이어받습니다.
보드로 진행 보여주기
카드를 개발 중·리뷰 대기·완료로 옮겨 남은 양이 한눈에 보이는 상태로 만듭니다.
리뷰와 회고하기
2주의 마무리입니다. 만든 것에 대한 의견과 진행 방식에 대한 의견을 나눠서 다루는 것이 스크럼의 방식입니다.
동작하는 것 보여주기
스프린트 리뷰에서 자료가 아니라 실제로 동작하는 화면을 관계자에게 보여 주고 의견을 받습니다.
의견을 백로그로
받은 의견을 제품 백로그 열에 카드로 되돌려 다음 순서 정하기의 재료로 삼습니다.
KPT로 Try 하나 정하기
회고에서 진행 방식을 다시 보고, 다음 스프린트에서 시험할 Try를 하나만 정합니다.
