애자일 개발

애자일 개발은 짧은 반복 주기로 작업을 완료하고, 지속적인 피드백을 반영하며, 이해도가 향상됨에 따라 계획을 조정하는 소프트웨어 개발 접근 방식입니다. 2001년 발표된 애자일 선언문에서 제시된 이 개념은 네 가지 핵심 가치, 즉 프로세스와 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 소프트웨어를, 계약 협상보다 고객과의 협업을, 그리고 계획을 따르는 것보다 변화에 대응하는 것을 우선시합니다.

선언문의 표현은 종종 중요한 방식으로 잘못 인용됩니다. 각 진술은 두 가지 가치 있는 것 중 하나를 선호하는 것을 나타내는 것이지, 두 번째 것을 거부하는 것이 아닙니다. 이 문서는 오른쪽에 있는 항목들도 가치가 있지만, 왼쪽에 있는 항목들이 더 가치 있다고 명시적으로 밝히고 있습니다. 선언문을 문서화, 계획 또는 계약을 금지하는 것으로 해석하는 구현 방식은 선언문의 내용 중 절반을 무시하는 것이며, 일반적으로 비판자들이 접근 방식 자체의 문제점으로 지적하는 혼란을 초래합니다.

근본적인 이유는 불확실성에 있습니다. 순차적 개발은 요구사항을 사전에 정확하게 명시할 수 있다는 가정을 전제로 하는데, 이는 잘 이해된 문제에는 적용되지만, 사람들의 반응에 따라 가치가 달라지는 제품에는 적합하지 않습니다. 반복적 개발은 의사결정과 그에 대한 증거 확보 사이의 간격을 단축함으로써 오류로 인한 비용을 줄여주는데, 이는 문제의 불확실성이 클수록 더욱 중요해집니다.

실제로 가장 흔히 발생하는 실패는 원칙 없이 절차만 도입하는 것입니다. 조직들은 일일 회의, 반복 주기, 예상 소요 시간 산정 등의 절차를 도입하면서도 고정된 범위, 고정된 마감일, 연간 계획 수립, 그리고 피드백을 반영하는 메커니즘 부재를 반복합니다. 그 결과, 2주 단위로 진행되는 순차적인 개발과 추가 회의가 발생하는데, 이는 제대로 된 접근 방식보다 훨씬 느리고, 해당 방법론에 대한 광범위한 회의론을 낳습니다.

고객과의 협업은 조직들이 가장 어려워하고 가장 자주 간과하는 요소입니다. 피드백에 맞춰 변화하려면 실제로 피드백을 얻어야 하는데, 이는 실제 사용자가 작동하는 소프트웨어를 정기적으로 사용해야 한다는 것을 의미합니다. 내부 이해관계자나 문서화된 사양과 같은 대리인에 의존하여 작업하는 팀은 목적의식을 부여하는 입력 없이 반복 작업을 수행하며, 아무도 검증하지 않은 방향으로 자신 있게 반복 작업을 진행합니다.

규모 확장은 원래 선언문에서 다루지 않았던 실질적인 어려움을 야기합니다. 선언문은 소규모의 같은 장소에 있는 팀을 염두에 두고 작성되었기 때문입니다. 하나의 제품을 위해 여러 팀을 조율하려면 정렬, 의존성 관리 및 아키텍처 일관성을 위한 메커니즘이 필요하며, 이를 해결하기 위해 개발된 다양한 확장 프레임워크는 오히려 원래 의도했던 프로세스 부담을 다시 가져온다는 비판을 자주 받습니다. 이러한 갈등은 이해 부족이 아니라 실제로 존재하는 문제입니다.

평가는 규정 준수보다는 결과에 초점을 맞춰야 합니다. 중요한 질문은 아이디어 구상부터 검증된 학습까지 걸리는 시간이 단축되었는지, 근거가 뒷받침될 때 팀이 방향을 바꿀 수 있는지, 마감일에 쫓기지 않고 품질을 유지할 수 있는지, 그리고 제품이 사용자에게 실질적으로 더 나은 경험을 제공하는지 여부입니다. 정해진 사양에 맞춰 매년 제품을 출시하면서 모든 규정된 절차를 따르는 팀은 용어만 익힐 뿐, 실질적인 이점은 얻지 못합니다.

이 접근 방식은 팀의 실무뿐만 아니라 조직 환경에도 크게 의존하기 때문에 도입하려면 실행 팀 외부의 거버넌스, 자금 조달 및 계획 변경이 필요한 경우가 많습니다. 실제로 이러한 문제는 내부에서 해결됩니다. 방열판 열 관리용 배송 과정 자체와 함께, 피드백 루프는 다음과 같은 요소들에 의해 뒷받침됩니다. 사용자 조사그리고 조직이 내부적으로 역량을 구축할 때는 보통 그 역량을 특정 체계 내에 확립합니다. 제품 부서 계획과 실행에 대한 책임이 함께 ​​있는 곳.