Sk planet 이야기

PRODUCT OWNER

SCRUM MASTER(Agile Coach) SCRUM TEAM

빠르게 살펴보는 Agile 그리고 SK Planet 이야기

고 종 범

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

Agile 하면 생각나는 것들




Agile 이란 무엇인가 ?

프로젝트의 생명주기동안 반복적인 개발을 촉진한다 .

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다 .

기민함 , 날렵함

Agile 이란 무엇인가 ?

Agile 에 대한 정의 - 애자일 선언문우리는 , 소프트웨어를 개발하면서 ,

그리고 또한 다른 사람의 개발을 도와주면서 소프트웨어를 개발하는 더 나은 방법들을 찾아나가고 있다 .

이 작업을 통해 다음과 같은 가치를 추 구하게 되었다 .

프로세스나 도구 보다는 개인과 상호 작용을 ,

포괄적인 문서보다는 작동하는 소프트웨어를 ,

계약에 대한 협상보다는 고객과의 협력을 ,

계획을 고수하기 보다는 변화에 대응을 더욱 가치 있게 여긴다 .

이 말은 , 전자도 가치가 있긴 하지만 , 우리는 후자 쪽에 더 많은 가치를 둔다는 것이다 .

Agile Values Framework

Agile

동작하는 소프트웨어

고객과의협력개인과의상호작용

변화에대응

책임감 신뢰

협력배움

신뢰 책임감 배움 협력개방성 자율성 위험 투명성

진실성 / 청렴 동기 부여 피드백 자기 조직화장인정신 헌신 적응성 의사소통

공감 / 존중 상호 책임 공유 단일성 / 공유된 목표

참고 : Why Agile Works - http://www.infoq.com/minibooks/why-agile-works

http://www.infoq.com/minibooks/why-agile-works

Agile 에서 중요한 것ValuesPrinciples

Practices

SK Planet 의 Agile 측정하기

Values Principles

Communication

Respect Simplicity

Courage Feedback

Humanity

Economics

Mutural Benefit

Flow

Opportunity

Redundancy

SelfSimilarit

y

Improvement

Diversity

Reflection

Failure

Quality

Baby Steps

Accepted

Responsibility

SK Planet 의 Agile 측정하기

SK Planet 의 Agile 측정하기아기 발걸음품질잉여

경제성 / 비전

용기

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

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

Scrum스크럼

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

UserScrum 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

ProductBacklogs

SprintPlanning

Sprint-

Daily Scrum

SprintReview

SprintRetrospe

ctive

SprintBacklogs

ScrumBoard

Burndown

Chart

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

XP(eXtreme Programing)


1990 년대 후반 켄트 벡 (Kent Beck) 을 중심으로 여러 엔지니어들이 프로젝트를 진행하며 얻었던 교훈을 기반으로 효과적이라 생각되는 개발 기법을 모은 하나의 방법론“성공을 준비하라 .

성공에서 한 발짝 뒤로 물러나 자신을 보호하지 말라 . 최선을 다한 다음 결과에 대처하라 .

이것이 극단 extreme 이다 .”


익스트림 프로그래밍의 공동저자이자 아내“신시아 안드레스”심리학 석사- 조직 행동론- 의사 결정 분석- 여성학

XP 에는 일을 수행하는 사람에 포커스하기 때문에 심리학을 포함하고 있다 .

XP(eXtreme Programing) - 가치Communicati

on

Respect Simplicity

Courage Feedback

XP(eXtreme Programing) - 가치• 의사 소통은 단방향이 아니라 양방향이다 .• 우리는 한 팀이라는 느낌을 만들고 효과적으로 협동하려면 의사소통이 중요하다 .• 의사 소통은 가장 기본적인 가치이며 가장 중요한 가치이다 .

Communication

Outside

Inside

행동

감정 지각감정에 대한 감정

기대열망 ( 보편적 소망 )

자기 (Self)

사티어 빙산의사소통

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

Simplicity

Simplicity is the ultimate sophistication. ~ Leonardo da Vinci

XP(eXtreme Programing) - 가치• 어떻게 하는 것이 ' 제대로 ' 하는 것인지 모를 수 있다 .• 오늘은 제대로 돌아가던 것이 내일은 그렇지 않을지도 모른다 .• 오늘 모든 것을 ' 제대로 ' 하는 데에 시간이 너무 걸려서 해결책을 다 구현하기도 전에 내일의 바뀐 상황이 그 해결책을 무효로 만들지도 모른다 .

Feedback

돌이킬수 없는늦은 피드백

Sprint 마다 빠른 피드백

XP(eXtreme Programing) - 가치• 실패하는 해결책을 버리고 새로운 해결책을 찾아 나서는 용기는 단순함을 북돋운다 .• 진짜 답변 , 구체적인 답변을 추구하는 용기는 피드백을 낳는다 .• 다른 가치들과 조화를 이룰 때 강력해 진다 .• 진실을 말할 수 있는 용기는 의사소통과 신뢰를 자라게 한다 .

Courage

행동 실수 결과

실수 예방 실수 관리

FAIL 이란 ? ‘ 배우는 과정의 첫번째 시도’ (First Attempt In Learning)

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

Respect

개인개인

개인

개인

개인

팀개인

개인개인

개인

개인

팀

XP(eXtreme Programing) - 원칙

XPPrinciples

XPPrinciples

Humanity

Economics

Mutural Benefit

