분석은 보다 민첩한 계획을 위한 기반입니다.

애자일 계획본질적으로 빠르고 적응력이 뛰어나며, 필요에 따라 변경할 수 있는 여지를 제공합니다. 그러나 유연하게 설계된 프로세스는 애자일 팀 내에서 어떤 사용자 스토리를 우선시해야 하는지에 대한 주관적인 요인의 영향을 받을 수도 있습니다.

애자일 계획에서 진정한 객관성은 데이터와 분석을 통해서만 확보할 수 있습니다. 데이터는 프로세스 내에서 무슨 일이 일어나고 있는지, 그리고 그 프로세스의 실제 결과가 어떻게 되는지에 대한 진실을 보여줍니다. DevOps 작업은 다음과 같습니다. 데이터는 어떤 기능과 스토리가 가치를 가지고 있는지, 그리고 어떤 가치를 제공하는지, 예를 들어 사용성 개선이나 매출 증대와 같은 가치를 제공하는지 알려줍니다. 데이터는 측정 가능한 결과와 추측을 구분하는 데 사용되는 도구입니다.

데이터가 없으면 수행된 작업이 사용자에게 긍정적인 영향을 미치고 우선순위가 높은 비즈니스 성과를 달성하는 데 도움이 되는지 여부에 단절이 발생할 수 있습니다. 데이터 누락으로 인해 우선순위가 임의로 설정될 수도 있습니다. 그러나 데이터가 활용되면 개발팀뿐 아니라 조직 전체의 이해관계자들이 다음과 같은 중요한 질문에 대한 답을 과학적으로 도출할 수 있습니다.

1. 사용자에게 가장 중요한 기능은 무엇입니까?
2. 어떻게 하면 프로세스를 개선할 수 있을까?
3. 우리는 효율적인 방법으로 최대의 가치를 제공하고 있는가?

데이터 피드백은 비전을 안내하고 때로는 임의적인 의사 결정 과정의 특성을 제거합니다.

데이터 분석을 활용해 민첩한 계획을 개선하고 구체적인 가치를 창출하는 더 나은 결과를 도출하는 방법에 대한 몇 가지 예를 소개합니다.

• 사용자 스토리 우선 순위 지정
• 데이터 피드백을 사용하여 릴리스 계획 수립
• 스프린트 성능 평가
• 프로세스 최적화 기회 찾기
• 시장의 변화하는 요구에 신속하게 대응하기 위해 전환
• 고객에게 필요한 새로운 기능 결정

예측된 비즈니스 결과에 따라 사용자 스토리 우선 순위 지정

모든 피드백을 평가하는 것이 중요합니다. 공동 창작 기회가 매출이나 제품 출시와 같은 비즈니스 목표에서 도출할 수 있는 가치는 수동적 또는 능동적인 사용자 또는 고객 피드백에서도 얻을 수 있습니다.

• 수동적 피드백 특정 기능의 일일 활성 사용 및 사용자 오류 보고와 같은 측정 항목이 포함됩니다.
• 능동적 피드백 설문조사, 사용자 불만, 요청 등이 포함됩니다.

이러한 피드백 데이터를 활용하면 어떤 사용자 스토리가 가장 큰 영향을 미칠 수 있는지에 대한 객관적인 측정이 가능합니다. 예를 들어, 사용자 지표와 고객 피드백을 조합하면 사용자 이탈과 관련된 높은 지연 시간을 경험하는 특정 플랫폼 작업을 파악할 수 있습니다. 이는 지연 시간을 해결하고, 이탈률을 줄이며, 고객 경험을 개선할 수 있는 기회를 제공합니다.

