Scrum and kanban with jira

SCRUM & KANBAN with JIRA
JIRA 를 이용한 스크럼, 칸반 적용 안내

카카오 > 플랫폼기술팀
Benedict(이호정)

세미나 목표
스크럼과 칸반에 대해 이해해 봅시다.
JIRA를 이용해서 스크럼과 칸반을 적용하는 방법을 배워봅시다.
간단한 JIRA 팁, 개발도구들과의 연동 기능에 대해 알아봅시다.

목차
• Overview
• Scrum
• Scrum w/ JIRA
• Break
• Kanban
• Kanban w/ JIRA
• Conclusion

OVERVIEW
S/W DEVELOPMENT
AGILE

WATERFALL
분석
설계
구현
테스트
유지
보수
- 전통적인 S/W 개발 방법론
- Sequential Development Process

over
30
over
20
over
70
roles
activities
artifacts
RUP
복잡하다.

아직 기획이 안끝나서  
개발을 못하고 있어요. 아니, 이제와서 이걸 이렇게 바꾸면  
어쩌자는 겁니까?
샵검색을 말씀드린건데 삽을 검색하시면...
음... 이상하네요. 
제 컴퓨터에서는 잘 되는데..
또 변경될텐데  
대충 돌아가게만 만들지 뭐... 아직 안 끝났어?
네 아직이요.
언제 끝나는데?
곧 끝날것 같아요.

애자일 소프트웨어 개발 선언문
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.  
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
 
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를 
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

ref. https://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf

INTERNAL
FEEDBACK LOOP
EXTERNAL
FEEDBACK LOOP
- Pair Programming
- TDD
- Peer Review
- Continuous Integration
- Daily Stand-up Meeting
- Iteration Review/Retro
- Iteration planning
- Release planning

SCRUM
OVERVIEW
PROCESS
DO SCRUM RIGHT
HELPS & HURDLES
SCRUM WITH JIRA

스크럼의 정의
가장 가치 있는 제품을 생산적이고 창의적으로 배포하기 위하여
복잡하게 얽힌 적응적 문제들 (complex adaptive problems)을
다룰 수 있도록 하는 프레임워크
 
간단하고
이해하기 쉽지만,
마스터하기는 어려운 프레임워크 입니다. 
ref. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf

스크럼 이론#1
스크럼은 경험적 프로세스 관리 이론,
혹은 경험주의 (empiricism) 이론에 기반하고 있습니다.
반복
Iterative
점진
Incremental
예측을 최적화 하고,
위험 요소를 관리하기 위해
반복적이고, 점진적인 접근방법을 취합니다.

스크럼 이론#2
경험적 프로세스 관리를 수행하는 데 필요한 세 가지 축
투명성
Transparency
검토
Inspection
적응
Adaptation

3 ROLEs
4 EVENTs
3 ARTIFACTs
Product Owner
Scrum Master
Team
Product Owner
Sprint
Review
Sprint
Retros.
Estimation
Sprint
Planning

스프린트#0
- 조직내 공감대 형성
- 전체 주요 기능 목록 도출(Product Backlog)
- 릴리스 플래닝(로드맵)
- 주요 마일스톤, QA, CBT, 출시일 등
- 이터레이션 플래닝
- 스프린트 길이는?
- 스크럼 이벤트
- 일일 스크럼, 플래닝, 리뷰, 회고는 언제?
- 추정 및 추정 단위는?
- 스크럼 보드 설계
- 정책 명시화
- 스크럼 진행 방식, DOD(Definition of Done, 완료 정의)

SCRUM EVENT
스프린트 계획(SPRINT PLANNING)
일일 스탠드업(DAILY SCRUM)
스프린트 리뷰(SPRINT REVIEW)
스프린트 회고(SPRINT RETROSPECTIVE)
커뮤니케이션은 어떤 프로젝트에서든 성공의 열쇠가 됩니다.
스크럼팀은 네 가지 주요 미팅을 통해 팀 업무를 체계화합니다.
각 미팅을 통해 팀은 팀으로서 계획하고, 인도(Delivery)하고 배웁니다.

