세미나�목표
스크럼과�칸반에�대해�이해해�봅시다.�
JIRA를�이용해서�스크럼과�칸반을�적용하는�방법을�배워봅시다.�
간단한�JIRA�팁,�개발도구들과의�연동�기능에�대해�알아봅시다.
아직�기획이�안끝나서�개발을�못하고�있어요. 아니,�이제와서�이걸�이렇게�바꾸면�
어쩌자는�겁니까?
샵검색을�말씀드린건데�삽을�검색하시면...
음...�이상하네요.제�컴퓨터에서는�잘�되는데..
또�변경될텐데�대충�돌아가게만�만들지�뭐... 아직�안�끝났어?��
네�아직이요.��언제�끝나는데?��
곧�끝날것�같아요.
애자일�소프트웨어�개발�선언문
우리는�소프트웨어를�개발하고,�또�다른�사람의�개발을�도와주면서�소프트웨어�개발의�더�나은�방법들을�찾아가고�있다.�
이�작업을�통해�우리는�다음을�가치�있게�여기게�되었다.
공정과�도구보다�개인과�상호작용을�
포괄적인�문서보다�작동하는�소프트웨어를�
계약�협상보다�고객과의�협력을�
계획을�따르기보다�변화에�대응하기를
가치�있게�여긴다.�이�말은,�왼쪽에�있는�것들도�가치가�있지만,�우리는�오른쪽에�있는�것들에�더�높은�가치를�둔다는�것이다.
ref.�https://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf
ref.�https://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf
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�
스크럼의�정의
가장�가치�있는�제품을�생산적이고�창의적으로�배포하기�위하여��복잡하게�얽힌�적응적�문제들�(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
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
큰�작업을�작게�나누고,�각각의�작업은�그�크기를�산정합니다.�
반복된�스프린트를�통해�팀의�속도를�알�수�있습니다.�
개발팀은�반복주기�동안�몰입할�수�있는�업무의�양을�직접�선정할�수�있습니다.�
이로�인해�정밀한�일정�예측이�가능해집니다.
SPRINT�REVIEW
매�주기(스프린트)별로�우리가�완성한�결과물을�확인할�수�있습니다.�
결과물을�토대로�다음�나아갈�방향을�결정할�수�있습니다.�
리뷰�후�진행되는�기획의�변경이�자연스러운�활동이�됩니다.
장애물
어렵습니다!
- 기획자,�개발자,�테스터�각자의�언어로�백로그를�관리합니다.�
- 백로그를�쪼개고,�그룹화�하고,�실제�작업과�일치시키는�작업이�어렵습니다.�
- 추정은�아무리�해도�매번�틀립니다.�왜�해야하는지�의문의�듭니다.�
- 일일�스크럼은�일일�보고처럼�느껴집니다.�
- 스프린트�도중에�계획되지�않은�업무들이�쏟아지거나,�진행중인�작업의�기획이�변경되어�버립니다.�
- 스프린트가�일주일인데�플래닝,�리뷰,�회고,�부가적인�회의를�하다보면�정작�일할�시간이�없습니다.�
- 몇번의�스프린트만으로는�Inspect&Adapt�가�잘�동작하지�않습니다.
SCRUM JIRA
PRODUCT�
^�
VERSIONS�
^�
SPRINTS�
^�
BACKLOGS
PROJECT�
^�
VERSIONS�
^�
SPRINTS�
^�
ISSUES�
연결�관계
이슈�링크(ISSUE�LINK)�이슈간�연결�관계를�설정할�수�있음.�
- blocks�
- is�blocked�by�
- relates�to�
- duplicates�
- has�to�be�done�before�
- has�to�be�done�after
BURNDOWN�CHART
- 모든�백로그를�완료하지�못함�- 팀의�능력보다�많은�백로그를�선택했거나�- 추정을�타이트하게�했거나�- 예상치�못한�이슈가�발생했거나
- 스프린트�기간보다�짧은�시간에�모두�완료�- 팀의�능력보다�적은�백로그를�선택했거나�- 추정을�넉넉하게�했거나�- 인센티브가�나왔거나(?)
- 이상적인�가이드�라인
SWIMLANE
- 커스텀�쿼리(사용자�커스텀)�- 담당자별(PRE�DEFINED)�- 에픽별별(PRE�DEFINED)�- 스토리별(PRE�DEFINED)�- NO�SWIMLANE
이슈를�횡으로�그룹화
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
KANBANOVERVIEW�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)”�
단지�작업�보드를�사용한다고�해서�칸반을�하는것은�아니다.�
LIMIT�WIP
대기�행렬�이론,�리틀의�법칙
WIP�=�Th�*�CT�
- WIP(진행�중�업무)�=�개발�시스템에서�완료되지�않은�항목의�평균량�
- Th(처리량)�=�단위�시간�동안�팀의�출력�
- CT(사이클�타임)�=�팀이�한�항목을�마치는�데�걸리는�평균�시간
처리량을��늘리려면? Th�=�WIP�/�CT
�‘일정�시스템에�오랜�시간�동안�머물러�있는�고객의�평균적인�수치(WIP)는��오랜�시간�동안에�걸친�평균�실제�도착율(Th)과��
시스템에서�고객이�머문�평균�시간(CT)을�곱한�값과�동일하다’�
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)으로�진행할�수�있습니다.�
Do
- 업무�흐름의�단계별로�고유한�기능을�갖도록�합니다.�
- 각�단계별로�역할에�따라�소유열을�구분하도록�합니다.�
- WIP�수용량에�여유가�있을때에만�신규�작업을�수락합니다.�
- 병목지점을�찾아내서�함께�빠르게�해결합니다.�
- 팀이�자발적으로�업무를�당겨올수�있도록�권한을�부여합니다.�
- 우선�순위�관리�정책을�명시합니다.�
- 작업을�당겨올때�가장�우선적으로�처리해야할�작업을�선택하도록�
Do�Not
- 작업의�크기가�너무�커서�특정�상태에�너무�오래�머물러�있습니다.�
- 작업을�당겨오는것이�아니라�밀어넣습니다.�
- 작업�흐름에�포함되어�있지�않은�작업�단계가�있습니다.
WIP
WIP�제한은�지나치게�여유가�있거나,�병목이�있는�흐름단계를�드러내게�합니다.�
실시간으로�이런�단계를�파악할�수�있게�되므로��
상황이�악화되기�전에�빠르게�문제를�해결할�수�있습니다.�
Do
- 작업�항목을�가능한�작고�관리�가능한�규모로�쪼갭니다.�
- 팀의�최적�WIP�제한�수치를�찾기위해�주기적으로�변화를�시도합니다.�
- 단,�피드백을�얻을수�있을�만큼은�해봐야합니다.�
- 분야별로�작업�흐름의�단계를�구분하도록�합니다.
Do�Not
- WIP�제한이�절대�바뀌지�않습니다.�
- 필요할�때마다�WIP�제한을�늘립니다.�
- 병목지점이나�문제점에�대해�함께�해결하기�보다�새로운�작업을�끌어오기만�합니다.�
- 병목지점,�문제점을�근본적으로�개선하는것보다�인력과�시간만을�더�투입하려고�합니다.
좋은점
- 쉽습니다.�
- 스크럼의�좋은점들이�칸반에서도�가능해집니다.�
- 스크럼의�어려운점들을�칸반은�해결해줍니다.�
- 스크럼보다�더욱�기민하게�대응할�수�있습니다.
장애물
- 스크럼과�마찬가지로�경험주의�이론에�기반을�두고�있기에�단기간에�개선이�이루어지지는�않습니다.�
- 스크럼보다�더�간단하지만,�칸반�역시�핵심�이론인�‘당김방식’,�‘WIP�제한’�에�대한�충분한�이해가�필요합니다.
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