애자일의 애자도 모르면서 scrum 방법론 같은 것만 형식적으로 사용하다 보니
애자일에 대해서 많이 궁금했던 터라 개념, 철학을 한번 찾아 봄.
[Agile 정의]
먼저 사전적 정의는 다음과 같다..
http://dictionary.reference.com/browse/agile?s=t
ag·ile [aj-uhl, -ahyl] adjective
1. quick and well-coordinated in movement; lithe: an agile leap.
2. active; lively: an agile person.
3. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile.
http://endic.naver.com/enkrEntry.nhn?sLn=kr&entryId=6021a018893e48b6bbb505245a8f96f8&query=agile
형용사
1. 날렵한, 민첩한
2. (생각이) 재빠른, 기민한
an agile mind/brain예문 발음듣기
재빠른 생각[회전이 빠른 두뇌]
날렵한, 민첩한, 기민한...
뭔가 감이 오는가? 사실 스크럼 할때도 이런 단어들을 들었지만 별 감흥이 없었음.
좀 더 자세한 설명을 찾아보자
What is Agility? by Jim Highsmith
http://jimhighsmith.com/what-is-agility/
- Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.
- Agility is the ability to balance flexibility and stability.
In an uncertain and turbulent world, success belongs to companies that have the capacity to create change, and maybe even chaos, for their competitors. Creating change disrupts competitors; responding to change guards against competitive thrusts. Creating change requires innovation: developing new products, creating new sales channels, reducing product development time, customizing products for increasingly smaller market segments.
위 article을 보면 급변하는 기업 비지니스 환경에서 변화를 이뤄내는 역량을 가지고 변화에 민첩하게 대응 하는 기업들은 경쟁에서 성공하며 이런 변화에는 여러 혁신들이 필요하다라는 설명을 하고 있음. 즉 Agility/Agile 하다라고 말하는 것은 비지니스 요구사항에 민첩하게 반응한다는 의미로 보임.
한글판 Wikipedia에서는 애자일 개발 방법론을 다음과 같이 표현하고 있다.
http://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C
애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸다. 익스트림 프로그래밍 (XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있다
좀 더 나아가서 Agile software 개발 선언을 보자
[Manifesto for Agile Software Development]
http://agilemanifesto.org/iso/en/
http://agilemanifesto.org/iso/ko/
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries
Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
선언문에서 오른쪽 굵은 글씨로 표시된 "개인과 상호작용", "작동하는 소프트웨어", "고객과의 협력", "변화에 대응" 하는것에 가치를 두고 있음.
[Principles behind the Agile Manifesto]
http://agilemanifesto.org/iso/en/principles.html
http://agilemanifesto.org/iso/ko/principles.html
애자일 선언 이면의 원칙들인데 너무 많아서 옮기는 것은 쉽지 않고 몇개만 옮겨 보면 다음과 같다. 모든 원칙들이 인상이 깊지만 아래 굵은 글씨의 것들이 참 인상적이다.
가치있는 소프트웨어를 전달하여 고객을 만족 시키는 것을 목적을 가지고
요구사항 변경에 수용할 수 있는 탄력적이고 반복적인 프로젝트 진행과
motivated individuals들로 구성된 self-organizing team을 구성하여 신뢰하고
불필요한 프로세스를 줄이고 합리적인 방법으로 프로젝트를 진행하는 원칙을 지키는 것 이게 핵심이 아닐까 생각 함.
우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
(Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.)
비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
(
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.)
동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
(
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.)
작동하는 소프트웨어가 진척의 주된 척도이다.
(
Working software is the primary measure of progress.)
단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.
(
Simplicity--the art of maximizing the amount of work not done--is essential.)
최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
(The best architectures, requirements, and designs emerge from
self-organizing teams.)
[Agile 철학]
http://en.wikipedia.org/wiki/Agile_software_development#Philosophy
사실 Agile 개발 방법론들이나 간단한 정의는 들어 봤으나 기반 철학에 대해서 궁금했었음. 영문 Wikipedia를 보면 다음과 같은 것들이 있음.
- Adaptive vs. Predictive
- Iterative vs. Waterfall
- Code vs. Documentation
[Adaptive vs, Predictive]
해석은 제대로 못하겠으나 개발 방법론은 Predictive한 것 부터 Adaptive한것들이 존재하며 Agile 방법들은 Adaptive한 축에 속한다. 일정 수립에 있어서도 Rolling Wave 접근법으로 유연한 일정을 수립하여 변경을 수용할 수 있게 한다.
앞서 말한 predictive한 기존 SE 방법론들은 예상치 못한 risk들을 방지하고자 Risk management들을 수행하지만 plan 단계에서 이를 잘못할 경우 project 전개가 산으로 갈 수도 있음.
아래는 개발 방법론들을 비교한 도표..
Home grounds of different development methods
| Agile methods | Plan-driven methods | Formal methods |
|---|
| Low criticality | High criticality | Extreme criticality |
| Senior developers | Junior developers(?) | Senior developers |
| Requirements change often | Requirements do not change often | Limited requirements, limited features see Wirth's law |
| Small number of developers | Large number of developers | Requirements that can be modeled |
| Culture that responds to change | Culture that demands order | Extreme quality |
[Iterative vs. Waterfall]
Waterfall의 단점은 많이 들어서.. Agile 방법론들은 iterative하며 대표적인 예는 Exterme Programming.
[Code vs. Documentation]
Scott Ambler states that documentation should be "Just Barely Good Enough" (JBGE),[21] that too much or comprehensive documentation would usually cause waste, and developers rarely trust detailed documentation because it's usually out of sync with codes,[20] while too little documentation may also cause problems for maintenance, communication, learning and knowledge sharing.
위에서 말한듯이 documentation은 딱 필요한 만큼만 하는게 맞는 것 같다. 많은면 쓰레기와 다름없고 코드와 sync가 맞지 않은 경우가 다반사고 너무 적은 documentation은 나중에 유지보수나 코드와 관련된 대화, 이해가 어렵기 때문이다.
결과물로는 적당한? documentation과 동작하는 코드가 맞는것 같지만.. 적당함.. 어렵기는 하겠다.
그리고 Agile에서는 Self motivated team에 기반하고 있다는 것도 기본으로 알아야 할 사항이 아닐까 생각한다. 사실상 방법론들이나 회고 자체가 개선을 기반하여 있고 개선의 의지가 있는 팀이어야지만 가능할 것이니..
[Agile methods]
:
http://en.wikipedia.org/wiki/Agile_software_development#Agile_methods
[Agile practices]