Do
- 한 날에 미팅이 여러 건 예정된 경우 미팅을 몰아서
진행합니다.
- 정말 필요한 경우를 제외하고는 회의 참석자는 최소
한으로 합니다.
- 스크럼 미팅은 정기적으로 진행합니다.
- 각 미팅은 미팅의 목적에 벗어나지 않도록 합니다.
Do Not
- 미팅이 하루 종일 흩어져 있어 사이사이 프로젝트 작
업 시간이 30-60분 밖에 안 됩니다.
- 의사결정에 크게 필요치 않은 사람들까지도 단순히
정보를 얻기 위한 목적으로 참석을 요구 받습니다.
- 필요에 따라 또는 불규칙하게 미팅이 열립니다.

PRODUCT BACKLOG
제품 백로그는 제품의 가능한 모든 요구사항에 대한 우선 순위화된 목록입니다.
또한 제품 백로그는 제품에 대한 모든 변경 요구사항을 포함하는 단 하나의 소스입니다.
제품 책임자가 제품 백로그 (내용, 가용성, 우선순위화 등) 에 대한 책임을 가지고 있습니다.
제품 백로그는 요구사항에 대한 완성본이 아닙니다.

Do
- 제품 백로그는 모든 프로젝트 멤버, 이해관계자가 쉽
게 확인할 수 있도록 가시화 합니다.
- 필요에 따라 백로그들을 구조화 하도록 합니다.
- 백로그별로 상대적인 우선 순위에 따라 정렬하도록
합니다.
- 새로운 백로그가 추가되거나, 새로운 상황이 발생한
경우 우선순위를 재조정 합니다.
- 팀의 모든 작업을 백로그에 포함하도록 합니다.
- 고객에게 보여지는 기능 뿐만 아니라 내부적인 작업들 또한 백로그
로 도출합니다.
Do Not
- 백로그가 프로젝트 시작시에만 우선순위를 설정하
고, 프로젝트 진행중에는 조정되지 않습니다.
- 백로그 항목이 제품 기능으로만 구성되어 있습니다.
- 백로그 목록은 한번 작성된 이후 업데이트 되지 않습
니다.

SPRINT PLANNING
스프린트에서 수행되어야 할 작업들을 스프린트 계획 미팅에서 정합니다.
이 계획은 전체 스크럼 팀의 공동 작업으로 만들어집니다.
백로그
선정 > 백로그
구체화
추정
>
범
위&
담당자
선
> >
스
프린트
백로그
확

Do
- 미팅전 필요한 정보를 수집합니다.
- 제품 백로그, 가장 최근의 제품 증분, 스프린트 동안의 개발팀 가
용 인력 예상, 개발팀의 과거 생산성 자료
- 아래 두가지 질문에 대한 답을 정합니다.
- 이번 스프린트에서 무엇을 할 수 있는가? (Product Backlog)
- 선택된 작업들을 어떻게 완료하나? (Sprint Backlog)
- *Sprint Goal 을 정하도록 합니다.
- 추정을 통해 스프린트 백로그들의 크기를 예측하
고, 스프린트에서 진행할 작업량을 결정합니다.
- 진행할 작업량에 대한 결정은 개발팀이 합니다.
- 같은 언어, DOD(Definition of Done, 완료 정의)
Do Not
- 제품 책임자 또는 개발리더가 임의로 작업할 백로그
를 선정하고 개발팀에 할당합니다.
- 추정 작업시에 제품 책임자 또는 개발리더 임의로 작
업의 크기를 선정합니다.
- 스프린트에 끝낼수 없는 크기의 작업을 선정합니다.
- 미팅 시간 제한없이 끝장토론으로 플래닝, 추정을 진
행합니다.
*Sprint Goal : 제품 백로그를 구현함으로써 스프린트 동안 달성하고자 하는 목표, 스프린트를
왜 진행하는지에 대한 가이드.

