티스토리 뷰

원본글은 github에 있습니다.


애자일은 태생이 포괄적이다. 그래서 추상적이다.

 

Plan(Predictive) Driven

마틴파울러에 따르면,
90년대 전통적인 개발방식(traditional plan-driven software engineering)의 문제점을 보완하려고 나타난 여러가지 방법론들이 있었다.

XP, Scrum, Crystal, DSDM, FDD 등등의 방법론들이 발전하고 있었지만, 소수의견 이었고,
주류(전통적인 개발방식)에 대항하기 위해 힘을 모은 것 같다.

그 방법론들을 만든 사람들과 대표자들이 모여서 통합 선언문 만들었다.
Agile이란 이름으로 결정되기전, 또 하나의 이름 후보는 'Adaptive'였다고 한다.

나는 그 동안 XP가 애자일의 구현체라고 생각했다. 모호한 애자일의 내용을 구체적으로 설명해줬기 때문이다.
그런데 아니였다. 스크럼 아저씨의 이야기처럼 XP, Scrum같은 lightweight 방법론들이 오히려 애자일의 부모이다. 애자일 밑에 있지 않다.

애자일을 보고 이해하기 어렵다면, 그 부모를 보면 될 것 같다.

 

애자일 선언문

에는 애자일이 추구하는 4개의 가치와 12개의 원칙이 있다.

문서에도 잘 나와있지만, 머리에 넣고 꺼내기쉽게, 내 나름대로 요약을 해보았다.

 

Agile's Values

'a보다 b를 더 중요하게 여긴다.'의 형식을 사용하는데,
a가 기존 개발방식의 문제점이었던 것 같다.

  1. 프로세스보다 사람
  2. 문서보다 작동하는 결과물
  3. 계약보다 고객과 협업
  4. 예측보다 대응

어떤 팀/회사가 이 가치들을 실제로 중요하게 여긴다면 애자일하다고 할 수 있겠다.

반대로

  1. 사람보다 프로세스
  2. 작동하는 결과물보다 문서
  3. 고객과 협업보다 계약
  4. 대응보다 예측

을 실제로 중요하게 여긴다면 애자일 하지 못하다고 할 수 있겠다.

추상적인 가치들을 설명하기 위해, 선더버드 회의 이후 원칙이 추가 되었다고 한다.

 

Agile's Principles

  1. 고객만족 최우선
  2. 요구사항변경 환영
  3. 동작하는 결과 수시제공
  4. 매일협업
  5. 동기부여된 사람
  6. 면대면 대화 지향
  7. 동작하는 결과로 진척확인
  8. 일정한 속도유지
  9. 기술적 탁월함/좋은 설계에 관심
  10. 꼭 할일만 함
  11. 스스로 팀 지향
  12. 정기적 팀 반성/변화

어떤 팀/회사가 원칙들을 잘 지키고 있다면 애자일 하다고 할 수 있겠다.
원칙의 목적은 가치를 얻기 위함이니 가치를 잊고 원칙만 고수한다면 애자일하다고 하기 어렵겠다.

클린 애자일을 보면, 애자일의 4가지 가치가 '밥먹으면 배부르다' 수준을 넘어서,
'실제로 일하는 방식'을 바꾸기 원했고, 12가지 원칙을 만들어진 것 같다.

 

그래서?

소프트웨어를 만들며 고통의 시간을 보내본 사람들은,
가치와 원칙을 보면서 참 좋은 말들이라고 고개를 끄덕일만 하다.
하지만 특히 개발자 입장에서, 실제로 어떻게 해야하는지, 가치와 원칙만 읽고 행하기는 어려운 것 같다.

엉클밥은 에서 그 해결책으로 익스트림 프로그래밍의 실천방법을 이용한다.

나도 그 영향을 받아 이렇게 하고 있다.