사용자 스토리 우선순위 지정의 많은 일반적인 방법은 다음과 같이 주관적이라는 점을 명심하십시오. 모스크바 우선 포커또한, 많은 중요한 결정들이 제품 소유자나 애자일 팀의 재량에 맡겨집니다. 좋은 의도를 가지고 있더라도, 데이터 없이 결정을 내린다면 결국 추측에 불과합니다. 스크럼 리더들에게 직관만이 유일한 지침이 될 수는 없습니다. 스크럼 리더들은 가장 큰 이점을 가져올 수 있는 스토리에 집중해야 합니다. 구현 시간과 같은 내부적인 고려 사항 또한 스크럼 팀이 가장 큰 가치를 제공하는 스토리에 우선순위를 두지 못하게 만들 수 있습니다.

서비스, ​​테스트, 보안 및 운영에서 얻은 데이터 피드백을 사용하여 릴리스 계획을 수립합니다.

다른 도메인의 분석을 적용하는 것은 위의 사용자 스토리 우선순위 지정 사용 사례와 유사하지만 릴리스 계획의 더 큰 규모에 해당합니다. Agile 및 DevOps 팀은 서비스, 테스트, 보안 및 운영 부문의 데이터 피드백이 필요합니다. 이러한 피드백을 통해 출시 계획에 중요한 우선순위를 부여할 수 있습니다. 가장 매력적인 기능을 추구하는 것만으로는 충분하지 않습니다. 선택을 뒷받침할 데이터가 있어야 합니다.

데이터 피드백은 중요한 단계입니다. DevOps. 그것은의 일부입니다 8자 모양 다이어그램하지만 간과될 수 있습니다. 개발 부서는 운영 피드백만을 기반으로 관행이나 우선순위를 조정하라는 지시를 거의 받지 않습니다. 그러나 이러한 피드백은 모든 작업 단계에서 더 큰 가치 창출을 실현하는 데 필수적일 수 있습니다. 데이터는 제품의 중요한 변경 사항을 파악하고 중요한 항목을 출시 일정에 추가할 수 있습니다.

예를 들어 보안 테스트에서 취약점이 보고되면 보호의 격차를 메우기 위한 노력이 필요하다는 것을 의미합니다.

마찬가지로, 다음에서 생성된 운영 보고서 변화 위험을 측정하는 분석 결함이나 사고로 이어지는 관행에 대해 개발팀에 알릴 수 있습니다. 개발 리더는 모든 주요 기록 시스템의 데이터를 활용하여 변경 위험의 원인이 되는 특정 관행, 팀, 개인 또는 CI 상관 관계를 근절하고 해결할 수 있습니다.

스프린트 성과 및 비즈니스 결과 평가

많은 애자일 팀은 예상 결과를 지향하지만, 실제 결과가 항상 측정되는 것은 아닙니다. 성과 평가는 저조한 성과를 처벌하는 수단으로 여겨지기보다는 자기 성찰적인 방식으로 이루어져야 합니다. 팀은 단순히 "무엇이 잘못되었는가?"라고 묻는 대신, "무엇이 잘되었는가?"와 "무엇을 개선할 수 있는가?"라고 질문할 수 있습니다.

평가 도구의 좋은 예는 다음과 같습니다. 번다운 차트이 차트는 작업 마일스톤을 기반으로 스프린트 내 작업 진행 상황을 보여줍니다. 이러한 짧은 작업 덩어리에는 스프린트 기간 동안 완료해야 할 구체적인 목표가 포함되어 있으며, 각 마일스톤을 완료하는 데 걸리는 시간은 시각적으로 추적되며, 더 짧은 시간은 차트에 더 짧은 "단계"로 표시됩니다.

일반적으로 완료된 스프린트 결과를 보고 목표 달성 여부에 따라 성과가 좋거나 나쁘다고 판단할 수 있습니다. 하지만 번다운 차트를 자세히 살펴보면 더 복잡한 그림을 그릴 수 있습니다. 스프린트를 일찍 완료하면 마일스톤 사이의 작업을 확장할 수 있지만, 마감일을 놓쳤다는 것은 너무 많은 작업이 수행되었음을 의미할 수 있습니다. 가파른 단계로 구성된 번다운 시각화는 작업이 충분한 단위로 나누어지지 않았음을 의미할 수 있습니다. 이러한 데이터는 실행 가능하며, 더욱 효과적인 스프린트를 계획하는 데 도움이 될 수 있습니다.