…
아직 안 끝났어요?
네 아직이요...
언제 끝나는데요?
음... 곧?

지금 하는거 말고 이것
먼저 해줘요. 그 작업은 플래닝때 없었던
항목인데요?
그건 아는데
이게 더 중요해요.
…

…
지금 개발중인거 이렇
게 바꿔야 해요. 한참 개발중인데요?
그건 아는데 그래도 바꿔줘
요. 네…
저번에 그거 다시 원래
대로 하죠.
뚝딱뚝딱...

ON SPRINT
개발팀은 스프린트 동안에 하기로 한 작업들을 완료할 수 있도록 최선을 다합니다.
스프린트 동안에는 개발팀은 스펙의 변경, 외부 요인 으로 인한 방해를 받아서는 안됩니다.
그리고 일일스크럼을 통해 스프린트를 점검하도록 합니다.

진행 상황 추적
- 진행 상황을 공유하면 프로젝트 진행상황이 투명해
지고 명확해집니다.
- 누구나 쉽게 진행 상황을 확인할 수 있도록 가시화
함으로 인해 불필요한 커뮤니케이션 비용을 줄일수
있습니다.
- 목표한 작업들을 스프린트내에 완료할 수 있을지에
대한 예측을 가능하게 합니다.
- 스프린트를 거듭할수록 더욱 정밀해집니다.

Do
- 스프린트 길이를 가능한 짧게 유지합니다.
- 스프린트 길이를 늘 같게 유지합니다.
- 팀이 회복 불가능할 정도로 논점을 벗어나면 스프린
트를 중단합니다.
- 잠시 시간을 갖고 어디서부터 잘못 됐는지 파악해 다시 시작합니
다.
- 작업 보드나 번다운 차트등의 도구를 활용합니다.
- 작업 보드는 항상 실제 작업과 동기화 하도록 합니다.
- 점수나 완료된 항목으로 팀을 서로 비교하지 못하게
합니다. 누구나 속도가 다르기 마련입니다.
Do Not
- 원래 약속한 업무가 끝날 때까지 스프린트가 늘어집
니다.
- PO가 팀의 스프린트 우선순위를 스프린트 도중에
계속해서 바꿉니다.
- PO가 스프린트 도중에 새로운 백로그를 추가하거나
기존 백로그를 제거합니다.
- 스프린트 백로그에 포함되지 않은 작업을 진행합니
다.
- 스프린트가 끝나가면 작업 보드를 일괄 갱신합니다.

DAILY SCRUM
일일 스크럼은 개발팀이 각자 수행한 작업들을 확인한 후 조율하고,
다음 24 시간 동안 해야 할 작업들의 계획을 하는 15 분 타임박스 미팅입니다.
나는 어제 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 했는지?
나는 오늘 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 할 것인지?
나 혹은 개발팀이 스프린트 목표 달성을 하는데 방해요소가 있는지 ?

Do
- 모든 개발팀 멤버가 참여하도록 합니다.
- 스크럼 마스터는 미팅의 방향이 다른곳으로 가지 않
도록 조율합니다.
- 참석자들은 일관된 패턴으로 현황을 공유합니다.
- 어제 뭐했고, 오늘 뭐할거고, 어떤 문제가 있어.
- 미팅의 복잡도를 줄이기 위해 같은 장소, 같은 시간
에 진행합니다.
- 추가적인 논의가 필요한 경우 후속 미팅을 따로 진행
하도록 합니다.
Do Not
- 발생한 문제에 대한 해결을 위한 토론을 하느라 30
분 1시간씩 진행합니다.
- 하고 있는 일에 대해서만 보고 형태로 공유를 하고,
장애물에 대해서는 공유하지 않습니다.
- 스크럼팀 멤버가 아닌 사람이 스프린트 진행과 관계
없는 공지나 다른 목적으로 미팅을 진행하기도 합니
다.

