Sk planet 이야기

PRODUCT OWNER
SCRUM MASTER
(Agile Coach) SCRUM TEAM
빠르게 살펴보는 Agile 그리고 SK Planet 이야기
고 종 범

1부. 애자일이란 무엇인가?
애자일의 정의와 철학

Agile 하면 생각나는 것들

Agile 이란 무엇인가?
프로젝트의 생명주기동안 반복적인 개발을 촉진한다.
애자일 방법론은 소프트웨어 개발 방법에 있어서
아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에
타협점을 찾고자 하는 방법론이다.
기민함, 날렵함

Agile 에 대한 정의 - 애자일 선언문
우리는, 소프트웨어를 개발하면서,
그리고 또한 다른 사람의 개발을 도와주면서
소프트웨어를 개발하는 더 나은 방법들을 찾아나가고 있다.
이 작업을 통해 다음과 같은 가치를 추 구하게 되었다.
프로세스나 도구 보다는 개인과 상호 작용을,
포괄적인 문서보다는 작동하는 소프트웨어를,
계약에 대한 협상보다는 고객과의 협력을,
계획을 고수하기 보다는 변화에 대응을 더욱 가치 있게 여긴다.
, 전자도 가치가 있긴 하지만, 우리는 후자 쪽에 더 많은 가치를 둔다는 것

Agile Values Framework
Agile
동작하는
소프트웨어
고객과의
협력
개인과의
상호작용
변화에
대응
책임감 신뢰
협력배움
신뢰 책임감 배움 협력
개방성 자율성 위험 투명성
진실성 / 청렴 동기 부여 피드백 자기 조직화
장인정신 헌신 적응성 의사소통
공감 / 존중 상호 책임 공유
단일성 / 공유된 목
표
참고 : Why Agile Works - http://www.infoq.com/minibooks/why-agile-works

Agile 에서 중요한 것
Values
Principles
Practices

SK Planet 의 Agile 측정하기
Values Principles
Communication
Respect Simplicity
Courage Feedback
Humanity
Economi
cs
Mutural
Benefit
Flow
Opportun
ity
Redunda
ncy
Self
Similarity
Improve
ment
Diversity
Reflectio
n
Failure
Quality
Baby
Steps
Accepted
Responsi
bility

아기 발걸음
품질
잉여
경제성/비전
용기

가치와 원칙을 지키기 위해서는

2부. 애자일에는 어떤 것들이 있는가?
Scrum, XP, Kanban

Scrum
* 출처 : 애자일 SW 개발 101

Scrum 구성원
PRODUCT OWNER SCRUM MASTER SCRUM TEAM

Scrum 구성원의 역할
• 보통 5~9명으로 구성되며 하나의 스프린트 기간 동안 구현해야 할 기능을 사용자
스토리로 도출하고 이를 구현
• 스프린트 동안 구현해야 하는 기능을 완료하기 위해 노력하며 이를 위한 권한을
갖고 있음
SCRUM
TEAM

Scrum Team 의 역할
SCRUM
TEAM
User Story Product
진행 상태
이슈 사항
기능 완료 책임
기능 구현 권한

Product Owner 의 역할
• 고객의 요구사항을 이해하고, 고객으로부터 의사결정에 대한 권한을 위임받아 제
품에 대한 사업적 비전을 가지고 있으며 제품의 성공에 대한 책임을 가진 사람.
• 제품 기능목록에 해당하는 제품 백로그(product backlog)를 만들고 우선순위를 조
정하거나 새로운 항목을 추가하는 일을 관리.
• 스프린트에 대한 계획을 수립할 때까지 중요한 역할을 하지만 스프린트가 시작되
면 최대한 팀 운영에 관여하지 않는 걸 권장
Area Responsibility
People
• 사용자와 고객의 Needs 에 대한 이해
• 개발팀과의 협업
• 이해 당사자들의 관계 관리
Strategy
• 사업적 모델 제시
• 제품 로드맵 제시
• 제품 UX 와 제품의 기능 목록 제시
Learning &
Delivery
• 다음 작업에 대한 목표 제시 : Sprint Goal, 상세 스토리
• 제품의 가치에 대한 수집과 분석
• 제품의 UX, 기능목록과 사업모델의 지속적 관리
• 개발 프로젝트에 대한 추적관리
• 제품 출시에 대한 관리
PRODUCT
OWNER

