SlideShare a Scribd company logo
1 of 91
Download to read offline
SW 개발
OPENSNS 권혁
Agile
- 어느 출근길(feat. 권혁 부장)
What’s the Problem
Agile SW 개발
| 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
어이쿠
| Waterfall 방법론의 문제점
자!!
이제 오픈
했으니
요구사항
추가다!
개발기간이
얼마 남지
않았어.
모두 주말
출근이다!
| Agile 방법론의 등장 배경 – 패러다임의 변화
Time to
Market
Budget Risk
Cancellation
Cost
Scope Creep
Requiremen
ts Error
Technology
Risk
Testing Risk
Why?Agile
| 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
| Core Value
Better Software
중요한 것
먼저
지속적인
변화 관리
더 나은
의사소통
| Agile 방법론의 가치제안(VALUE PROPOSITION)
VISIBILITY ADAPTABILITY
BUSINESS VALUE RISK
Agile Development
Traditional Development
What is Agile
| Agile 선언문 http://agilemanifesto.org/
| Agile 선언문 http://agilemanifesto.org/
공정과 도구보다 개인과 상호작용을
Agile Value #1
I’m
EXCEPTION
• 소프트웨어는 기계가 아닌 사람이 만들고 사람이 사용
• 애자일은 소프트웨어의 중심인 사람에 더욱 큰 가치를 두고 있다는 것
포괄적인 문서보다 작동하는 소프트웨어를
Agile Value #2
어떻게 잔디를 갈퀴질 할 것인지
에 대한 계획서 작성
우아한 잔디 무늬에 대한 디자인 제시
섬세하면서 포괄적인 청소 계획
수립
고객에게 가치 있는 결과물은 무엇일까?
계약 협상보다 고객과의 협력을
Agile Value #3
• 프로젝트 시작도 전에 초기에 계약과 스펙, 요구사항을 확정 짓는 것보다
• 개방적이고 적극적인 커뮤니케이션을 통해 고객과 더 나은 솔루션을 찾는 것
• 내가 스스로 그리고 먼저 나의 모든 가시적, 잠재적 고객들에게 적극적으로 노력
고객님
원하시는 게
뭐에요?
계획을 따르기보다 변화에 대응하기를
Agile Value #4
• 플랜A가 실패한다고 걱정하지 말라. 25개의 알파벳이 더 있으니
• 외부 환경이나 현실에 대한 변화만이 아니라 스스로의 변화도 필요
• 모든 내적 외적 변화를 이해하고 반영하고 발전해 나가기 위해 노력
소프트웨어의 12가지 원칙
Agile
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
우리의 최고 우선 순위는 가치 있는 소프트웨어를
일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.
비록 개발 후반부일지라도 요구사항 변경을 환영하라.
애자일 프로세스들은 변화를 활용해
고객의 경쟁력에 도움이 되게 한다.
| 불확실성의 뿔(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)
작동하는 소프트웨어를 자주 전달하라.
약 2주에서 2개월의 정도의 간격으로 전달하되,
간격이 짧을수록 좋다.
| The Agile Mona Lisa (http://www.yoomee.com/about-agile)
Women
in Pastoral
Setting
• 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만 테스트를 실시
비즈니스 영역 사람들과 개발자들은
프로젝트 전체에 걸쳐 매일 함께 일해야 한다.
동기가 갖추어져 있는 개인들로 프로젝트를 구성하라.
그들에게 그들이 필요로 하는 환경과 지원을 제공하라.
그리고 그들이 일을 끝낼 수 있도록 신뢰하라.
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
http://pleaseenjoy.com/projects/personal/10-levels-of-intimacy-in-todays-communication
어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, 정보를 전달하는
가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대화이다.
작동하는 소프트웨어가 진척 측정의 주된 척도이다.
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
애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자 그리고 사용자들은 일정한 속도를 계속 유지할 수 있어야 한다.
[기업이 변해야 김대리가 산다] <6> 근로시간 단축 효과
야근 않고 회의 줄이니 매출 쑥쑥·고용 껑충
“우리도 야근을 없애고, 직원들 휴가도 자주 보
내주고 싶습니다. 그런데 당장 시행하기에 겁이
나네요. 매출이 떨어지거나 필요한 업무를 제대
로 처리하지 못하진 않을지 걱정이 앞섭니다.”
반도체 부품을 만드는 중소기업을 운영하는 A씨
는 2013년 근로시간을 단축하겠다는 계획서를
고용노동부에 제출했다. 하지만 갑작스러운 주
문 물량 증가 등 경영환경 변화로 결국 계획을
이행하지 못했다. A씨는 “야근이나 회식을 줄이
고 회의를 짧게 하는 등 업무효율성을 높이면 직
원들의 만족도가 높아지는 것을 모르는 것은
며 “다만 생산성 상승이 담보되지 않는 상황에서 섣불리 시행하기는 어렵다”고 털어놨다. 기업 입
장에서는 근로시간 단축과 업무 방식 개선이 일종의 모험인 셈이다. 오랜 시간 자리잡아 왔던 장
시간 근로 관행을 하루아침에 고치는 것이 쉽지 않은 데다 단기간 시행으로는 효과가 나타나지 않
는 경우도 있기 때문이다.
기술적 탁월함과 좋은 설계에 대한 지속적 관심이
기민함을 향상시킨다.
간결함-하지 않아도 되는 일의 양을 최소화하는
기술은 필수적이다.
최상의 아키텍처, 요구사항 그리고 설계는 자기조직화
(self-organizing)되어 있는 팀에서 나온다.
팀은 정기적으로
더 효과적으로 일할 수 있는 방법을 숙고하고,
그에 따라 자신/팀의 행동을 조율하고 조정한다.
에 대한 오해Agile
A specific methodology
Agile Software
Development
Agile Method
Practices
Scrum
Crystal
Adaptive
XP
FDD
RUPKanban
Time-boxing
User-stories
Daily scrum
Reviews Continuous Integration
Test-driven Development
Visual
Management
Glorified hacking
Working without
planning
A silver
bullet
Suitable for all types of projects
Need
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
| Agile Delivery Approach
제안된 아이디어의
기술적 가능성과
비즈니스 가치를
평가
제안된 아이디어를
정제하고 구체화
개발준비를 위한
계획 준비
반복적 개발을 통
해 고품질의 동작
하는 소프트웨어를
전달
동작되는
소프트웨어를
운영환경에 배포
ITERATION
ITERATION
ITERATION
ASSESS PLAN DELIVER DEPLOY
05% 10% 80% 05%
프로젝트Agile
Inception
운전 기사
어떤 놈이야~
오른쪽으로
갔어야지
바보야!
아직
멀었나?
에어컨 좀
틀어주세요
AC
전 전거장에서
내렸어야 했는데
잔말 말고
그냥
따라와
시끄럽다
조용히 좀
가지!
대부분의 프로젝트는 시작도 하기 전에 실패한다.
| Inception Deck
• 대부분의 프로젝트가 실패하는 이유는
• 성공의 의미가 서로 다르게 해석되는 경우가 많다. (동상이몽)
| Inception Deck
• 프로젝트 성공 확률을 높이기 위해
• 프로젝트 시작 시점에…
• 프로젝트 관련자들이 함께 모여…
• 프로젝트에 대한 기대하는 바가 동일하도록…
• 적절한 질문을 통해 생각을 공유
• 추정하지 말고 명쾌하고 진술하고 질문하기
• 꼭 물어야 하는 10가지 질문으로 구성
• ~couple days, a week
• 1~6 months of planning
• 프로젝트 초기 단계에 고객과 개발팀이 서로를 알아가는
과정. “Inception Deck” 이 시기에 사용하는 도구
Enter Inception Deck
1. 우리가 왜 여기 모였는가?
2. 엘리베이터 피치 만들기
3. 제품 박스 디자인 하기
4. 하지 말아야 할 리스트 만들기
5. 프로젝트 관련자 알아보기
6. 해결책을 보여주기
7. 무엇이 야근거리가 될 것인가?
8. 규모 정하기
9. 기회비용 파악하기
10.우선 순위 파악하기
모두가 함께 버스에 안전하게 탑승
목적지까지 성공적으로 운행
• 고객, 프로젝트 구성원 모두 같은 목표와 비전을 공유
• 더 많은 정보를 공유함으로
• 서로 대립하는 세력과 Trade-off이 균형 유지
• 자율적으로 생각하고 판단하는 능력으로 혁신적인 해결
책 모색
• 우리가 이 프로젝트를 해야 할 이유는 무엇인가?
1. 우리가 왜 여기 모였는가? (Ask why we are here)
2. 엘리베이터 피치 만들기 (Create an Elevator Pitch)
Pitch me
the Wii.
2. 엘리베이터 피치 만들기 (Create an Elevator Pitch)
For [어린 자녀를 분 부모들]
Who [전통적인 게임 콘솔을 지루해하는 ]
The [닌텐도 위] is a [패밀리 엔터테인먼트 시
스템]
That [온 가족이 함께 즐길 수 있는]
Unlike [XBOX, PS3은 복잡한 조이스틱과 컨
트롤러를 가지고 있음]
Our Product [온가족(심지어 할머니도)이 함께
즐길 수 있는 자연스러운 제스쳐를 기반으로 한
게임기]
• 프로젝트의 핵심을 분명히 이해 (Seeing the big picture)
• 팀원으로 하여금 고객의 입장에서 생각하도록 함
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)
• 팀원으로 하여금 고객의 입장에서 생각하도록 함
• 제품의 기능을 고객에게 일일이 설명하려는 바보 같은 짓은 절대
하지 말자. (Features)
• 고객이 정말 알고 싶어 하는 것은 과연 이 제품이 자신의 삶의 질
을 더 낫게 할 수 있는지에 있다. (Benefits)
• Step 1. List the benefits
• Step 2. Create a slogan
• Step 3. Draw your creation
3. 제품 박스 디자인 하기 (Design a product box)
4. 하지 말아야 할 리스트 만들기 (Create a NOT list)
• 범위 내 – 프로젝트 진행 시 꼭 해결해야 할 중요사항
• 범위 외 – 다음 릴리즈나 이 프로젝트에서 해결 할 수 없는 것들
• 미해결 – 더 고민 한 후 결정해야 할 사항
5. 프로젝트 관련자 알아보기 (Meet your neighbors)
• 언제나 관련자들은 생각하는 것보다 크다
• 이 프로젝트에 관련된 사람들이 누구인지 파악하는 것이 중요
6. 해결책을 보여주기 (Show the solution)
• 팀을 고르기 전에 아키텍처를 결정
• 해결책을 이야기 함으로써 얻는 이점들
• 어떤 도구나 기술을 사용할 지 추축할 수 있다.
• 프로젝트의 제약사항이나 범위를 시각화 할 수 있다.
• 리스크에 대해 상의할 수 있다.
7. 무엇이 야근거리가 될 것인가? (Ask What Keeps Us Up at Night)
• 리스크를 미리 파악하면 좋은 점
• 프로젝트를 하는 동안 감수해야 할 문제점들을 일찍 파악
• 납득할 수 없는 이야기에 대한 반론의 기회
• 팀의 결속력을 강화, 서로의 경험을 배울 수 있는 기회
8. 규모 정하기 (Size It Up)
• 프로젝트가 얼마나 걸리는지 예측해보는 것으로, 정확하지 않아도 언제쯤 소
프트웨어가 출시될 지 알아야 한다.
• 작고 다룰 수 있는 크기로 나누어야 한다. (Iteration based)
• 현재 상태의 가능한 정보를 기반으로 합리적인 기간을 예측하여 관련자에게
알려주어야 한다.  상황이 변경되면 계획은 수정
9. 기회비용 파악하기 (Be Clear on What’s Going to Give)
• 프로젝트의 제약을 파악하고, 이에 대한 대책을 생각하라
• 프로젝트에서 집중해야 할 대상에 대한 토론을 통해 위기상황 발생 시 가이드
라인 마련
10. 우선 순위 파악하기 (Show What It’s Going to Take)
• 계획을 세웠으면, 이를 구현하기 위해 필요한 것과 비용을 알아 내야 한다.
• 최고의 팀 구성
• 최종 결정권자 파악
• 비용에 대한 예측
• 모든 정보의 수집
Inception Deck 정리
• 프로젝트 시작 전에 이 프로젝트가 가지는 가치와 비전에 대해 기틀을 잡고 시
작할 수 있음.
• 10가지 질문에 대한 결과는 모든 팀원과 이해관계자와 공유해야 한다.
• 반드시 수행해야 할 도구는 아니다.
• 하지만 프로젝트 시작 전에 껄끄러운 질문/이슈에 대해서 자연스럽게 토론할
수 있도록 지원
• Pcolla sub project는 inception deck을 작성해보자!
개발 프로세스Agile
Scrum
What is Scrum
• 스크럼이란 단어는 럭비(혹은 미식 축구)에서 유래
1. 게임의 기본 단위가 정해진 시간이 아닌, '공이 땅에 떨어질 때 까지'라는 유동적인 단위로
진행되며 (이 단위를 스프린트::도약 라고 함)
2. 개인에 의해 정확히 정해진 포지션보다는, 한 스프린트마다 상황과 전략에 따라 팀원들의
위치와 역할이 유동적으로 정해짐
| Scrum이란
• 스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경
험적 관리기법의 대표적인 형태
• 럭비스타일의 두 가지 특징을 소프트웨어 엔지니어링에 적용한 것이 스크럼
개발 방법론
• 커다란 프로젝트를 작은 단위로 나누고, 그 작은 단위를 하나의 팀이 모두가
집중적으로 파고들어 끝낸다는 것
| Scrum이란
• 스크럼은 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경
험적 관리기법의 대표적인 형태
• 럭비스타일의 두 가지 특징을 소프트웨어 엔지니어링에 적용한 것이 스크럼
개발 방법론
• 커다란 프로젝트를 작은 단위로 나누고, 그 작은 단위를 하나의 팀이 모두가
집중적으로 파고들어 끝낸다는 것
| 가치 있는 소프트웨어를 일찍 그리고 자주 전달하라
• 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
Process
| Scrum의 역할
Product Owner Scrum Team
Scrum Master
• 제품 기능목록에 해당하
는 제품 백로그(product
backlog) 생성
• 우선순위 조정
• 스프린트 계획 수립
• 스프린트 시작 시에는 팀
운영에 관여하지 않음
• 스크럼의 원칙과 가치를
지키면서 스크럼 팀이 개
발을 진행할 수 있도록
지원
• 스크럼 팀의 업무를 방해
하는 요소를 제거하기 위
해 노력
• 보통 5~9명으로 구성되며
하나의 스프린트 기간 동
안 구현해야 할 기능을 사
용자스토리로 도출/구현
• 스프린트 동안 구현해야
하는 기능을 완료하기 위
해 노력
| 제품 백로그 (Product Backlog)
• 제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책
임자가 주로 우선순위를 결정
• 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대
한 추정은 주로 스토리 포인트라 불리는 기준을 이용
User Story
• 사용자 스토리란 서비스 고객에게 가치를 줄 수 있는 기능을 서술
• 좋은 사용자 스토리는 다음 요소를 갖춰야 함 (INVEST)
• 독립적이다. (Independent)
• 다른 스토리에 종속되지 않아야 한다.
• 협상 가능해야 한다. (Negotiable)
• 너무 세세하게 작성하지 말아야 한다.
• 가치가 있어야 한다. (Valuable)
• 추정 가능해야 한다.(Estimable)
• 적당한 크기여야 한다. (Sized right)
• 하나의 이터레이션에서 개발할 수 있어야 한다.
• 테스트 가능해야 한다. (Testable)
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>
통합테스트 조건 만족
<스토리 포인트>
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
• 플래닝 포커 게임과 결합하여 사용
| 스프린트 계획 (Sprint planning)
• 각 스프린트에 대한 목표를 세우고 제품 백로그로부터 스프린트에서 진행할
항목을 선택
• 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립
• 각 스프린트에 해당되는 스프린트 백로그 생성
• 플래닝 포커(Planning Poker) 등의 기법을 활용하여 추정
Planning Poker
1. 모든 팀원들이 카드를 한 벌씩 나눠 갖는다.
2. 태스크 하나를 두고 자신이 생각하는 작업 시간 카드를 선택한다.
3. 모두가 동시에 카드를 뒤집어서 일치하는 시간이 나오면 그 시간을 확정
4. 일치하지 않으면 가장 큰 값과 가장 적은 값을 선택한 멤버가 이유를 설명
5. 충분한 토의를 거쳐 다시 한번 카드를 선택
| 스프린트 백로그 (Sprint Backlog)
• 제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책
임자가 주로 우선순위를 결정
• 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대
한 추정은 주로 스토리 포인트라 불리는 기준을 이용
| 스크럼 대시보드 (Scrum dash-board)
| 스크럼 대시보드 (Scrum dash-board)
| 일일 스크럼 (Daily scrum)
• 매일 진행하는 15분간의 프로젝트 진행상황을 공유하는 회의
• 모든 팀원이 참석하며 매일매일 각자가 한 일, 할 일, 문제점 등을 논의
Daily stand up meeting, EBAY
| 번다운 차트 (Burndown chart)
• 개발을 완료하기까지 남은 작업량을 보여주는 그래프, 각 이터레이션 별로 남
아있는 작업량을 스토리 포인트라는 것으로 나타낸 것
| 스프린트 리뷰 (Sprint review)
• 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의
• 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백 받음
• 가능하면 해당 스프린트 동안 진행된 모든 작업에 대한 데모를 진행
Customer showcase(고객이 참여하는 것이 좋음)
Commit &
Deliver
Commit &
Deliver
SPRINT
LENGTH
SPRINT
LENGTH
Potentially shippable
product increment
Potentially shippable
product increment
| 스프린트 회고 (Sprint review)
• 스프린트 리뷰 이후, 그 다음 스프린트 계획 전에 수행 스프린트 리뷰는 제품에
대해 되돌아보고-개선을 하는 시간인 반면에, 스프린트 회고는 절차(프로세스)
에 대해 되돌아보고-개선을 하는 시간
• 개발팀, 스크럼 마스터, 제품소유자는 스크럼에서 수행한 것과 그렇지 않은 것
을 토의하고 관련된 기술적인 이슈를 이야기함 더 나은 스크럼팀이 되는데 도움
이 되는데 필요한 지속적인 프로세스 개선(continuous process
improvement)에 초점
| 스크럼의 특징
• 투명성 Transparency
• 스크럼은 스크럼 회의, 소멸차트, 스프린트 리뷰와 같은 기법을 이용해서 다른 방법론에 비해
프로젝트의 상태나 문제점을 잘 드러내줌.
• 타임박싱 Time boxing
• 일일 스크럼은 매일같이 15분이라는 짧은 시간에 진행해야 하며, 스프린트 리뷰는 매 이터레
이션 마다 주기적으로 진행. 스크럼 자체를 진행하는데 들어가는 시간을 엄격하게 제한함으로
써 프로젝트 진행에만 집중
• 커뮤니케이션 Communication
• 일일 스크럼에서 각 개발자들이 어떤 방해물(blocker)로 인한 문제를 겪고 있는지 공유하고,
흔히 플래닝 포커라는 방식으로 진행되곤 하는 각 사용자 스토리의 구현 난이도/시간을 토론
하는 절차는 프로젝트 내 커뮤니케이션을 원활하게 해줌
• 경험주의 모델 "Inspect & Adapt" model
• 스크럼은 고유의 프로세스 모델을 가지고 있지만 많은 기법들이 프로젝트에 참여하고 있는 개
개인의 경험에 기반. 스크럼은 기본적인 구조만 같을 뿐 실제로 일을 진행하게 되면 팀마다 달
라지는 것을 허용
을 목적이 아닌Agile
수단으로
모든 프로젝트는 고유하다.
끼워 맞추기 보다 맛있게 골라먹자
- 어느 출근길(feat. 권혁 부장)
늘 하던 대로만 한다면,
늘 얻던 그만큼밖에 얻을 수 없다
Agile SW 개발

