보다 빠른 전달가치를 중시하여, 애자일 제품 관리 고객 피드백에 대한 빠른 대응을 우선시해야 합니다. 그럼에도 불구하고 많은 조직은 여전히 ​​번거로운 변경 관리 방식에 의존하고 있으며, 이는 릴리스 전달에 병목 현상을 초래할 수 있습니다. 수동 변경 검토와 같은 기존 관행이 리드 타임 및 주기 시간에 영향을 미치도록 방치하면 제품과 고객 경험 모두에 부정적인 영향을 미칩니다.

제품 관리자가 변경 승인 시간 단축과 같은 노력에 참여하는 경우는 드물지만, 실제로는 변경 전달 속도를 높이는 것이 백로그 관리만큼이나 중요합니다. 따라서 변경 승인 팀은 제품 관리자에게 역으로 접근하여 사용자 스토리에서 배포까지의 프로세스를 가속화하고, 변경 승인 시간에 대한 공동의 책임을 지는 방식으로 중간에서 서로 만나야 합니다.

데이터 분석 및 자동화와 같은 기술을 통해 변경 승인 속도를 높일 수 있습니다. 인공지능 및 머신러닝(AI/ML) 분석은 변경 위험을 모델링하여 팀이 실질적인 위험 위협을 야기하는 변경에만 시간을 할애할 수 있도록 지원합니다. 자동화는 특히 표준 변경 모델에 적합한 저위험 변경에 대한 자동 승인을 제공할 수 있습니다. 이러한 프로세스는 릴리스 빈도를 높이고 고객 만족도를 향상시킵니다. 또한 다음 릴리스에서 유익한 변경 사항을 즉시 배포할 수 있는 기회를 제공합니다.

변화 관리가 가치 전달의 중요한 지점입니다.

소프트웨어 배포 파이프라인은 릴리스가 변경 승인을 기다리는 동안 크게 느려질 수 있습니다. 그러나 많은 조직은 변경 승인 정책에 여전히 신중한 태도를 보이며 거의 모든 경우에 변경 자문 위원회(CAB)의 수동 승인을 요구합니다.

변경 승인이 개발에서 운영으로의 이관(handoff)을 의미하기 때문에 개발 속도 저하가 발생할 수도 있습니다. 조직이 개발과 운영 사이에 심하게 분리되어 있는 경우, 새 릴리스가 배포 승인을 기다리는 동안 대기열이 형성될 수 있습니다. 이러한 관계를 고려할 때, 변경 승인이 느리다는 것은 단순히 고객이 다음 릴리스를 기다리는 것 이상의 의미를 가질 수 있다는 점을 언급할 가치가 있습니다. 또한, 개발 과정에서 피드백을 활용하여 진행 중인 작업에 반영하는 데 지연이 발생할 수 있음을 나타낼 수도 있습니다.

The scrum.org 팀은 이러한 피드백 지연이 초래하는 악영향을 강조하고, 팀원들이 짧은 출시 기간보다 짧은 "학습 시간", 즉 빠른 피드백 루프를 모색하는 것을 개념적으로 고려하도록 장려합니다. 그 차이는 미묘하지만, 문화적 관행에 반영될 것입니다. 변경 사항이 배포되면 기업은 고객과 사용자의 피드백 루프를 기반으로 해당 변경 사항의 효과를 파악하기 시작할 수 있습니다.

변화 관리팀은 중요한 역할을 합니다. 바로 릴리스가 품질, 성능, 보안에 대한 최소 기준을 충족하는지 확인하는 게이트키퍼 역할을 하는 것입니다. 이는 결국 전체적인 가치 제공으로 요약될 수 있습니다. 팀은 다음 두 가지를 통합하여 핸드오프 문제를 해결할 수 있습니다.

1. 변경 검토 주기 시간의 소유권을 양측에서 장려하기 위해 필요한 프로세스 개선을 구현합니다. DevOps
2. 위험 관리를 더 빠르고 유익하게 만들기 위해 분석 기술에 투자하세요

