SlideShare a Scribd company logo
1 of 168
Download to read offline
SCRUM & KANBAN with JIRA
JIRA 를 이용한 스크럼, 칸반 적용 안내
카카오 > 플랫폼기술팀
Benedict(이호정)
세미나 목표
스크럼과 칸반에 대해 이해해 봅시다.
JIRA를 이용해서 스크럼과 칸반을 적용하는 방법을 배워봅시다.
간단한 JIRA 팁, 개발도구들과의 연동 기능에 대해 알아봅시다.
목차
• Overview
• Scrum
• Scrum w/ JIRA
• Break
• Kanban
• Kanban w/ JIRA
• Conclusion
OVERVIEW
S/W DEVELOPMENT
AGILE
S/W DEVELOPMENT
WATERFALL
분석
설계
구현
테스트
유지
보수
- 전통적인 S/W 개발 방법론
- Sequential Development Process
over
30
over
20
over
70
roles
activities
artifacts
RUP
복잡하다.
아직 기획이 안끝나서 

개발을 못하고 있어요. 아니, 이제와서 이걸 이렇게 바꾸면 

어쩌자는 겁니까?
샵검색을 말씀드린건데 삽을 검색하시면...
음... 이상하네요.

제 컴퓨터에서는 잘 되는데..
또 변경될텐데 

대충 돌아가게만 만들지 뭐... 아직 안 끝났어?
네 아직이요.
언제 끝나는데?
곧 끝날것 같아요.
무엇이 문제 일까요?
LONG FEEDBACK LOOP
AGILE
애자일 소프트웨어 개발 선언문
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 

이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.


공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
AGILE METHODOLOGY USED
ref. https://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf
AGILE TECHNIQUES
ref. https://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf
REASONS
FOR ADOPTING AGILE
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
SCRUM OVERVIEW
스크럼의 정의
가장 가치 있는 제품을 생산적이고 창의적으로 배포하기 위하여
복잡하게 얽힌 적응적 문제들 (complex adaptive problems)을
다룰 수 있도록 하는 프레임워크


간단하고
이해하기 쉽지만,
마스터하기는 어려운 프레임워크 입니다.