More Related Content

What's hot

애자일 도입과 사례 공유
애자일 도입과 사례 공유애자일 도입과 사례 공유
애자일 도입과 사례 공유agilekorea
 
Sonarqube 20160509
Sonarqube 20160509Sonarqube 20160509
Sonarqube 20160509영석 조
 
애자일 하라
애자일 하라애자일 하라
애자일 하라진수 허
 
Agile 방법론
Agile 방법론Agile 방법론
Agile 방법론Astin Choi
 
애자일을 실천하는 사람들이 겪는 어려움
애자일을 실천하는 사람들이 겪는 어려움애자일을 실천하는 사람들이 겪는 어려움
애자일을 실천하는 사람들이 겪는 어려움Bonna Choi
 
Sk planet 이야기
Sk planet 이야기Sk planet 이야기
Sk planet 이야기종범 고
 
애자일 S/W 개발
애자일 S/W 개발애자일 S/W 개발
애자일 S/W 개발영기 김
 
모바일 앱 개발을 위한 Agile 적용
모바일 앱 개발을 위한 Agile 적용모바일 앱 개발을 위한 Agile 적용
모바일 앱 개발을 위한 Agile 적용Kevin Kim
 
사용자 스토리 기반의 스크럼
사용자 스토리 기반의 스크럼사용자 스토리 기반의 스크럼
사용자 스토리 기반의 스크럼Junyi Song
 