Agile 제품 관리에는 변경 관리가 포함되어야 합니다.

애자일 제품 관리자는 이미 많은 업무를 처리해야 합니다. 그럼에도 불구하고 필요한 변경 사항이 적시에 시장에 반영되도록 전체 사이클 타임에 대한 책임을 져야 합니다.

뒤처지는 "주문 접수자" 역할을 넘어 주도적이고 적극적인 역할로 전환하기 위해 애자일 전문가들은 변화 관리와 제품 관리가 유연해질 수 있도록 프로세스 개선 기회를 찾는 것이 좋다고 제안합니다. 팀 크리시Prosci의 최고 혁신 책임자는 다음을 포함한 효과적인 변화 관리 관행에 대해 설명합니다.

• 접근 — 변경 관리 접근 방식은 Agile 프로세스 단계에 맞춰야 하며 어떤 활동이 가치를 창출하는지에 대해 선택적이어야 합니다.
• 리소스 — 변경 관리 리소스 요구 사항은 Agile 개발 노력 전반에 걸쳐 다르며, 주어진 단계의 직원 영향에 따라 방향을 전환할 준비가 되어 있어야 합니다.
• 프로젝트 관리와의 통합 — 변화 관리팀과 프로젝트팀은 더 높은 수준의 의사소통과 협업을 통해 더 일찍 통합해야 합니다.

프로세스를 매핑하고 변경 관리를 개선할 수 있는 부분을 파악하세요. 니나 스카르니치 (PMP, Publicis Seattle)은 절차적 문제가 프로세스를 지나치게 복잡하게 만들어 병목 현상을 야기할 수 있다고 말합니다. "이런 상황이 발생할 때, 문제를 해결하는 가장 쉬운 방법은 시간 낭비 부분을 파악하고, 업무 프로세스를 간소화하며, 워크플로우를 개선할 기회를 찾는 것입니다."

더 작은 배치 크기를 목표로 하세요. DevOps그룹 변화에 대한 사고 실험을 실행했습니다. 배포 빈도 분기별에서 월별, 그리고 일별로 전환되었습니다. "배치 크기가 작을수록 테스트, 배포, 실패 시 롤백이 더 쉽습니다. 따라서 배포 빈도 증가와 배치 크기 축소로 인해 변경 실패율, 리드 타임, MTTR(평균 고장 수리 시간)이 감소하고 가용성이 향상될 것으로 예상됩니다."

더 빈번한 배포는 덜 빈번한 주기로 동일한 변경을 수행하는 것보다 전체적으로 더 많은 가치를 제공한다는 점을 인식하세요. DevOps그룹 "각 배포는 고객이 실제로 무엇을 원하고 필요로 하는지 파악할 수 있는 기회이므로, 낭비되는 노력도 줄어들 것으로 예상됩니다. 많은 팀이 고객이 실제로 원하지 않고 사용하지 않는 기능을 구축하는 데 시간을 허비합니다(일부 추정에 따르면 제공된 기능의 최대 50% 이상이 고객에게 가치를 제공하지 않아 낭비입니다). 더 자주, 더 작은 단위로 배포함으로써, 궁극적으로 아무런 가치도 제공하지 못하는 대량의 작업을 한꺼번에 처리하는 것을 방지할 수 있습니다."

애자일 제품 관리에는 고객 피드백을 향후 기능 계획에 반영해야 하는 필요성을 포함하여 많은 우선순위가 있지만, 제품 관리는 변경 전달 시간도 높은 기준으로 유지해야 합니다. 다시 말해, 변경 관리 개선은 가치 전달 가속화와 개선을 위한 쉬운 목표인 경우가 많습니다. DevOps 전반적인 팀 연속성.

디지털 혁신을 위한 데이터 기반 통합 전략을 구축하는 방법을 알고 싶으신가요? 웨비나를 시청해 보세요. 놀라운 비즈니스 성과의 핵심은 데이터입니다.