Scrum and kanban with jira

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

    -
  • Category

    Software

  • view

    1.456
  • download

    1

Transcript of Scrum and kanban with jira

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

카카오�>�플랫폼기술팀�

Benedict(이호정)

세미나�목표

스크럼과�칸반에�대해�이해해�봅시다.�

JIRA를�이용해서�스크럼과�칸반을�적용하는�방법을�배워봅시다.�

간단한�JIRA�팁,�개발도구들과의�연동�기능에�대해�알아봅시다.

목차

• Overview�

• Scrum�

• Scrum�w/�JIRA�

• Break�

• Kanban�

• Kanban�w/�JIRA�

• Conclusion

OVERVIEWS/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�

SCRUMOVERVIEW�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

KANBANOVERVIEW�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

감사합니다.�:)