Scrum and kanban with jira
Scrum and kanban with jira Scrum and kanban with jira
Scrum and kanban with jira 호정 이
 
Scrum - Agile Development Process
Scrum - Agile Development ProcessScrum - Agile Development Process
Scrum - Agile Development ProcessKook Maeng
 
0. review. 린과 애자일 개발
0. review. 린과 애자일 개발0. review. 린과 애자일 개발
0. review. 린과 애자일 개발Unyong (Sheldon) Choi
 
애자일 게임 개발이란?
애자일 게임 개발이란?애자일 게임 개발이란?
애자일 게임 개발이란?Kay Kim
 
[Atlassian in 부산]해외 자동차 업체 b사의 agile 적용 사례_모우소프트
[Atlassian in 부산]해외 자동차 업체 b사의 agile 적용 사례_모우소프트[Atlassian in 부산]해외 자동차 업체 b사의 agile 적용 사례_모우소프트
[Atlassian in 부산]해외 자동차 업체 b사의 agile 적용 사례_모우소프트Atlassian 대한민국
 
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)Kay Kim
 
소프트웨어 개발 프로세스 개선
소프트웨어 개발 프로세스 개선소프트웨어 개발 프로세스 개선
소프트웨어 개발 프로세스 개선Jung Dohyun
 
