2013년 6월 27일 (목), 오마실에서 애자일에 대해 소개하는 발표

부르스 페일러(Bruce Feiler): 가정을 위한 애자일 프로그래밍

http://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family.html (자막)

부루스 페일러는 급진적인 아이디어를 가지고 있습니다. 현대 가정의 스트레스를 다루기 위해, 애자일 방법론을 사용하세요. 애자일 소프트웨어 프로그래밍에서 영감을 얻어, 페일러는 융통성과 아이들로부터의 아이디어와 지속적인 반응과 책임을 북돋아주는 가정 활동을 소개합니다. 한가지 놀라운 점은 아이들이 스스로 처벌을 정한다는 것이죠.

1. 항상 적응하라.

애자일 시스템의 위대한 점은 변화하는 시스템을 만드는 것이고, 그래서 실시간으로 일어나는 일에 대응할 수 있게 되지요. 6개월 전에 했던 일을 오늘 똑같이 한다면, 일을 잘못하고 있는 것입니다. 가족 식사 시간을 옮기는 것이 바로 융통성인거죠.

2. 아이들에게 힘을 실어주세요.

아이들이 스스로 자라도록 해주세요. 스스로 독립적이 되도록 연습할 기회를 주는 겁니다. 워렌 버핏의 은행가와 얘기할 때, 제가 아이들이 스스로 용돈을 가지고 실수하도록 내버려두지 않는다고 나무라더군요. 제가 "하지만 아이들이 막다른 곳으로 치닫는다면요?"고 하자, 그는 "6불의 용돈을 가지고 실수하는 것이 6만 불의 연봉이나, 6백만 불의 유산을 가지고 실수하는 것보다 훨씬 낫지요."라더군요.

3. 여러분의 이야기를 들려주세요.

큰 줄거리의 일부분으로 스스로를 인식하고 있는 아이가 더 큰 자신감을 가지고 있다고 합니다. 여러분의 이야기를 하라는 것입니다. 가족의 아름다웠던 순간들을 상기시켜주고 힘들었던 시간을 어떻게 극복했는지를 얘기하는데 시간을 투자하세요. 아이들에게 이 행복한 이야기를 해준다면 바로 아이들에게 스스로 더 행복해질 수있는 도구를 주는 것입니다.

IT 프로젝트의 현재

방대한 산출물

돌이킬 수 없는 일정

번거로운 보고체계. 진척율은 10% -> 30% -> 50% -> 70% -> 90% -> 99% -> 99.9% -> 99.9% -> 99.9% -> ...

결과는?

동부화재, 1500억 들인 차세대 사실상 ‘실패’

• 자원 예측 실패 : 구입한 솔루션이 있는데, 프로젝트가 진행될수록 최초 산정 용량의 2~4배 규모가 필요하게 되어 자원 예측에 실패. 비용 증가 및 후반 투입 대응 불능.

• 잦은 변경 : 프로그램 작성 과정에서 고객의 요구, 즉 동부화재의 프로그램 변경 요구가 많았다는 주장이 제기. 많은 공을 들여 프로그램을 작성하고, 화면을 제작해 화재 직원들을 상대로 확인을 거치면, 같은 업무에 대해 수차례 재작업 요구를 하는 등 발주처 횡포가 만만치 않았던 것으로 보인다. 당연히 기간은 정해져 있고, 업무량도 많은데 같은 업무를 수차례 반복하면서 일정을 맞추기 쉽지 않았다는게 업계 전언이다.

• 폭탄 돌리기 : 연내 오픈 불가능하다는 판단이 서자, 이전의 총괄 상무를 경질하고, CIO가 투입되어 특단의 조치를 취함. 조직 내 주도권 싸움을 벌이며 그룹 감사 부서에 투서 및 진정이 난무.

외국 사례