Product Owner 의 역할
PRODUCT
OWNER
Stakeholder
User
Scrum Team
제품의 비전
성공에 대한 책임
제품의 로드맵
요구사항 User Story
요구사항 결정권한
위임 우선순위

Scrum Master 의 역할
• 스크럼의 원칙과 가치를 지키면서 스크럼을 운영할 수 있도록 Leading 하는 사람
• 스크럼 팀이 개발을 진행할 수 있도록 코칭하고 지원
• 스크럼 팀의 의사소통을 중재하고 팀에서 발생하는 이슈를 찾아서 제거하기 위해
노력
Area Responsibility
Encourage
• 면대면(Face to Face) 커뮤니케이션
• 변화에 대한 적응 관리
• 발생하는 이슈를 찾고 이를 제거하기 위한 노력
Reflect
• Sprint 상태 정보에 대한 시각화 (Burndown Chart, Scrum
Boards)
• 스크럼 팀의 회고를 돕고 지속적 개선에 대한 도움
• 스크럼 도구 사용에 대한 도움
Facilitate
• 모든 회의와 행사에 대한 facilitater 역할
• 스크럼 팀의 Release 계획에 대한 도움
• 스크럼 팀의 지속성에 대한 관리
Learn &
Share
• 애자일에 대한 지속적 학습 수행
• 경험한 애자일에 대한 스크럼 마스터간의 공유
Reward &
Protect
• 스크럼 팀의 작은 성공에 대한 축하와 칭찬
• 외부 압력에 대한 스크럼 팀 보호
SCRUM
MASTER

Scrum Master 의 역할
SCRUM
MASTER
Scrum Leader
Scrum Coach
Facilitator
Change Agent
Scrum Team 에게 Scrum 을 적용하고 유
지하기
위해 Scrum 을 leading 하도록 한다.
Scrum 도입에 어려움을 겪는 팀원들을 위해서
Scrum 적용 및 업무수행에 대하여 coaching 하도록 한다.
Scrum Team 이 Scrum 을 진행하는 과정
에서 팀원간의 의사소통을 중재하고 팀에
서 발생하는 이슈에 대하여 해결 방법을
찾도록 한다.
Scrum 을 적용함에 있어서 발생하는 수많
은 변화에 대하여 관리를 하고 변화의 지
속성을 위해 끊임없이 변화를 유도하도록
한다.

Scrum Practices
Product
Backlogs
Sprint
Planning
Sprint
-
Daily
Scrum
Sprint
Review
Sprint
Retrospec
tive
Sprint
Backlogs
Scrum
Board
Burndown
Chart

Extreme Programing, XP
익스트림 프로그래밍

XP(eXtreme Programing)
1990년대 후반 켄트 벡(Kent Beck)을 중심으로 여러 엔지니어들이 프로젝
트를 진행하며 얻었던 교훈을 기반으로 효과적이라 생각되는 개발 기법을
모은 하나의 방법론
“성공을 준비하라.
성공에서 한 발짝 뒤로 물러나 자신을 보호하지 말라.
최선을 다한 다음 결과에 대처하라.
이것이 극단extreme 이다.”

익스트림 프로그래밍의 공동저자이자
아내
“신시아 안드레스”
심리학 석사
- 조직 행동론
- 의사 결정 분석
- 여성학
을 수행하는 사람에 포커스하기 때문에 심리학을 포

XP(eXtreme Programing) - 가치
Communication
Respect Simplicity
Courage Feedback

• 의사 소통은 단방향이 아니라 양방향이다.
• 우리는 한 팀이라는 느낌을 만들고 효과적으로 협동하려면 의사소통이 중요하다.
• 의사 소통은 가장 기본적인 가치이며 가장 중요한 가치이다.
Communication
Outside
Inside
행동
감정 지각
감정에 대한 감정
기대
열망(보편적 소망)
자기(Self)
사티어 빙산의사소통

• 제대로 작동할만한 (효과가 있을 법한) 가장 단순한 것은 뭘까?
• 불필요한 복잡성을 제거하는 쪽으로 기울이라는 것이다.
• 단순성을 성취하면 그만큼 의사소통해야 할 것도 줄일 수 있다.
Simplicity
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci

• 어떻게 하는 것이 '제대로' 하는 것인지 모를 수 있다.
• 오늘은 제대로 돌아가던 것이 내일은 그렇지 않을지도 모른다.
• 오늘 모든 것을 '제대로' 하는 데에 시간이 너무 걸려서 해결책을 다 구현하기도
전에 내일의 바뀐 상황이 그 해결책을 무효로 만들지도 모른다.
Feedback
돌이킬수 없는
늦은 피드백
Sprint 마다 빠른 피드백

• 실패하는 해결책을 버리고 새로운 해결책을 찾아 나서는 용기는 단순함을 북돋운다.
• 진짜 답변, 구체적인 답변을 추구하는 용기는 피드백을 낳는다.
• 다른 가치들과 조화를 이룰 때 강력해 진다.
• 진실을 말할 수 있는 용기는 의사소통과 신뢰를 자라게 한다.
Courage
행동 실수 결과
실수 예방 실수 관리
FAIL 이란 ? ‘배우는 과정의 첫번째 시도’ (First Attempt In Learning)

• 모든 사람은 인간으로서 동등한 가치를 지닌다.
• 팀에 속한 모든 개인의 기여를 존중해야한다.
• 개인의 경험과 지식에 대해서도 존중할 수 있어야 한다.
• 나도 중요한 사람이고 당신도 중요한 사람이다.
Respect
개인
개인
개인
개인
개인
팀
개인
개인
개인
개인
개인
팀

XP(eXtreme Programing) - 원칙
XP
Principles
XP
Principles
Humanity
Economi
cs
Mutural
Benefit
Flow
Opportun
ity
Redunda
ncy
Self
SimilarityImprove
ment
Diversity
Reflectio
n
Failure
Quality
Baby
Steps
Accepted
Responsi
bility

원칙 설명
인간성
(Humanity)
• 기본적인 안전 : 실직에 대한 두려움은 이 욕구를 위협한다.
• 성취감 : 자신이 속한 사회에 기여할 수 있는 기회와 능력
• 소속감 : 집단에서 자신의 존재 이유와 책임감을 끌어내며, 공유하는 목표에 기여할
수 있는 능력
• 성장 : 자신의 기술과 시야를 확장할 수 있는 기회
• 친밀감 : 다른 사람을 깊게 이해하고 다른 사람들에게도 깊이 이해 받을 수 있는 능
력
경제성
(Economics)
• 경제성을 인정하지 않는 SW 개발은 '기술적 성공'이라는 공허한 승리만 얻을 위험이
있다.
• 비즈니스 목표에 부합하며, 비즈니스 필요를 충족하는지 확실히 해두어라.
상호 이익
(Mutural Benefit)
• 내게 지금 이익이 되고, 나중에도 이익이 되고, 내 고객에게도 이익이 되는 실천방법
들을 찾는 것
• 가장 중요한 XP 의 원칙이지만 가장 고수하기 힘든 원칙이기도 하다.

원칙 설명
자기유사성
(Self-Similarity)
• 기존에 가지고 있는 해결책으로 새로운 문제를 해결하는데 적용해 보는 것은 좋은
시작점이다.
• 어떤 해결책의 구조를 다른 맥락에, 심지어 규모에 차이가 있는 다른 맥락일지라도
적용해 보라
개선
(Improvement)
• 개선을 통해 탁월한 소프트웨어 개발에 도달하는 것
다양성
( Diversity)
• 팀에는 다양성이 필요하다.
• 다양한 종류의 기술, 사고방식, 시야들이 모여 있어야 한다.
• 다양성의 원칙은 ‘전체 팀Whole Team’ 이라는 실천방법으로 표현된다.
반성
( Reflection)
• 좋은 팀은 그저 일만 하지 않으며, 어떻게 일하는지 왜 일하는지도 생각한다.
• 배움이란 행동이 반성을 거친 것이다.

원칙 설명
흐름
(Flow)
• ‘흐름'의 원칙은 개선을 위해 가치를 조금씩, 점진적으로, 계속해서, 자주 배치하라고
권한다.
• 일일 빌도도 흐름 원칙에 기반을 둔 실천 방법이다.
기회
(Opportunity)
• 생존'에만 집착하는 태도는 일을 무사히 넘길 정도까지만 문제를 해결하도록 만든다
.
• 뛰어난 실력을 갖추려면, 문제를 단지 생존의 문제가 아니라 배움과 개선의 기회로
전환할 줄 알아야 한다.
잉여
(Redundancy)
• SW 개발에서 핵심적이면서 해결하기 어려운 문제에는 해결방법을 여러 개 마련해
놓아야 한다.
• 짝 프로그래밍, 지속적인 통합, 함께 앉기, 진짜 고객의 참여, 매일 배치가 그 예다.