ref. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf
스크럼 이론#1
스크럼은 경험적 프로세스 관리 이론,
혹은 경험주의 (empiricism) 이론에 기반하고 있습니다.
ref. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf
반복
Iterative
점진
Incremental
예측을 최적화 하고,
위험 요소를 관리하기 위해
반복적이고, 점진적인 접근방법을 취합니다.
스크럼 이론#2
경험적 프로세스 관리를 수행하는 데 필요한 세 가지 축
ref. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf
투명성
Transparency
검토
Inspection
적응
Adaptation
SCRUM PROCESS
3 ROLEs
4 EVENTs
3 ARTIFACTs
Product Owner
Scrum Master
Team
Product Owner
Sprint
Review
Sprint
Retros.
Estimation
Sprint
Planning
DO SCRUM RIGHT
스프린트#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
…
아직 안 끝났어요?
네 아직이요...
언제 끝나는데요?
음... 곧?
지금 하는거 말고 이것
먼저 해줘요. 그 작업은 플래닝때 없었던
항목인데요?
그건 아는데
이게 더 중요해요.
…
…
지금 개발중인거 이렇
게 바꿔야 해요. 한참 개발중인데요?
그건 아는데 그래도 바꿔줘
요. 네…
저번에 그거 다시 원래
대로 하죠.
뚝딱뚝딱...
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 WITH JIRA
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
스크럼보드 생성
프로젝트 사이드바에서 직접 생성
2. PRODUCT BACKLOG
백로그 생성
이슈 생성 단축키 : c
단축키 : 1
백로그 생성
다이얼로그 닫지 않고 계속 생성
에픽 생성
에픽-이슈 매핑
Drag & Drop
3. RELEASE PLANNING
버전 생성
버전-이슈 매핑
Drag & Drop
4. SPRINT PLANNING
스프린트 생성
스프린트-이슈 매핑
Drag & Drop
추정
담당자 지정
담당자 지정 단축키 : a
나를 담당자로 지정 단축키: i
스프린트 시작
5. ON SPRINT
ACTIVE SPRINT
단축키 : 2
스프린트 백로그 추가
이슈 생성후
백로그 화면에서 스프린트 매핑
추정치 변경
이슈 편집화면에서 수정가능
이슈 편집 단축키 : e
5. SPRINT REVIEW
스프린트 완료
스프린트 리포트
번다운 차트
완료된 백로그
완료되지 않은 백로그
6. SPRINT RETROSPECTIVE
회고 미팅 노트
스프린트 - 위키 회고 미팅 노트
페이지 연동
회고 미팅 노트
7. REPORT
BURNDOWN CHART
- 모든 백로그를 완료하지 못함
- 팀의 능력보다 많은 백로그를 선택했거나
- 추정을 타이트하게 했거나
- 예상치 못한 이슈가 발생했거나
- 스프린트 기간보다 짧은 시간에 모두 완료
- 팀의 능력보다 적은 백로그를 선택했거나
- 추정을 넉넉하게 했거나
- 인센티브가 나왔거나(?)
- 이상적인 가이드 라인
기타 리포트
에픽 리포트
버전 리포트
에픽 번다운
릴리스 번다운
컨트롤 차트
벨로시티 차트
누적흐름도(CFD)
8. CUSTOMIZE BOARD
CONFIGURE BOARD
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
보드에서 이슈 선택시
우측 이슈 상세 화면
레이아웃 설정
9. DASHBOARD &
WALLBOARD
10. SHORTCUT
JIRA 단축키
? = shift + /
11. Github, Confluence 연동
12. JIRA plugins
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
Q&A
Break
KANBAN
OVERVIEW
PROCESS
BASIC PRINCIPLE & CORE PRACTICE
DO KANBAN RIGHT
HELPS & HURDLES
KANBAN WITH JIRA
KANBAN OVERVIEW
칸반, 칸반 시스템
도요타 생산 시스템(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가 계속 늘어난다면 더 이상의 개선이 이루어지긴 어렵습니다.
오히려 스트레스와 작업 전환으로 인해 팀의 처리량이 감소합니다.
KANBAN PROCESS
칸반에는 프로세스가 없습니다.
칸반은 프로세스 또는 프로젝트 관리 방법이 아니라
기존 프로세스를 더 나은 방법으로 개선하도록 도와주는
관리 방법이다.
KANBAN BASIC PRINCIPLE
어떤 상황이라도, 지금 바로 시작할 수 있다.
점진적인 변화 방식을 지향한다.
처음에는 기존의 역할, 책임, 직함을 존중한다.
칸반에 대한 오해
스크럼은 개발 프로젝트에 적합하고,
칸반은 운영에만 적합하다.
칸반은 개발, 운영, 작업관리 등
어떤 방식의 업무에도 적용할 수 있는 방법이다.
KANBAN CORE PRACTICE
VISUALIZE
현재의 업무 흐름을 시각화 하도록 합니다.
업무가 어디에서 시작되어 어떻게 흘러가는지를 나타내도록 합니다.
현재 하고 있는 업무가 업무흐름에 나타나야 합니다.
LIMIT WIP
진행중인 업무의 양을 제한합니다.
WIP 제한에 결린 경우 기존 작업이 빠지기 전에는
새로운 작업을 당겨 올 수 없습니다.
WIP의 양을 제한하면 칸반팀은 누구도 작업 부담의 심한 압력을 받지 않고
자신의 일정한 흐름을 유지할 수 있습니다
MANAGE FLOW
흐름을 관리합니다.
업무가 흘러가는 과정을 항상 관찰하도록 합니다.
어느 지점에 병목이 있는지,
어떤 작업이 특정 상태에 오랫동안 머물러 있는지
바로바로 확인하고 해결하도록 합니다.
업무 흐름이 막힘없이 일정한 속도로 흘러가도록 해야합니다.
MAKE POLICIES EXPLICIT
정책을 명시화 합니다.
정책이 명시적이지 않으면 개선 논의가 어렵습니다.
업무 진행 방식, DOD, 백로그 관리, 우선 순위 관리등의 정책들을 명시화 하도록 합니다.
IMPROVE COLLABORATIVELY
협업을 개선하도록 합니다.
칸반은 칸반팀 누구나 받아들일수 있는 지속적이고 점진적인 변화를 추구합니다.
모든 칸반팀원이 업무 흐름, 위험 요소 등을 이해한다면,
쉽게 개선하고 합의에 이를수 있습니다.
IMPLEMENT
FEEDBACK LOOP
피드백 루프를 실행하도록 합니다.
스크럼의 Daily Scrum, Sprint Review, Retrospective 를 칸반에서도 실행할 수 있습니다.
스크럼과 다른점은
칸반 일일 스탠드업 - 사람이 기준이 아니라 작업이 기준입니다.
리뷰, 회고 - 각각 별개의 리듬(Cadence)으로 진행할 수 있습니다.
DO KANBAN RIGHT
FLOW & PULL
흐름을 최적화 할수록 사이클타임이 짧아지고 처리량이 증가합니다.
흐름 최적화를 위해 칸반은 당김(Pull)방식을 지향하고 있습니다.
Do
- 업무 흐름의 단계별로 고유한 기능을 갖도록 합니다.
- 각 단계별로 역할에 따라 소유열을 구분하도록 합니
다.
- WIP 수용량에 여유가 있을때에만 신규 작업을 수락
합니다.
- 병목지점을 찾아내서 함께 빠르게 해결합니다.
- 팀이 자발적으로 업무를 당겨올수 있도록 권한을 부
여합니다.
- 우선 순위 관리 정책을 명시합니다.
- 작업을 당겨올때 가장 우선적으로 처리해야할 작업을 선택하도록
Do Not
- 작업의 크기가 너무 커서 특정 상태에 너무 오래 머
물러 있습니다.
- 작업을 당겨오는것이 아니라 밀어넣습니다.
- 작업 흐름에 포함되어 있지 않은 작업 단계가 있습니
다.
WIP
WIP 제한은 지나치게 여유가 있거나, 병목이 있는 흐름단계를 드러내게 합니다.
실시간으로 이런 단계를 파악할 수 있게 되므로
상황이 악화되기 전에 빠르게 문제를 해결할 수 있습니다.
Do
- 작업 항목을 가능한 작고 관리 가능한 규모로 쪼갭니
다.
- 팀의 최적 WIP 제한 수치를 찾기위해 주기적으로 변
화를 시도합니다.
- 단, 피드백을 얻을수 있을 만큼은 해봐야합니다.
- 분야별로 작업 흐름의 단계를 구분하도록 합니다.
Do Not
- WIP 제한이 절대 바뀌지 않습니다.
- 필요할 때마다 WIP 제한을 늘립니다.
- 병목지점이나 문제점에 대해 함께 해결하기 보다 새
로운 작업을 끌어오기만 합니다.
- 병목지점, 문제점을 근본적으로 개선하는것보다 인
력과 시간만을 더 투입하려고 합니다.
뭐가 좋아지나요?
칸반이 킹왕짱 세젤존좋?
좋은점
- 쉽습니다.
- 스크럼의 좋은점들이 칸반에서도 가능해집니다.
- 스크럼의 어려운점들을 칸반은 해결해줍니다.
- 스크럼보다 더욱 기민하게 대응할 수 있습니다.
장애물
- 스크럼과 마찬가지로 경험주의 이론에 기반을 두고
있기에 단기간에 개선이 이루어지지는 않습니다.
- 스크럼보다 더 간단하지만, 칸반 역시 핵심 이론인 ‘당
김방식’, ‘WIP 제한’ 에 대한 충분한 이해가 필요합니
다.
KANBAN WITH JIRA
칸반 보드는
백로그 메뉴가 없습니다.
보드 제일 우측열에 Release 링크가 있습니다.

제일 우측열 이슈들을 특정 버전으로 릴리스 하는 기능
나머지는 다 똑같아요
CONFIGURE WIP LIMIT
WIP LIMIT 설정
WIP 제한
- 이슈 갯수
- 서브 태스크를 제외한 이슈갯수
- MIN WIP, MAX WIP
WIP LIMIT 설정
제한 초과일 경우
빨간색으로 표시
DAYS IN STATUS
카드 하단 점의 갯수!!
RELEASE
Done 열의 이슈에
버전을 할당한 후 릴리스 합니다.
보드에서 슝~
CONCLUSION
뉴호라이즌스 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
Q&A
감사합니다. :)

More Related Content

What's hot

애자일 스크럼과 JIRA
애자일 스크럼과 JIRA 애자일 스크럼과 JIRA
애자일 스크럼과 JIRA Terry Cho
 
칸반(Kanban)
칸반(Kanban)칸반(Kanban)
칸반(Kanban)영기 김
 
로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법Jeongsang Baek
 
스크럼(Scrum)
스크럼(Scrum)스크럼(Scrum)
스크럼(Scrum)영기 김
 
Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#Yoshifumi Kawai
 
