스크럼이나 XP를 구성하는 기법들은 관심이 많지만 정작 애자일 선언(Manifestor of Agile Alliance)의 가치가 원칙에 대해서는 별로 관심이 없습니다. 하지만 이 선언의 가치와 원칙은 애자일 개발을 이해하는데 매우 중요합니다.
개인과 상호작용이 프로세스와 툴보다 우선이다.
일을 잘하는데 있어 프로세스와 툴은 두번째 입니다. 첫번째는 상호간의 커뮤니케이션 능력입니다. 훌륭한 개발팀은 뛰어난 개발자들이 모여야만 가능한 것은 아닙니다. 개발 역량은 좀 떨어져도 팀웍이 좋으면 충분히 좋은 개발팀이 될 수 있습니다.
프로세스 역시 이를 위해 존재하는 것입니다. 프로세스를 위한 프로세스는 의미가 없습니다.
적당한 툴 역시 중요합니다. 그러나 무조건 툴을 맹신하는 것은 좋지 않습니다. 너무 어려워서 툴 자체를 배우고 적용하는데 비용이 많이 든다면 과감히 포기하고 화이트보드를 선택하는 것도 나쁘지 않습니다. 최소한의 기능을 가진 오픈소스로 시작하는게 좋습니다.
동작하는 소프트웨어가 포괄적인 문서보다 우선이다.
코드만 있고 문서가 없는 시스템은 애자일 프로젝트라 해도 좋은 시스템이 아닙니다. 중요한 설계 결정에 대한 이유나 결정, 시스템 구조에 대한 설명은 사람이 읽을 수 있는 문서 형태로 있어야 합니다.
코드와 문서를 일치시키기 위해 노력하는 것은 시간낭비 입니다. 그보다는 필요한 내용만 요약해서 작성하고 적당한 수준에서 유지하는게 좋습니다. 팀원간에 교육이나 새로운 팀원을 위한 가장 좋은 자료는 코드와 팀원간의 페어 프로그래밍입니다.
고객 협력이 계약 협상보다 우선이다.
계약서에 명시된 프로젝트 범위나 일정을 지키는 건 현실적으로 어렵습니다. 계약 당시에 범위나 일정을 정확히 정의한다는 것 자체가 불가능합니다. 결국에는 어긋날 수 밖에 없습니다.
프로젝트를 성공적으로 끝내기 위해서는 한정된 비용으로 일의 범위와 기한을 맞추려 노력하기 보다는 고객과 협력해서 이를 관리하는게 중요합니다.
변화에 대한 반응이 계획을 따르는 것보다 우선이다.
소프트웨어 개발은 계획대로 진행되기 어렵다. 비즈니스 환경은 변하기 쉽고, 시스템이 동작하는 것을 본 고객은 좀 더 높은 요구사항을 내고 싶어한다. 개발자는 변경된 요구사항을 반영하는데 얼마나 많은 시간이 걸릴지 잘 예상하지 못합니다.
프로젝트 전체에 대한 계획을 세우고 이를 맞추려 노력하기 보다는 2주~3주 단위로 짧게 계획을 세우면서 변화에 대응해 나가는게 중요합니다.
