지속적인 개선 살펴보기
지속적인 개선은 DevOps 분류의 8가지 기능 중 하나입니다.
지속적인 개선이 필요한 이유 살펴보기
지속적인 개선에는 측정이 빠질 수 없습니다. 측정할 수 없다면 개선되었는지 여부를 알 수 없으니까요.
2017년에 발표된 Forrester 보고서 Faster Software Delivery Will Accelerate Digital Transformation(빠른 소프트웨어 제공은 디지털 트렌스포메이션을 가속화)은 리드 타임과 프로세스 타임 사이에 상당한 낭비가 발생하고 있음을 보여줍니다. 이는 우리에게 측정이 없이는 차이를 파악할 수 없고 조직이 시간을 얼마나 낭비하고 있는지 알 수 없음을 다시금 상기시켜 줍니다.
특정 낭비가 프로세스에 미치는 영향을 측정하고 나면 개선을 위한 업무의 우선 순위를 손쉽게 정할 수 있습니다.
출처: Forrester, Faster Software Delivery Will Accelerate Digital Transformation, March 9, 2017 by Diego Lo Giudice, Christopher Condo with Christopher Mines, Luis Deya
그러나 측정할 수 없는 경우에 고객 경험을 어떻게 개선할 수 있을까요? Forrester 연구는 “테스트한 기능과 사용한 기능 간에 약간이 중첩이 있다는 것은 개발자가 고객을 더 정확하게 파악할 필요가 있다”는 것을 보여줍니다. 테스트된 애플리케이션 기능과 사용된 애플리케이션 기능 간의 중첩은 약 35%입니다.
새로운 기능의 사용 현황과 효과를 측정하지 않고서 어떻게 좋은 소프트웨어를 만들 수 있을까요? 잘못 파악할 확률이 65%이므로 차이를 아는 것은 아주 중요합니다.
지속적인 개선이란?
DevOps 프로세스를 지속적이고 솔직하게 관찰하면 팀은 가능한 개선 사항을 파악할 수 있습니다.
모든 개선은 변화를 요구하지만 모든 변화가 개선으로 이어지는 것은 아닙니다. 이것이 측정이 DevOps를 사용하는 조직에 중요한 성공 요인인 이유입니다. Peter Drucker의 말대로 “측정할 수 없다면 개선할 수 없습니다.”
효과적인 피드백 메커니즘이 없으면 앱이 비즈니스에 미치는 효과를 개선하기 어렵습니다. 따라서 데이터 기반 조정 수행에 중점을 두고 DevOps 개선을 위한 학습 중심 접근 방식의 환경을 만드는 것이 중요합니다.
측정 및 메트릭
먼저 측정을 살펴보겠습니다. Nicole Forsgren, Jez humble 및 Gene Kim의 저서 Accelerate에 따르면 소프트웨어 제공 성과에 가장 중요한 4가지 측정값은 다음과 같습니다.
- 변화에 소요되는 리드 타임: 소프트웨어 제공 속도에 대한 척도입니다. 커밋된 코드에서 프로덕션에서 성공적으로 실행되는 코드까지 가는 데 걸리는 시간
- 배포 빈도: 응답 시간, 팀 화합력, 개발자 역량, 개발 도구 효과 및 전체 DevOps 팀 효율성에 대한 직접 또는 간접적 측정값입니다.
- 평균 복원 시간: 서비스 인시던트 발생 시 기본 앱 또는 서비스를 복원하는 데 일반적으로 걸리는 시간입니다.
- 변경 내용 실패 비율: 소프트웨어 릴리스 및 인프라 구성 변화를 포함하여 프로덕션에 시도한 변경 내용의 실패 비율입니다.
운영 상태 메트릭, 사용 현황, 개발속도 및 라이브 사이트 상태 등을 측정하는 것이 DevOps 리더십의 역할입니다. 즉, 작업이 아닌 영향을 측정합니다. 메트릭은 실행 가능한 경우에만 유용합니다.
스크럼 팀은 팀 수용작업량, 팀 개발속도, 번다운(burndown) 및 버그 수를 측정하지만 이러한 메트릭은 팀의 컨텍스트 내에서만 관련이 있습니다. 그러나 DevOps 리더십이 영향에 집중하는 것이 중요합니다.
중요
작업이 아닌 영향을 측정하세요.
측정하는 것은 다음과 같습니다.
사용 현황
개발속도
라이브 사이트 상태
- 취득
- 참여
- 만족도
- 변동
- 기능 사용 현황
- 빌드 시간
- 자체 테스트 시간
- 배포 시간
- 학습 시간
- 검색 시간
- 통신 시간
- 완화 시간
- 고객 영향
- 인시던트 방지 항목
- 라이브 사이트 문제 에이징
- 고객당 SLA
- 고객 지원 메트릭
관찰하지 않는 항목은 다음과 같습니다.
- 원래 예상 값
- 완료된 시간
- 코드 줄
- 팀 수용작업량
- 팀 번다운(burndown)
- 팀 개발속도
- 발견된 버그 수
중요
메트릭은 비즈니스 결과에 영향을 줍니다.
KPI를 습관과 일치시키는 것이 중요합니다. 이는 긍정적인 비즈니스 결과를 얻는 데 도움이 됩니다.
KPI를 보강하고 성공을 위한 팀 구성에 필요한 중요한 습관은 다음과 같습니다.
- 팀 자율성 및 조직 연계: 빌드의 대상, 방식, 이유와 관련이 있습니다. 모든 리더십과 기능 팀이 투명하고 효과적으로 협업을 수행하려면 조직 전체를 관통하는 공통된 보조 또는 속도가 필요합니다.
- 고객 중심: 모든 노력은 고객 가치에 직접 또는 간접적인 영향을 주어야 합니다.
- 프로덕션 중심 사고: 개발, 테스트 및 운영 지원 중에 기능 및 버그 처리 방법을 구분짓지 않는 사고방식입니다. 모든 항목은 프로덕션 중에 자동화, 버전 관리 및 미세 조정되어야 합니다.
- 품질은 왼쪽에, 실패는 빠르게: 품질 향상을 위해 기능 제공 주기에서 테스트와 보안에 대한 검토, 유효성 검사 및 승인은 가능한 한 빠르게 실시하고 실패를 빠르게 경험하는 사고방식입니다.
지속적인 피드백
다음으로 협업을 위해 지속적인 피드백을 사용하는 방법을 살펴보겠습니다.
가장 많이 회자되는 최신 앱 개발자들은 스타트업 출신입니다. 그들의 성공 비결은 무엇일까요? 몇 년간의 정교한 프로세스에 구애받지 않는 린(lean) 관행을 구축했기 때문입니다.
린 스타트업은 놀랍도록 긍정적이고 지속적인 피드백 문화를 통해 아이디어를 발전시키고 실현하며 다듬는 최적 경로를 구축했습니다.
- 조기에, 자주 릴리스
- 최소한의 실효성 있는 제품으로 시작
- 가설 기반 개발 사용
- 고객 피드백을 통한 지속적인 개선
가치 스트림 매핑을 통한 지속적인 개선
측정 및 피드백이 있는 경우 데이터 기반의 개선이 가능해집니다.
지속적인 개선을 지원하는 한 가지 효과적인 방법은 가치 스트림 매핑입니다. 가치 스트림은 고객의 요청에 부응하고자 조직이 수행하는 작업의 시퀀스입니다.
가치 스트림 매핑은 작업 수행 방식의 단절, 중복성 및 격차를 발견하고 해결하는 데 매우 효과적인 방법입니다. 이는 단순한 도구가 아니라 검증된 관리 활동의 토대가 되는 팀 기반 방법론입니다.
가치 스트림 분석은 제공 프로세스를 세분화하고 리드 타임, 주기 시간 및 유휴 시간을 측정하여 팀이 데이터 기반의 워크플로우를 조정할 수 있도록 합니다.
측정값은 팀이 계획하고 효율성 변화를 파악하여 잠재적 프로세스 문제를 확인하는 데 도움이 됩니다.
팁
리드 타임과 주기 시간이 낮을수록 팀의 처리량은 더 빨라집니다.
프로세스 개선을 위한 향후 변경 사항을 확인할 수 있도록 불필요한 비부가가치 작업 및 필요한 비부가가치 작업 간의 차이점을 파악할 수 있어야 합니다.
불필요한 비부가가치 작업은 낭비에 불과합니다. 이는 고객에게 가치 있게 여겨지지 않으며 조직의 발전을 위해서도 필요하지 않습니다. 제품에 어떠한 가치도 더하지 않고 리소스만 소비합니다.
데이터 기반 DevOps: 메트릭을 이용한 여정 설정
DevOps 혁신은 하나의 여정이며, 이를 경험하는 가장 효과적인 방법은 데이터 기반 DevOps입니다.
DevOps의 효과를 측정하고 DevOps 혁신 이니셔티브에 투명성을 부여하려면 전체적인 접근 방법을 설정하는 것이 좋습니다. 성공을 나타내는 메트릭에 초점을 맞추어 DevOps에 필요한 학습과 실험을 촉진하는 문화를 만듭니다. 잘못을 처벌하기 보다는 올바른 습관을 북돋으며 성공을 인정합니다.