애자일 프로세스
폭포수 프로세스는 복잡한 문제를 잘 파악하고 이해하여 해결하는 프로젝트에는 적합합니다. 하지만 프로그램을 개발한다는 측면에서는 문서화 등의 오버헤드가 많은 단점이 있습니다. 이런 단점을 개발하기 위한 것이 애자일 프로세스입니다. 애자일 프로세스는 팀워크, 사용자와 협력하여 개발, 변경을 위한 설계, 짧은 주기의 반복으로 빠른 속도로 개발하고 자주 출시한다는 면을 강조합니다. 애자일 프로세스는 새로운 가치와 원리, 최적의 방법을 제시하고 있는데 이로써 폭포수 프로세스의 단점을 해결하고 있다.
애자일 프로세스는 다음 네 가지 가치를 철학으로 담고 있다.
1. 절차와 도구보다는 개인과 소통을 중요시합니다.
전통적인 프로세스에서는 계획 위주의 절차가 프로젝트 성공을 위하여 필수적이라고 믿습니다. 즉 소프트웨어의 품질은 프로세스에 의하여 좌우된다고 믿어왔습니다. 프로세스가 일부를 수긍이 가지만 경험에 의하면 프로젝트팀 구성원의 능력과 팀워크가 더 중요하다. 전통적인 프로세스는 절차에 맞는 도구를 잘 사용하면 개발에 성공할 수 있었습니다. 하지만 최근의 소프트웨어는 지식 중심적이며 개발자의 지식에 크게 좌우된다. 또한 시스템의 규모가 커져 팀원들이 협력하여 작업이 많아 개인의 능력과 팀워크가 프로젝트 성공에 필수 요소가 되었습니다.
2. 잘 쓴 문서보다는 실행되는 소프트웨어에 더 가치를 둔다.
지난 수십 년 동안 소프트웨어 개발은 분석과 설계 문서를 준비하는 데 많은 공을 들여왔다. 그 이유는 좋은 소프트웨어는 좋은 설계 문서를 통하여 이루어진다는 믿음 때문이다. 하지만 많은 개발자들의 경험에 의하면 프로그래밍하기 전까지는 진정한 요구를 결정하거나 설계가 작동하는지 확인하기 어렵습니다. 이런 경우 잘 쓴 문서가 도움이 안 되며 완성될 시스템에 대한 망상을 주어 오히려 방해될 수 있습니다. 문서를 잘 준비한다는 의미는 그만큼 코딩과 테스팅에 시간을 적게 사용한다는 의미가 됩니다. 애자일 프로세스는 잘 실행되는 소프트웨어가 진정한 요구이며 설계라고 여겨집니다.
3. 계약 절충보다는 고객 협력을 더 중요하게 여긴다.
전통적인 프로세스는 고객이 무엇을 원하는지 알아내고 절충하는 과정이 있습니다. 요구 명세서를 작성하고 여기에 서명하여 계약이 이루어집니다. 이후 개발 과정에 고객은 설계를 리뷰하고 인수 테스트하는 작업에만 참여합니다. 따라서 고객과 함께 결정하여야 할 중요한 사항을 개발팀이 결정하게 될 수도 있습니다. 고객과의 협력은 프로젝트 성공에 필수적입니다. 고객이 원하는 진정한 요구가 무엇인지 서로 의견을 교환하고 상호 이해하는 것이 프로젝트의 실패 확률을 줄이게 됩니다.
4. 계획을 따라 하는 것보다 변경에 잘 대응하는 것을 중요하게 여긴다.
전통적인 프로세스는 변경을 제어합니다. 변경될 경우 비용이 많이 발생하기 때문이다. 요구 명세서와 같은 산출물이 작성된 후에는 동결하고 이후 발생하는 변경은 엄격한 관리 절차를 밟아야 합니다. 변경 요구에 대한 대응 작업을 막고 있습니다. 오늘날 세상은 빠르게 변하고 비즈니스 조건도 급격히 변하고 있어서 변경을 잘 대처하는 것이 성패를 가늠하는 요소가 되고 있습니다. 소프트웨어에 대한 변경도 피할 수 없는 것입니다. 인터넷 기술의 발전으로 웹 애플리케이션을 빠르게 자주 변경하게 되었으며 또한 그렇게 하여야 살아남을 수 있다. 계획 중심의 프로세스는 이런 상황에 잘 맞지 않기 때문에 애자일 프로세스가 출현한 것이라 할 수 있습니다. 애자일 프로세스의 가장 중요한 원리는 사용자가 적극적으로 프로젝트에 참여한다는 점이다. 전통적인 프로세스는 요구 분석에 개발 노력의 15~25% 정도를 사용합니다. 이 정도로는 개발 초기 단계에 진정한 요구를 찾기 어렵고 계속 변경될 여지가 있습니다. 따라서 애자일 프로세스에서는 개발팀과 사용자 대표가 자주 만나고 많은 시간을 대화하여 잘못된 요구가 없게 하고 있다면 수정합니다.
애자일 프로세스에서는 개발팀이 중요한 결정을 내리는 권한이 가집니다. 프로세스나 도구보다는 개발자나 팀의 협력이 더 중요하기 때문입니다. 팀원들은 책임과 권한을 가지고 서로 긴밀히 협력합니다.
전통적인 프로세스에서는 요구를 동결하지만 애자일 프로세스는 변경을 환영하는 입장입니다. 작업의 범위가 요구의 변경으로 인하여 확대될 수 있음을 의미합니다. 하지만 요구의 변경은 정해진 예산과 시간 범위 안에서 수용할 수 있습니다. 즉 추가적인 노력은 중요하지 않은 다른 요구를 포기함으로 가능합니다. 애자일 프로세스는 문서보다 실행되는 시스템에 더 가치를 둔다고 하였습니다. 이를 위하여 작은 카드에 사용자 스토리 또는 사용 사례나 피처 단위로 요구를 파악합니다. 또한 스토리 카드나 스크린 캡처 등으로 사용자가 시스템과 어떻게 상호작용하는지 가시화한다. 이런 작업이 복잡한 문서화 작업을 피하고 요구를 쉽게 변경하거나 절충하는 데 도움을 줍니다.
애자일 프로세스는 사용 사례 또는 사용자 스토리나 피처 단위로 조금씩 반복적으로 릴리스합니다. 이렇게 하면 여러 가지 장점이 있다. 프로젝트의 진도가 눈이 보이고 사용자는 한 번에 작은 새로운 피처에 집중할 수 있습니다. 또한 사용자의 피드백을 주기 쉬우며 프로젝트의 위험도를 줄여준다.
애자일 프로세스는 다음 반복 주기로 넘어가기 전에 각 기능을 완성한다. 즉각 기능은 다음 반복 주기로 넘어가기 전에 100% 구현되고 테스트 됩니다. 이렇게 될 수 있는 이유는 각 기능에 대한 테스트가 개발이 완료되기 전에 준비되기 때문입니다. 이를 테스트 중심 개발이라 합니다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)