• 영국 국가보건서비스(NHS) IT 현대화 프로그램: 스케줄보다 2년 지체. 100억 달러의 예산이 초과. 주요 계약 업체 iSoft는 도산 일보 직전.
• 미국 공군의 ERP 프로젝트: 2005년 시작, 2012년 폐기. 1억 달러 손실을 남기고 프로젝트 실패. 프로젝트를 계속할 경우 종료시까지 1억 달러 추가 예상. 2005년 계약 당시 오라클은 8천만 달러에 입찰.

• The scariest software project horror stories of 2012

애자일의 형성

이전의 소프트웨어 개발은 문서 중심의, 무거운 개발 프로세스였음. 이에 더 나은, 현실적인 소프트웨어 개발 과정에 대한 고민들이 시작됨.

그 중 한 흐름이 애자일.

기민한, 민첩한, 유연한, 반응이 빠른, 적응력이 뛰어난

애자일 선언

2001년, AgileManifesto가 발표됨. XP, SCRUM, DSDM, CrystalFamily 등의 각자의 방법론의 대표들이 함께 모임.

애자일 선언

• 공정과 도구보다 개인과 상호작용을

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

• 계약 협상보다 고객과의 협력을

• 계획을 따르기보다 변화에 대응하기를

이전의 소프트웨어 개발은, '주문, 설계, 제작'의 one-pass로 이루어졌다.

애자일 선언 이면의 12가지 원칙

우리는 다음 원칙을 따른다:

1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

7. 작동하는 소프트웨어가 진척의 주된 척도이다.

8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.

9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

10. 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.

11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

사실 너무 많다. 배경이나 구조화가 이루어지지 않으면 각자각자로 보인다.

누가 썼는가? 그들의 배경의 공통점은 무엇인가? 어디서 영향을 받았는가? 그 원류는 애자일 이외의 다른 분야에 어떤 영향을 주었는가?

뭐가 좋은가?

VersionOne이라는 회사에서 매년 애자일 도입 현황 조사를 한다. 다음은 2011년 레포트 결과 중 일부이다.

왜 애자일을 도입했는가?

1. 생산성 향상을 위해 (83%)
2. 시장 출시 속도(time to market)를 가속화하기 위해 (80%)
3. 변화하는 우선순위에 대응하기 위해 (77%)

애자일 도입으로 얻은 효과는?

1. 변화하는 우선순위를 대응할 수 있는 능력 (84%)
2. 프로젝트 가시성(visibility) 향상 (77%)
3. 생산성 향상 (75%)
4. 팀 사기 향상 (72%)
5. 빠른 시장 출시(time to market) (71%)

도입한 애자일 종류

1. SCRUM (52%)

2. SCRUM/XP Hybrid (14%)

3. Custom Hybrid (9%)
4. Don't Know (8%)

도입한 애자일 실천법

1. Daily Scrum (78%)
2. Iteration Planning (74%)
3. Unit Testing (70%)
4. Release Planning (65%)
5. Burndown (64%)
6. Retrospective (64%)
7. Continuous Integration (54%)
8. Automated Builds (53%)
9. Velocity (52%)
10. Coding Standards (51%)

Scrum

스크럼은 여러 애자일 학파 중 가장 간단한 프레임워크를 가짐.

세일즈 조직의 Scrum 도입 사례

JeffSutherland의 컨설팅 사례. Agile2011에서 발표된 페이퍼.

기존 세일즈 조직의 상황

개개인의 작업과 진척도에 초점을 둠

서로 목표나 세일즈 방법 등에 대한 커뮤니케이션이 없었음. 주로 CRM 시스템을 통해 일함. 각자의 일하는 프로세스는 블랙박스이고 성사 계약 수와 규모 정도만 공유됨. 주 초에 각자의 실적 예상치를 공유하고, 주말에 실제 실적을 공유함.

세일즈는 태생적으로 예측 불가능하다고 믿음

