애자일과 워터폴 비교

• 상세한 제품 요구 사항 및 문서를 통해 새로운 프로그래머는 빠르고 쉽게 온보딩할 수 있습니다.
• 문서화는 프로젝트에 대한 명확한 범위를 제공하여 프로젝트 매니저가 예산, 일정, 주요 이정표를 이해당사자에게 전달할 수 있도록 합니다.

• 고객은 프로젝트 초기에 모든 요구 사항을 설명하는 것이 어려워 문서에 공백이 생길 수 있습니다.
• 개발 프로세스 중 최소한의 고객 협업은 제품이 기대치에 미치지 못할 경우 비용이 많이 드는 변경으로 이어질 수 있습니다.
• 테스터는 프로세스 후반에 문제와 버그를 보고하여 대체 프로그램 아키텍처에 정보를 제공할 수 있습니다.

워터폴 개발과 달리 애자일은 프로젝트 관리에 대한 반복적인 접근 방식으로 정의됩니다. 애자일 팀은 처음부터 긴 프로젝트 요구 사항의 초안을 작성하는 대신 제품을 특정 기능으로 나누고, 스프린트로 알려진 특정 시간 제약 하에서 각 기능을 처리합니다.

애자일 프로젝트 관리에는 일반적으로 5~9명으로 구성된 자율적인 다기능 팀이 필요합니다. 이들은 함께 각 스프린트 중에 실행 가능한 소프트웨어를 개발하여 이전 반복 주기에서 만들어진 다른 기능 코드와 결합합니다. 스프린트 기간이 끝나면 팀은 이해관계자에게 작업을 시연하여 피드백을 받고 소프트웨어 개발에 대한 접근 방식을 유연하게 조정할 수 있습니다. 팀은 피드백을 자주 받을 수 있으므로 개발 수명 주기 동안 제품 로드맵을 조정하여 기능이 사용자의 기대에 진정으로 부합하도록 할 수 있습니다. 워터폴 접근 방식에서는 일반적으로 고객 참여가 최종 제품 제공 시점에 이루어지므로 요구 사항이 잘못 해석되거나 문서화되면 비용이 많이 들 수 있습니다.

17명이 워터폴 프로젝트 관리 시스템이 매우 비효율적이라고 생각했으며, 2001년에 소프트웨어 개발 프로세스에 대한 이들의 아이디어는 '애자일 매니페스토'로 알려진 작업으로 결실을 맺었습니다. 이 문서는 소프트웨어 개발 작업 스트림 내에서 우선순위를 정해야 할 특정 가치와 원칙을 강조하며 스크럼, 칸반, 기능 중심 개발(FDD), 익스트림 프로그래밍 등 널리 사용되는 민첩한 프레임워크를 다수 탄생시켰습니다. 그 이후로 민첩한 소프트웨어 개발은 특히 폭포수 모델에 비해 인기가 높아졌습니다.

럭비 경기에서 영감을 받은 애자일 스크럼은 럭비 공을 차지하기 위해 포워드가 스크럼을 이루어 협력하는 방식과 유사하게 결과물을 달성하기 위한 팀워크를 강조합니다. 애자일 스크럼 팀의 기술 세트는 다양하지만 일반적으로 다음과 같은 역할을 포함합니다.

• 프로덕트 오너: 이 팀원은 고객과 비즈니스 모두의 요구 사항을 나타냅니다. 사용자 스토리를 작성함으로써 팀은 기능 요청이 특정 문제를 해결하는 데 어떻게 도움이 될 수 있는지 이해할 수 있으며, 이러한 스토리는 팀이 해결해야 할 작업 백로그를 공식화합니다. 이 담당자는 또한 고객에 대한 가치에 따라 스토리의 우선순위를 정하며, 이는 이론적으로 비즈니스 가치로 전환되어야 합니다. 프로덕트 오너는 이러한 방식으로 팀을 이끌지만 마감일을 정하거나 팀에 작업 전달 방법을 지시하지는 않습니다.
• 스크럼 마스터: 이 팀원은 전반적인 애자일 개발 프로세스를 촉진합니다. 프로젝트 매니저와 마찬가지로 팀이 맡은 일을 차질 없이 수행하고 프로젝트 동안 집중력을 유지할 수 있도록 돕습니다. 또한 중립적인 입장에서 팀원 간 의견 불일치를 중재하는 역할을 할 수도 있습니다. 예를 들어, 팀원들이 주어진 스프린트에서 얼마나 많은 일을 맡을지에 대해 의견이 다를 수 있습니다. 특히 프로덕트 오너는 팀이 주어진 기간 내에 수행할 수 있는 범위를 넘어서는 약속을 하도록 압박할 수 있습니다. 이럴 때 스크럼 마스터는 팀원들에게 자신들의 역할과 책임 범위를 다시 상기시켜 줄 수 있습니다.

