칸반과 스크럼

들어가기

스크럼

따라서 우리는 대규모 조직에서 오랜 시간 동안 커다란 것을 만들기보다는 소규모 팀에서 짧은 시간 동안 작은 것을 만들도록 한다. 단, 전체적인 모습을 볼 수 있게 정기적으로 통합한다.

칸반

작업 흐름을 시각화하라
- 일을 작은 조각으로 나누고, 카드에 각 항목을 기입한 후 벽에 붙인다.
- 이름이 부여된 열을 사용하여 각 항목이 작업 흐름의 어디에 있는지 표시한다.
WIP 개수를 제한하라. 각 작업 흐름 상태별로 작업 중인 항목을 얼마나 허용할 것인지 화실한 수치를 부여한다.
리드 타임을 측정하고, 리드 타임을 가능한 한 짧고 예측 가능하게 만들 수 있도록 프로세스를 최적화한다.
칸반은 신호 카드를 의미하는 일본어로, 어떤 일을 할 수 있는 상태인지 알려주는 방식
- 백로그^backlog에서 카드를 당겨와서 진행 중 영역으로 옮기면, 카드를 당겨혼 사람은 해당 업무를 수행할 수 있다.
  
  리드 타임^{lead time}
  
  한 항목을 완료하는 데 소요되는 평균 시간, 이름바 '사이클 타임'. 또는, 처음 요청한 시간부터 요청을 완료하는 데 걸리는 경과 시간
  
  사이클 타임^cycle time
  
  업무 항목^{work item}이 진행 중 업무 상태에 머무른 시간

스크럼과 칸반은 둘 다 프로세스 도구다
- 도구: 작업이나 목적을 달성하려고 사용하는 모든 것
- 프로세스: 일하는 방법
비판이 아닌 이해를 통해 도구를 비교하자
- 나이프와 포트, 어떤 것이 더 나을까? … 처한 상황에 따라 답이 달라지기 때문이다.
완전한 도구도, 완벽한 도구도 없다
- 올바른 도구 사용은 성공하도록 도와주지만 성공을 보장해주지는 않는다.
스크럼은 칸반보다 규범적이다.
- 규범적: 지켜야 할 규칙이 많다.
- 적응적: 지켜야 할 규칙이 적다.
- 칸반의 제약 사항이라고는 단지 일의 흐름을 시각화하라는 것과, 작업 중인 일의 양을 제한하라는 것뿐이다. '멋대로’와 종이 한 장 차이지만 놀랄 만큼 막강하다.
스스로를 한 가지 도구에 제한하지 말라!

모든 작업은 Initiative를 달성하기 위해 진행한다.
큰 작업 단위가 있다면 Epic을 생성한다.
- Epic은 여러 프로젝트의 여러 팀을 포괄하여, 여러 보드에서 추적할 수 있다.
- ex) “2050년 3월 우주 관광 로켓 발사”
Epic을 이루기 위한 Story(= User Story)를 작성한다.
- Story는 최종 사용자의 관점에서 작성된 요구 사항이다.
- ex) “2050년 4월 발사 날짜를 포함하도록 날짜 범위 업데이트”
Story를 달성하기 위한 Subtask(혹은 checklist)를 생성한다.
- Checklist는 Issue로 전활할 수 있다.

epics vs stories agile development

Jira 기반으로 정리 (참고)
스토리
- 사용자 스토리, 최종 사용자의 관점에서 작성한 짧은 요구 사항 or 요청
- 요약: 사용자 스토리는 최종 사용자의 관점에서 작성한 소프트웨어 기능에 대한 일반적인 비공식 설명입니다. 목적은 소프트웨어 기능이 고객에게 가치를 제공하는 방법을 명확히 설명하는 것입니다.
- 소프트웨어 시스템 요구 사항으로 볼 수 있지만 사용자를 우선시하여 최종 사용자를 대화의 중심으로 둠
- 애자일 프레임워크에서
  - 스크럼에서 사용자 스토리가 스프린트에 추가되고 그 기간동안 번다운된다.
  - 칸반에서 사용자 스토리를 백로그로 가져와서 워크플로를 통해 실행한다.
에픽
- 스토리의 집합
- 여러 개의 작은 스토리로 나눌 수 있는 대규모 작업
- 실질적인 관점에서 볼 때 에픽은 작업 계층 구조의 최상위 계층
이니셔티브
- 공통의 목표를 추구하는 에픽의 모음
- 이니셔치브를 에픽으로 분할하면 팀의 일상 업무가 전반적인 비즈니스 목표와 연결될 수 있음
테마
- 에픽과 이니셔티브의 창출을 주도하는 조직 목표
스토리, 작업, 에픽 *