디지털 발명을 통해 채택 역량 강화

궁극적인 혁신 테스트는 발명품에 대한 고객의 반응입니다. 가설이 사실로 증명되었나요? 고객이 솔루션을 사용하나요? 원하는 사용자 비율의 요구 사항을 충족하도록 스케일링되나요? 가장 중요한 점으로, 사용자들이 계속 돌아오고 있나요? MVP(최소 기능 제품) 솔루션이 배포될 때까지 이러한 질문을 할 수 없습니다.

이 문서에서는 CI/CD(연속 통합 및 지속적인 배포) 파이프라인 도구를 사용하여 채택 역량을 강화하는 데 초점을 맞춥니다. 연속 통합은 업데이트된 단일 프로젝트를 갖기 위해 하루에 여러 번 코드를 자동화하는 것입니다. 지속적인 배포는 하루 종일 이러한 기능을 자동으로 전달하는 것입니다.

채택에 영향을 주는 CI/CD 마찰 줄이기

기술과 프로세스를 적절히 조합하여 채택에 대한 몇 가지 장애물을 최소화할 수 있습니다. CI/CD 또는 DevOps 프로세스에 대한 지식이 있는 독자들은 다음 CI/CD 파이프라인 프로세스에 익숙할 것입니다. 이 문서에서는 혁신 및 피드백 루프를 촉진하는 클라우드 채택 팀의 시작점을 설정합니다. 이 시작점은 제품과 팀이 성숙함에 따라 보다 견고한 CI/CD 또는 DevOps 접근 방식을 발전시킬 수 있습니다.

고객 영향 측정값에 설명된 대로 가설에 대한 긍정적인 유효성 검사에는 반복 및 의사 결정이 필요합니다. 이 CI/CD 문서의 목적은 혁신을 늦추는 기술 급증을 최소화하는 동시에 모범 사례를 유지하는 것입니다. 이렇게 하면 팀이 현재 고객의 요구를 충족하면서 향후 성공을 위해 설계하는 데 도움이 됩니다.

채택 및 디지털 발명 역량 강화: 성숙도 모델

혁신 방법론의 주요 목표는 고객 파트너십을 구축하고 피드백 루프를 가속화하는 것이며, 이는 시장 혁신으로 이어집니다. 다음 이미지 및 섹션에서는 이 방법론을 지원하는 초기 구현에 대해 설명합니다.

• 공유 솔루션: 솔루션의 모든 측면에 대해 중앙 집중식 리포지토리를 설정합니다.
• 피드백 루프: 반복을 통해 피드백 루프를 일관되게 관리할 수 있도록 합니다.
• 연속 통합: 솔루션을 정기적으로 빌드하고 통합합니다.
• 신뢰할 수 있는 테스트: 솔루션 품질 및 예상 변경 내용의 유효성을 검사하여 테스트 메트릭의 안정성을 보장합니다.
• 솔루션 배포: 팀이 고객과 변경 내용을 신속하게 공유할 수 있도록 솔루션을 배포합니다.
• 통합 측정: 전체 팀의 명확한 분석을 위해 피드백 루프에 학습 메트릭을 추가합니다.

기술 급증을 최소화하려면 처음에는 이러한 원칙에 따라 성숙도가 낮다고 가정합니다. 가설이 점점 세분화됨에 따라 스케일링할 수 있는 도구 및 프로세스에 맞춰 미리 계획합니다. Azure에서 GitHub 및 Azure DevOps를 사용하면 소규모 팀이 거의 마찰 없이 시작할 수 있습니다. 이러한 팀은 스케일링 솔루션을 협업하고 수백 개의 고객 가설을 테스트하는 수천 명의 개발자를 포함하도록 확장될 수 있습니다. 이 문서의 나머지 부분에서는 이러한 원칙에 따라 채택 역량을 강화하는 "크게 계획, 작게 시작" 접근 방식을 보여줍니다.

공유 솔루션

고객 영향 측정값에 설명된 대로 가설에 대한 긍정적인 유효성 검사에는 반복 및 의사 결정이 필요합니다. 혁신 주기 동안 성공보다 실패가 훨씬 많이 발생할 것입니다. 예상된 동작입니다. 그러나 고객 요구 사항, 가설 및 솔루션이 대규모로 조정될 때 세계는 빠르게 변화합니다.

디지털 발명 및 혁신을 스케일링할 때 솔루션에 대한 공유 코드 베이스보다 유용한 도구는 없습니다. 아쉽게도 어떤 반복 또는 MVP가 승리하는 조합을 만들어 내는지 예측할 수 있는 믿을 만한 방법은 없습니다. 따라서 공유 코드 베이스 또는 리포지토리를 최대한 빨리 설정하는 것이 좋습니다. 이것은 지연되면 안 되는 하나의 기술 급증입니다. 팀이 다양한 MVP 솔루션을 반복함에 따라 공유 리포지토리를 사용하면 쉽게 협업하고 개발을 가속화할 수 있습니다. 솔루션을 변경한 후 학습 메트릭이 아래로 내려가면 버전 제어를 통해 보다 효과적인 이전 버전의 솔루션으로 롤백할 수 있습니다.