Undocumented agile.dist
Undocumented agile.distUndocumented agile.dist
Undocumented agile.distJongin Oh
 
성공하는 애자일을 위한 짧은 이야기
성공하는 애자일을 위한 짧은 이야기성공하는 애자일을 위한 짧은 이야기
성공하는 애자일을 위한 짧은 이야기종범 고
 
애자일 프랙티스
애자일 프랙티스애자일 프랙티스
애자일 프랙티스한 경만
 

What's hot (20)

애자일 도입과 사례 공유
애자일 도입과 사례 공유애자일 도입과 사례 공유
애자일 도입과 사례 공유
 
Sonarqube 20160509
Sonarqube 20160509Sonarqube 20160509
Sonarqube 20160509
 
애자일 하라
애자일 하라애자일 하라
애자일 하라
 
Agile 방법론
Agile 방법론Agile 방법론
Agile 방법론
 
애자일을 실천하는 사람들이 겪는 어려움
애자일을 실천하는 사람들이 겪는 어려움애자일을 실천하는 사람들이 겪는 어려움
애자일을 실천하는 사람들이 겪는 어려움
 
Sk planet 이야기
Sk planet 이야기Sk planet 이야기
Sk planet 이야기
 
애자일 S/W 개발
애자일 S/W 개발애자일 S/W 개발
애자일 S/W 개발
 