원칙 설명
실패
(Failure)
• 실패가 지식을 늘려주는 한, 그것은 허비가 아니다.
품질
(Quality)
• 낮은 품질을 감수한다고 프로젝트가 빨라지지 않는다.
• 높은 품질을 요구한다고 프로젝트가 느려지지도 않는다.
아기 발걸음
( Baby Steps)
• 단계를 잘게 쪼갤 때 생기는 부하가 큰 변화를 시도했다가 실패해서 다시 원상태로
돌아갈 때 드는 낭비보다 휠씬 작다는 사실을 인정하는 것이다.
받아들이는 책임
(Accepted
Responsibility)
• 어떤 일을 하겠다고 서명한 사람이 그 일의 평가도 내리는 것

XP(eXtreme Programing) - 실천방안
함께 앉기
개발 작업은 팀 전체가 들어가기에 충분할 정도로 크고 열린 공간에서 하라
전체 팀
프로젝트가 성공하기 위해 필요한 기술과 시야를 지닌 사람들을 전부 팀에 포함시켜라.
우리는 팀에 소속되어 있으며, 이 안에서 함께하고, 서로의 작업, 성장, 배움을 돕는다.
정보를 제공하는 작업공간
작업 공간을 작업에 대한 것들로 채워라. 프로젝트에 관심이 있는 관찰자라면 누구든지 팀이 사용하는 공간에
15초 안에 프로젝트가 어떻게 진행되는지 대략 감을 잡을 수 있어야 한다.
활기찬 작업
생산적으로 일할 수 있는 정도의 시간만, 그리고 일의 활력을 유지할 수 있는 정도의 시간만 일해라.
짝 프로그래밍
제품으로 출시할 프로그램을 두 사람이 컴퓨터 한 대에 앉아 작성해라
스토리
고객에게 가치를 줄 수 있는 최소한의 기능을 단위로 해서 계획하라
일주일별 주기
한 번에 일주일 분량의 일을 계획하라

XP(eXtreme Programing) - 실천방안
분기별 주기
한 번에 한 분기 분량의 일을 계획하라
여유
어떤 계획이든, 일정에 뒤쳐질 경우 포기할 수 있는 비교적 급하지 않은 업무를 포함시켜라
10분 빌드
10분 만에 자동으로 전체 시스템을 빌드하고 모든 테스트를 돌려라
지속적 통합
변경한 것은 두 세시간만에 통합하고 테스트해라
테스트 우선 프로그래밍
코드를 한 줄이라도 변경하기 전에 자동화된 테스트를 먼저 작성하라
점진적 설계
시스템의 설계에 매일 투자하라

께 팀의 가치와 원칙, 실천방안을 만들고 신청하는 것
“운전은 차를 똑바른 방향으로 가도록 맞추어 놓고 그대로 두는 게 아니야. 운전은 계속 신경을
이번에는 이쪽으로 조금, 다음에는 저쪽으로 조금씩 방향을 고치면서 가는 거지.”
불확실성

Lean & Kanban
• 도요타 자동차의 독특한 생산방식의 원칙과 실천법을 정리하는 데서 린(Lean)이라는 개념 은 시작되
• 린에서 중요한 개념은 JIT(Just In Time) 으로 필요한 시점에 필요한 만큼만 생산하는 것을 의미한다.
• 칸반(Kanban)은 일종의 작업 지시서로서 당김(Pull) 방식의 생산시스템을 구축하는데 중요한 역할을 합
• 스크럼은 Sprint 에서 할 일을 배분한다면 칸반은 큐에 쌓인 일을 할 수 있는 사람이 가져가 처리하는
• 칸반은 한 번에 진행되는 일의 수를 제한함으로써 지속적인 배포에 초점을 맞추고, 더 효율적으로 만들어준다
http://en.wikipedia.org/wiki/Kanban

Lean
“Muda, Muri, Mura”
“불필요, 불합리, 불균형”