Flow

Opportunity

Redundancy

SelfSimilarit

yImprove

ment

Diversity

Reflection

Failure

Quality

Baby Steps

Accepted

Responsibility

XP(eXtreme Programing) - 원칙원칙 설명

인간성(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 & Kanban

Lean & Kanban

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

http://en.wikipedia.org/wiki/Kanban

http://en.wikipedia.org/wiki/Kanban

Lean

“Muda, Muri, Mura”

“불필요 , 불합리 , 불균형”

Lean

Lean

Tom & Marry Poppendieck

개발 원칙낭비를 제거하라 . 파레토 법칙 (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


Kanban Board - 시각화



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-DrivenDevelopmen

t

Refactoring

Test-AfterDevelopmen

t

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 TrackingSystem(JIRA)

Review Meeting

Stakeholder

Long-Term Release(Scrum)

Pair Programmin

g

Work In Progress(WIP)

Static AnalysisCoding Convention

3 부 . SK Planet 에서의 AgileAgile 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 방법론

애자일 한 팀역량 중심의 팀협업 중심의 팀개인별 과제수행 팀팀의 다양성

사업의 다양성

서비스 사업 플랫폼 사업 ConsumerProduct

MerchantProduct

Scrum 과 같이 단일 방법론으로 조직확산이 안되는 이유는 다양성에 있다 .

조직의 다양성과 Agile 방법론복잡한 문제는 복잡한 방식으로 풀수 밖에 없다 . 다양한 방법론 도입으로 접근해야한다 .

XP Scrum Kanban

Agile

Water-Scrum-Fall

Scrumban

Agile 확산 접근 방법개별 팀의 특성을 파악하고 , 적절한 방법론을 찾고 , 변화를 시작해야한다 .그렇게 하기 위해서는 Change Agent 인 Agile Coach 가 수행할 수 있다 .

관찰하기 측정하기 흐름제어 애자일도입하기 지속적변화통제

실제 도입 시점현재

Agile Coach 양성과 Agile 확산

SACT(SKP Agile Coach Training)

Scrum Master - Practices

Scrum Master - Coaching

애자일 SW 개발 101 워크숍Agile 의 가치가 무엇이고 , 어떤 애자일 방법론들이 있는지 학습하며 , 애자일을 SW 개발에 실제로 적용하기 위해 어떤 노력을 해야하는지 배우게 되는 과정으로 가장 널리 사용되는 스크럼 기반의 프로젝트 진행방법을 경험하는 과정

AgileCoach전문가 과정

ScrumMaster과정

ScrumTeam전사 과정

Scrum 에 대한 상세한 방법에 대하여 학습하고 Scrum Master 의 역할에 대하여 학습하는 과정- 애자일 개론 및 실천방안- 스크럼 마스터의 역할

Scrum Master 가 갖추어야한 Coaching 방법에 대하여학습하고 연습하는 과정- 애자일 코칭 기법- 애자일 코칭 연습

Agile 개론과 철학에 대하여 깊이있게 탐구하고 Agile Coach 가 갖추어야 하는 Coaching 방법에 대하여 학습하고 연습함으로써 개인과 조직이 더 효과적이 될 수 있게 코치가 되는 과정- 조직문화 , 습관설계 , 코칭 기법 , 퍼실리테이션 , 측정과 실험- 애자일 개론과 철학 , 애자일 기술적 실천법

Agile CoachCommunity

Improvement

전사적으로는 “애자일 SW 개발 101 워크숍”을 통해 Scrum 을 학습하고 , SACT 와 Scrum Master 과정을 통해 Agile Coach 를 양성하고 , 적극적인 관심을 같은 Agile Coach 들이 서로 커뮤니케이션 하면서 애자일 확산을 점진적으로 진행하도록 한다 .

Agile Coach Community : SACI (SK Planet Agile Coach Improvement)

애자일 사례 학습 이슈 연구 및 해결안 모색친선을 통한 회복 코칭 연습

Agile Coach 간의 다양한 활동을 통해 점진적 애자일 전파

학습 지식 및 이슈 사례에 대한 공유 및 발표

@Tech SocialCastReadmeSeminar

Agile Coach 를 기반으로 한 Agile 확산 방법론

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

Agile Coach 의 활동 사례

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

애자일에 대한 오해 - 애자일은 쉽다 ?

사실 애자일은 더 많은 것을 알아야 하고 , 더 많은 것을 수행해야 한다 .

애자일에 대한 오해 - 애자일은 쉽다 ?

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

애자일에 대한 오해 - 애자일은 OOO 이 필요 없다 .

계획 설계 문서 QA

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다 .

애자일에 대한 오해 - 애자일을 도입하면 빠르게 만들수 있다 ?

짧은 기간에 동작하는 제품을 만들기 때문에 빠르게 만드는 것처럼 보일 수 있다 .

애자일에 대한 오해 - 프로젝트 성공률을 높여준다 ?

작은 프로젝트가 성공률이 높다 . 큰 프로젝트를 작게 나누어서 하는 것이 성공률이 높다 .

The Standish Group 의 CHAOS MANIFESTO 2013

애자일에 대한 오해 - 프로젝트 성공률을 높여준다 ?

The Standish Group 의 CHAOS MANIFESTO 2013

애자일 프로세스를 포함해 애자일 철학에 들어있는 것들이 성공률을 높여준다 .

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

Engineering

Sk planet 이야기