소프트웨어 개발 과정이 UnderUncertainty를 포함하고 있다는 것을 인정하고, 효과적으로 대응하기 위해 개발 과정에서 팀 혹은 조직의 Agility를 향상시키는 것이 AgileDevelopment의 목표이다.
KentBeck을 비롯해서 여러 실천법들의 대표자들이, 문서 주도(drive)의, 무거운(heavyweight) 소프트웨어 개발 프로세스(대표적으로 WaterfallModel)의 대안을 찾기 위해 모였다.
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일 선언에 참여한 사람들의 명단은 다음과 같다.
Pragmatic movement |
Not specified |
|||||
KentBeck |
Arie van Bennekum |
MartinFowler |
AlistairCockburn이 그의 책 Agile Software Development: The Cooperative Game에 애자일 선언이 만들어질 당시의 정황을 잘 기록해두었다.
KentBeck이 Startup Lessons Learned Conference 2010에서 발표한 애자일 선언 2.0도 살펴볼만하다.
Team vision and discipline over individuals and interactions
Validated learning over working software
Customer discovery over customer collaboration
Initiating change over responding to change
-
팀 비전과 원칙을 개인과 상호작용보다
검증된 학습을 작동하는 소프트웨어보다
고객 탐색을 고객과의 협력보다
변화를 일으키기를 변화에 대응하기보다
Agile에 대해 GeraldWeinberg가 쓴 AgileImpressions도 읽어볼만 하다. Agile 이전에는 과연 Agile이 없었는가, 그때는 어떻게 개발했는가, Agile이 있기 이전의 경험이 있는 어르신의 눈에는 애자일이 어떻게 보이는가.
애자일 선언 이면의 12가지 원칙
우리는 다음 원칙을 따른다:
- 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
- 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
- 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
- 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
- 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
- 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
- 작동하는 소프트웨어가 진척의 주된 척도이다.
- 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.
- 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
- 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.
- 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
- 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
역사
애자일 프레임워크 분류
계열 |
시작연도 |
영향 |
비고 |
1996 (C3) |
|
||
mid 1990 |
|
||
1995 (OOPSLA95) |
OOPSLA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
쿠팡에서 하고 있는 방법 |
대개의 애자일 패밀리들이 PLoP나 OOPSLA 같은 컨퍼런스 커뮤니티의 영향을 받았다. 커뮤니티 자체의 관심사가 전반적으로 애자일을 뒷받침하고 있었다.
AC2의 기술적 측면의 분류
- 개론적 이해
- 계획하고 조정하기
- 사용자 경험(UX)
- 요구사항
설계: PaperPrototype
테스팅: ExploratoryTesting
- 관찰과 가시화
- 회고와 회의
- 기술적 리더십과 관리
기타 이슈
애자일을 팀에 전파하는 것을 돕는 AgileCoaching도 있다.
CustomerDevelopment와 더불어 LeanStartup에 중요한 기법이다.
누가 AgileMeeting이라는 주제를 정리해놨을 것 같다.
컨퍼런스
XP
Agile Alliance (AgileConference)
--
소프트웨어 개발 방법론으로서의 애자일 말고, 애자일한 팀, 애자일한 조직이란 무엇일까?
Holacracy: 이건 좀 아닌듯.
아메바 경영: 이건 좀 더 살펴볼만할듯. (책/아메바 경영)
내가 현재 가지고 있는 생각 하에서는 일단 학습조직의 특징을 가지고 있을 것 같다. AndyHunt의 실용주의 운동에서도 일상 업무를 어떻게 개선할까 골똘히 생각(회고)해본 결과로 여러 실천법들을 제안하고 있다. 애자일 자체가 중요하기보다는, 애자일 실천법을 고안해낼 수 있는 그 생성적(generative) 능력을 보유하는 것이 중요하다고 본다. ChristopherAlexander는 책/TheTimelessWayOfBuilding에서, 생성적 프로세스의 중요성을 이야기하고 있다. 그러기 위해서는 팀 자체가 학습조직이 되어서 자신이 수행하고 있는 업무들을 얕은 수준에서, 또한 깊은 수준에서 성찰하고 개선하는 능력이 필요하다.
다른 것도 있겠지.
Teamwork 수준이 높아져야 하겠다. 일단은 HighPerformanceTeam이 지닌 특징을 두루 가지고 있을 것이다.
애자일한 팀의 특징은 생각나는대로 더 추가하도록 하고, 그러면 애자일한 팀을 어떻게 만들어갈 것인가? 어떻게 하면 그런 팀이 될 수 있는가? 어떻게 저런 특성들을 지니도록 할 수 있을까? 무엇이 시발점이 될까?
일단은 애자일 코칭에서는 코칭이 그 첫 시작점이라고 생각하는 것 같다.
팀이 추구하는 가치를 정리하고 - 그것이 XP의 가치가 될 수도 있고, SCRUM의 가치가 될 수도 있고, 또는 일부 겹치지만 겹치지 않는 다른 가치들이 있을 수도 있고 - 그것을 어떻게 추구해나갈까, 이런 가치 중심적인 접근도 있을 것 같다. 하지만 또한 가치 중심적이지 않은 사람들도 많다. 가치를 뜬구름 잡는 것이라고 여기고, 현실적인 접근을 원하는 사람들도 있을거고 - 결국은 돈 벌고 자신이 생계를 이어나갈 수는 있어야 하는거 아니냐, 학습조직이든 애자일이든 이런건 두루뭉술한 이상일 뿐이다라고 주장하는 - 하지만 그런 사람들도 '현실적인', '구체적인', '단기간에 성과로 이어지는'이라는 가치를 중요하게 여기는 셈이겠다.
결국은 개개인이 원하는 팀의 모습이 무엇이고, 그 팀을 이루어가자는 합의와 헌신이 이루어지고, 그것을 어떻게 구현해나갈까 하는 성찰이 있어야 가능하지 않을까? 그러면 결국 학습조직적인 특징은 초기부터 필요한 것인가? 어쩌면 그래서 많은 애자일리스트들이 처음 도입할만한 실천법으로 ProjectRetrospectives를 꼽는지도 모르겠다.
소프트웨어에서의 애자일을 잘 이해하려면, 소프트웨어 바깥의 책을 읽는게 도움이 되는 것 같다. 소프트웨어 분야의 애자일 서적을 읽으면, 특정한 도구나 방법에 매몰되기 쉬운 것 같다. 애자일의 배경, 맥락, 마인드셋 등을 잘 이해할 필요가 있다.
그런 면에서는 이런 책들을 읽어보면 좋다.
코칭 마인드셋도 중요하고.
책
AlistairCockburn, 책/AgileSoftwareDevelopmentTheCooperativeGame
JimHighsmith, Agile Project Management
RonJerries, The Nature of Software Development
RonJerries, AnnAnderson, ChetHendrickson, Exetreme Programming Installed
JeffSutherland, Scrum: The Art of Doing Twice the Work in Half the Time
KenSchwaber, MikeBeedle, Agile Software Development with Scrum
KenSchwaber, The Enterprise and Scrum
MikeBeedle, MartineDevos, YonatSharon, KenSchewaber, JeffSutherland, SCRUM: An extension pattern language for hyperproductive software development
AndrewHunt, DaveThomas, The Pragmatic Programmer
김창준님 추천 저자들: "애자일의 이론적/사상적 배경을 이해하고 싶은 분들에게 추천드리는 저자 목록을 만들어 봤습니다. 프로그래밍 쪽은 뺐습니다."
교육학
복잡계 과학
심리학
경제학
경영학
건축학