코드 리포지토리를 관리하는 용도로 가장 널리 채택된 CI/CD 도구는 불과 몇 단계만에 공유 코드 리포지토리를 만들 수 있는 GitHub입니다. 또한 Azure DevOps의 Azure Repos 기능을 사용하여 Git 또는 TFVC 리포지토리를 만들 수 있습니다.

피드백 루프

고객을 솔루션의 일부로 만드는 것은 혁신 주기 동안 고객 파트너십을 구축하는 열쇠입니다. 이 작업은 고객 영향을 측정하여 달성됩니다. 고객과 대화하고 직접 테스트해야 합니다. 둘 다 효과적으로 관리해야 하는 피드백을 생성합니다.

피드백의 모든 지점은 고객의 요구 사항에 대한 솔루션이 될 수 있습니다. 더 중요한 것은, 직접 고객 피드백의 모든 부분은 파트너십을 개선할 수 있는 기회를 나타냅니다. 피드백이 MVP 솔루션으로 만들어지면 고객과 함께 축하할 일입니다. 일부 피드백이 실행 가능하지 않더라도 피드백의 우선 순위를 낮추는 결정에 대한 투명성을 유지한다면 성장형 사고방식 및 지속적인 학습에 대한 초점을 보여줄 수 있습니다.

Azure DevOps에는 피드백을 요청, 제공 및 관리하는 방법이 포함되어 있습니다. 이러한 도구는 팀이 조치를 취하고 투명한 피드백 루프에 대한 후속 조치를 제공할 수 있도록 피드백을 중앙 집중화합니다.

연속 통합

연속 통합은 업데이트된 단일 프로젝트를 갖기 위해 하루에 여러 번 코드를 자동화하는 것입니다. 채택 규모가 커지고 가설이 대규모의 진정한 혁신에 가까워지면서 테스트할 작은 가설의 수가 빠르게 증가하는 경향이 있습니다. 정확한 피드백 루프와 원활한 채택 프로세스를 위해서는 이러한 가설을 통합하고 혁신의 기본 가설을 지원하는 것이 중요합니다. 이를 위해서는 빠르게 혁신하고 성장해야 하며, 그러려면 여러 개발자가 핵심 가설의 변형을 테스트해야 합니다. 이후 단계 개발 활동에서는 각각 공유 솔루션을 빌드하는 여러 개발자 팀이 필요할 수도 있습니다. 연속 통합은 모든 움직이는 부분을 관리하기 위한 첫 번째 단계입니다.

연속 통합에서는 코드 변경 내용이 기본 분기에 자주 병합됩니다. 자동화된 빌드 및 테스트 프로세스는 기본 분기의 코드가 항상 프로덕션 품질이 되도록 합니다. 이렇게 하면 개발자가 함께 협력하여 정확하고 신뢰할 수 있는 피드백 루프를 제공하는 공유 솔루션을 개발할 수 있습니다.

Azure DevOps 및 Azure Pipelines는 GitHub 또는 기타 리포지토리에서 불과 몇 단계만에 연속 통합 기능을 제공합니다. 자세한 내용은 연속 통합이란?을 참조하거나 연속 통합 실습 랩을 사용해 보세요. 솔루션 아키텍처를 사용하여 Azure DevOps를 통해 CI/CD 파이프라인 만들기를 가속화할 수 있습니다.

신뢰할 수 있는 테스트

모든 솔루션의 결함은 가양성 또는 가음성을 만들 수 있습니다. 예기치 않은 오류로 인해 사용자 채택 메트릭이 쉽게 잘못 해석될 수 있습니다. 또한 가설의 테스트를 정확하게 나타내지 않는 고객으로부터 부정적인 피드백을 생성할 수 있습니다.

MVP 솔루션을 초기 반복하는 동안 결함이 예상됩니다. 얼리어답터는 결함을 사랑스럽다고 생각할 수도 있습니다. 초기 릴리스에서는 일반적으로 수용 테스트가 없습니다. 그러나 공감을 가지고 빌드하는 한 가지 측면은 요구 사항 및 가설의 유효성 검사와 관련이 있습니다. 둘 다 배포 전에 코드 수준의 단위 테스트와 수동 수용 테스트를 통해 완료할 수 있습니다. 이러한 방법을 함께 사용하여 테스트 안정성을 높일 수 있습니다. 잘 정의된 일련의 빌드, 단위 및 수용 테스트를 자동화하려고 시도해야 합니다. 이렇게 하면 가설 및 최종 솔루션에 대한 미세 조정과 관련된 신뢰할 수 있는 메트릭이 보장됩니다.