개발 원칙
낭비를 제거하라.
파레토 법칙(2:8의 법칙)에 의거, 개발에 중요한 20%에 집중하고 낭비되는 요소(가외기능, 혼란, 경계 넘어가기)
품질을 내재화 하라.
개발 초기부터 각각의 SW 모듈에 대한 품질을 강조하고 제일 먼저 집중할 수 있도록 한다.
지식을 창출하라.
표준은 개선하기 위해 존재하는 것이며 과학적 방법을 통해 누구나 변경하고 장려할 수 있도록 해야 한다.
확정을 늦춰라.
마지막까지 변화를 수용할 수 있도록 코드를 작성한다. 돌이킬 수 없는 결정은 마지막에 내리라고 충고한다.
전체를 최적화하라.
고객 요구에서 SW 배포까지 전체적인 흐름에 초점을 맞춰야한다.
사람을 존중하라.
팀은 공동 목표를 달성하기 위해 자부심, 신뢰, 칭찬을 통해 맺어진 상호간의 책임의식을 가져야 한다.
빨리 인도하라.
한번에 전달되는 제품의 크기를 작게 하고 작업량을 줄여야 한다.
.

Kanban Recipe
품질에 집중한다.
진행 중 업무(WIP)를 줄인다.
자주 출시한다.
요구량을 처리량에 맞춘다.
우선순위를 부여한다.
예측성을 개선하기 위해 변동성의 원인을 공략한다.
잦은 출시를 하는
프로젝트에 적합
마지막에
개선을 통한
변화 시작
WIP(Work In Progress)
현재 진행 중인 업무로 실제로 처리할
수 있는 업무의 양으로 한정해야함.

핵심 실천 방안
.
시각화 한다.
진행 중 업무를
제한한다.
흐름을 관리한
다.
정책을
명시한다.
피드백 루프를
실행한다.
함께 개선하고
실험을 통해
발전시킨다.
http://www.slideshare.net/mrbin95/kanbannbt

Kanban Board - 시각화
참고 : http://www.slideshare.net/mrbin95/kanbannbt

WIP 제한

흐름 관리하기

피드백 루프

Practices in Active Sprint
스프린트를 수행하면서 하는 프랙틱스

TDD vs TAD
TDD : Test Driven Development TAD : Test After Development
• Test-First Development
• 테스트 코드를 먼저 만들고 테스트를 통과하는 프로
그램을 만드는 방식
• 코드 커버리지가 100%에 가까워 진다.
• 개발하면서 리팩토링이 가능하다.
• 품질 측면에서 좋은 방안이다.
• 생산성 측면에서 다소 시간이 많이 걸린다.
• Test-After Development
• 프로그램을 만든 후 이를 테스트 하기 위해 테스트
코드를 추가적으로 만드는 방식
• 코드 커버리지가 통상적으로 최대 75% 정도가 된다
.
• 리팩토링을 해야하는 경우 수정 범위가 넓어질 수
있다.
• 품질 측면에서 다소 떨어질 수 있다.
• 생산성 측면에서 시간을 절약할 수 있다.
요한 것은 품질을 위해서 테스트를 수행하는 행위 자체에 있다
테스트 코드가 있다는 것은 리팩토링 하기 용이하다는 것이다

Pair/Mob Programming
Pair Programming Mob Programming
• 두 사람이 진행하는 방식
• Driver, Navigator 로 구분
• Driver 를 번갈아 가면서 진행
• 교대 시간은 두 사람이 합의하에 교대
• 하나의 PC 를 이용
• 모니터 공유 등 확장 기능을 통해 두대의 PC 사용
도 가능
• 3명 ~ 5명(다수) 가량이 진행하는 방식
• 1명의 Driver 와 다수의 Navigator
• Product Owner 의 참여가 가능
• 교대 시간은 참여자의 합의하에 교대
• 다수가 참여하는 만큼 빔 프로젝트나 대형 모니터를
사용
• Mobbing 하는 중에 필요에 따라 개인 업무를 위해
빠져나갈수 있음
수가 함께 하는 작업인 만큼 협의한 규칙이나 퍼실리테이션이 필