안정적인 서비스 운영 2014.03
안정적인 서비스 운영   2014.03안정적인 서비스 운영   2014.03
안정적인 서비스 운영 2014.03Changyol BAEK
 
Scrum 101
Scrum 101Scrum 101
Scrum 101beLithe
 
협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0Sangcheol Hwang
 
Jira + Confluence + Bitbucket으로 이슈 트래킹 걸음마 떼기
Jira + Confluence + Bitbucket으로 이슈 트래킹 걸음마 떼기Jira + Confluence + Bitbucket으로 이슈 트래킹 걸음마 떼기
Jira + Confluence + Bitbucket으로 이슈 트래킹 걸음마 떼기KyeongmanKang
 
Agile & SCRUM basics
Agile & SCRUM basicsAgile & SCRUM basics
Agile & SCRUM basicsArun R
 
Jira software 8.0 8.5 community presentation
Jira software 8.0 8.5 community presentationJira software 8.0 8.5 community presentation
Jira software 8.0 8.5 community presentationMaitrey Patel
 
애자일 S/W 개발
애자일 S/W 개발애자일 S/W 개발
애자일 S/W 개발영기 김
 
Introduction to JIRA
Introduction to JIRAIntroduction to JIRA
Introduction to JIRAguestb67fcdb
 
PHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったことPHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったことKentaro Matsui
 
Estimation techniques for Scrum Teams
Estimation techniques for Scrum TeamsEstimation techniques for Scrum Teams
Estimation techniques for Scrum TeamsJesus Mendez
 
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장Dylan Ko
 

What's hot (20)

애자일 스크럼과 JIRA
애자일 스크럼과 JIRA 애자일 스크럼과 JIRA
애자일 스크럼과 JIRA
 
칸반(Kanban)
칸반(Kanban)칸반(Kanban)
칸반(Kanban)
 
로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법로그 기깔나게 잘 디자인하는 법
로그 기깔나게 잘 디자인하는 법
 
스크럼(Scrum)
스크럼(Scrum)스크럼(Scrum)
스크럼(Scrum)
 
Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#Building the Game Server both API and Realtime via c#
Building the Game Server both API and Realtime via c#
 
안정적인 서비스 운영 2014.03
안정적인 서비스 운영   2014.03안정적인 서비스 운영   2014.03
안정적인 서비스 운영 2014.03
 
Scrum 101
Scrum 101Scrum 101
Scrum 101
 
협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0협업도구 및 주요 Agile practices 적용사례 v1.0
협업도구 및 주요 Agile practices 적용사례 v1.0
 
Agile
Agile Agile
Agile
 
Jira + Confluence + Bitbucket으로 이슈 트래킹 걸음마 떼기
Jira + Confluence + Bitbucket으로 이슈 트래킹 걸음마 떼기Jira + Confluence + Bitbucket으로 이슈 트래킹 걸음마 떼기
Jira + Confluence + Bitbucket으로 이슈 트래킹 걸음마 떼기
 
Agile & SCRUM basics
Agile & SCRUM basicsAgile & SCRUM basics
Agile & SCRUM basics
 
Jira software 8.0 8.5 community presentation
Jira software 8.0 8.5 community presentationJira software 8.0 8.5 community presentation
Jira software 8.0 8.5 community presentation
 
애자일 S/W 개발
애자일 S/W 개발애자일 S/W 개발
애자일 S/W 개발
 
Agile Metrics 101
Agile Metrics 101Agile Metrics 101
Agile Metrics 101
 
Introduction to JIRA
Introduction to JIRAIntroduction to JIRA
Introduction to JIRA
 
Scrum Guide In One Slide
Scrum Guide In One SlideScrum Guide In One Slide
Scrum Guide In One Slide
 
Scrum and JIRA
Scrum and JIRAScrum and JIRA
Scrum and JIRA
 
PHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったことPHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったこと
 
Estimation techniques for Scrum Teams
Estimation techniques for Scrum TeamsEstimation techniques for Scrum Teams
Estimation techniques for Scrum Teams
 
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장
[우리가 데이터를 쓰는 법] 모바일 게임 로그 데이터 분석 이야기 - 엔터메이트 공신배 팀장
 

Similar to Scrum and kanban with jira

스크럼 101
스크럼 101스크럼 101
스크럼 101Daniel Lim
 
스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발Insub Lee
 
Scrum - Agile Development Process
Scrum - Agile Development ProcessScrum - Agile Development Process
Scrum - Agile Development ProcessKook Maeng
 
Introduction of scrum 안성현 20120606
Introduction of scrum 안성현 20120606Introduction of scrum 안성현 20120606
Introduction of scrum 안성현 20120606SeongHyun Ahn
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스Hee Jae Lee
 
스크럼 리뷰 이지원 발표용
스크럼 리뷰 이지원 발표용스크럼 리뷰 이지원 발표용
스크럼 리뷰 이지원 발표용지원 이
 
언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing software언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing softwareKevin Kim
 
2019 nexters x spoqa
2019 nexters x spoqa2019 nexters x spoqa
2019 nexters x spoqaKimHeamin1
 
애자일 게임 개발: 최전선의 이야기(Gamefest 2006)
애자일 게임 개발: 최전선의 이야기(Gamefest 2006)애자일 게임 개발: 최전선의 이야기(Gamefest 2006)
애자일 게임 개발: 최전선의 이야기(Gamefest 2006)Kay Kim
 
프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험Jihye OK
 
프로젝트 Xxx에 적용하고 싶은 개발방법
프로젝트 Xxx에 적용하고 싶은 개발방법프로젝트 Xxx에 적용하고 싶은 개발방법
프로젝트 Xxx에 적용하고 싶은 개발방법도형 임
 
SWDeveloperStory201501
SWDeveloperStory201501SWDeveloperStory201501
SWDeveloperStory201501Suho Kwon
 
Agile SW 개발
Agile SW 개발Agile SW 개발
Agile SW 개발혁 권
 
Agile의 의미와 Agile 계획 수립(Gdc2007)
Agile의 의미와 Agile 계획 수립(Gdc2007)Agile의 의미와 Agile 계획 수립(Gdc2007)
Agile의 의미와 Agile 계획 수립(Gdc2007)Kay Kim
 
프로덕트 매니지먼트하기
프로덕트 매니지먼트하기프로덕트 매니지먼트하기
프로덕트 매니지먼트하기YOO SE KYUN
 
애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In Th...
애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In Th...애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In Th...
애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In Th...Kay Kim
 