모바일 앱 개발을 위한 Agile 적용
모바일 앱 개발을 위한 Agile 적용모바일 앱 개발을 위한 Agile 적용
모바일 앱 개발을 위한 Agile 적용
 
사용자 스토리 기반의 스크럼
사용자 스토리 기반의 스크럼사용자 스토리 기반의 스크럼
사용자 스토리 기반의 스크럼
 
Scrum and kanban with jira
Scrum and kanban with jira Scrum and kanban with jira
Scrum and kanban with jira
 
Scrum - Agile Development Process
Scrum - Agile Development ProcessScrum - Agile Development Process
Scrum - Agile Development Process
 
0. review. 린과 애자일 개발
0. review. 린과 애자일 개발0. review. 린과 애자일 개발
0. review. 린과 애자일 개발
 
애자일 게임 개발이란?
애자일 게임 개발이란?애자일 게임 개발이란?
애자일 게임 개발이란?
 
[Atlassian in 부산]해외 자동차 업체 b사의 agile 적용 사례_모우소프트
[Atlassian in 부산]해외 자동차 업체 b사의 agile 적용 사례_모우소프트[Atlassian in 부산]해외 자동차 업체 b사의 agile 적용 사례_모우소프트
[Atlassian in 부산]해외 자동차 업체 b사의 agile 적용 사례_모우소프트
 
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
실전 애자일 게임 개발 (Agile Game Agile Game Development From The Trenches)
 