애자일 팀의 다른 팀원들은 다양할 수 있지만 일반적으로 설계, 분석, QA, 개발과 같은 다양한 분야의 사용자가 포함됩니다. 이들은 함께 협업하여 수행할 작업의 양과 완료 방법을 결정합니다.

애자일 방법론은 팀이 함께 모이는 방식으로도 정의됩니다. 팀 전체의 워크플로를 촉진하는 데 도움이 되는 특정 회의가 있습니다. 그중 일부는 다음과 같습니다.

• 스프린트 계획: 이 회의에서 팀은 함께 모여 현재 스프린트의 일부가 될 스토리를 결정합니다. 프로덕트 오너는 사용자 스토리의 우선 순위를 정하지만 나머지 팀은 설정된 기간 동안 완료할 수 있는 사용자 스토리의 수와 방법에 동의해야 합니다.
• 일일 스탠드업: 이러한 간단한 회의는 일일 스크럼이라고도 합니다. 이러한 체크인 과정에서 각 팀원은 완료된 작업, 예정된 작업, 지연을 초래할 수 있는 방해 요소나 종속성과 같은 개별 진행 상황을 전달합니다.
• 데모: 이 회의에서는 스프린트 기간 동안 팀이 완성한 실행 가능한 소프트웨어를 선보입니다. 스프린트는 2주에서 4주까지 다양합니다. 프로덕트 오너는 사용자 스토리가 '완료'의 정의를 충족하는지 판단합니다. 그렇지 않은 경우 누락된 항목을 설명하기 위해 제품 백로그를 정리할 수 있습니다. 팀이 이해관계자에게 프레젠테이션하여 피드백을 받을 수 있는 기회이기도 합니다.
• 회고: 팀 성찰을 위해 마련된 시간으로, 팀이 향후 더 나은 결과를 얻기 위해 워크플로를 개선할 수 있는 방법을 파악합니다.

• 팀 설계는 더 많은 협업을 촉진합니다.
• 제품 개발은 유연하게 조정 가능한 설계 방식으로 진행됩니다.
• 코드는 개발 단계에서 반복될 때마다 테스트되기 때문에 코드 결함은 향후 소프트웨어 설계에 영향을 줄 수 있습니다.
• 빈번한 피드백이 고객 요구 사항의 우선순위를 높이기 때문에 고객 만족도가 더 높은 경향이 있습니다.
• 각 기능이 독립적으로 실행 가능한 소프트웨어이므로 지속적인 통합이 가능합니다.
• 이러한 린 유형의 소프트웨어 개발은 고객 및 제품 불일치의 위험이 적기 때문에 비용을 절감할 수 있습니다.

• 애자일 접근 방식에는 포괄적인 문서가 부족할 수 있습니다. 이로 인해 신규 개발자 온보딩, 이해관계자에 대한 프로젝트 일정 안내, 정확한 비용 추정 제공이 어려워질 수 있습니다.
• 확장이 어려울 수 있습니다.

개발 팀은 두 가지 프로젝트 관리 방식 모두에서 성공을 거두었지만, 애자일 프로세스에 더 많은 추진력이 있는 것은 분명합니다. 오늘날 기업이 얻을 수 있는 이점을 살펴보면 그 이유를 어렵지 않게 알 수 있습니다. 팀이 진행 상황을 추적하는 데 도움이 되는 여러 프로젝트 관리 도구가 있지만, IBM은 개발자가 보다 애자일한 방식으로 코딩할 수 있는 시스템을 제공할 수도 있습니다.