# Agile

- 정의 : 짧은 주기의 개발 단위를 반복하여 조금씩 개선해 나가는 Projct 관리 방법입니다.
<details>
<summary>자세히 알아보기</summary>

- iterative approach to project management
- 반복에 기반한 Project 관리 방법입니다.
- software development that helps teams deliver value to their customers faster and with fewer headaches
- 까다로운 과정 없이 고객에게 더 빠르게 가치를 제공하기 위한 소프트웨어 개발 방법입니다.
- Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments
- 한 번에 완벽하게 출시하기 보단, 작지만 유의미한 개선을 추구합니다.
- Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly
- 요구 사항, 계획과 결과에 따라 자연스럽게 빠른 대응을 할 수 있는 방법입니다.

</details>

- 배경
- 시대가 바뀌어 가면서 Software의 사용자가 일반 대중으로 바뀌었습니다.
- 또한, Business Cycle이 짧아지고 사용자의 욕구와 trand가 빨리 바뀌게 되었습니다.
- 때문에 Software 개발의 불확실성이 높아졌습니다.
- 하지만, 기존의 폭포수 방법론은 애플리케이션이 실제로 동작할 때까지 수 개월이 걸렸기 때문에 이 시점에서 새로운 요구사항이 등장할 가능성이 높아졌습니다.
- Software가 배포된 후 기능을 변경하면 비용이 많이 들고, 해당 시점에서 사용하지 않는 기능도 존재하는 등 자원의 낭비가 많아짐을 알게 됩니다.
- 이에 경량 방법론 주의자들이 해 보면서 고쳐나가는 방식의 방법론을 고안했습니다.

- 목적
- 시장의 변화와 고객의 feedback에 신속하게 대응하기 위함입니다.
- 고객의 문제를 효과적으로 해결하기 위해 상세한 문서, 합의보다 고객 및 팀원과의 상호작용과 협업을 더 중요시 합니다.
- 적당히 엉성한 계획과 작은 제품, 잦은 개선을 토대로 최소 비용으로 변경사항에 대한 피드백을 받고 최종 계획에 반영할 수 있습니다.
- 자율성을 토대로 Agile team이 직접 자체 표준을 설정하여 주인의식을 갖게 함으로써 업무 효율을 높입니다.

- 선언문
- 공정과 도구보다 **개인과 상호작용**을
- 포괄적인 문서보다 **작동하는 소프트웨어**를
- 계약 협상보다 **고객과의 협력**을
- 계획을 따르기보다 **변화에 대응하기**를

- 원칙
- 우리의 최우선 순위는 가치있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
- 비록 개발의 후반부일지라도 요구 사항 변경을 환영하라. 변화를 활용해 고객의 경쟁력에 도움이 되게 하라.
- 작동하는 소프트웨어를 자주 전달하라. 두어 주 간격으로 하되 더 짧은 시간을 선호하라.
- 비즈니스에 관련된 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다.
- 동기가 부여된 개인들을 중심으로 프로젝트 팀을 구성하라. 그들이 필요로하는 환경을 지원해 주고, 그들이 일을 끝낼 수 있다고 확신하라.
- 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대 면 대화다.
- 작동하는 소프트웨어가 진척의 주된 척도다.
- 고객, 개발자, 사용자는 일정한 속도를 계속 유지하며 지속 가능한 개발을 장려해야 한다.
- 기술적 탁월성과 좋은 설계에 대한 지속적인 관심이 기민함을 높인다.
- 단순성이 필수적이다.
- 최고의 아키텍쳐, 요구 사항, 설계는 자기 조직적인 팀에서 나온다.
- 팀은 정기적으로 어떻게 더 효과적이 될 수 있을지 숙고하고 행동을 조율한다.