SPRINT REVIEW
스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의입니다.
스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백을 받습니다.
스프린트 리뷰의 결과는 다음 스프린트의 계획을 위한 기반 자료가 됩니다.

Do
- 제품 책임자가 완료된 백로그, 완료되지 않은 백로그
에 대해 설명합니다.
- 개발팀은 완료된 백로그를 시연(DEMO) 합니다.
- 전체 그룹이 다음에 무엇을 할지 함께 의논하여 스프
린트 리뷰 미팅이 다음 스프린트 계획에 가치있는 조
언을 제공합니다.
- 제품 책임자는 현재 남아있는 제품 백로그를 설명하
고, (필요하다면) 현재까지의 진행상황을 바탕으로
언제쯤 프로젝트가 완료될지 공유합니다.
- 남아있는 백로그의 크기, 팀의 속도(스프린트)를 기반으로 예측
Do Not
- 경과 보고를 위한 공식 미팅이 아닙니다.
- 완료된 제품 증분을 발표함으로 피드백을 얻고, 서로간의 협력을
촉진하기 위한 미팅입니다.
- 리뷰 미팅 직전에 작업의 상태를 In-Progress 에서
Done으로 변경합니다.
- 완료에 대한 기준이 달라 개발자가 완료했음에도 시
연이 불가능한 경우가 있습니다.
- 추정에 맞추기 위해 완료되지 않은 작업도 완료로 처
리합니다.

RETROSPECTIVE
스프린트 회고 미팅은 스크럼 팀이 스스로를 되돌아보고,
다음 스프린트 동안 무엇을 개선할 수 있을지 계획할 수 있는 기회를 제공합니다.
지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토합니
다.
잘 된 것들 그리고 개선의 여지가 있는 주요 항목들을 알아내고 순위화합니다.
스크럼 팀이 작업을 수행하는 방법에 대한 개선을 실천할 수 있도록 계획을 수립합니다.

Do
- 항상 지금보다 더 잘 할수 있다는 마음가짐을 갖습니
다.
- 모든 스크럼팀 멤버가 참여하도록 합니다.
- 스프린트 리뷰 미팅 이후 정기적으로 진행합니다.
- 회고 미팅후에 스크럼팀은 다음 스프린트에서 실천
할 개선 사항들을 확인할 수 있어야 합니다.
- 액션 아이템 도출
Do Not
- 잘잘못을 따지는 자리가 아닙니다.
- 문제점만 확인하고 이를 개선하기 위한 계획, 행동을
하지 않습니다.

스크럼 도입하면
뭐가 좋아지는데요?

PRODUCT BACKLOG
프로젝트 초기에 한번 만들어지고 위키, 아지트 어딘가에 머물러 있는 기획서가 아니라
프로젝트 진행 기간 동안 살아 숨쉬는(?) 백로그를 소유하게 됩니다.

SPRINT PLANNING
큰 작업을 작게 나누고, 각각의 작업은 그 크기를 산정합니다.
반복된 스프린트를 통해 팀의 속도를 알 수 있습니다.
개발팀은 반복주기 동안 몰입할 수 있는 업무의 양을 직접 선정할 수 있습니다.
이로 인해 정밀한 일정 예측이 가능해집니다.

ON SPRINT
스프린트 기간동안 방해받지 않고
스프린트 목표를 위해 전력 질주 할 수 있습니다.

DAILY SCRUM
매일 매일 진행상황을 공유합니다.
장애물 또한 즉각 확인하고 대처할 수 있게 됩니다.

BOARD
BUNRDOWN CHART
스크럼팀 구성원 모두가 프로젝트의 진행상황을 쉽게 이해하게 됩니다.
잘 진행되고 있는지, 장애물을 만나 멈춰 있는지 투명하게 드러납니다.

SPRINT REVIEW
매 주기(스프린트)별로 우리가 완성한 결과물을 확인할 수 있습니다.
결과물을 토대로 다음 나아갈 방향을 결정할 수 있습니다.
리뷰 후 진행되는 기획의 변경이 자연스러운 활동이 됩니다.