팀 목표 또한 성공의 핵심입니다. 자율적인 팀은 생산성을 향상시킬 뿐만 아니라 직원 참여도를 높여줍니다.

으로 맥킨지 & 컴퍼니 기사에서는 "성공적인 애자일 조직은 목표를 설정하고 성과를 평가할 때 팀 성과에 중점을 두며, 종종 팀이 스스로 목표를 정의하여 소유권을 갖도록 허용합니다."라고 설명합니다.

최적화 기회를 위한 프로세스를 면밀히 조사합니다.

조직은 업무 흐름뿐만 아니라 각 업무 단계에 따른 가치 흐름을 이해할 수 있어야 합니다. 이러한 가치 흐름 시각화 분석을 통해 프로세스 개선의 기회를 발견할 수 있습니다.

한 가지 예시 기능은 전체 리드/사이클 시간을 특정 단계에서 소요된 시간과 비교하여 달성됩니다. DevOps. 흐름 시간을 파악하면 작업 사이의 단계, 즉 릴리스가 완료되지 않은 상태, 승인을 기다리는 상태, 또는 팀 간 핸드오프 과정에서 림보 상태에 있는 상태를 파악할 수 있습니다. 다음과 같은 질문을 던져볼 수 있습니다.

• 이런 '사각지대'를 어떻게 없앨 수 있을까?
• 팀에 사전 승인을 받을 수 있나요?
• 변화를 더 표준화된 방식으로 모델링할 수 있을까?
• 보안 컨설턴트를 스크럼 팀에 배치하는 등 팀을 재구성하여 별도의 컨설팅이 필요 없게 할 수 있을까요?

조직은 단순히 제품을 개선하는 데 그치지 않고, 당연하게 여겨왔던 프로세스도 반복적으로 개선할 수 있음을 깨닫게 될 것입니다. 데이터는 도구, 프로세스, 인력 등 다른 영역의 병목 현상을 보여줄 수 있습니다. 이러한 병목 현상을 파악하는 것은 번거로운 수동 단계와 프로세스를 파악하고 자동화하여 민첩성과 효율성을 높일 수 있는 기회이기도 합니다.

데이터 시대에 맞춰 민첩한 계획 수립

애자일은 생산적인 사고방식이지만, 종종 자의적이거나 주관적인 요인에 좌우될 수 있습니다. 소프트웨어 개발은 ​​직관이나 판단에 기반하기보다는 데이터 중심적이어야 합니다.

예를 들어, 사용자 스토리의 우선순위를 정하는 데 비데이터 기반 방식을 사용하는 경우가 있습니다. 이러한 방식은 종종 제품 관리자나 제품 책임자가 시장과 고객에 대한 지식을 바탕으로 판단하는 데, 주관적일 수 있습니다.

데이터를 프로세스에 적용하면 더 나은 제품을 개발할 수 있을 뿐만 아니라 팀의 불필요한 업무도 줄일 수 있습니다. 데이터는 책임감과 주인의식을 강화할 수 있습니다. 분석에 대한 셀프서비스 접근 권한을 갖춘 팀은 목표를 설정하고, 프로세스를 개선하고, 더 나은 성과를 달성하기 위해 자율적으로 운영될 수 있습니다.

애자일 자체에는 민첩성이 필요합니다. 데이터만이 이를 달성할 수 있습니다. 그렇지 않으면, 눈 가리고 다트를 던지며 과녁의 정중앙을 맞추기를 바라는 것과 마찬가지입니다.

팀 수준에서만 Agile을 사용하는 것이 조직의 발전을 저해하는 이유와 효과성과 확장성을 높이기 위해 할 수 있는 일을 eBook에서 알아보세요.팀 수준의 애자일이 충분하지 않은 8가지 이유".