Agile sw development 101
Agile sw development 101Agile sw development 101
Agile sw development 101Kiwon Kyung
 

Similar to Scrum and kanban with jira (20)

스크럼 101
스크럼 101스크럼 101
스크럼 101
 
스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발스크럼을 이용한 게임 개발
스크럼을 이용한 게임 개발
 
Scrum - Agile Development Process
Scrum - Agile Development ProcessScrum - Agile Development Process
Scrum - Agile Development Process
 
Introduction of scrum 안성현 20120606
Introduction of scrum 안성현 20120606Introduction of scrum 안성현 20120606
Introduction of scrum 안성현 20120606
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
 
스크럼 리뷰 이지원 발표용
스크럼 리뷰 이지원 발표용스크럼 리뷰 이지원 발표용
스크럼 리뷰 이지원 발표용
 
개발 관리론
개발 관리론개발 관리론
개발 관리론
 
언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing software언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing software
 
2019 nexters x spoqa
2019 nexters x spoqa2019 nexters x spoqa
2019 nexters x spoqa
 
Work With Engineer
Work With EngineerWork With Engineer
Work With Engineer
 
애자일 게임 개발: 최전선의 이야기(Gamefest 2006)
애자일 게임 개발: 최전선의 이야기(Gamefest 2006)애자일 게임 개발: 최전선의 이야기(Gamefest 2006)
애자일 게임 개발: 최전선의 이야기(Gamefest 2006)
 
프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험
 
프로젝트 Xxx에 적용하고 싶은 개발방법
프로젝트 Xxx에 적용하고 싶은 개발방법프로젝트 Xxx에 적용하고 싶은 개발방법
프로젝트 Xxx에 적용하고 싶은 개발방법
 
SWDeveloperStory201501
SWDeveloperStory201501SWDeveloperStory201501
SWDeveloperStory201501
 
Agile SW 개발
Agile SW 개발Agile SW 개발
Agile SW 개발
 
Agile의 의미와 Agile 계획 수립(Gdc2007)
Agile의 의미와 Agile 계획 수립(Gdc2007)Agile의 의미와 Agile 계획 수립(Gdc2007)
Agile의 의미와 Agile 계획 수립(Gdc2007)
 
프로덕트 매니지먼트하기
프로덕트 매니지먼트하기프로덕트 매니지먼트하기
프로덕트 매니지먼트하기
 