각자 작업의 진척도를 제한적으로 볼 수 있다는 점 뿐만 아니라, 응집된 프로세스가 없었음. 세일즈 조직 전체 성과를 보기보다는 개개인의 성과에 초점을 맞춤. 처음 이 프로젝트를 시작할 때, 담당자는 매우 회의적이었음. 소프트웨어 개발과 세일즈는 다르다고. 세일즈는 훨씬 예측 불가능하다고.

결과에서만 인사이트를 얻음(실적 숫자로만)

성공은 오직 성사 거래 건수로만 측정됨. 프로세스가 어떻게 실적에 영향을 미치는지 예측하는 시스템이 없었음. 일일 통화 건수를 기록해보려는 시도는 있었지만, 실제로 무엇이 거래 성사에 영향을 주는지는 몰랐음. 운영(management)은 오직 최종 거래 건수 지표만을 통해서 상황을 판단하고 조정할 수 있었음.

세일즈 프로세스에서 인과관계의 예측 불가능성

어떤 작업이 최종 결과에 영향을 미치는지 몰랐음. 실적을 올리는 방법은 오직 빡쎄게 일하는 것 뿐. 스마트하게 일하는 방법을 찾는게 불가능한 상황.

세일즈 활동에 대해 성찰이나 개선이 없었음

오직 매일의 루틴한 작업만 신경썼지 자주 성찰을 한다거나 싸이클마다 개선을 이룬다는 개념이 없었음. 간혹 성공 사례가 있는 경우 그걸 배워서 써먹는 경우는 있었지만, 어쩌다가(ad-hoc) 일어나는 일이었을 뿐 함께 스마트하게 일하는 방법을 배우는 정기적인 기회는 없었음.

Scrum을 세일즈 조직에 도입하기로 한 이후, 팀은 한 명의 세일즈 매니저를 ScrumMaster로 지목하고 일일 스크럼 회의를 진행하도록 함. 부서 담당자가 제품 담당자 역할로 한 명을 임명하고, 주간 스프린트를 주관하도록 함. 마지막으로 스크럼 보드를 만들어서 작업 목록을 만들고 진행 상황을 파악할 수 있도록 함.

그리고는 그냥 함 (Just do it).

• 월요일마다 주간 스프린트 리뷰 회의를 함. 같은 날에 회고도 하고 다음 스프린트 계획 회의도 함.
• 분기별 세일즈 목표 회의도 여전히 하고 (릴리즈까지 13개의 스프린트를 두었다.)
• 매주마다 현재 무엇이 어떻게 진행되고 있는지, 적응(변화)해야 할 것은 무엇인지 탐색함. 스크럼 컨설턴트/코치에게 조언도 듣고.
• 스크럼 보드를 사용하고 burn-up을 사용해서 작업을 우선순위에 따라 정렬함 (because over-target sales should not be expressed in negative numbers),
• 매일 오전 9:30에 스크럼 보드 앞에서 일일 스탠드업 미팅을 함.

첫번째 주간에, 스크럼을 하는 접근 방법이 빠르게 진화함. 스크럼 보드의 사용법이 계속적으로 적응해감. 처음에 세일즈 팀은 스크럼에 별로 동기부여도 안되어있고 스크럼 규칙에 대해 숙지도 안되어 있었음. 스크럼 마스터로 임명된 사람은 자주 자리를 비웠고, 팀은 일일 스탠드업 미팅을 잘 하지 않았음. 스크럼 마스터가 사무실에 있을 때도 제 시간에 시작하지 않거나, 15분 타임박스를 지키지도 않았음.

자기들의 실수를 깨닫고 다시 시작하기로 함.

중요한 변화는 한 컨설턴트가 애자일 자각 이벤트를 했던 것. 원래는 그 회사의 고객들을 위한 행사였는데, 정작 세일즈 팀에 가장 큰 영향을 미쳤음. 과거에는 콜드 콜을 통해서 고객들과 만나려고 시도하곤 했음. 이 무료 행사를 통해서 세일즈 팀은 잠재 고객들과 만나서 친밀감을 쌓을 수 있는 기회를 얻게 된 것.

배운 점

