여러 산업 분야에서 가치가 있지만, 민첩한 방법론은 소프트웨어 개발 및 소프트웨어 개발 수명주기 (SDLC) 중에 가장 성공적인 것으로 입증되었습니다. 민첩한 선언문의 12 가지 핵심 원칙에서 출발 한 민첩한 방법론에는 결과물을 지속적으로 모니터링하고 개선하는 데 중점을 둔 반복 프로세스가 포함됩니다.
민첩한 프로세스는 기존의 폭포수 기법에 대한 대안으로 개발되었습니다. Waterfall 방법은 다음 단계로 넘어 가기 전에 단계를 완료해야하는 순차적 인 설계 프로세스입니다. 일반적으로, 폭포수 방법론은 건설에서 성공적으로 입증되었습니다. 그러나 더 많은 기술 산업의 경우 민첩한 접근 방식이 더 큰 가치를 지닙니다. 단계별 접근 방식을 따르는 대신 프로젝트의 모든 단계가 동시에 완료됩니다. 애자일 프로세스는 오류를 식별하고 프로젝트를 완전히 다시 시작할 필요가 없도록하여 개발주기의 예측할 수없는 특성을 처리하려고합니다.
민첩한 방법론
민첩한 방법론의 핵심 원칙은 지속적인 결과물을 통해 고객 가치를 충족시키고 제공하는 것입니다. 민첩한 방법은 장기간에 걸쳐 하나의 큰 프로젝트를 다루기보다는 프로젝트를 효과적이고 신속하게 완료 할 수있는 작고 단순하며 관리하기 쉬운 작업으로 나눕니다.
Spotify는 민첩한 프로세스로 잘 알려져 있습니다. 분대라고하는 회사의 가장 작은 그룹 단위는 자율적 인 스타트 업으로 작동합니다. 각 분대는 특정 기능에 중점을두고 실행 가능한 최소 제품을 기준으로 반복하여 업데이트를 조기에 자주 릴리스합니다. 정의에 따르면 최소 실행 가능한 제품은 팀이 작동하는 것과 그렇지 않은 것을 결정하는 데 필요한 최대 정보를 수집 할 수있는 최신 버전의 제품입니다. Spotify에서 각 팀은 작은 프로젝트를 처리합니다. 그러나 각 프로젝트는 더 큰 고객 가치 창출이라는 공통의 목표를 달성합니다.
조직은 제품을 조기에 자주 제공함으로써 가치를 높이 지 않는 모든 것을 제거해야합니다. 각 소규모 팀은 오랜 기간 동안 하나의 미션에 집중하므로 오류를 식별하고 제거하는 데 도움이되므로 개발주기의 특정 영역에서 전문가가됩니다. Waterfall 방법을 사용하면 상당한 시간, 돈 및 에너지가 이미 소비 된 후 프로젝트가 끝날 때까지 피드백이 제공되는 반면, 민첩한 방법론은 지속적인 피드백을 통해 변경 사항을 허용합니다. 원래 계획을 준수하는 관점에서 지속적인 피드백과 유연성을 통해 기능을 추가하거나 변경하여 조직이 업계의 최신 개발을 최신 상태로 유지할 수 있습니다.
민첩한 프로젝트의 작업은 반복을 통해 이루어집니다. 반복은 일반적으로 1-2 주 정도 소요되며, 이 기간 동안 고객의 요구가 개발되고 테스트 가능한 실행 가능한 제품으로 전환됩니다. 민첩한 방법론의 주요 특징은 프로젝트가 일련의 반복으로 구성된다는 가정입니다. 팀은 속도를 사용하여 계획을 현실적으로 유지하고 과도하게 커밋되지 않도록 각 반복 동안 달성 한 양을 추적 할 수 있습니다. 각 반복에서 선적 가능 제품은 분석, 설계, 테스트, 품질 보증 및 사용자 경험을 거쳐 완성됩니다. 모든 미세 조정 된 기능이 누락 될 수 있지만 팀 구성원은 필요한 경우 제품을 출시 할 수 있다고 확신해야합니다.
스크럼 방법론
Scrum, Lean 및 Extreme Programming을 포함한 몇 가지 프레임 워크가 민첩한 방법론 내에 존재합니다. 민첩한 방법론으로 전환하는 대부분의 조직은 단순성과 유연성으로 인해 스크럼으로 시작하기로 선택합니다. 스크럼 프로젝트는 회사와 고객에게 역할뿐만 아니라 역할, 회의 및 규칙에 대한 구조를 제공합니다. 팀 구성원은 예측 불가능한 상황에 대처하기 위해 프로세스를 학습하고 적응시키는 책임이 있습니다.
각 스크럼 프로젝트에는 백 로그 또는 작업 목록이 있습니다. 계획 단계에서 백 로그에는 작업, 목표 및 실행 기간이 채워집니다. 백 로그에 대해 논의한 후, 프로젝트는 스프린트로 분류되며, 이 기간은 여러 백 로그 항목을 완료하는 것을 목표로하는 1-2 주 기간입니다. 각 스프린트 동안 팀은 매일 진행되어 현재 진행 상황, 향후 진행 상황 및 진행을 방해하는 요소에 대해 논의합니다. 각 스프린트가 끝날 때 제품 출시가 발생할 경우 필요한 모든 단계를 완료해야합니다.
다음으로 제품 소유자는 스프린트 백 로그의 모든 스토리가 충분히 완료되었는지 확인하기 위해 검토를 수행합니다. 현재 ScrumMaster는 회고를 위해 팀을 만납니다. 팀원들은 미래의 스프린트에 대한 행동을 조정하기 위해 자신의 프로세스에 반영합니다. ScrumMaster는 일반적인 장애를 피하고 토론을위한 격려적인 환경을 조성하는 것이 중요합니다. 소프트웨어 및 제품 개발의 예측할 수없는 특성으로 인해 각 스프린트는 고유하며 변경 사항에 적응해야합니다.
Scrum 프로젝트는 제품 소유자, ScrumMaster 및 팀에 의해 촉진됩니다. 각 스프린트 동안 자체 관리 개인으로 구성된 팀은 필요한 모든 작업을 수행하는 방법을 결정하고 위임 할 책임이 있습니다. 팀 내에서 각 구성원은 전문 영역을 가지고 있습니다. 그러나 공식적인 제목이나 계층 구조는 없습니다. ScrumMaster는 스프린트 백 로그의 투명성을 보장하면서 장애를 해결하고 팀을 추적하는 전담 개인입니다. 마지막으로, 제품 소유자는 제품 비전을 작성하고 전달할 책임이 있으며 제품을 더 개발해야하는지 출시 준비가되었는지 결정합니다.
결론
오늘날 소프트웨어 개발에 널리 사용되는 민첩한 방법론은 정의 된 프로세스가없는 작업을 위해 개발되었습니다. 순차적 접근 방식과 달리 민첩한 방법은 반복적 인 유형의 작업을위한 것이 아닙니다. 많은 산업 분야에서 비즈니스 구조 내에서 민첩한 방법론을 구현해 왔습니다.
민첩한 프레임 워크에는 개인이 예측할 수없고 유연성을 다루는 데 도움이되는 Scrum, 린 및 익스트림 프로그래밍을 포함한 여러 하위 집합이 포함되어 있습니다. 표면적으로 민첩한 방법론은 종단 간 프로세스를 개선하는 데 도움이 될 수 있습니다. 그러나 개인이 일하기 위해서는 헌신적이고, 적응 가능하며, 배울 수 있어야합니다.