SPRINT RETROSPECTIVE
회고를 통해 더 잘할 수 있는 방법은 없는지 고민하게 합니다.
모든 스크럼팀 구성원 스스로...

단! Do Scrum Right 일 경우

스크럼 해봤는데
별로던데요?
과연 스크럼이 문제일까요?

장애물
어렵습니다!
- 기획자, 개발자, 테스터 각자의 언어로 백로그를 관리합
니다.
- 백로그를 쪼개고, 그룹화 하고, 실제 작업과 일치시키는
작업이 어렵습니다.
- 추정은 아무리 해도 매번 틀립니다. 왜 해야하는지 의문
의 듭니다.
- 일일 스크럼은 일일 보고처럼 느껴집니다.
- 스프린트 도중에 계획되지 않은 업무들이 쏟아지거나,
진행중인 작업의 기획이 변경되어 버립니다.
- 스프린트가 일주일인데 플래닝, 리뷰, 회고, 부가적인 회
의를 하다보면 정작 일할 시간이 없습니다.
- 몇번의 스프린트만으로는 Inspect&Adapt 가 잘 동작하
지 않습니다.

이해하기는 쉽지만,
마스터 하기는 어렵습니다!

SCRUM JIRA
PRODUCT
^
VERSIONS
^
SPRINTS
^
BACKLOGS
PROJECT
^
VERSIONS
^
SPRINTS
^
ISSUES

ORGANIZE ISSUES
유형, 상하, 포함, 연결

유형별 구분
- Story
- New Feature
- Task
- Bug
- Improvement
- …
이슈 타입

상하 관계
에픽(Epic)
오직 하나의 상위 관계만 맺을수 있음. 이슈(Issue)
서브태스크(Sub-task)

포함 관계
버전(Version)
스프린트(Sprint)
컴포넌트(Component)
여러 포함 관계를 맺을 수 있음.
레이블(Label)

연결 관계
이슈 링크(ISSUE LINK)
이슈간 연결 관계를 설정할 수 있음.
- blocks
- is blocked by
- relates to
- duplicates
- has to be done before
- has to be done after

1. 프로젝트 및 스크럼 보드 생성

프로젝트 생성
Service Desk > Create Service Desk Request

스크럼보드 생성
프로젝트 사이드바에서 직접 생성

백로그 생성
이슈 생성 단축키 : c
단축키 : 1

백로그 생성
다이얼로그 닫지 않고 계속 생성

에픽-이슈 매핑
Drag & Drop

버전-이슈 매핑
Drag & Drop

스프린트-이슈 매핑
Drag & Drop

담당자 지정
담당자 지정 단축키 : a
나를 담당자로 지정 단축키: i

스프린트 백로그 추가
이슈 생성후
백로그 화면에서 스프린트 매핑

추정치 변경
이슈 편집화면에서 수정가능
이슈 편집 단축키 : e

스프린트 리포트
번다운 차트
완료된 백로그
완료되지 않은 백로그

회고 미팅 노트
스프린트 - 위키 회고 미팅 노트
페이지 연동

BURNDOWN CHART
- 모든 백로그를 완료하지 못함
- 팀의 능력보다 많은 백로그를 선택했거나
- 추정을 타이트하게 했거나
- 예상치 못한 이슈가 발생했거나
- 스프린트 기간보다 짧은 시간에 모두 완료
- 팀의 능력보다 적은 백로그를 선택했거나
- 추정을 넉넉하게 했거나
- 인센티브가 나왔거나(?)
- 이상적인 가이드 라인

기타 리포트
에픽 리포트
버전 리포트
에픽 번다운
릴리스 번다운
컨트롤 차트
벨로시티 차트
누적흐름도(CFD)

GENERAL
- 보드 이름
- 보드 관리자
- 보드에 노출시킬 이슈 필터
- 보드 공유 설정

WORKFLOW
- 워크플로우 조정
- 컬럼, 상태 관리

