ISO/IEC/IEEE 24765:2017은 애자일 개발(agile development)을 반복 개발, 잦은 점검과 조정, 점진적 인도를 바탕으로 하는 소프트웨어 개발 접근 방식으로 정의한다. 이 접근 방식에서 요구와 해결책은 여러 기능을 갖춘 팀의 협업과 이해관계자의 지속적인 피드백을 거치며 발전한다.[1] SWEBOK V4.0a에 따르면 애자일 방법은 짧은 반복 개발 주기마다 시연할 수 있는 동작하는 제품을 만들고, 고객을 자주 참여시키며, 요구 변경에 열려 있다.[2] 점진·반복 생명주기 자체는 소프트웨어 개발 생명주기에서 다룬다.
애자일 선언
Extreme Programming, Scrum, DSDM(Dynamic Systems Development Method) 같은 경량 개발 방법을 대표하던 열일곱 명이 2001년 2월 11일부터 13일까지 미국 유타주 Snowbird에 모여 Manifesto for Agile Software Development(애자일 선언)에 합의했고, 참석자 모두가 선언에 서명했다.[3] 선언의 저자들은 선언을 agilemanifesto.org에 공개하고, 저자가 아닌 지지자들의 서명도 받아 명단으로 실었다.[4]
선언의 저자들은 네 가지 가치를 두 항목을 견주는 꼴로 적고, 뒤 항목에도 가치가 있지만 앞 항목을 더 중시한다고 밝혔다.[5]
| 더 중시하는 것 | 그보다 덜 중시하는 것 |
|---|---|
| 개인과 상호작용 | 프로세스와 도구 |
| 동작하는 소프트웨어 | 포괄적인 문서 |
| 고객과의 협력 | 계약 협상 |
| 변화에 대응하기 | 계획을 따르기 |
선언의 저자들은 이 가치 뒤에 열두 원칙을 두었다. 요지는 다음과 같다.[6]
- 가치 있는 소프트웨어를 일찍부터 끊이지 않게 인도해 고객을 만족시키는 일을 가장 앞에 둔다.
- 개발이 많이 진행된 뒤에 들어온 요구 변경도 받아들이고, 변화를 고객의 경쟁력으로 돌린다.
- 동작하는 소프트웨어를 몇 주에서 몇 달 사이 간격으로 자주 인도하되, 간격은 짧을수록 좋다.
- 업무 쪽 사람과 개발자는 프로젝트 기간 내내 날마다 함께 일한다.
- 의욕 있는 사람들을 중심으로 프로젝트를 꾸리고, 필요한 환경과 지원을 주며 일을 해낼 것이라 믿고 맡긴다.
- 개발 팀에 정보를 전하고 팀 안에서 정보를 나누는 데는 얼굴을 맞댄 대화가 가장 효율적이고 효과적이다.
- 진척을 재는 첫째 척도는 동작하는 소프트웨어다.
- 지속 가능한 개발을 추구해, 후원자, 개발자, 사용자가 한결같은 속도를 기한 없이 이어 갈 수 있어야 한다.
- 기술적 탁월함과 좋은 설계에 늘 관심을 두면 민첩성이 높아진다.
- 할 필요가 없는 일은 되도록 하지 않고 넘기는 단순함이 핵심이다.
- 가장 좋은 아키텍처, 요구, 설계는 스스로 조직하는 팀에서 나온다.
- 팀은 정기적으로 더 효과적으로 일할 방법을 돌아보고 그에 맞춰 행동을 다듬는다.[6]
대표 방법
SWEBOK V4.0a에 따르면 널리 쓰이게 된 애자일 방법에는 XP(Extreme Programming)와 Scrum 등이 있다. 이 지침에 따르면 DevOps는 애자일 개발의 잦은 반복이 주는 피드백에, 운영 환경에서 오는 피드백을 더한다.[2]
폭포수 모델과의 차이
폭포수 모델은 예측형 생명주기의 한 예다. 폭포수 모델은 문서 주도(document-driven) 모델이고, 한 단계가 끝나야 다음 단계를 시작할 수 있는 엄격한 프로세스를 따른다. 이와 달리 적응형 생명주기는 새로 드러나는 요구를 받아들이고 계획을 반복마다 고치도록 짜인다. 짧은 반복 개발 주기를 거치며 요구를 점차 구체화하고, 처음 계획을 차츰 고쳐 가며 위험과 비용을 줄이며, 핵심 이해관계자가 계속 참여한다.[2]
ISO/IEC/IEEE 24765:2017은 적응형 생명주기(adaptive life cycle)를 변경 주도 방법이나 애자일 방법이라고도 부르는 프로젝트 생명주기로 정의한다. 이 생명주기는 변경을 쉽게 받아들이고 이해관계자가 계속 깊이 참여해야 하며, 반복적이고 점진적이되 반복이 대개 2주에서 4주로 매우 짧고 시간과 자원이 고정된다.[1]
SWEBOK V4.0a에 따르면 애자일 선언의 서명자들은 사용자의 요구가 바뀌면 개발의 어느 단계에서든 요구를 고칠 수 있도록 프로세스가 변경에 열려 있어야 한다고 보았다. 이들은 소프트웨어를 작은 단위로 점진적으로 인도하기를 내세웠다.[2]