1. 세일즈가 생각했던 것보다 훨씬 예측 가능하더라. 스크럼을 사용하자 인과관계가 표면으로 드러났다.
2. 세일즈팀 혼자만으로는 충분하지 않다. 전체 가치 측면에서 움직이는 것이 매우 중요하다.
3. 스크럼은 관계 관리와 입소문이 세일즈에서 매우 중요하다는 점을 드러내주었다.

성과

스크럼 도입 이후, 회사 매출이 두 배가 되었다. 물론 세일즈 부서만의 영향은 아닐테지만, 한 이사는 증가한 매출에서 적어도 50% 정도는 스크럼 도입의 영향인 것 같다고 했다. 팀은 훨씬 자기 동기부여(self-motivated)되었고, 잦은 회고와 적응 싸이클을 통해서 자신들의 세일즈 프로세스가 효과적인지 성찰하고 있다.

팀은 훨씬 집중해서 일하게 되었다. 어떻게 프로세스가 동작하는지 알게 되었고, 프로세스를 어떻게 제어하고 개선하는지 알게 되었다.

교회 조직의 Scrum 도입 사례

흥미로운 점

개개인과 상호 의사소통을 중요시한다. XP에서는 그걸 아예 극도의 실천방법을 통해서 실현한다. 아예 업무 자체를 짝프로그래밍이라는 방식으로 하는 것이다. 보통 회사에서 상호 의사소통과 개개인을 강조하려면, 업무 자체의 프로세스는 그대로 둔 채, 회식을 하거나 단합대회를 하는 등을 한다. 그런데 XP는 아예 업무 형태 자체를 바꾸어버렸다.

현재 하고 있는 것을 어떻게 더 낫게 할까? 추구하는 가치가 잘 반영되게 하려면 어떤 모양으로 바꿔볼 수 있을까를 곰곰히 생각하고 반영하는 것. 프로세스(패턴) 자체도 생성적이다.

시대적 배경

이렇게 좋은거면 다른 분야에도 확산시키면 좋겠는데? 사실은 다른 분야의 영향들을 받은 것.

• ChristopherAlexander: 유기적, 진화적 과정으로서의 건축.

• NonakaIkujiro: 지식경영, 자기조직화 경영, HBS에 실린 TheNewNewProductDevelopmentGame.

• 도요타의 LeanManufacturing 등

기타 분야에의 적용

기타 분야의 Agility 적용

• AgileChurch

• 디지털 싱글 음반
• 유니클로 소량 생산
• 도요타 생산 시스템
• Lean Publishing

실제 적용하는데 어려움

Growing Mindset & Fixed Mindset

정해진대로 해서는 도로 고정된 process가 되어버린다. 생성적으로, 패턴화하면서 적응해가야 한다.

참고자료

에토 코이치로, “패턴, Wiki 그리고 XP: 시간을 초월한 창조의 원칙 ”,제이펍, 2010

• 위키피디아 등으로 널리 알려진 웹 형태인 Wiki, 애자일 학파 중 하나인 eXetreme Programming의 사상적 원리를, 그 둘이 공통적으로 뿌리로 가지고 있는 크리스토퍼 알렉산더의 사상과 역사적인 변천사 등을 통해 알아볼 수 있습니다.

켄트 백, 신시아 안드레스, "익스트림 프로그래밍", 인사이트, 2006

• 익스트림 프로그래밍에 대한 가장 권위있는 책입니다.

AC Sutherland, J Sutherland, "Scrum in Church: Saving the world one team at a time", Agile Conference, 2009

• SCRUM의 창시자 중 한 사람인 제프 서덜랜드가 4개 교회에 스크럼을 도입해본 경험을 쓴 논문입니다.

R van Solingen, J Sutherland, “Scrum in sales: How to improve account management and sales processes”, Agile Conference, 2011

• 역시 서덜랜드가 세일즈 조직에 스크럼을 도입해본 경험을 쓴 논문입니다.