SWIMLANE
- 커스텀 쿼리(사용자 커스텀)
- 담당자별(PRE DEFINED)
- 에픽별별(PRE DEFINED)
- 스토리별(PRE DEFINED)
- NO SWIMLANE
이슈를 횡으로 그룹화

QUICK FILTER
추가적인 JQL 을 통해
보드에 노출되는 이슈를 필터링
JQL : JIRA QUERY LANGUAGE

CARD COLOR
카드컬러
- 이슈 타입별
- 우선순위별
- 담당자별
- 커스텀 쿼리
- NONE

CARD LAYOUT
기본 카드 레이아웃
- 이슈번호
- 이슈타입 아이콘
- 우선순위 아이콘
- 담당자 프로필 이미지
- 스토리포인트
- 에픽
추가 필드 설정된 카드

ESTIMATION
- 추정 필드 설정
- 타임 트래킹 방식 설정

WORKING DAYS
리포트, 통계정보에서 제외할
작업일 설정

ISSUE DETAIL VIEW
보드에서 이슈 선택시
우측 이슈 상세 화면
레이아웃 설정

Agile card for JIRA
• JIRA 이슈를 프린트해서 오프라인 보드구성
• 오프라인 보드와 지라 보드 동기화를 QR코드 인식으로 통해 간단하게
• https://marketplace.atlassian.com/plugins/
com.spartez.scrumprint.scrumplugin/server/overview

Agile poker for JIRA
• JIRA Scrum planning 에서 사용가능한 플래닝포커 플러그인
• https://marketplace.atlassian.com/plugins/
com.spartez.jira.plugins.jiraplanningpoker/server/overview

KANBAN
OVERVIEW
PROCESS
BASIC PRINCIPLE & CORE PRACTICE
DO KANBAN RIGHT
HELPS & HURDLES
KANBAN WITH JIRA

칸반, 칸반 시스템
도요타 생산 시스템(TPS)의 서브 시스템중 하나이다.
칸반은 신호 카드를 의미한다.
TPS의 기본적인 사고는 Just In Time, 생산 자동화에
기반하고 있다.

칸반의 정의
칸반은 점진적으로 서비스 출시를 개선하기 위한 관리 방법이다.
ref. http://djaa.com/kanban-framework
소프트웨어 개발이나 프로젝트 관리 또는 IT 운영에서 사용하는
프로세스나 프레임워크가 아니다.
칸반은 “프레임워크(framework)”가 아니라 “방법(method)”
단지 작업 보드를 사용한다고 해서 칸반을 하는것은 아니다.

칸반이론
Pull
Limit
WIP
당김(Pull)방식과
진행중 업무 제한(Limit WIP)이
없다면 칸반이 아니다.

당김 방식
“Benedict, 다음에는 샵검색 개발해주세요.”
가 아니라,
“오픈 채팅 개발이 끝났으니, 샵검색은 제가 개발할게요”

LIMIT WIP
대기 행렬 이론, 리틀의 법칙
WIP = Th * CT
- WIP(진행 중 업무) = 개발 시스템에서 완료되지 않은 항목의 평균량
- Th(처리량) = 단위 시간 동안 팀의 출력
- CT(사이클 타임) = 팀이 한 항목을 마치는 데 걸리는 평균 시간
처리량을
늘리려면?
Th = WIP / CT
‘일정 시스템에 오랜 시간 동안 머물러 있는 고객의 평균적인 수치(WIP)는
오랜 시간 동안에 걸친 평균 실제 도착율(Th)과
시스템에서 고객이 머문 평균 시간(CT)을 곱한 값과 동일하다’

WIP를 늘리면 처리량이
증가할까요?
아니오!

LIMIT WIP
처리량과 WIP 관계 WIP 증가에 대한 팀의 반응
한계점까지는 처리량이 증가하다가
그 이후에는 오히려 감소합니다.
WIP가 늘어나면 팀이 최대 가용 처리량에 도달하기 전까지
업무를 최적화하고 출시 프로세스의 낭비를 제거하게 만들 수 있습니다.
그 이후에도 WIP가 계속 늘어난다면 더 이상의 개선이 이루어지긴 어렵습니다.
오히려 스트레스와 작업 전환으로 인해 팀의 처리량이 감소합니다.

