## page was renamed from 오이씨 마실: 애자일 소개
#acl +All:read
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 프로젝트의 현재 =

방대한 산출물

{{http://cfs12.tistory.com/image/27/tistory/2009/09/12/00/38/4aaa6edc16be4}}

돌이킬 수 없는 일정

{{http://www.microsoft.com/korea/Press/pressroom/2010/05/image/img_Project_2010.jpg}}

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

{{http://cfs9.blog.daum.net/original/22/blog/2008/02/27/21/16/47c554813d4b0&filename=%EC%97%85%EB%AC%B4%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%9D%BC%EC%A0%95%EA%B4%80%EB%A6%AC.jpg}}

결과는?


[[http://www.bikorea.net/news/articleView.html?idxno=7987|동부화재, 1500억 들인 차세대 사실상 ‘실패’]]
 * '''자원 예측 실패''' : 구입한 솔루션이 있는데, 프로젝트가 진행될수록 최초 산정 용량의 2~4배 규모가 필요하게 되어 자원 예측에 실패. 비용 증가 및 후반 투입 대응 불능.
 * '''잦은 변경''' : 프로그램 작성 과정에서 고객의 요구, 즉 동부화재의 프로그램 변경 요구가 많았다는 주장이 제기. 많은 공을 들여 프로그램을 작성하고, 화면을 제작해 화재 직원들을 상대로 확인을 거치면, 같은 업무에 대해 수차례 재작업 요구를 하는 등 발주처 횡포가 만만치 않았던 것으로 보인다. 당연히 기간은 정해져 있고, 업무량도 많은데 같은 업무를 수차례 반복하면서 일정을 맞추기 쉽지 않았다는게 업계 전언이다.
 * '''폭탄 돌리기''' : 연내 오픈 불가능하다는 판단이 서자, 이전의 총괄 상무를 경질하고, CIO가 투입되어 특단의 조치를 취함. 조직 내 주도권 싸움을 벌이며 그룹 감사 부서에 투서 및 진정이 난무.

외국 사례
 * 영국 국가보건서비스(NHS) IT 현대화 프로그램: 스케줄보다 2년 지체. 100억 달러의 예산이 초과. 주요 계약 업체 iSoft는 도산 일보 직전. 
 * 미국 공군의 ERP 프로젝트: 2005년 시작, 2012년 폐기. 1억 달러 손실을 남기고 프로젝트 실패. 프로젝트를 계속할 경우 종료시까지 1억 달러 추가 예상. 2005년 계약 당시 오라클은 8천만 달러에 입찰.
 * [[http://www.computerworld.com/s/article/9234581/The_scariest_software_project_horror_stories_of_2012?pageNumber=1|The scariest software project horror stories of 2012]]


거대한 프로젝트라서? 사용자가 욕심이 많아서? 

작은 프로젝트에서도 충분히 가능한 일. 홈페이지 제작을 맡긴다고 하자.
 * 불확실성: 뭘 만들어야 할지 너도 나도 모른다.
 * 맞지 않는 옷: 만들어서 가져온게 내 업무 패턴과 맞지 않는 경우, 업무 환경은 변화하는데 시스템이 쫓아오지 못하는 경우.

= 애자일의 형성 =

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

그 중 한 흐름이 애자일.

||Agile||Inflexible||
||{{http://farm5.staticflickr.com/4106/5166720439_51d647dbe7_d.jpg}}||{{http://farm4.staticflickr.com/3559/3827630924_783414c013_d.jpg}}||
||(Photo by [[http://www.flickr.com/photos/yeliseev/5166720439/|Sergey Yeliseev]])||(Photo by [[http://www.flickr.com/photos/mr_mo-fo/3827630924/|Des Morris]])||

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

= 애자일 선언 =

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

애자일 선언

 * 공정과 도구보다 '''개인과 상호작용'''을
 * 포괄적인 문서보다 '''작동하는 소프트웨어'''를
 * 계약 협상보다 '''고객과의 협력'''을
 * 계획을 따르기보다 '''변화에 대응하기'''를

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


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

우리는 다음 원칙을 따른다:
 1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 '''일찍 그리고 지속적으로 전달'''해서 '''고객을 만족'''시키는 것이다.
 1. 비록 개발의 후반부일지라도 '''요구사항 변경'''을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
 1. 작동하는 소프트웨어를 '''자주 전달'''하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
 1. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 '''함께 일해야''' 한다.
 1. '''동기가 부여된 개인'''들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
 1. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 '''면대면 대화'''이다.
 1. 작동하는 소프트웨어가 '''진척의 주된 척도'''이다.
 1. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 '''일정한 속도를 계속 유지''' 할 수 있어야 한다.
 1. 기술적 '''탁월성'''과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
 1. '''단순성'''이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.
 1. 최고의 아키텍처, 요구사항, 설계는 '''자기 조직적인 팀에서 창발'''한다.
 1. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 '''조율하고 조정'''한다.

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

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

= 뭐가 좋은가? =

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

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

애자일 도입으로 얻은 효과는?
 1. 변화하는 우선순위를 대응할 수 있는 능력 (84%)
 1. 프로젝트 가시성(visibility) 향상 (77%)
 1. 생산성 향상 (75%)
 1. 팀 사기 향상 (72%)
 1. 빠른 시장 출시(time to market) (71%)

도입한 애자일 종류
 1. [[SCRUM]] (52%)
 1. [[SCRUM]]/[[XP]] Hybrid (14%)
 1. Custom Hybrid (9%)
 1. Don't Know (8%)

도입한 애자일 실천법
 1. Daily Scrum (78%)
 1. Iteration Planning (74%)
 1. Unit Testing (70%)
 1. Release Planning (65%)
 1. Burndown (64%)
 1. Retrospective (64%)
 1. Continuous Integration (54%)
 1. Automated Builds (53%)
 1. Velocity (52%)
 1. Coding Standards (51%)


= Scrum =

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

{{http://4.bp.blogspot.com/-9vLjiCcBzn0/UTJhsCIbpcI/AAAAAAAAHis/pH88CRDiD_U/s1600/Prescriptiveness+in+Agile+Processes.png}}

스크럼의 구조

{{http://www.verheulconsultants.nl/Scrum-overview.png}}

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


== 성과 ==

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

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


= 시대적 배경 =

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

 * ChristopherAlexander: 유기적, 진화적 과정으로서의 건축.
 * NonakaIkujiro: 지식경영, 자기조직화 경영, HBS에 실린 TheNewNewProductDevelopmentGame.
 * PeterSenge: Learning Organization
 * 도요타의 LeanManufacturing 등

== 미국의 1960년-1980년대 배경 ==

||<#eeeeee>시대||<#eeeeee>사회 경제적 환경||<#eeeeee>비즈니스||
||1960-70년대||베트남 전쟁 발발. 반문화(counter culture), 히피 운동, 페미니즘 등 유행<<BR>>시민의 권리와 낙태 운동이 확산<<BR>>대체의학이나 영성 수련 등의 비전통적인 모델이 유행<<BR>>음악, 비틀즈 음악이나 자기계발 서적 등을 통해 동양사상이 유입됨||X이론 Y리더십 모델이 개발됨.<<BR>>프로세스 컨설팅, 경영 그리드, 상황적 리더십 모델이 만들어짐<<BR>>NTL과 Tavistock이 감수성 훈련을 함<<BR>>과업중심과 관계중심 행동에 대한 탐색이 시작되고 협력적 리더십이 연구됨<<BR>>조직에서의 성과 이론(excellence theory)들이 개발됨<<BR>>관리에서 리더십으로 초점이 이동함<<BR>>조직개발에 GestaltTherapy 개념과 방법이 적용됨<<BR>>컨설팅 기관들이 설립됨.||
||1980년대||불확실성, 애매함, 모순(역설), 불연속성의 시대<<BR>>사회, 경제, 문화적인 변화가 더 가속화됨.<<BR>>냉전이 끝나고 베를린 장벽이 무너짐<<BR>>일본과 유럽이 새로운 산업 강국이 됨<<BR>>주요 산업 국가들 간의 상호 영향 시대||Luthens가 행동심리학의 결과물들을 경영 모델, 용어 등에 도입하고 조직 행동 변화 모델이라고 명명함.<<BR>>권력이 관리자의 권위에서 직원들의 헌신으로 이동함.<<BR>>경영 이론이 점점 협동(collaboration), 협력(participation), 영향력(influence)으로 이동함<<BR>>품질주의 운동이 일어나 프로세스 개선과 [[PDCAmodel]]에 대한 관심이 일어남.<<BR>>개인이라는 개념에서 인적 자원이라는 개념으로 발전함<<BR>>개인적, 업무적 상담을 위해 Employee Assistance Program (EAP)가 탄생함.||
||1990-2004년대||불확실성은 계속되고, 불연속성, 전체 품질(total quality)과 문화 변화의 확산<<BR>>경제적 빈부 격차의 심화<<BR>>소비에트 연방의 몰락<<BR>>중국이 자유화됨<<BR>>산업사회에서 정보사회로의 이동<<BR>>이민과 세계화<<BR>>PC의 확산, 인터넷과 다른 디지털 커뮤니케이션 수단의 확산<<BR>>수직적 권위의 몰락<<BR>>건강과 운동에 대한 관심과 염려가 증가<<BR>>복잡성을 대하기 위해 통합적이고 시스템적인 접근법이 개발됨.<<BR>>기업가정신과 서비스 경제의 대두<<BR>>포스트모던 사회의 복잡성<<BR>>국제적으로 의식과 영적 패러다임이 이동하고 융합됨<<BR>>인류에 대한 인본주의적 세계관<<BR>>개인주의 경향<<BR>>환경과 지속가능성에 대한 관심<<BR>>국제적으로 테러리즘이 중요한 요인으로 부상함||스트레스와 긴 업무 시간에 대한 염려로 일과 삶의 균형이 이슈가 됨.<<BR>>개인 생산성으로 초점이 이동함<<BR>>business fix-it에서 잠재력 계발의 직업 개발로 이동<<BR>>Cross-discipline 접근법과 이론이 규범화됨<<BR>>리더십 이론이 balanced scorecard, reengineering, 복잡계 이론, 리더십 과학, 감성 지능 등을 포함하게 됨<<BR>>조직 학습과 시스템 사고가 결합됨<<BR>>긍정 탐색이 조직 변화를 일으키기 위해 만들어짐||


= 실제 적용하는데 어려움 =

애자일은 변화를 받아들이고 적응하는 것이 가장 중요하다. 그런데 특정한, 고정된 '애자일 방법론'을 하나 선택해서 가져와서 쓰게 되면 애자일이 아니게 된다. 현재에서부터 한 걸음씩, 필요한 것들을 수용하고 조직의 상황에 맞게 변형하면서 도입해야 한다.

 * 애자일에 관계없이, 현재 우리 조직에서 잘 작동하고 있는 부분은 패턴으로 정리해서 자기 조직의 애자일 실천법으로 강화시키고,
 * 잘 되고 있지 않는 부분은 어떻게 개선하면 좋을지, 혹시 기존의 애자일 실천법 중에 도움이 될 만한 것이 있는지 찾아서 변형해서 사용

프로세스와 생산성에 대해 조직 내에서 스스로 생각하고 성찰하는 능력이 절대적으로 중요함.

[[XP]]에서 독특한 실천방법 중 하나가 짝프로그래밍이다. [[XP]]에서 중요하게 여기는 가치 중 하나가 의사소통인데, 그걸 어떻게 하면 잘 할 수 있을까 생각하다가, 아예 그것을 프로세스로 만들어버린 것이다. 보통 회사들에서 '의사소통이 부족한데? 방안 좀 생각해봐' 하면, 회식을 하거나 단합대회를 할 것. 하지만 [[XP]]에서는 아예 업무 자체를 짝으로 하도록 해서 의사소통을 극대화시킨 것.

의사소통의 중요성을 공감하지 못하는 회사에서 짝프로그래밍을 하더라도 큰 효과를 보기는 어려움. 의사소통 자체를 중요하게 여기는 분위기라야 프랙티스들이 뿌리내릴 수 있다.

VersionOne의 설문 중, 애자일 도입의 장벽은?
 1. 조직 문화를 변화시키는 능력 (52%)
 1. Availability of personnel with right skills (40%)
 1. 변화에 대한 일반적인 저항 (39%)

== XP의 가치 ==
 * '''의사소통''': 올바르게 의사소통하라. 여러 프랙티스 중에는 의사소통 없이는 이루어질 수 없는 것들이 많다. 프로젝트의 문제의 많은 원인 중 하나는 누군가가 다른 누군가에게 뭔가 중요한 것을 말하지 않았기 때문이다.
 * '''단순성''': 작동 가능한 가장 간단한 것이 무엇인가? 오늘 간단한 것을 만들고 다음날 조금 더 노력해서 그것을 바꾸는 것이, 정작 다음날이 되면 쓰지 않을 뭔가 복잡한 것을 오늘 만들고 있는 것보다 낫다. 
 * '''피드백''': 시스템의 현재 상태에 대한 구체적인 피드백은 너무나 값진 것이다. 낙관주의는 프로그래밍의 직업병이다. 피드백이 그 치료약이다.
 * '''용기''': 용기를 가져라. 좋은 소프트웨어를 만드는 일이라면 무엇이든지 주저하지 말아라. 코드를 버리는 것, 방향을 바꾸는 것, 심지어 개발 후반부에 바꾸는 것 조차도. What's to say that you won't ever develop yourself into a corner? Courage.
 * '''존중''': 소프트웨어 개발에서 생산성과 인간성을 동시에 개선하려면, 팀에 속한 모든 개인의 기여를 존중해야 한다.

의사소통, 단순성, 피드백, 용기, 존중만이 소프트웨어를 효과적으로 개발하게 할 수 있는 가치는 아니다. 이것들은 XP를 이끄는 가치다. 여러분의 조직, 여러분의 팀, 여러분 자신은 다른 가치들을 선택할 수도 있다. 제일 중요한 것은 팀이 신봉하는 가치에 팀의 행동이 어울리도록 만드는 것이다.

== SCRUM의 가치 ==
 * '''헌신 (Commitment)''': 목표에 기꺼이 헌신함. Scrum provides people all the authority they need to meet their commitments.
 * '''집중 (Focus)''': 당신의 일을 하라. 당신이 하기로 한 일에 대해서 모든 노력과 능력을 다해 집중하라. 다른 것은 아무 것도 걱정하지 마라.
 * '''개방성 (Openness)''': 스크럼은 모든 사람에게 프로젝트의 모든 것이 투명하게 보이도록 한다.
 * '''존중 (Respect)''': 개개인은 각자의 배경과 경험을 통해 형성된다. 팀에 포함된 다른 사람들을 존중하는 것은 중요하다.
 * '''용기 (Courage)''': 용기를 가지고 헌신하고 행동하고 개방하고 존중받기를 기대하라.

{{http://ptgmedia.pearsoncmg.com/images/chap2_9780321637703/elementLinks/02-01.jpg}}

여러분의 팀은 어떤 가치를 선택했고, 어떻게 일하고 있으신가요?

= 결언 =

애자일은 어떤 완성된 특정한 방법론이어서 가져와서 쓰면 되는 어떤 것이라기보다는, '지금보다 더 나은 (개선, Kaizen)' 조직을 추구하는 경향성이라고 표현하면 좋을듯.

그 과정에서 UnderUncertainty를 인정하고, [[Agility]]를 추구하는 태도를 견지한다면, 구체적인 실천방법들은 스스로 도출되어 나올 것.

= 참고자료 =

'''에토 코이치로, “패턴, 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'''
 역시 서덜랜드가 세일즈 조직에 스크럼을 도입해본 경험을 쓴 논문입니다.