소프트웨어 개발 프로세스 개선
소프트웨어 개발 프로세스 개선소프트웨어 개발 프로세스 개선
소프트웨어 개발 프로세스 개선
 
What is agile
What is agileWhat is agile
What is agile
 
Undocumented agile.dist
Undocumented agile.distUndocumented agile.dist
Undocumented agile.dist
 
성공하는 애자일을 위한 짧은 이야기
성공하는 애자일을 위한 짧은 이야기성공하는 애자일을 위한 짧은 이야기
성공하는 애자일을 위한 짧은 이야기
 
애자일 프랙티스
애자일 프랙티스애자일 프랙티스
애자일 프랙티스
 

Viewers also liked

SVN에서 GIT으로 전환하기
SVN에서 GIT으로 전환하기SVN에서 GIT으로 전환하기
SVN에서 GIT으로 전환하기재윤 정
 
Softskills
SoftskillsSoftskills
Softskills혁 권
 
Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리SangJin Kang
 
애자일 코치
애자일 코치애자일 코치
애자일 코치영기 김
 
신입웹개발자교육
신입웹개발자교육신입웹개발자교육
신입웹개발자교육은숙 이
 
애자일활용사례
애자일활용사례애자일활용사례
애자일활용사례Dexter Jung
 
애자일은 반드시 없어져야 한다
애자일은 반드시 없어져야 한다애자일은 반드시 없어져야 한다
애자일은 반드시 없어져야 한다종범 고
 
스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요Insub Lee
 
2015 Newguest presentation wide OT
2015 Newguest presentation wide OT2015 Newguest presentation wide OT
2015 Newguest presentation wide OTWonWoo Jo
 
TDD & Agile in Vingle
TDD & Agile in VingleTDD & Agile in Vingle
TDD & Agile in VingleVingle Inc.
 
Agile Spirit Base On The Book "Agile Samuari"
Agile Spirit Base On The Book "Agile Samuari"Agile Spirit Base On The Book "Agile Samuari"
Agile Spirit Base On The Book "Agile Samuari"운용 최
 
자바 프로그래밍 Agile(2장 자바의 기초)
자바 프로그래밍 Agile(2장 자바의 기초)자바 프로그래밍 Agile(2장 자바의 기초)
자바 프로그래밍 Agile(2장 자바의 기초)brain816
 
Java script 신입교육
Java script 신입교육Java script 신입교육
Java script 신입교육준성 황
 
새 직원 교육
새 직원 교육새 직원 교육
새 직원 교육gahae
 
201206 agile hiring
201206 agile hiring201206 agile hiring
201206 agile hiringKevin Kim
 

Viewers also liked (15)

SVN에서 GIT으로 전환하기
SVN에서 GIT으로 전환하기SVN에서 GIT으로 전환하기
SVN에서 GIT으로 전환하기
 
Softskills
SoftskillsSoftskills
Softskills
 
Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리Agile - SCRUM을 통한 개발관리
Agile - SCRUM을 통한 개발관리
 
애자일 코치
애자일 코치애자일 코치
애자일 코치
 
신입웹개발자교육
신입웹개발자교육신입웹개발자교육
신입웹개발자교육
 
애자일활용사례
애자일활용사례애자일활용사례
애자일활용사례
 
애자일은 반드시 없어져야 한다
애자일은 반드시 없어져야 한다애자일은 반드시 없어져야 한다
애자일은 반드시 없어져야 한다
 
스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요스크럼, 이걸 왜 하나요
스크럼, 이걸 왜 하나요
 
2015 Newguest presentation wide OT
2015 Newguest presentation wide OT2015 Newguest presentation wide OT
2015 Newguest presentation wide OT
 
TDD & Agile in Vingle
TDD & Agile in VingleTDD & Agile in Vingle
TDD & Agile in Vingle
 
Agile Spirit Base On The Book "Agile Samuari"
Agile Spirit Base On The Book "Agile Samuari"Agile Spirit Base On The Book "Agile Samuari"
Agile Spirit Base On The Book "Agile Samuari"
 
자바 프로그래밍 Agile(2장 자바의 기초)
자바 프로그래밍 Agile(2장 자바의 기초)자바 프로그래밍 Agile(2장 자바의 기초)
자바 프로그래밍 Agile(2장 자바의 기초)
 
Java script 신입교육
Java script 신입교육Java script 신입교육
Java script 신입교육
 