칸반에는 프로세스가 없습니다.
칸반은 프로세스 또는 프로젝트 관리 방법이 아니라
기존 프로세스를 더 나은 방법으로 개선하도록 도와주는
관리 방법이다.

어떤 상황이라도, 지금 바로 시작할 수 있다.
점진적인 변화 방식을 지향한다.
처음에는 기존의 역할, 책임, 직함을 존중한다.

칸반에 대한 오해
스크럼은 개발 프로젝트에 적합하고,
칸반은 운영에만 적합하다.
칸반은 개발, 운영, 작업관리 등
어떤 방식의 업무에도 적용할 수 있는 방법이다.

VISUALIZE
현재의 업무 흐름을 시각화 하도록 합니다.
업무가 어디에서 시작되어 어떻게 흘러가는지를 나타내도록 합니다.
현재 하고 있는 업무가 업무흐름에 나타나야 합니다.

LIMIT WIP
진행중인 업무의 양을 제한합니다.
WIP 제한에 결린 경우 기존 작업이 빠지기 전에는
새로운 작업을 당겨 올 수 없습니다.
WIP의 양을 제한하면 칸반팀은 누구도 작업 부담의 심한 압력을 받지 않고
자신의 일정한 흐름을 유지할 수 있습니다

MANAGE FLOW
흐름을 관리합니다.
업무가 흘러가는 과정을 항상 관찰하도록 합니다.
어느 지점에 병목이 있는지,
어떤 작업이 특정 상태에 오랫동안 머물러 있는지
바로바로 확인하고 해결하도록 합니다.
업무 흐름이 막힘없이 일정한 속도로 흘러가도록 해야합니다.

MAKE POLICIES EXPLICIT
정책을 명시화 합니다.
정책이 명시적이지 않으면 개선 논의가 어렵습니다.
업무 진행 방식, DOD, 백로그 관리, 우선 순위 관리등의 정책들을 명시화 하도록 합니다.

IMPROVE COLLABORATIVELY
협업을 개선하도록 합니다.
칸반은 칸반팀 누구나 받아들일수 있는 지속적이고 점진적인 변화를 추구합니다.
모든 칸반팀원이 업무 흐름, 위험 요소 등을 이해한다면,
쉽게 개선하고 합의에 이를수 있습니다.

IMPLEMENT
FEEDBACK LOOP
피드백 루프를 실행하도록 합니다.
스크럼의 Daily Scrum, Sprint Review, Retrospective 를 칸반에서도 실행할 수 있습니다.
스크럼과 다른점은
칸반 일일 스탠드업 - 사람이 기준이 아니라 작업이 기준입니다.
리뷰, 회고 - 각각 별개의 리듬(Cadence)으로 진행할 수 있습니다.

FLOW & PULL
흐름을 최적화 할수록 사이클타임이 짧아지고 처리량이 증가합니다.
흐름 최적화를 위해 칸반은 당김(Pull)방식을 지향하고 있습니다.

Do
- 업무 흐름의 단계별로 고유한 기능을 갖도록 합니다.
- 각 단계별로 역할에 따라 소유열을 구분하도록 합니
다.
- WIP 수용량에 여유가 있을때에만 신규 작업을 수락
합니다.
- 병목지점을 찾아내서 함께 빠르게 해결합니다.
- 팀이 자발적으로 업무를 당겨올수 있도록 권한을 부
여합니다.
- 우선 순위 관리 정책을 명시합니다.
- 작업을 당겨올때 가장 우선적으로 처리해야할 작업을 선택하도록
Do Not
- 작업의 크기가 너무 커서 특정 상태에 너무 오래 머
물러 있습니다.
- 작업을 당겨오는것이 아니라 밀어넣습니다.
- 작업 흐름에 포함되어 있지 않은 작업 단계가 있습니
다.