Code Review
Off-line On-line
• 코드 리뷰 미팅 요청
• 사전에 리뷰할 코드의 범위를 제시하는 것을 권장
• 다수가 참여하는 만큼 빔 프로젝트 등을 사용
• 경우에 따라 퍼실리테이터를 두는 것을 권장
• 리뷰어는 코딩 컨벤션에서부터 알고리즘까지 조언
가능
• 조언 받은 사항은 빠른 시일내에 반영후 공유
• Gerrit, Stash 등의 도구를 이용
• 도구를 이용하여 리뷰 신청
• 리뷰어가 리뷰하고 코멘트 추가
• 필요한 경우 오프라인으로 만나서 구두로 설명
• 리뷰어는 가능한 당일 리뷰하는 것이 좋음
• 리뷰어는 코딩 컨벤션에서부터 알고리즘까지 조언
가능
• 코멘트한 부분을 수정후 리뷰어가 승인하는 과정이
있음
뷰는 보다 나은 디자인과 보다 나은 코드가 무엇인지 배우는 단
잘못을 탓하거나 실력을 평가하는 시간이 되어서는 안된다.

Continuous Integration
소개
• CI 는 팀이 작업한 소스코드, 데이터베이스 스크립트, 코드 검사(Inspection), 자동화 테스트 등을 가능하
면 자주 통합하는 소프트웨어 개발 실천법이다.
• 자주 통합하고 검증함으로써 최신 코드가 항상 건강한 상태인지 확인할 수 있으며, 통합 주기를 짧게 가져
감으로써 오류 발생 시 원인 파악을 신속하게 할 수 있다.
• 최소 하루 한번 이상 통합을 진행하는 것을 권장한다.
• 자동화된 빌드를 통해 가능한 빨리 통합 에러가 없는지 검증하는 작업이다.
필요 사항
• 코드 저장소(Code Repository) : SVN,
GIT
• CI 통합 서버 : Hudson, Jenkins
• 빌드 도구 : Ant, Maven, Gradle

Practices 영향 관계도
Test-Driven
Development
Refactoring
Test-After
Development
Clean
Code
Code Review
Configuration
Management
(SK Valley)
CQI (Sonar)
Continuous
Delivery
(Javis)
Continuous
Integration
(Jenkins)
Scrum Meeting
Frequent Release
(Kanban)
Scrum Sprint
Retrospective
Planning Meeting
Scrum Board
Kanban Board
Issue Tracking
System
(JIRA)
Review
Meeting
Stakeholder
Long-Term
Release
(Scrum)
Pair
Programming
Work In Progress
(WIP)
Static AnalysisCoding Convention

3부. SK Planet 에서의 Agile
Agile Coach 기반의 확산 방법론

SK Planet 의 Agile 확산 방법론
다양성의 존중

Agile 방법론의 종류
XP
(eXtreme
Programming)
Scrum
Kanban
Feature-Driven
Development
Lean Software
Development
Agile 에는 다양한 방법론이 존재한다.

Agile 방법론의 종류별 도입 Case 예제
XP
(eXtreme
Programming)
Scrum
Kanban
불확실성이 높은 경우, 적은 인원, Release 일정 없음, 빠르게 실험할 경우
Pair Programming, Mob Programming 등이 가능한 경우
불확실성이 대체로 낮은 경우, 많은 인원, 3개월 이상의 기간, 납기 준수
잦은 Release 를 수행해야하는 경우
기획, 설계, 개발, 테스트 등 절차적으로 수행하고자 하는 경우
한 제품 혹은 한 서비스의 주기적 업그레이드가 필요한 운영성 업무
Case 예제
어떤 방법이 옳은 것인지 명확한 가이드는 존재하지 않음

조직의 다양성과 Agile 방법론
애자일 한 팀역량 중심의 팀협업 중심의 팀개인별 과제수행 팀
팀의 다양성
사업의 다양성
서비스 사업 플랫폼 사업
Consumer
Product
Merchant
Product
과 같이 단일 방법론으로 조직확산이 안되는 이유는 다양성에

조직의 다양성과 Agile 방법론
복잡한 방식으로 풀수 밖에 없다. 다양한 방법론 도입으로
XP Scrum Kanban
Agile

Agile 확산 접근 방법
팀의 특성을 파악하고, 적절한 방법론을 찾고, 변화를 시작해야
게 하기 위해서는 Change Agent 인 Agile Coach 가 수행할 수
관찰하기 측정하기 흐름제어
애자일
도입하기
지속적
변화통제
실제 도입 시점현재

