애자일은 태생이 포괄적이다. 그래서 추상적이다.
마틴파울러에 따르면,
90년대 전통적인 개발방식(traditional plan-driven software engineering)의 문제점을 보완하려고 나타난 여러가지 방법론들이 있었다.
XP, Scrum, Crystal, DSDM, FDD 등등의 방법론들이 발전하고 있었지만, 소수의견 이었고, 주류(전통적인 개발방식)에 대항하기 위해 힘을 모은 것 같다.
그 방법론들을 만든 사람들과 대표자들이 모여서 통합 선언문 만들었다.
Agile이란 이름으로 결정되기전, 또 하나의 이름 후보는 'Adaptive'였다고 한다.
나는 그 동안 XP가 애자일의 구현체라고 생각했다. 모호한 애자일의 내용을 구체적으로 설명해줬기 때문이다.
그런데 아니였다. 스크럼 아저씨의 이야기처럼 XP, Scrum같은 lightweight 방법론들이 오히려 애자일의 부모이다. 애자일 밑에 있지 않다.
애자일을 보고 이해하기 어렵다면, 그 부모를 보면 될 것 같다.
에는 애자일이 추구하는 4개의 가치와 12개의 원칙이 있다.
문서에도 잘 나와있지만, 머리에 넣고 꺼내기쉽게, 내 나름대로 요약을 해보았다.
'a보다 b를 더 중요하게 여긴다.'의 형식을 사용하는데,
a가 기존 개발방식의 문제점이었던 것 같다.
- 프로세스보다 사람
- 문서보다 작동하는 결과물
- 계약보다 고객과 협업
- 예측보다 대응
어떤 팀/회사가 이 가치들을 실제로 중요하게 여긴다면 애자일하다고 할 수 있겠다.
반대로
- 사람보다 프로세스
- 작동하는 결과물보다 문서
- 고객과 협업보다 계약
- 대응보다 예측
을 실제로 중요하게 여긴다면 애자일 하지 못하다고 할 수 있겠다.
추상적인 가치들을 설명하기 위해, 선더버드 회의 이후 원칙이 추가 되었다고 한다.
- 고객만족 최우선
- 요구사항변경 환영
- 동작하는 결과 수시제공
- 매일협업
- 동기부여된 사람
- 면대면 대화 지향
- 동작하는 결과로 진척확인
- 일정한 속도유지
- 기술적 탁월함/좋은 설계에 관심
- 꼭 할일만 함
- 스스로 팀 지향
- 정기적 팀 반성/변화
어떤 팀/회사가 원칙들을 잘 지키고 있다면 애자일 하다고 할 수 있겠다.
원칙의 목적은 가치를 얻기 위함이니 가치를 잊고 원칙만 고수한다면 애자일하다고 하기 어렵겠다.
클린 애자일을 보면, 애자일의 4가지 가치가 '밥먹으면 배부르다' 수준을 넘어서,
'실제로 일하는 방식'을 바꾸기 원했고, 12가지 원칙을 만들어진 것 같다.
소프트웨어를 만들며 고통의 시간을 보내본 사람들은,
가치와 원칙을 보면서 참 좋은 말들이라고 고개를 끄덕일만 하다.
하지만 특히 개발자 입장에서, 실제로 어떻게 해야하는지, 가치와 원칙만 읽고 행하기는 어려운 것 같다.
엉클밥은 책에서 그 해결책으로 익스트림 프로그래밍의 실천방법을 이용한다.
나도 그 영향을 받아 이렇게 하고 있다.