새 직원 교육
새 직원 교육새 직원 교육
새 직원 교육
 
201206 agile hiring
201206 agile hiring201206 agile hiring
201206 agile hiring
 

Similar to Agile SW 개발

언제 애자일을 써야 좋을까? 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
 
Agile의 본질과 실천
Agile의 본질과 실천 Agile의 본질과 실천
Agile의 본질과 실천 Hyungseok Shim
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스Hee Jae Lee
 
프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험Jihye OK
 
Agile sw development 101
Agile sw development 101Agile sw development 101
Agile sw development 101Kiwon Kyung
 
Project Management
Project ManagementProject Management
Project Managementcherryhacker
 
린스타트업 이해와 Case study(Lean Startup and Case Study)
린스타트업 이해와 Case study(Lean Startup and Case Study)린스타트업 이해와 Case study(Lean Startup and Case Study)
린스타트업 이해와 Case study(Lean Startup and Case Study)Matthew Lee
 
[AIS 2018][Team Practice] 작은 규모를 위한 Scrum과 Enterprise를 위한 SAFe – 모우소프트
[AIS 2018][Team Practice] 작은 규모를 위한 Scrum과 Enterprise를 위한 SAFe – 모우소프트[AIS 2018][Team Practice] 작은 규모를 위한 Scrum과 Enterprise를 위한 SAFe – 모우소프트
[AIS 2018][Team Practice] 작은 규모를 위한 Scrum과 Enterprise를 위한 SAFe – 모우소프트Atlassian 대한민국
 
스크럼 101
스크럼 101스크럼 101
스크럼 101Daniel Lim
 
[Web Agency] Project Process Standard Guide
[Web Agency] Project Process Standard Guide[Web Agency] Project Process Standard Guide
[Web Agency] Project Process Standard GuideSang Beom (Chris) Roh
 
개발자 리서치 활동강화 방안 180109
개발자 리서치 활동강화 방안 180109개발자 리서치 활동강화 방안 180109
개발자 리서치 활동강화 방안 180109한 경만
 
Kakao agile 2nd story
Kakao agile 2nd storyKakao agile 2nd story
Kakao agile 2nd story호정 이
 
12 해결한 도출
12 해결한 도출12 해결한 도출
12 해결한 도출humana12
 
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개태준 문
 
4강. 프로토 타이핑 (prototyping)
4강. 프로토 타이핑 (prototyping)4강. 프로토 타이핑 (prototyping)
4강. 프로토 타이핑 (prototyping)Ho Hyun Lee
 
화해 제품팀이 일하는 방법
화해 제품팀이 일하는 방법화해 제품팀이 일하는 방법
화해 제품팀이 일하는 방법Jinsoo Hwang
 
EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다이상한모임
 
클라우드 네이티브로의 전환을 위한 여정
클라우드 네이티브로의 전환을 위한 여정클라우드 네이티브로의 전환을 위한 여정
클라우드 네이티브로의 전환을 위한 여정VMware Tanzu Korea
 

Similar to Agile SW 개발 (20)

언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing software언제 애자일을 써야 좋을까? The better ways of developing software
언제 애자일을 써야 좋을까? The better ways of developing software
 
Agile의 본질과 실천
Agile의 본질과 실천 Agile의 본질과 실천
Agile의 본질과 실천
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
 
프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험프로덕트 매니저 8년의 경험
프로덕트 매니저 8년의 경험
 
Agile sw development 101
Agile sw development 101Agile sw development 101
Agile sw development 101
 
Project Management
Project ManagementProject Management
Project Management
 
린스타트업 이해와 Case study(Lean Startup and Case Study)
린스타트업 이해와 Case study(Lean Startup and Case Study)린스타트업 이해와 Case study(Lean Startup and Case Study)
린스타트업 이해와 Case study(Lean Startup and Case Study)
 
[AIS 2018][Team Practice] 작은 규모를 위한 Scrum과 Enterprise를 위한 SAFe – 모우소프트
[AIS 2018][Team Practice] 작은 규모를 위한 Scrum과 Enterprise를 위한 SAFe – 모우소프트[AIS 2018][Team Practice] 작은 규모를 위한 Scrum과 Enterprise를 위한 SAFe – 모우소프트
[AIS 2018][Team Practice] 작은 규모를 위한 Scrum과 Enterprise를 위한 SAFe – 모우소프트
 
스크럼 101
스크럼 101스크럼 101
스크럼 101
 
[Web Agency] Project Process Standard Guide
[Web Agency] Project Process Standard Guide[Web Agency] Project Process Standard Guide
[Web Agency] Project Process Standard Guide
 
AKC2020 인썸니아 이성훈
AKC2020 인썸니아 이성훈AKC2020 인썸니아 이성훈
AKC2020 인썸니아 이성훈
 
개발자 리서치 활동강화 방안 180109
개발자 리서치 활동강화 방안 180109개발자 리서치 활동강화 방안 180109
개발자 리서치 활동강화 방안 180109
 
