5. | Traditional Practices
Requirement
• Requirement Doc.
• Prepare Use Cases
Design
• Software architecture
• Map the stakeholders
Implementation
• Construct the software
• Data storage & retrieval
Verification
• Install
• Test and Debug
Maintenance
• Check errors
• Optimize capabilities
초기에 모든 요구사항/일정/
자원에 대한 정의
개발이 들어가기 시작하면
변경사항은 계획에 위협
마지막 단계에서 고객에게 이
익을 전달
Waterfall Methodology
11. | Why Agile
Constraints
Estimates
Waterfall Agile
계획 중심으로
일정/비용 산정
비전/가치 중심으로
기능 산정
Features Cost Schedule
ScheduleCost Features
Michelle Slinger in “Relating PMBOK Practices to Agile Practices”
Value/Vision
Driven
Plan
Driven
17. 공정과 도구보다 개인과 상호작용을
Agile Value #1
I’m
EXCEPTION
• 소프트웨어는 기계가 아닌 사람이 만들고 사람이 사용
• 애자일은 소프트웨어의 중심인 사람에 더욱 큰 가치를 두고 있다는 것
18. 포괄적인 문서보다 작동하는 소프트웨어를
Agile Value #2
어떻게 잔디를 갈퀴질 할 것인지
에 대한 계획서 작성
우아한 잔디 무늬에 대한 디자인 제시
섬세하면서 포괄적인 청소 계획
수립
고객에게 가치 있는 결과물은 무엇일까?
19. 계약 협상보다 고객과의 협력을
Agile Value #3
• 프로젝트 시작도 전에 초기에 계약과 스펙, 요구사항을 확정 짓는 것보다
• 개방적이고 적극적인 커뮤니케이션을 통해 고객과 더 나은 솔루션을 찾는 것
• 내가 스스로 그리고 먼저 나의 모든 가시적, 잠재적 고객들에게 적극적으로 노력
고객님
원하시는 게
뭐에요?
20. 계획을 따르기보다 변화에 대응하기를
Agile Value #4
• 플랜A가 실패한다고 걱정하지 말라. 25개의 알파벳이 더 있으니
• 외부 환경이나 현실에 대한 변화만이 아니라 스스로의 변화도 필요
• 모든 내적 외적 변화를 이해하고 반영하고 발전해 나가기 위해 노력
22. PLAN Analysis Design Develop Test Deploy Operate
PLAN
Analysis
Design
Develop
Test
Deploy
PLAN
Analysis
Design
Develop
Test
Deploy
PLAN
Analysis
Design
Develop
Test
Deploy
Operate
이익
비용
이익
비용
투자
투자
회수
회수
Late ROI
Early ROI
TraditionalAgile
우리의 최고 우선 순위는 가치 있는 소프트웨어를
일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.
23. 비록 개발 후반부일지라도 요구사항 변경을 환영하라.
애자일 프로세스들은 변화를 활용해
고객의 경쟁력에 도움이 되게 한다.
24. | 불확실성의 뿔(Cone of uncertainty)
0.25x
0.5x
0.67x
0.8x
1.0x
1.25x
1.5x
2x
4x
Variability in the
Estimate of
Project Scope
(effort, cost, features)
Time
Initial
Concept
Approved
Product
Definition
Requirements
Complete
UI Design
Complete
Detailed
Design
Complete
Software
Complete
Software Project Survival Guide (Steve McConnell 1997)
25. 작동하는 소프트웨어를 자주 전달하라.
약 2주에서 2개월의 정도의 간격으로 전달하되,
간격이 짧을수록 좋다.
26. | The Agile Mona Lisa (http://www.yoomee.com/about-agile)
Women
in Pastoral
Setting
27. • 15,000+ developers in 40+ offices
• 4000+ projects under active development
• 5,500+ submissions per day on average
• All Builds from source
• 20+ sustained code changes per minutes with 60+ peaks
• 50% of code changes monthly
• 75+ million test cases run per day
| How Google Tests Software(2012)
• 구글은 애자일 개발과 Scrum의 Early adopter
• 오래 전부터 엔터프라이즈 레벨에서 Agile Testing 기법을 사용
• 15,000명 이상의 개발자가 매일 7,500만 테스트를 실시
29. 동기가 갖추어져 있는 개인들로 프로젝트를 구성하라.
그들에게 그들이 필요로 하는 환경과 지원을 제공하라.
그리고 그들이 일을 끝낼 수 있도록 신뢰하라.
30. Project Manager
“나를 따르라”
Self-
Organizing
Customer
Leader Tester AA/DA/QA
Developers
Coach
Facilitator
Cross
Functional
Teams
• 작업은 팀을 중심으로 구성
• 대부분의 작업은 PM에 의해서 할당됨
• Functional silos(자기부서의 이익만 추구)
• 팀은 작업을 중심으로 구성
• 같이 참여하는 고객
• 책임감과 자율성/자기 조직화/자기 관리
• 직위나 역할에 상관없이 누구나 프로젝트에 필
요한 일을 함, 품질은 팀 모두의 책임
Product
Owner
Traditional Team Agile Team
32. 작동하는 소프트웨어가 진척 측정의 주된 척도이다.
PLAN Analysis Design Develop Test Deploy Operate
PLAN
Analysis
Design
Develop
Test
Deploy
PLAN
Analysis
Design
Develop
Test
Deploy
PLAN
Analysis
Design
Develop
Test
Deploy
Operate
이익
비용
이익
비용
투자
투자
회수
회수
Late ROI
Early ROI
TraditionalAgile
33. 애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자 그리고 사용자들은 일정한 속도를 계속 유지할 수 있어야 한다.
34. [기업이 변해야 김대리가 산다] <6> 근로시간 단축 효과
야근 않고 회의 줄이니 매출 쑥쑥·고용 껑충
“우리도 야근을 없애고, 직원들 휴가도 자주 보
내주고 싶습니다. 그런데 당장 시행하기에 겁이
나네요. 매출이 떨어지거나 필요한 업무를 제대
로 처리하지 못하진 않을지 걱정이 앞섭니다.”
반도체 부품을 만드는 중소기업을 운영하는 A씨
는 2013년 근로시간을 단축하겠다는 계획서를
고용노동부에 제출했다. 하지만 갑작스러운 주
문 물량 증가 등 경영환경 변화로 결국 계획을
이행하지 못했다. A씨는 “야근이나 회식을 줄이
고 회의를 짧게 하는 등 업무효율성을 높이면 직
원들의 만족도가 높아지는 것을 모르는 것은
며 “다만 생산성 상승이 담보되지 않는 상황에서 섣불리 시행하기는 어렵다”고 털어놨다. 기업 입
장에서는 근로시간 단축과 업무 방식 개선이 일종의 모험인 셈이다. 오랜 시간 자리잡아 왔던 장
시간 근로 관행을 하루아침에 고치는 것이 쉽지 않은 데다 단기간 시행으로는 효과가 나타나지 않
는 경우도 있기 때문이다.
46. PRACTICES
AGILE VALUES
Working Deliverables
Human Interactions
Customer Collaboration
Responding to Change
AGILE PRINCIPLES
Simplicity Human
Transparency
Frequent Delivery Customer
Involvement
Technical Excellence
Team Work
Self Organisation
Emergent Design
Working Deliverables
Continuous Improvement
Sustainable Pace
AGILE TEAM PRACTICES AGILE TECHNICAL
PRACTICES
Test-Driven Development
Continuous Integration
Automated Deployment
Incremental Design and Architecture
Acceptance Test-Driven Development
Refactoring
Technical Spikes
Exploratory Testing
Collective Code Ownership
Definition of Done
Colocation
Daily Stand Ups
Iteration Planning
Customer Showcase
Retrospective
Adaptive Release Plan
Cross-Functional Team
Requirements as Stories
Planning/Story Wall
Informative Workspace
Burn Up/Down Charts
Parking Lot Diagrams
Success Sliders
Planning Poker
PRINCIPLES
VALUES
| Agile Foundation
47. | Agile Delivery Approach
제안된 아이디어의
기술적 가능성과
비즈니스 가치를
평가
제안된 아이디어를
정제하고 구체화
개발준비를 위한
계획 준비
반복적 개발을 통
해 고품질의 동작
하는 소프트웨어를
전달
동작되는
소프트웨어를
운영환경에 배포
ITERATION
ITERATION
ITERATION
ASSESS PLAN DELIVER DEPLOY
05% 10% 80% 05%
50. | Inception Deck
• 대부분의 프로젝트가 실패하는 이유는
• 성공의 의미가 서로 다르게 해석되는 경우가 많다. (동상이몽)
51. | Inception Deck
• 프로젝트 성공 확률을 높이기 위해
• 프로젝트 시작 시점에…
• 프로젝트 관련자들이 함께 모여…
• 프로젝트에 대한 기대하는 바가 동일하도록…
• 적절한 질문을 통해 생각을 공유
• 추정하지 말고 명쾌하고 진술하고 질문하기
• 꼭 물어야 하는 10가지 질문으로 구성
• ~couple days, a week
• 1~6 months of planning
• 프로젝트 초기 단계에 고객과 개발팀이 서로를 알아가는
과정. “Inception Deck” 이 시기에 사용하는 도구
52. Enter Inception Deck
1. 우리가 왜 여기 모였는가?
2. 엘리베이터 피치 만들기
3. 제품 박스 디자인 하기
4. 하지 말아야 할 리스트 만들기
5. 프로젝트 관련자 알아보기
6. 해결책을 보여주기
7. 무엇이 야근거리가 될 것인가?
8. 규모 정하기
9. 기회비용 파악하기
10.우선 순위 파악하기
모두가 함께 버스에 안전하게 탑승
목적지까지 성공적으로 운행
53. • 고객, 프로젝트 구성원 모두 같은 목표와 비전을 공유
• 더 많은 정보를 공유함으로
• 서로 대립하는 세력과 Trade-off이 균형 유지
• 자율적으로 생각하고 판단하는 능력으로 혁신적인 해결
책 모색
• 우리가 이 프로젝트를 해야 할 이유는 무엇인가?
1. 우리가 왜 여기 모였는가? (Ask why we are here)
54. 2. 엘리베이터 피치 만들기 (Create an Elevator Pitch)
Pitch me
the Wii.
55. 2. 엘리베이터 피치 만들기 (Create an Elevator Pitch)
For [어린 자녀를 분 부모들]
Who [전통적인 게임 콘솔을 지루해하는 ]
The [닌텐도 위] is a [패밀리 엔터테인먼트 시
스템]
That [온 가족이 함께 즐길 수 있는]
Unlike [XBOX, PS3은 복잡한 조이스틱과 컨
트롤러를 가지고 있음]
Our Product [온가족(심지어 할머니도)이 함께
즐길 수 있는 자연스러운 제스쳐를 기반으로 한
게임기]
• 프로젝트의 핵심을 분명히 이해 (Seeing the big picture)
• 팀원으로 하여금 고객의 입장에서 생각하도록 함
56. 2. 엘리베이터 피치 만들기 (Create an Elevator Pitch)
For [target customer]
Who [statement of the need or
opportunity ]
The [product name] is a [product
category]
That [key benefit, compelling reason o
buy]
Unlike [primary competitor]
Our Product [statement of primary
differentiation]
• 프로젝트의 핵심을 분명히 이해 (Seeing the big picture)
• 팀원으로 하여금 고객의 입장에서 생각하도록 함
57. • 제품의 기능을 고객에게 일일이 설명하려는 바보 같은 짓은 절대
하지 말자. (Features)
• 고객이 정말 알고 싶어 하는 것은 과연 이 제품이 자신의 삶의 질
을 더 낫게 할 수 있는지에 있다. (Benefits)
• Step 1. List the benefits
• Step 2. Create a slogan
• Step 3. Draw your creation
3. 제품 박스 디자인 하기 (Design a product box)
58. 4. 하지 말아야 할 리스트 만들기 (Create a NOT list)
• 범위 내 – 프로젝트 진행 시 꼭 해결해야 할 중요사항
• 범위 외 – 다음 릴리즈나 이 프로젝트에서 해결 할 수 없는 것들
• 미해결 – 더 고민 한 후 결정해야 할 사항
59. 5. 프로젝트 관련자 알아보기 (Meet your neighbors)
• 언제나 관련자들은 생각하는 것보다 크다
• 이 프로젝트에 관련된 사람들이 누구인지 파악하는 것이 중요
60. 6. 해결책을 보여주기 (Show the solution)
• 팀을 고르기 전에 아키텍처를 결정
• 해결책을 이야기 함으로써 얻는 이점들
• 어떤 도구나 기술을 사용할 지 추축할 수 있다.
• 프로젝트의 제약사항이나 범위를 시각화 할 수 있다.
• 리스크에 대해 상의할 수 있다.
61. 7. 무엇이 야근거리가 될 것인가? (Ask What Keeps Us Up at Night)
• 리스크를 미리 파악하면 좋은 점
• 프로젝트를 하는 동안 감수해야 할 문제점들을 일찍 파악
• 납득할 수 없는 이야기에 대한 반론의 기회
• 팀의 결속력을 강화, 서로의 경험을 배울 수 있는 기회
62. 8. 규모 정하기 (Size It Up)
• 프로젝트가 얼마나 걸리는지 예측해보는 것으로, 정확하지 않아도 언제쯤 소
프트웨어가 출시될 지 알아야 한다.
• 작고 다룰 수 있는 크기로 나누어야 한다. (Iteration based)
• 현재 상태의 가능한 정보를 기반으로 합리적인 기간을 예측하여 관련자에게
알려주어야 한다. 상황이 변경되면 계획은 수정
63. 9. 기회비용 파악하기 (Be Clear on What’s Going to Give)
• 프로젝트의 제약을 파악하고, 이에 대한 대책을 생각하라
• 프로젝트에서 집중해야 할 대상에 대한 토론을 통해 위기상황 발생 시 가이드
라인 마련
64. 10. 우선 순위 파악하기 (Show What It’s Going to Take)
• 계획을 세웠으면, 이를 구현하기 위해 필요한 것과 비용을 알아 내야 한다.
• 최고의 팀 구성
• 최종 결정권자 파악
• 비용에 대한 예측
• 모든 정보의 수집
65. Inception Deck 정리
• 프로젝트 시작 전에 이 프로젝트가 가지는 가치와 비전에 대해 기틀을 잡고 시
작할 수 있음.
• 10가지 질문에 대한 결과는 모든 팀원과 이해관계자와 공유해야 한다.
• 반드시 수행해야 할 도구는 아니다.
• 하지만 프로젝트 시작 전에 껄끄러운 질문/이슈에 대해서 자연스럽게 토론할
수 있도록 지원
• Pcolla sub project는 inception deck을 작성해보자!
67. What is Scrum
• 스크럼이란 단어는 럭비(혹은 미식 축구)에서 유래
1. 게임의 기본 단위가 정해진 시간이 아닌, '공이 땅에 떨어질 때 까지'라는 유동적인 단위로
진행되며 (이 단위를 스프린트::도약 라고 함)
2. 개인에 의해 정확히 정해진 포지션보다는, 한 스프린트마다 상황과 전략에 따라 팀원들의
위치와 역할이 유동적으로 정해짐
68. | Scrum이란
• 스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경
험적 관리기법의 대표적인 형태
• 럭비스타일의 두 가지 특징을 소프트웨어 엔지니어링에 적용한 것이 스크럼
개발 방법론
• 커다란 프로젝트를 작은 단위로 나누고, 그 작은 단위를 하나의 팀이 모두가
집중적으로 파고들어 끝낸다는 것
69. | Scrum이란
• 스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경
험적 관리기법의 대표적인 형태
• 럭비스타일의 두 가지 특징을 소프트웨어 엔지니어링에 적용한 것이 스크럼
개발 방법론
• 커다란 프로젝트를 작은 단위로 나누고, 그 작은 단위를 하나의 팀이 모두가
집중적으로 파고들어 끝낸다는 것
70. | 가치 있는 소프트웨어를 일찍 그리고 자주 전달하라
• OBJECTIVE:
• Deliver a Product Increment in a fixed time period
• Called a “SPRINT”
Commit &
Deliver
Commit &
Deliver
SPRINT
LENGTH
SPRINT
LENGTH
Potentially shippable
product increment
Potentially shippable
product increment
72. | Scrum의 역할
Product Owner Scrum Team
Scrum Master
• 제품 기능목록에 해당하
는 제품 백로그(product
backlog) 생성
• 우선순위 조정
• 스프린트 계획 수립
• 스프린트 시작 시에는 팀
운영에 관여하지 않음
• 스크럼의 원칙과 가치를
지키면서 스크럼 팀이 개
발을 진행할 수 있도록
지원
• 스크럼 팀의 업무를 방해
하는 요소를 제거하기 위
해 노력
• 보통 5~9명으로 구성되며
하나의 스프린트 기간 동
안 구현해야 할 기능을 사
용자스토리로 도출/구현
• 스프린트 동안 구현해야
하는 기능을 완료하기 위
해 노력
73. | 제품 백로그 (Product Backlog)
• 제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책
임자가 주로 우선순위를 결정
• 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대
한 추정은 주로 스토리 포인트라 불리는 기준을 이용
74. User Story
• 사용자 스토리란 서비스 고객에게 가치를 줄 수 있는 기능을 서술
• 좋은 사용자 스토리는 다음 요소를 갖춰야 함 (INVEST)
• 독립적이다. (Independent)
• 다른 스토리에 종속되지 않아야 한다.
• 협상 가능해야 한다. (Negotiable)
• 너무 세세하게 작성하지 말아야 한다.
• 가치가 있어야 한다. (Valuable)
• 추정 가능해야 한다.(Estimable)
• 적당한 크기여야 한다. (Sized right)
• 하나의 이터레이션에서 개발할 수 있어야 한다.
• 테스트 가능해야 한다. (Testable)
75. User Story
앞면 뒷면
As a <role>, I want to
<shot description of
feature>
so that I can
<value or why need
functionality>
Given … <some initial
context>
When … <an event
occurs>
Then … <ensure some
outcomes>
통합테스트 조건 만족
<스토리 포인트>
76. User Story Point
앞면
As a <role>, I want to
<shot description of
feature>
so that I can
<value or why need
functionality>
<스토리 포인트>
• 사용자 스토리 중에서 추정 가능한 적
당한 스토리를 3으로 정하고 스토리
포인트 단위 정함
• 기준을 기점으로 상대적인 크기 계산
• 3보다 2배정도 큰 일이면 5
• 3보다 절반정도면 1,2
• 플래닝 포커 게임과 결합하여 사용
77. | 스프린트 계획 (Sprint planning)
• 각 스프린트에 대한 목표를 세우고 제품 백로그로부터 스프린트에서 진행할
항목을 선택
• 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립
• 각 스프린트에 해당되는 스프린트 백로그 생성
• 플래닝 포커(Planning Poker) 등의 기법을 활용하여 추정
78. Planning Poker
1. 모든 팀원들이 카드를 한 벌씩 나눠 갖는다.
2. 태스크 하나를 두고 자신이 생각하는 작업 시간 카드를 선택한다.
3. 모두가 동시에 카드를 뒤집어서 일치하는 시간이 나오면 그 시간을 확정
4. 일치하지 않으면 가장 큰 값과 가장 적은 값을 선택한 멤버가 이유를 설명
5. 충분한 토의를 거쳐 다시 한번 카드를 선택
79. | 스프린트 백로그 (Sprint Backlog)
• 제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책
임자가 주로 우선순위를 결정
• 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대
한 추정은 주로 스토리 포인트라 불리는 기준을 이용
82. | 일일 스크럼 (Daily scrum)
• 매일 진행하는 15분간의 프로젝트 진행상황을 공유하는 회의
• 모든 팀원이 참석하며 매일매일 각자가 한 일, 할 일, 문제점 등을 논의
Daily stand up meeting, EBAY
83. | 번다운 차트 (Burndown chart)
• 개발을 완료하기까지 남은 작업량을 보여주는 그래프, 각 이터레이션 별로 남
아있는 작업량을 스토리 포인트라는 것으로 나타낸 것
84. | 스프린트 리뷰 (Sprint review)
• 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의
• 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백 받음
• 가능하면 해당 스프린트 동안 진행된 모든 작업에 대한 데모를 진행
Customer showcase(고객이 참여하는 것이 좋음)
Commit &
Deliver
Commit &
Deliver
SPRINT
LENGTH
SPRINT
LENGTH
Potentially shippable
product increment
Potentially shippable
product increment
85. | 스프린트 회고 (Sprint review)
• 스프린트 리뷰 이후, 그 다음 스프린트 계획 전에 수행 스프린트 리뷰는 제품에
대해 되돌아보고-개선을 하는 시간인 반면에, 스프린트 회고는 절차(프로세스)
에 대해 되돌아보고-개선을 하는 시간
• 개발팀, 스크럼 마스터, 제품소유자는 스크럼에서 수행한 것과 그렇지 않은 것
을 토의하고 관련된 기술적인 이슈를 이야기함 더 나은 스크럼팀이 되는데 도움
이 되는데 필요한 지속적인 프로세스 개선(continuous process
improvement)에 초점
86. | 스크럼의 특징
• 투명성 Transparency
• 스크럼은 스크럼 회의, 소멸차트, 스프린트 리뷰와 같은 기법을 이용해서 다른 방법론에 비해
프로젝트의 상태나 문제점을 잘 드러내줌.
• 타임박싱 Time boxing
• 일일 스크럼은 매일같이 15분이라는 짧은 시간에 진행해야 하며, 스프린트 리뷰는 매 이터레
이션 마다 주기적으로 진행. 스크럼 자체를 진행하는데 들어가는 시간을 엄격하게 제한함으로
써 프로젝트 진행에만 집중
• 커뮤니케이션 Communication
• 일일 스크럼에서 각 개발자들이 어떤 방해물(blocker)로 인한 문제를 겪고 있는지 공유하고,
흔히 플래닝 포커라는 방식으로 진행되곤 하는 각 사용자 스토리의 구현 난이도/시간을 토론
하는 절차는 프로젝트 내 커뮤니케이션을 원활하게 해줌
• 경험주의 모델 "Inspect & Adapt" model
• 스크럼은 고유의 프로세스 모델을 가지고 있지만 많은 기법들이 프로젝트에 참여하고 있는 개
개인의 경험에 기반. 스크럼은 기본적인 구조만 같을 뿐 실제로 일을 진행하게 되면 팀마다 달
라지는 것을 허용