WIP
WIP 제한은 지나치게 여유가 있거나, 병목이 있는 흐름단계를 드러내게 합니다.
실시간으로 이런 단계를 파악할 수 있게 되므로
상황이 악화되기 전에 빠르게 문제를 해결할 수 있습니다.

Do
- 작업 항목을 가능한 작고 관리 가능한 규모로 쪼갭니
다.
- 팀의 최적 WIP 제한 수치를 찾기위해 주기적으로 변
화를 시도합니다.
- 단, 피드백을 얻을수 있을 만큼은 해봐야합니다.
- 분야별로 작업 흐름의 단계를 구분하도록 합니다.
Do Not
- WIP 제한이 절대 바뀌지 않습니다.
- 필요할 때마다 WIP 제한을 늘립니다.
- 병목지점이나 문제점에 대해 함께 해결하기 보다 새
로운 작업을 끌어오기만 합니다.
- 병목지점, 문제점을 근본적으로 개선하는것보다 인
력과 시간만을 더 투입하려고 합니다.

뭐가 좋아지나요?
칸반이 킹왕짱 세젤존좋?

좋은점
- 쉽습니다.
- 스크럼의 좋은점들이 칸반에서도 가능해집니다.
- 스크럼의 어려운점들을 칸반은 해결해줍니다.
- 스크럼보다 더욱 기민하게 대응할 수 있습니다.
장애물
- 스크럼과 마찬가지로 경험주의 이론에 기반을 두고
있기에 단기간에 개선이 이루어지지는 않습니다.
- 스크럼보다 더 간단하지만, 칸반 역시 핵심 이론인 ‘당
김방식’, ‘WIP 제한’ 에 대한 충분한 이해가 필요합니
다.

칸반 보드는
백로그 메뉴가 없습니다.
보드 제일 우측열에 Release 링크가 있습니다. 
제일 우측열 이슈들을 특정 버전으로 릴리스 하는 기능
나머지는 다 똑같아요

WIP LIMIT 설정
WIP 제한
- 이슈 갯수
- 서브 태스크를 제외한 이슈갯수
- MIN WIP, MAX WIP

WIP LIMIT 설정
제한 초과일 경우
빨간색으로 표시

Done 열의 이슈에
버전을 할당한 후 릴리스 합니다.
보드에서 슝~

뉴호라이즌스 with 워터폴
뉴호라이즌스 with 스크럼
뉴호라이즌스 with 칸반

더 나아지고 싶으신가요?
어떤것도 하고 있지
않으신가요?
안녕히 가세요.
칸반을 시도해보세요.
스크럼이
잘 안되시나요?
스크럼
계속 잘 해나가면
됩니다.

REFERENCE
스크럼가이드
- http://www.scrumguides.org/docs/scrumguide/v1/Scrum-
Guide-US.pdf
- (번역) http://www.scrumguides.org/docs/scrumguide/v1/
Scrum-Guide-KR.pdf
스크럼 체크리스트
- https://www.crisp.se/wp-content/uploads/2012/05/
Scrum-checklist.pdf
칸반과 스크럼
- http://www.infoq.com/minibooks/kanban-scrum-
minibook
잘가요 스크럼 반가워요 칸반
- https://stormpath.com/blog/so-long-scrum-hello-kanban/
- (번역) http://pitzcarraldo.github.io/articles/2014/05/08/
goodbye-scrum-hello-kanban/
칸반
- (BOOK) http://book.daum.net/detail/book.do?
bookid=KOR9788966261222
VersionOne - 9th(2014) state of agile development survey
- https://www.versionone.com/pdf/state-of-agile-development-
survey-ninth.pdf
Do Agile Right - Atlassian
- https://www.atlassian.com/landing/agile/project-
management

Scrum and kanban with jira

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Scrum and kanban with jira

Ähnlich wie Scrum and kanban with jira (20)

Scrum and kanban with jira