Azure Test Plans 기능은 수동 또는 자동화된 테스트 실행 중에 테스트 계획을 개발하고 운영하는 도구를 제공합니다.

솔루션 배포

채택 역량을 강화하는 가장 의미 있는 측면은 고객에 대한 솔루션 릴리스를 제어하는 능력일 것입니다. 고객에게 솔루션을 릴리스하기 위한 셀프 서비스 또는 자동화된 파이프라인을 제공하면 피드백 루프를 가속화할 수 있습니다. 고객이 솔루션의 변경 내용과 빠르게 상호 작용할 수 있도록 하여 고객을 프로세스에 초대합니다. 이 방법은 가설을 더 빠르게 테스트하여 가정과 잠재적 재작업을 줄입니다.

솔루션을 배포하는 여러 가지 방법이 있습니다. 가장 일반적인 세 가지는 다음과 같습니다.

• 지속적인 배포는 코드 변경 내용을 프로덕션에 자동으로 배포하는 가장 발전된 방법입니다. 성숙한 가설을 테스트하는 성숙한 팀의 경우 지속적인 배포가 매우 유용할 수 있습니다.
• 개발 초기 단계에서는 지속적인 업데이트가 더 적합할 수 있습니다. 지속적인 업데이트에서 모든 코드 변경 내용은 프로덕션과 유사한 환경에 자동으로 배포됩니다. 개발자, 비즈니스 의사 결정권자 및 팀의 다른 팀원은 이 환경을 사용하여 자신의 작업이 프로덕션에 사용 가능한지 확인할 수 있습니다. 진행 중인 비즈니스 활동에 영향을 주지 않고 이 방법을 사용하여 고객과 가설을 테스트할 수도 있습니다.
• 수동 배포는 릴리스를 관리하는 방법 중 가장 덜 정교한 방법입니다. 그 이름처럼 팀의 누군가가 가장 최근의 코드 변경 내용을 수동으로 배포합니다. 이 접근 방식은 오류가 발생하기 쉽고 신뢰할 수 없으며, 대부분의 경험 많은 엔지니어들은 이 접근 방식을 안티패턴으로 간주합니다.

이러한 평가에도 불구하고 MVP 솔루션을 처음 반복할 때는 수동 배포가 일반적입니다. 솔루션이 매우 유동적이고 고객 피드백을 알 수 없는 경우 전체 솔루션(또는 핵심 가설)을 초기화하는 것은 상당한 위험이 따릅니다. 수동 배포의 일반적인 규칙은 고객 증명 없음, 배포 자동화 없음입니다.

일찍 투자하면 시간 손해를 볼 수 있습니다. 보다 중요한 것은, 초기 피벗에 대한 팀의 저항력을 높이는 릴리스 파이프라인에 대한 종속성이 생길 수 있다는 점입니다. 처음 몇 번의 반복 후 또는 고객 피드백이 잠재적인 성공을 제안하는 경우 보다 발전된 배포 모델을 신속하게 채택해야 합니다.

가설 유효성 검사의 모든 단계에서 Azure DevOps 및 Azure Pipelines는 지속적인 업데이트 및 지속적인 배포 기능을 제공합니다. 지속적인 업데이트에 대해 자세히 알아보거나 실습 랩을 확인하세요. 솔루션 아키텍처는 Azure DevOps 통해 CI/CD 파이프라인 만들기를 가속화할 수도 있습니다.

통합 측정

고객 영향을 측정할 때는 고객이 솔루션의 변화에 어떻게 반응하는지 이해하는 것이 중요합니다. 원격 분석 데이터라고 하는 이 데이터는 사용자(또는 사용자 코호트)가 솔루션을 만들 때 수행한 작업에 대한 인사이트를 제공합니다. 이 데이터에서 가설의 정량적 유효성 검사를 쉽게 얻을 수 있습니다. 그런 다음, 이러한 메트릭을 사용하여 솔루션을 조정하고 보다 세분화된 가설을 생성할 수 있습니다. 이러한 미묘한 변화는 이후 반복에서 초기 솔루션의 성숙도를 높이는 데 도움이 되며, 궁극적으로 대규모 채택을 반복하도록 유도합니다.

Azure에서 Azure Monitor는 고객 환경에서 데이터를 수집하고 검토할 수 있는 도구와 인터페이스를 제공합니다. Azure Boards를 사용하여 이러한 관찰 결과와 인사이트를 적용하면 백로그를 구체화할 수 있습니다.

다음 단계

채택 역량을 강화하는 데 필요한 CI/CD 파이프라인 도구 및 프로세스를 이해했으면 보다 발전된 혁신 분야인 디바이스와 상호 작용에 대해 알아볼 차례입니다. 이 분야는 물리적 환경과 디지털 환경 간의 장벽을 줄여 솔루션을 더 쉽게 채택하는 데 도움이 될 수 있습니다.