애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In Th...
애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In Th...애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In Th...
애자일 게임 개발: 현실 세계의 혼돈을 다루는 법 (Agile Game Development: Dealing With Chaos In Th...
 
Sprint & Jira
Sprint & JiraSprint & Jira
Sprint & Jira
 
Agile sw development 101
Agile sw development 101Agile sw development 101
Agile sw development 101
 

Scrum and kanban with jira

  • 1. SCRUM & KANBAN with JIRA JIRA 를 이용한 스크럼, 칸반 적용 안내
  • 3. 세미나 목표 스크럼과 칸반에 대해 이해해 봅시다. JIRA를 이용해서 스크럼과 칸반을 적용하는 방법을 배워봅시다. 간단한 JIRA 팁, 개발도구들과의 연동 기능에 대해 알아봅시다.
  • 4. 목차 • Overview • Scrum • Scrum w/ JIRA • Break • Kanban • Kanban w/ JIRA • Conclusion
  • 7. WATERFALL 분석 설계 구현 테스트 유지 보수 - 전통적인 S/W 개발 방법론 - Sequential Development Process
  • 9. 아직 기획이 안끝나서 
 개발을 못하고 있어요. 아니, 이제와서 이걸 이렇게 바꾸면 
 어쩌자는 겁니까? 샵검색을 말씀드린건데 삽을 검색하시면... 음... 이상하네요.
 제 컴퓨터에서는 잘 되는데.. 또 변경될텐데 
 대충 돌아가게만 만들지 뭐... 아직 안 끝났어? 네 아직이요. 언제 끝나는데? 곧 끝날것 같아요.
  • 12. AGILE
  • 13. 애자일 소프트웨어 개발 선언문 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 
 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다. 
 공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를
 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
  • 20. INTERNAL FEEDBACK LOOP EXTERNAL FEEDBACK LOOP - Pair Programming - TDD - Peer Review - Continuous Integration - Daily Stand-up Meeting - Iteration Review/Retro - Iteration planning - Release planning
  • 21. SCRUM OVERVIEW PROCESS DO SCRUM RIGHT HELPS & HURDLES SCRUM WITH JIRA
  • 23. 스크럼의 정의 가장 가치 있는 제품을 생산적이고 창의적으로 배포하기 위하여 복잡하게 얽힌 적응적 문제들 (complex adaptive problems)을 다룰 수 있도록 하는 프레임워크 
 간단하고 이해하기 쉽지만, 마스터하기는 어려운 프레임워크 입니다.
 ref. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf
  • 24. 스크럼 이론#1 스크럼은 경험적 프로세스 관리 이론, 혹은 경험주의 (empiricism) 이론에 기반하고 있습니다. ref. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf 반복 Iterative 점진 Incremental 예측을 최적화 하고, 위험 요소를 관리하기 위해 반복적이고, 점진적인 접근방법을 취합니다.
  • 25. 스크럼 이론#2 경험적 프로세스 관리를 수행하는 데 필요한 세 가지 축 ref. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf 투명성 Transparency 검토 Inspection 적응 Adaptation
  • 27.
  • 28. 3 ROLEs 4 EVENTs 3 ARTIFACTs Product Owner Scrum Master Team Product Owner Sprint Review Sprint Retros. Estimation Sprint Planning
  • 30. 스프린트#0 - 조직내 공감대 형성 - 전체 주요 기능 목록 도출(Product Backlog) - 릴리스 플래닝(로드맵) - 주요 마일스톤, QA, CBT, 출시일 등 - 이터레이션 플래닝 - 스프린트 길이는? - 스크럼 이벤트 - 일일 스크럼, 플래닝, 리뷰, 회고는 언제? - 추정 및 추정 단위는? - 스크럼 보드 설계 - 정책 명시화 - 스크럼 진행 방식, DOD(Definition of Done, 완료 정의)
  • 31. SCRUM EVENT 스프린트 계획(SPRINT PLANNING) 일일 스탠드업(DAILY SCRUM) 스프린트 리뷰(SPRINT REVIEW) 스프린트 회고(SPRINT RETROSPECTIVE) 커뮤니케이션은 어떤 프로젝트에서든 성공의 열쇠가 됩니다. 스크럼팀은 네 가지 주요 미팅을 통해 팀 업무를 체계화합니다. 각 미팅을 통해 팀은 팀으로서 계획하고, 인도(Delivery)하고 배웁니다.
  • 32. Do - 한 날에 미팅이 여러 건 예정된 경우 미팅을 몰아서 진행합니다. - 정말 필요한 경우를 제외하고는 회의 참석자는 최소 한으로 합니다. - 스크럼 미팅은 정기적으로 진행합니다. - 각 미팅은 미팅의 목적에 벗어나지 않도록 합니다. Do Not - 미팅이 하루 종일 흩어져 있어 사이사이 프로젝트 작 업 시간이 30-60분 밖에 안 됩니다. - 의사결정에 크게 필요치 않은 사람들까지도 단순히 정보를 얻기 위한 목적으로 참석을 요구 받습니다. - 필요에 따라 또는 불규칙하게 미팅이 열립니다.
  • 33. PRODUCT BACKLOG 제품 백로그는 제품의 가능한 모든 요구사항에 대한 우선 순위화된 목록입니다. 또한 제품 백로그는 제품에 대한 모든 변경 요구사항을 포함하는 단 하나의 소스입니다. 제품 책임자가 제품 백로그 (내용, 가용성, 우선순위화 등) 에 대한 책임을 가지고 있습니다. 제품 백로그는 요구사항에 대한 완성본이 아닙니다.
  • 34. Do - 제품 백로그는 모든 프로젝트 멤버, 이해관계자가 쉽 게 확인할 수 있도록 가시화 합니다. - 필요에 따라 백로그들을 구조화 하도록 합니다. - 백로그별로 상대적인 우선 순위에 따라 정렬하도록 합니다. - 새로운 백로그가 추가되거나, 새로운 상황이 발생한 경우 우선순위를 재조정 합니다. - 팀의 모든 작업을 백로그에 포함하도록 합니다. - 고객에게 보여지는 기능 뿐만 아니라 내부적인 작업들 또한 백로그 로 도출합니다. Do Not - 백로그가 프로젝트 시작시에만 우선순위를 설정하 고, 프로젝트 진행중에는 조정되지 않습니다. - 백로그 항목이 제품 기능으로만 구성되어 있습니다. - 백로그 목록은 한번 작성된 이후 업데이트 되지 않습 니다.
  • 35. SPRINT PLANNING 스프린트에서 수행되어야 할 작업들을 스프린트 계획 미팅에서 정합니다. 이 계획은 전체 스크럼 팀의 공동 작업으로 만들어집니다. 백로그 선정 > 백로그 구체화 추정 > 범 위& 담당자 선 > > 스 프린트 백로그 확
  • 36. Do - 미팅전 필요한 정보를 수집합니다. - 제품 백로그, 가장 최근의 제품 증분, 스프린트 동안의 개발팀 가 용 인력 예상, 개발팀의 과거 생산성 자료 - 아래 두가지 질문에 대한 답을 정합니다. - 이번 스프린트에서 무엇을 할 수 있는가? (Product Backlog) - 선택된 작업들을 어떻게 완료하나? (Sprint Backlog) - *Sprint Goal 을 정하도록 합니다. - 추정을 통해 스프린트 백로그들의 크기를 예측하 고, 스프린트에서 진행할 작업량을 결정합니다. - 진행할 작업량에 대한 결정은 개발팀이 합니다. - 같은 언어, DOD(Definition of Done, 완료 정의) Do Not - 제품 책임자 또는 개발리더가 임의로 작업할 백로그 를 선정하고 개발팀에 할당합니다. - 추정 작업시에 제품 책임자 또는 개발리더 임의로 작 업의 크기를 선정합니다. - 스프린트에 끝낼수 없는 크기의 작업을 선정합니다. - 미팅 시간 제한없이 끝장토론으로 플래닝, 추정을 진 행합니다. *Sprint Goal : 제품 백로그를 구현함으로써 스프린트 동안 달성하고자 하는 목표, 스프린트를 왜 진행하는지에 대한 가이드.
  • 38. … 아직 안 끝났어요? 네 아직이요... 언제 끝나는데요? 음... 곧?
  • 39. 지금 하는거 말고 이것 먼저 해줘요. 그 작업은 플래닝때 없었던 항목인데요? 그건 아는데 이게 더 중요해요. …
  • 40. … 지금 개발중인거 이렇 게 바꿔야 해요. 한참 개발중인데요? 그건 아는데 그래도 바꿔줘 요. 네… 저번에 그거 다시 원래 대로 하죠. 뚝딱뚝딱...
  • 41. ON SPRINT 개발팀은 스프린트 동안에 하기로 한 작업들을 완료할 수 있도록 최선을 다합니다. 스프린트 동안에는 개발팀은 스펙의 변경, 외부 요인 으로 인한 방해를 받아서는 안됩니다. 그리고 일일스크럼을 통해 스프린트를 점검하도록 합니다.
  • 42. 진행 상황 추적 - 진행 상황을 공유하면 프로젝트 진행상황이 투명해 지고 명확해집니다. - 누구나 쉽게 진행 상황을 확인할 수 있도록 가시화 함으로 인해 불필요한 커뮤니케이션 비용을 줄일수 있습니다. - 목표한 작업들을 스프린트내에 완료할 수 있을지에 대한 예측을 가능하게 합니다. - 스프린트를 거듭할수록 더욱 정밀해집니다.
  • 43. Do - 스프린트 길이를 가능한 짧게 유지합니다. - 스프린트 길이를 늘 같게 유지합니다. - 팀이 회복 불가능할 정도로 논점을 벗어나면 스프린 트를 중단합니다. - 잠시 시간을 갖고 어디서부터 잘못 됐는지 파악해 다시 시작합니 다. - 작업 보드나 번다운 차트등의 도구를 활용합니다. - 작업 보드는 항상 실제 작업과 동기화 하도록 합니다. - 점수나 완료된 항목으로 팀을 서로 비교하지 못하게 합니다. 누구나 속도가 다르기 마련입니다. Do Not - 원래 약속한 업무가 끝날 때까지 스프린트가 늘어집 니다. - PO가 팀의 스프린트 우선순위를 스프린트 도중에 계속해서 바꿉니다. - PO가 스프린트 도중에 새로운 백로그를 추가하거나 기존 백로그를 제거합니다. - 스프린트 백로그에 포함되지 않은 작업을 진행합니 다. - 스프린트가 끝나가면 작업 보드를 일괄 갱신합니다.
  • 44. DAILY SCRUM 일일 스크럼은 개발팀이 각자 수행한 작업들을 확인한 후 조율하고, 다음 24 시간 동안 해야 할 작업들의 계획을 하는 15 분 타임박스 미팅입니다. 나는 어제 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 했는지? 나는 오늘 하루 동안 개발팀의 스프린트 목표 달성을 위해 무엇을 할 것인지? 나 혹은 개발팀이 스프린트 목표 달성을 하는데 방해요소가 있는지 ?
  • 45. Do - 모든 개발팀 멤버가 참여하도록 합니다. - 스크럼 마스터는 미팅의 방향이 다른곳으로 가지 않 도록 조율합니다. - 참석자들은 일관된 패턴으로 현황을 공유합니다. - 어제 뭐했고, 오늘 뭐할거고, 어떤 문제가 있어. - 미팅의 복잡도를 줄이기 위해 같은 장소, 같은 시간 에 진행합니다. - 추가적인 논의가 필요한 경우 후속 미팅을 따로 진행 하도록 합니다. Do Not - 발생한 문제에 대한 해결을 위한 토론을 하느라 30 분 1시간씩 진행합니다. - 하고 있는 일에 대해서만 보고 형태로 공유를 하고, 장애물에 대해서는 공유하지 않습니다. - 스크럼팀 멤버가 아닌 사람이 스프린트 진행과 관계 없는 공지나 다른 목적으로 미팅을 진행하기도 합니 다.
  • 46. SPRINT REVIEW 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의입니다. 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백을 받습니다. 스프린트 리뷰의 결과는 다음 스프린트의 계획을 위한 기반 자료가 됩니다.
  • 47. Do - 제품 책임자가 완료된 백로그, 완료되지 않은 백로그 에 대해 설명합니다. - 개발팀은 완료된 백로그를 시연(DEMO) 합니다. - 전체 그룹이 다음에 무엇을 할지 함께 의논하여 스프 린트 리뷰 미팅이 다음 스프린트 계획에 가치있는 조 언을 제공합니다. - 제품 책임자는 현재 남아있는 제품 백로그를 설명하 고, (필요하다면) 현재까지의 진행상황을 바탕으로 언제쯤 프로젝트가 완료될지 공유합니다. - 남아있는 백로그의 크기, 팀의 속도(스프린트)를 기반으로 예측 Do Not - 경과 보고를 위한 공식 미팅이 아닙니다. - 완료된 제품 증분을 발표함으로 피드백을 얻고, 서로간의 협력을 촉진하기 위한 미팅입니다. - 리뷰 미팅 직전에 작업의 상태를 In-Progress 에서 Done으로 변경합니다. - 완료에 대한 기준이 달라 개발자가 완료했음에도 시 연이 불가능한 경우가 있습니다. - 추정에 맞추기 위해 완료되지 않은 작업도 완료로 처 리합니다.
  • 48. RETROSPECTIVE 스프린트 회고 미팅은 스크럼 팀이 스스로를 되돌아보고, 다음 스프린트 동안 무엇을 개선할 수 있을지 계획할 수 있는 기회를 제공합니다. 지난 스프린트가 사람, 상호관계, 프로세스, 도구 측면에서 어떻게 진행되었는지 검토합니 다. 잘 된 것들 그리고 개선의 여지가 있는 주요 항목들을 알아내고 순위화합니다. 스크럼 팀이 작업을 수행하는 방법에 대한 개선을 실천할 수 있도록 계획을 수립합니다.
  • 49. Do - 항상 지금보다 더 잘 할수 있다는 마음가짐을 갖습니 다. - 모든 스크럼팀 멤버가 참여하도록 합니다. - 스프린트 리뷰 미팅 이후 정기적으로 진행합니다. - 회고 미팅후에 스크럼팀은 다음 스프린트에서 실천 할 개선 사항들을 확인할 수 있어야 합니다. - 액션 아이템 도출 Do Not - 잘잘못을 따지는 자리가 아닙니다. - 문제점만 확인하고 이를 개선하기 위한 계획, 행동을 하지 않습니다.
  • 51. PRODUCT BACKLOG 프로젝트 초기에 한번 만들어지고 위키, 아지트 어딘가에 머물러 있는 기획서가 아니라 프로젝트 진행 기간 동안 살아 숨쉬는(?) 백로그를 소유하게 됩니다.
  • 52. SPRINT PLANNING 큰 작업을 작게 나누고, 각각의 작업은 그 크기를 산정합니다. 반복된 스프린트를 통해 팀의 속도를 알 수 있습니다. 개발팀은 반복주기 동안 몰입할 수 있는 업무의 양을 직접 선정할 수 있습니다. 이로 인해 정밀한 일정 예측이 가능해집니다.
  • 53. ON SPRINT 스프린트 기간동안 방해받지 않고 스프린트 목표를 위해 전력 질주 할 수 있습니다.
  • 54. DAILY SCRUM 매일 매일 진행상황을 공유합니다. 장애물 또한 즉각 확인하고 대처할 수 있게 됩니다.
  • 55. BOARD BUNRDOWN CHART 스크럼팀 구성원 모두가 프로젝트의 진행상황을 쉽게 이해하게 됩니다. 잘 진행되고 있는지, 장애물을 만나 멈춰 있는지 투명하게 드러납니다.
  • 56. SPRINT REVIEW 매 주기(스프린트)별로 우리가 완성한 결과물을 확인할 수 있습니다. 결과물을 토대로 다음 나아갈 방향을 결정할 수 있습니다. 리뷰 후 진행되는 기획의 변경이 자연스러운 활동이 됩니다.
  • 57. SPRINT RETROSPECTIVE 회고를 통해 더 잘할 수 있는 방법은 없는지 고민하게 합니다. 모든 스크럼팀 구성원 스스로...
  • 58. 단! Do Scrum Right 일 경우
  • 60. 장애물 어렵습니다! - 기획자, 개발자, 테스터 각자의 언어로 백로그를 관리합 니다. - 백로그를 쪼개고, 그룹화 하고, 실제 작업과 일치시키는 작업이 어렵습니다. - 추정은 아무리 해도 매번 틀립니다. 왜 해야하는지 의문 의 듭니다. - 일일 스크럼은 일일 보고처럼 느껴집니다. - 스프린트 도중에 계획되지 않은 업무들이 쏟아지거나, 진행중인 작업의 기획이 변경되어 버립니다. - 스프린트가 일주일인데 플래닝, 리뷰, 회고, 부가적인 회 의를 하다보면 정작 일할 시간이 없습니다. - 몇번의 스프린트만으로는 Inspect&Adapt 가 잘 동작하 지 않습니다.
  • 65. 유형별 구분 - Story - New Feature - Task - Bug - Improvement - … 이슈 타입
  • 66. 상하 관계 에픽(Epic) 오직 하나의 상위 관계만 맺을수 있음. 이슈(Issue) 서브태스크(Sub-task)
  • 68. 연결 관계 이슈 링크(ISSUE LINK) 이슈간 연결 관계를 설정할 수 있음. - blocks - is blocked by - relates to - duplicates - has to be done before - has to be done after
  • 69. 1. 프로젝트 및 스크럼 보드 생성
  • 70. 프로젝트 생성 Service Desk > Create Service Desk Request
  • 73. 백로그 생성 이슈 생성 단축키 : c 단축키 : 1
  • 84. 담당자 지정 담당자 지정 단축키 : a 나를 담당자로 지정 단축키: i
  • 88. 스프린트 백로그 추가 이슈 생성후 백로그 화면에서 스프린트 매핑
  • 89. 추정치 변경 이슈 편집화면에서 수정가능 이슈 편집 단축키 : e
  • 92. 스프린트 리포트 번다운 차트 완료된 백로그 완료되지 않은 백로그
  • 94. 회고 미팅 노트 스프린트 - 위키 회고 미팅 노트 페이지 연동
  • 97. BURNDOWN CHART - 모든 백로그를 완료하지 못함 - 팀의 능력보다 많은 백로그를 선택했거나 - 추정을 타이트하게 했거나 - 예상치 못한 이슈가 발생했거나 - 스프린트 기간보다 짧은 시간에 모두 완료 - 팀의 능력보다 적은 백로그를 선택했거나 - 추정을 넉넉하게 했거나 - 인센티브가 나왔거나(?) - 이상적인 가이드 라인
  • 98. 기타 리포트 에픽 리포트 버전 리포트 에픽 번다운 릴리스 번다운 컨트롤 차트 벨로시티 차트 누적흐름도(CFD)
  • 101. GENERAL - 보드 이름 - 보드 관리자 - 보드에 노출시킬 이슈 필터 - 보드 공유 설정
  • 102. WORKFLOW - 워크플로우 조정 - 컬럼, 상태 관리
  • 103. SWIMLANE - 커스텀 쿼리(사용자 커스텀) - 담당자별(PRE DEFINED) - 에픽별별(PRE DEFINED) - 스토리별(PRE DEFINED) - NO SWIMLANE 이슈를 횡으로 그룹화
  • 104. QUICK FILTER 추가적인 JQL 을 통해 보드에 노출되는 이슈를 필터링 JQL : JIRA QUERY LANGUAGE
  • 105. CARD COLOR 카드컬러 - 이슈 타입별 - 우선순위별 - 담당자별 - 커스텀 쿼리 - NONE
  • 106. CARD LAYOUT 기본 카드 레이아웃 - 이슈번호 - 이슈타입 아이콘 - 우선순위 아이콘 - 담당자 프로필 이미지 - 스토리포인트 - 에픽 추가 필드 설정된 카드
  • 107. ESTIMATION - 추정 필드 설정 - 타임 트래킹 방식 설정
  • 108. WORKING DAYS 리포트, 통계정보에서 제외할 작업일 설정
  • 109. ISSUE DETAIL VIEW 보드에서 이슈 선택시 우측 이슈 상세 화면 레이아웃 설정
  • 111.
  • 112.
  • 114. JIRA 단축키 ? = shift + /
  • 116.
  • 117.
  • 118.
  • 119.
  • 121. Agile card for JIRA • JIRA 이슈를 프린트해서 오프라인 보드구성 • 오프라인 보드와 지라 보드 동기화를 QR코드 인식으로 통해 간단하게 • https://marketplace.atlassian.com/plugins/ com.spartez.scrumprint.scrumplugin/server/overview
  • 122. Agile poker for JIRA • JIRA Scrum planning 에서 사용가능한 플래닝포커 플러그인 • https://marketplace.atlassian.com/plugins/ com.spartez.jira.plugins.jiraplanningpoker/server/overview
  • 123. Q&A
  • 124. Break
  • 125. KANBAN OVERVIEW PROCESS BASIC PRINCIPLE & CORE PRACTICE DO KANBAN RIGHT HELPS & HURDLES KANBAN WITH JIRA
  • 127. 칸반, 칸반 시스템 도요타 생산 시스템(TPS)의 서브 시스템중 하나이다. 칸반은 신호 카드를 의미한다. TPS의 기본적인 사고는 Just In Time, 생산 자동화에 기반하고 있다.
  • 128. 칸반의 정의 칸반은 점진적으로 서비스 출시를 개선하기 위한 관리 방법이다. ref. http://djaa.com/kanban-framework 소프트웨어 개발이나 프로젝트 관리 또는 IT 운영에서 사용하는 프로세스나 프레임워크가 아니다. 칸반은 “프레임워크(framework)”가 아니라 “방법(method)” 단지 작업 보드를 사용한다고 해서 칸반을 하는것은 아니다.
  • 130. 당김 방식 “Benedict, 다음에는 샵검색 개발해주세요.” 가 아니라, “오픈 채팅 개발이 끝났으니, 샵검색은 제가 개발할게요”
  • 131. LIMIT WIP 대기 행렬 이론, 리틀의 법칙 WIP = Th * CT - WIP(진행 중 업무) = 개발 시스템에서 완료되지 않은 항목의 평균량 - Th(처리량) = 단위 시간 동안 팀의 출력 - CT(사이클 타임) = 팀이 한 항목을 마치는 데 걸리는 평균 시간 처리량을 늘리려면? Th = WIP / CT ‘일정 시스템에 오랜 시간 동안 머물러 있는 고객의 평균적인 수치(WIP)는 오랜 시간 동안에 걸친 평균 실제 도착율(Th)과 시스템에서 고객이 머문 평균 시간(CT)을 곱한 값과 동일하다’
  • 133. LIMIT WIP 처리량과 WIP 관계 WIP 증가에 대한 팀의 반응 한계점까지는 처리량이 증가하다가 그 이후에는 오히려 감소합니다. WIP가 늘어나면 팀이 최대 가용 처리량에 도달하기 전까지 업무를 최적화하고 출시 프로세스의 낭비를 제거하게 만들 수 있습니다. 그 이후에도 WIP가 계속 늘어난다면 더 이상의 개선이 이루어지긴 어렵습니다. 오히려 스트레스와 작업 전환으로 인해 팀의 처리량이 감소합니다.
  • 134.
  • 136. 칸반에는 프로세스가 없습니다. 칸반은 프로세스 또는 프로젝트 관리 방법이 아니라 기존 프로세스를 더 나은 방법으로 개선하도록 도와주는 관리 방법이다.
  • 138. 어떤 상황이라도, 지금 바로 시작할 수 있다. 점진적인 변화 방식을 지향한다. 처음에는 기존의 역할, 책임, 직함을 존중한다.
  • 139. 칸반에 대한 오해 스크럼은 개발 프로젝트에 적합하고, 칸반은 운영에만 적합하다. 칸반은 개발, 운영, 작업관리 등 어떤 방식의 업무에도 적용할 수 있는 방법이다.
  • 141. VISUALIZE 현재의 업무 흐름을 시각화 하도록 합니다. 업무가 어디에서 시작되어 어떻게 흘러가는지를 나타내도록 합니다. 현재 하고 있는 업무가 업무흐름에 나타나야 합니다.
  • 142. LIMIT WIP 진행중인 업무의 양을 제한합니다. WIP 제한에 결린 경우 기존 작업이 빠지기 전에는 새로운 작업을 당겨 올 수 없습니다. WIP의 양을 제한하면 칸반팀은 누구도 작업 부담의 심한 압력을 받지 않고 자신의 일정한 흐름을 유지할 수 있습니다
  • 143. MANAGE FLOW 흐름을 관리합니다. 업무가 흘러가는 과정을 항상 관찰하도록 합니다. 어느 지점에 병목이 있는지, 어떤 작업이 특정 상태에 오랫동안 머물러 있는지 바로바로 확인하고 해결하도록 합니다. 업무 흐름이 막힘없이 일정한 속도로 흘러가도록 해야합니다.
  • 144. MAKE POLICIES EXPLICIT 정책을 명시화 합니다. 정책이 명시적이지 않으면 개선 논의가 어렵습니다. 업무 진행 방식, DOD, 백로그 관리, 우선 순위 관리등의 정책들을 명시화 하도록 합니다.
  • 145. IMPROVE COLLABORATIVELY 협업을 개선하도록 합니다. 칸반은 칸반팀 누구나 받아들일수 있는 지속적이고 점진적인 변화를 추구합니다. 모든 칸반팀원이 업무 흐름, 위험 요소 등을 이해한다면, 쉽게 개선하고 합의에 이를수 있습니다.
  • 146. IMPLEMENT FEEDBACK LOOP 피드백 루프를 실행하도록 합니다. 스크럼의 Daily Scrum, Sprint Review, Retrospective 를 칸반에서도 실행할 수 있습니다. 스크럼과 다른점은 칸반 일일 스탠드업 - 사람이 기준이 아니라 작업이 기준입니다. 리뷰, 회고 - 각각 별개의 리듬(Cadence)으로 진행할 수 있습니다.
  • 148. FLOW & PULL 흐름을 최적화 할수록 사이클타임이 짧아지고 처리량이 증가합니다. 흐름 최적화를 위해 칸반은 당김(Pull)방식을 지향하고 있습니다.
  • 149. Do - 업무 흐름의 단계별로 고유한 기능을 갖도록 합니다. - 각 단계별로 역할에 따라 소유열을 구분하도록 합니 다. - WIP 수용량에 여유가 있을때에만 신규 작업을 수락 합니다. - 병목지점을 찾아내서 함께 빠르게 해결합니다. - 팀이 자발적으로 업무를 당겨올수 있도록 권한을 부 여합니다. - 우선 순위 관리 정책을 명시합니다. - 작업을 당겨올때 가장 우선적으로 처리해야할 작업을 선택하도록 Do Not - 작업의 크기가 너무 커서 특정 상태에 너무 오래 머 물러 있습니다. - 작업을 당겨오는것이 아니라 밀어넣습니다. - 작업 흐름에 포함되어 있지 않은 작업 단계가 있습니 다.
  • 150. WIP WIP 제한은 지나치게 여유가 있거나, 병목이 있는 흐름단계를 드러내게 합니다. 실시간으로 이런 단계를 파악할 수 있게 되므로 상황이 악화되기 전에 빠르게 문제를 해결할 수 있습니다.
  • 151. Do - 작업 항목을 가능한 작고 관리 가능한 규모로 쪼갭니 다. - 팀의 최적 WIP 제한 수치를 찾기위해 주기적으로 변 화를 시도합니다. - 단, 피드백을 얻을수 있을 만큼은 해봐야합니다. - 분야별로 작업 흐름의 단계를 구분하도록 합니다. Do Not - WIP 제한이 절대 바뀌지 않습니다. - 필요할 때마다 WIP 제한을 늘립니다. - 병목지점이나 문제점에 대해 함께 해결하기 보다 새 로운 작업을 끌어오기만 합니다. - 병목지점, 문제점을 근본적으로 개선하는것보다 인 력과 시간만을 더 투입하려고 합니다.
  • 153. 좋은점 - 쉽습니다. - 스크럼의 좋은점들이 칸반에서도 가능해집니다. - 스크럼의 어려운점들을 칸반은 해결해줍니다. - 스크럼보다 더욱 기민하게 대응할 수 있습니다. 장애물 - 스크럼과 마찬가지로 경험주의 이론에 기반을 두고 있기에 단기간에 개선이 이루어지지는 않습니다. - 스크럼보다 더 간단하지만, 칸반 역시 핵심 이론인 ‘당 김방식’, ‘WIP 제한’ 에 대한 충분한 이해가 필요합니 다.
  • 155. 칸반 보드는 백로그 메뉴가 없습니다. 보드 제일 우측열에 Release 링크가 있습니다.
 제일 우측열 이슈들을 특정 버전으로 릴리스 하는 기능 나머지는 다 똑같아요
  • 157. WIP LIMIT 설정 WIP 제한 - 이슈 갯수 - 서브 태스크를 제외한 이슈갯수 - MIN WIP, MAX WIP
  • 158. WIP LIMIT 설정 제한 초과일 경우 빨간색으로 표시
  • 160. 카드 하단 점의 갯수!!
  • 162. Done 열의 이슈에 버전을 할당한 후 릴리스 합니다. 보드에서 슝~
  • 164. 뉴호라이즌스 with 워터폴 뉴호라이즌스 with 스크럼 뉴호라이즌스 with 칸반
  • 165. 더 나아지고 싶으신가요? 어떤것도 하고 있지 않으신가요? 안녕히 가세요. 칸반을 시도해보세요. 스크럼이 잘 안되시나요? 스크럼 계속 잘 해나가면 됩니다.
  • 166. 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
  • 167. Q&A