Agile Coach 양성과 Agile 확산
SACT(SKP Agile Coach Training)
Scrum Master - Practices
Scrum Master -
Coaching
애자일 SW 개발 101 워크숍
Agile 의 가치가 무엇이고, 어떤 애자일 방법론들이 있는지 학습하며, 애자일을 SW 개발에 실
제로 적용하기 위해 어떤 노력을 해야하는지 배우게 되는 과정으로 가장 널리 사용되는 스크
럼 기반의 프로젝트 진행방법을 경험하는 과정
Agile
Coach
전문가 과
정
Scrum
Master
과정
Scrum
Team
전사 과정
Scrum 에 대한 상세한 방법에 대하여 학습
하고
Scrum Master 의 역할에 대하여 학습하는
과정
- 애자일 개론 및 실천방안
- 스크럼 마스터의 역할
Scrum Master 가 갖추어야한 Coaching 방
법에 대하여학습하고 연습하는 과정
- 애자일 코칭 기법
- 애자일 코칭 연습
Agile 개론과 철학에 대하여 깊이있게 탐구하고 Agile Coach 가 갖추어야 하는
Coaching 방법에 대하여 학습하고 연습함으로써 개인과 조직이 더 효과적이 될 수 있게
코치가 되는 과정
- 조직문화, 습관설계, 코칭 기법, 퍼실리테이션, 측정과 실험
- 애자일 개론과 철학, 애자일 기술적 실천법
Agile Coach
Community
Improvement
전사적으로는 “애자일 SW 개발 101 워크숍”을 통해
Scrum 을 학습하고, SACT 와 Scrum Master 과정을 통해
Agile Coach 를 양성하고, 적극적인 관심을 같은 Agile
Coach들이 서로 커뮤니케이션 하면서 애자일 확산을 점진
적으로 진행하도록 한다.

Agile Coach Community
: SACI (SK Planet Agile Coach Improvement)
애자일 사례 학습 이슈 연구 및 해결안 모색친선을 통한 회복 코칭 연습
Agile Coach 간의 다양한 활동을 통해 점진적
애자일 전파
학습 지식 및 이슈 사례에 대한 공유 및 발표
@Tech SocialCast
ReadmeSeminar

Agile Coach 를 기반으로 한 Agile 확산 방법론
산은 매우 복잡한 문제이다. 때문에 복잡한 방법으로 접근해
또 복잡한 문제를 점진적으로 풀어나가기 위해서는
지속력있는 Agile Coach가 점진적으로 수행하여야 한다.

Agile 에 대한 오해와 당부
Agile 은 방법론 그 이상의 것이다.

애자일에 대한 오해 - 애자일은 쉽다?
애자일은 더 많은 것을 알아야 하고, 더 많은 것을 수행해야

애자일에 대한 오해 - 애자일은 쉽다?
애자일 도입과 함께 혼돈의 시기가 찾아오기 마련입니다.
돈의 시기가 끝난후 통합의 시기를 거쳐 새로운 상태로 거듭나기까지 지속적인 노력이 필요합니

애자일에 대한 오해 - 애자일은 OOO이 필요 없다.
계획 설계 문서 QA
애자일 방법론은 소프트웨어 개발 방법에 있어서
아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에
타협점을 찾고자 하는 방법론이다.

애자일에 대한 오해 - 애자일을 도입하면 빠르게 만들수 있다
짧은 기간에 동작하는 제품을 만들기 때문에
빠르게 만드는 것처럼 보일 수 있다.

애자일에 대한 오해 - 프로젝트 성공률을 높여준다?
작은 프로젝트가 성공률이 높다. 큰 프로젝트를 작게 나누어서 하는 것이 성공률이 높다
The Standish Group 의 CHAOS MANIFESTO 2013

애자일에 대한 오해 - 프로젝트 성공률을 높여준다?
The Standish Group 의 CHAOS MANIFESTO 2013
로세스를 포함해 애자일 철학에 들어있는 것들이 성공률을

당부의 말씀
개별 팀의 특성을 파악하고,
우리에게 맞는 적절한 방법론을 찾아서,
지속적인 개선을 통해 변화를 시작해야 한다.

Sk planet 이야기

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Sk planet 이야기

Ähnlich wie Sk planet 이야기 (20)

Sk planet 이야기

Hinweis der Redaktion