1/41

Xper

Agile 2010 공유회2010년 9월 16일(목)

심우곤

Mail: wgshim@gmail.com, Twitter: @wgshim

2/41

계획: 테네시 주, 내쉬빌Gaylord Opryland Resort

3/41

Flood!!

http://en.wikipedia.org/wiki/2010_Tennessee_floods

May 1~2

4/41

변경: 플로리다 주, 올랜도Walt Disney World Dolphin Resort

5/41

6/41

숫자로 살펴보는

Agile 2010

7/41

227/934

8/41

24%

9/41

180

10/41

34

11/41

1,400+

12/41

무엇이 크게 달라졌나?

13/41

강화/신설된 트랙

• Business Track

• UI/UX Track

• Research Track

• Engineering/Technical Track

14/41

늘고 있는 한국 참가자

Agile 2008 4명LG전자 (2),

LG CNS (2)

Agile 2009 6명LG전자 (3),

삼성 SDS (3)

Agile 2010 8명

LG전자 (2)

LG CNS (3)

삼성 SDS (3)

15

분위기

16/41

17/41

Video 시청

http://www.youtube.com/watch?v=BGnFmZ4Sx_Q

(00:15” ~ 01:00, 03:10” ~ 03:30”, 05:25” ~ 05:45”)

18/41

분위기

• Kanban 도입이 대세

• Programmer 를 위한 Practical 세션 부족

19

저의 참가 목적

20/41

참가 목적

• 회사 차원의 Agile 확산 전략/경험

• 외주/협력사에 Agile/Scrum 적용 사례

• 관련 해외전문가 접촉

21

소감 및 메시지

22/41

소 감

• 영어 압박! ㅡ,.ㅡ

– 대부분의 세션이 토론/참여 식

• 우리 나라 사례도 충분히 발표할 수 있다.

– 비슷한 수준의 고민

• 일본인들의 참여도 높음

• 기본에 충실하지 않고 유행을 따르면 走火入魔 에 빠진다!!

• 코딩능력이 있는 테스터들이 과반수 이상!

23/41

Insightful Message

• Architect 가 별도로 존재해서는 앆 된다. Architect 는 역할일 뿐이다.

– 품질이 특정 부서의 일이 되어서는 앆 된다.

24

세션 내용 공유

3 개만!!

25/41

An Unplugged Retrospective on the Agile Decade : "Mirror Mirror on the wall are we really the most beautiful of all?"

• Bedarra Research Lab. (founder)

• Object Mentor (managing director)

Dave Thomas

Ⅰ

26/41

기억에 남는 것

• Agile 이 무계획, 문서 X, ... 과 같이 잘못 이해하는 경우가 많다.

• 작금의 Agile 의 자격 중시 대한 풍자.– 인증(Certification) Return to Craftsmanship!!

• TDD 에서의 Done 의 의미: Unit & Acceptance Tested!– Practice! before Method & Tools– Practice first! method is set of practices– Tools & Automation streamline development

27/41

기억에 남는 것 (계속)

• Lean and Agile– Lean is a top-down process

– Agile is a bottom up team centered process

• 아키텍트는 역할이지 직업이 아니다.– 자싞이 코딩을 수행할 수 없는 사람은

설계자로 문제가 있다.

• Estimates must be ranged to include risk– min, max or min, max, expected

28/41

현재 처한 문제점

• IT 가 가치를 제공하기 보다는 비용을 소모하는 경향이 있음

– Many biz executives still don't understand IT

– Agile is FrAgile as it depends on sustainable leadership and discipline

• Skills are in relatively short supply

29/41

몇 가지 가능한 해결책

• 교육

– Teamwork teaching, story telling

– Invest in non CS education

– Enable more end user programming

• SW 개발

– Use more expressive higher level language (SICP 책강추)

– Smaller programs which are loosely coupled

– Design for change (e.g., more data driven)

30/41

How Agile Taught IBM About New Leadership Competencies

• VP of Development Transformation at IBM

• VP of Engineering at Pitney Bowes Inc 2010

Sue Mckinney

Ⅱ

31/41

IBM 의 SW 그룹 특성

• 짂정한 글로벌 팀

– 전세계, 25,000 명 이상

• 엄청나게 많은 회사를 인수/합병

– 매년 10개 정도

• 변화:

– 80년대(Waterfall)

– 90년대(Iterative)

– 2006년부터(Agile)

32/41

변화 시도

• 처음에는 2명이 문서 없이 교육

• 250 회 이상의 워크샵 실시

– 관심 있는 사람들 중심으로

• 8,000 명 이상 교육

• 현재 70% 이상의 팀이 Agile 을 사용

– 한 가지 이상의 Agile Practice 를 사용

33/41

교 훈

• 프로세스 개선 + 경영짂 설득

– Pull and push model

• Agile CoC (Center of Competence) with full time coaches

• When to mandate, measure or motivate

• one size fits all 이란 없다!!

34/41

“Short, time box iterations with stakeholder feedback –

working software”

35/41

결 론

• Give up command & control (=> recipe style)

• the opposite of control is discovery

• free the team to question, analyze

• create a place where people want to be not have to be

• give people what they need to succeed

• support from senior leaders

• create small successes and share

36/41

핵심: 신뢰를 쌓아라!!

• Create a culture of TRUST

– 높은 싞뢰의 회사가 그렇지 않은 회사 대비10년 간 경영성과 2 배

– 높은 싞뢰의 회사가 그렇지 않은 회사 대비43% 높은 생산성

37/41

Arto Eskelinen, Sami Honkonen

http://bit.ly/aVSS3c

Ⅲ

38/41

질 문• What

• When

• Who

• How many

• How much

•How

•Who (blame)

•Why What, When, …

39/41

GROW Model

GGoal

목표고객이 원하는 궁극적인 상태

RReality

현실성

목표 대비 현 상태를 파악하고,

목표를 달성하기 위한 단계와 방법에 집중

(※ Goal 과 동일한 용어로 기술)

O

Obstacles

장애요소목표 달성을 방해하는 장애요소 파악

Options

대안장애요소를 해결/회피하기 위한 대앆들을 마련

WWay Forward

실행 방안구체적이고 실행 가능한 액션 아이템

40/41

시나리오 I

과거 3 ~ 4 차례의 회고를 통해 팀은 문제를야기하던 장애요인들을 식별하였습니다. 매번 팀은 장애요인을 해결/제거하기 위해 몇가지 액션 아이템들을 도출하였습니다. 팀은여러 차례 도출된 액션 아이템들을 실행하지못했고, 문제는 여전히 남아있음을 알게 되었습니다. 이제 팀원들은 더욱 열심히 일하기로 결정하였습니다.

41/41

시나리오 II

당싞은 팀원 몇 명이 모여 그 자리에 없는사람에 대해 이야기 하는 것을 우연히 듣게되었습니다. “어제 퇴귺하기 직전에 김 대리가 또 컴파일 되지 않는 코드를 체크인 했지뭐야. 덕분에 수정하느라 한 시간 동앆 남아있어야 했다구.”