Kakao agile 2nd story
Kakao agile 2nd storyKakao agile 2nd story
Kakao agile 2nd story
 
12 해결한 도출
12 해결한 도출12 해결한 도출
12 해결한 도출
 
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
DEVOPS 에 대한 전반적인 소개 및 자동화툴 소개
 
4강. 프로토 타이핑 (prototyping)
4강. 프로토 타이핑 (prototyping)4강. 프로토 타이핑 (prototyping)
4강. 프로토 타이핑 (prototyping)
 
화해 제품팀이 일하는 방법
화해 제품팀이 일하는 방법화해 제품팀이 일하는 방법
화해 제품팀이 일하는 방법
 
ITCT 사용자 중심 디자인 특강 - spoqa 남유정 UX designer
ITCT 사용자 중심 디자인 특강 - spoqa 남유정 UX designerITCT 사용자 중심 디자인 특강 - spoqa 남유정 UX designer
ITCT 사용자 중심 디자인 특강 - spoqa 남유정 UX designer
 
EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다EMOCON 2015 - 품질과 테스트는 다르다
EMOCON 2015 - 품질과 테스트는 다르다
 
클라우드 네이티브로의 전환을 위한 여정
클라우드 네이티브로의 전환을 위한 여정클라우드 네이티브로의 전환을 위한 여정
클라우드 네이티브로의 전환을 위한 여정
 

Agile SW 개발

  • 2. - 어느 출근길(feat. 권혁 부장)
  • 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
  • 9. | Agile 방법론의 등장 배경 – 패러다임의 변화 Time to Market Budget Risk Cancellation Cost Scope Creep Requiremen ts Error Technology Risk Testing Risk
  • 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
  • 12. | Core Value Better Software 중요한 것 먼저 지속적인 변화 관리 더 나은 의사소통
  • 13. | Agile 방법론의 가치제안(VALUE PROPOSITION) VISIBILITY ADAPTABILITY BUSINESS VALUE RISK Agile Development Traditional Development
  • 15. | Agile 선언문 http://agilemanifesto.org/
  • 16. | Agile 선언문 http://agilemanifesto.org/
  • 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만 테스트를 실시
  • 28. 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다.
  • 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
  • 31. http://pleaseenjoy.com/projects/personal/10-levels-of-intimacy-in-todays-communication 어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대화이다.
  • 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씨는 “야근이나 회식을 줄이 고 회의를 짧게 하는 등 업무효율성을 높이면 직 원들의 만족도가 높아지는 것을 모르는 것은 며 “다만 생산성 상승이 담보되지 않는 상황에서 섣불리 시행하기는 어렵다”고 털어놨다. 기업 입 장에서는 근로시간 단축과 업무 방식 개선이 일종의 모험인 셈이다. 오랜 시간 자리잡아 왔던 장 시간 근로 관행을 하루아침에 고치는 것이 쉽지 않은 데다 단기간 시행으로는 효과가 나타나지 않 는 경우도 있기 때문이다.
  • 35. 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다.
  • 36. 간결함-하지 않아도 되는 일의 양을 최소화하는 기술은 필수적이다.
  • 37. 최상의 아키텍처, 요구사항 그리고 설계는 자기조직화 (self-organizing)되어 있는 팀에서 나온다.
  • 38. 팀은 정기적으로 더 효과적으로 일할 수 있는 방법을 숙고하고, 그에 따라 자신/팀의 행동을 조율하고 조정한다.
  • 40. A specific methodology Agile Software Development Agile Method Practices Scrum Crystal Adaptive XP FDD RUPKanban Time-boxing User-stories Daily scrum Reviews Continuous Integration Test-driven Development Visual Management
  • 44. Suitable for all types of projects
  • 45. Need
  • 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%
  • 49. 운전 기사 어떤 놈이야~ 오른쪽으로 갔어야지 바보야! 아직 멀었나? 에어컨 좀 틀어주세요 AC 전 전거장에서 내렸어야 했는데 잔말 말고 그냥 따라와 시끄럽다 조용히 좀 가지! 대부분의 프로젝트는 시작도 하기 전에 실패한다.
  • 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) • 제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책 임자가 주로 우선순위를 결정 • 제품 백로그에 정의된 기능을 사용자 스토리라고 부르며 사용자 업무량에 대 한 추정은 주로 스토리 포인트라 불리는 기준을 이용
  • 80. | 스크럼 대시보드 (Scrum dash-board)
  • 81. | 스크럼 대시보드 (Scrum dash-board)
  • 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 • 스크럼은 고유의 프로세스 모델을 가지고 있지만 많은 기법들이 프로젝트에 참여하고 있는 개 개인의 경험에 기반. 스크럼은 기본적인 구조만 같을 뿐 실제로 일을 진행하게 되면 팀마다 달 라지는 것을 허용
  • 88. 모든 프로젝트는 고유하다. 끼워 맞추기 보다 맛있게 골라먹자
  • 89. - 어느 출근길(feat. 권혁 부장)
  • 90. 늘 하던 대로만 한다면, 늘 얻던 그만큼밖에 얻을 수 없다