소프트웨어를 출시하는 일만 머릿속에 꽉 차 있는 사람들과 작업하고, 개발할 때는 팀마다 그 팀에 적절하게 조율된 경량 프로세스를 사용하고, 변화에 지속적으로 순응해야 한다. 따라서 시스템에 대한 이해를 계속 유지하기 위해 지속적으로 코드를 읽고 소화하고, 할 수 있는 한 코드를 간단하고 명확하게 유지하라.
대실패를 한 번 경험하고 나면, 또 그런 실패를 겪지 않으려고 프로세스(process)를 만들게 된다. 하지만 에러는 계속 발생하기 때문에 계속해서 프로세스가 추가되고, 성가신 프로세스들이 쌓이게 된다. 그래서 팀이 느리게 될 정도로 쌓이면, 팀원들은 프로세스가 부족하다고 느끼게 되며, 계속 악순환이 된다. 이런 악순환은 2000년경 많은 소프트웨어 회사에서 일어났다.
이를 관찰하고는 소프트웨어 팀이 빠르게 일하고 변화에 반응할 수 있도록 하는 가치와 원칙을 세우기 위해 모였고, 그들이 애자일 연합이다.
애자일 선언문
프로세스와 툴보다 개인과 상호작용이 우선이다.
포괄적인 문서보다 동작하는 소프트웨어가 우선이다.
계약 협상보다 고객 협력이 우선이다.
계획을 따르는 것보다 변화에 대한 반응이 우선이다.
거대하고 툴이 넘쳐나는 상황은 툴이 부족한 상황만큼이나 좋지 않다
그 필요가 급박하고 중요하지 않다면 아무 문서도 만들지 마라(마틴의 문서화 제1법칙)
다음 2주간의 세부적인 계획 수립, 다음 3개월간의 개략적인 계획, 1년 후에 작업할 시스템에 대한 흐릿한 개념
애자일 실천방법은 빨리, 자주 공개하는 것이다
개발 후반부에 접어들었다 할지라도, 애자일 프로세스의 일원은 변화를 걱정하지 않는다. 소프트웨어의 구조를 탄력적으로 유지하기 위해 노력하고, 요구사항이 변경됐을 때 시스템에 미치는 영향을 최소화했기 때문이다
문서로 정보를 전달할 수 있겠지만, 필수적인 것은 대화다
애자일 프로젝트는 100미터 달리기가 아니라 마라톤처럼 진행된다