가치 흐름도로 프로세스 효율 평가
가치 흐름도, 즉 VSM을 만들면 현재 릴리스 주기 프로세스를 분석하는 데 도움이 됩니다. VSM의 목적은 프로세스에서 팀이 가치를 창출하는 부분과 낭비가 일어나는 부분을 시각적으로 보여주는 것입니다. 목표는 최소한의 낭비로 최대의 가치를 고객에게 제공하는 프로세스를 보유하는 것입니다. VSM은 가치에 기여하지 않거나, 제품의 가치를 실질적으로 축소하는 영역을 정확히 가려내는 데 도움이 될 수 있습니다.
Tailspin은 어떻게 평가하는지 알아보도록 하겠습니다.
팀에 갓 합류한 Mara는 기존 프로세스를 이해하는 데 도움이 될 VSM을 만들려고 합니다. 그녀는 VSM을 통해 팀이 DevOps 완성도 모델의 어느 단계에 있는지 파악하게 될 것입니다. 결과적으로, 완성도가 높은 팀일수록 일반적으로 완성도가 낮은 팀보다 더 높은 신뢰도와 더 적은 버그로 더 빠르게 출시합니다.
Mara는 자신이 아직 모든 것을 이해하지 못한다는 것을 알고 있으므로 회의실 화이트보드에 간단한 VSM을 만들 예정입니다. 어느 정도 격차가 있고 답할 수 없는 질문이 있겠지만 그래도 괜찮습니다. 시작이니까요. 그녀는 할 수 있는 만큼만 완성한 후에 팀과 공유할 것입니다. VSM은 Tailspin의 웹 사이트 개발 및 릴리스 방법을 개선하기 위한 첫걸음을 파악할 수 있는 공통의 출발점을 모두에게 제공합니다.
그녀의 지도를 살펴보겠습니다.
현재 프로세스 이해
Mara는 자신의 VSM을 발표하기 위해 회의실에 팀을 소집합니다.
Mara: VSM은 프로세스에서 고객에게 가치가 있는 부분과 가치 창출 없이 시간만 잡아먹는 부분을 평가하는 데 도움이 됩니다. 이 맵은 소프트웨어 기능 사양이 있는 왼쪽 상단에서 시작됩니다. 한 기능이 현재 릴리스 주기 프로세스를 거치는 방법을 알아보도록 하겠습니다.
몇몇 사람들이 눈을 희번덕거리지만 Mara는 밀고 나갑니다.
개발 프로세스
새 기능을 만드는 과정은 현재 소스 제어에서 레이블을 만드는 것으로 시작됩니다. 
레이블을 만들 수 있는 사람은 Andy 한 명 뿐입니다. 레이블은 메일로 요청합니다. 중앙 집중식 버전 제어 시스템을 사용하므로 Andy는 모든 기존 코드가 체크 인되고 안정될 때까지 기다렸다가 레이블을 만듭니다. 레이블이 생성되면 작업을 시작할 수 있다는 이메일이 수신됩니다. 이 프로세스는 최대 3일이 소요되고, 고객에게 아무런 가치가 없습니다. 고객에게 아무런 가치가 없는 작업에 소요되는 시간은 최대한 줄여야 합니다.
필요한 모든 파일에 대한 액세스 권한을 확보한 후 한 사람이 기능 코딩을 완료하려면 약 4일이 소요됩니다. 
소스 제어에 액세스하려면 회사 네트워크에 연결되어 있어야 합니다. 이 시간은 고객에게 가치가 있습니다. 고객은 이 기능을 원합니다.
테스트 프로세스
안정적인 빌드가 있다고 판단한 후에는 스프레드시트를 업데이트하여 Amita에게 테스트할 준비가 된 빌드가 있다는 사실과 그 위치를 알려주어야 합니다. 
그녀가 통보를 받으려면 2일이 걸립니다.
Amita는 빌드를 수동으로 테스트합니다. 
이 프로세스는 코드베이스가 커질수록 길어집니다. 현재는 3일이 걸린다고 가정해 보겠습니다. 그녀는 이메일로 Andy에게 버그 보고서를 보냅니다. 테스트는 가치를 부가하지 않지만 필요합니다.
그리고 Andy는 버그를 심사하고 업무를 할당할 시간이 필요합니다. Andy가 문제를 이해하고 적절한 개발자에게 배정하는 데 3일이 추가로 걸릴 수 있습니다.
운영 프로세스
Amita는 빌드를 승인할 경우 Tim에게 전달합니다. Tim은 추가적인 테스트를 위해 이러한 빌드를 사전 프로덕션 서버에 배포해야 합니다. 사전 프로덕션 서버는 웹 사이트를 실행하는 데 필요한 최신 패치 및 업데이트와 동기화되지 않는 경우가 종종 있습니다. Tim이 사전 프로덕션 서버를 배포하고 몇 가지 테스트를 실행하려면 약 2일이 소요됩니다. 다시 말하지만, 사전 프로덕션에 배포하는 동안에는 가치가 부가되지 않지만 필요한 작업입니다. 
빌드 프로덕션이 준비되면 경영진이 릴리스를 승인해야 배포할 수 있습니다. 승인은 모임에서 수행됩니다. 경영진이 만나서 릴리스를 검토하려면 4일이 소요됩니다.
결국 Tim은 기능을 배포하고, VSM의 오른쪽 상단 모서리에 있는 고객에게 기능이 제공됩니다. 프로덕션 서버 구성이 이동하여 사전 프로덕션 서버와 동기화 상태가 아닐 경우 Tim은 먼저 이를 업데이트해야 합니다. 이 과정에는 1일이 소요됩니다 
.
고객 가치 메트릭 계산
이제 주요 성능 메트릭을 살펴보고 평가할 수 있습니다.
총 리드 타임은 기능을 고객에게 제공하는 데 걸린 시간입니다. 여기에서 총 시간은 22일입니다. ‘프로세스 시간’은 고객에게 가치를 제공하는 기능에 소요된 시간입니다. 프로세스 시간은 코딩에 소요된 4일과 해당 기능을 배포하는 데 소요된 1일을 더한 총 5일입니다.
‘작업 비율’은 프로세스 시간을 총 리드 타임으로 나눈 값입니다.
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
이것이 효율성입니다. 효율성에 100을 곱하면 비율을 알 수 있습니다. 결과는 0%보다 크며, 일반적으로 100%보다 작습니다. 비율이 클수록 효율이 높은 것입니다.
숫자로 대체하면 다음과 같습니다.
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{ = .23}$$
결과에 100%를 곱하면 23%가 됩니다.
보시다시피 개선의 여지가 많습니다. 그리고 기능 개발에 22일이 걸린다면 너무 긴 시간입니다.
Tim: 이것이 우리 팀에 어떤 도움이 되나요?
여기서 어떤 식으로 진행해야 하나요?
Mara: 폐기물이 있는 지역을 정확히 파악할 수 있도록 현재 우리가 어디에 있는지 확인하는 데 도움이 됩니다. 고객에게 아무런 가치가 없는 일에 낭비하는 시간을 최소화하고자 합니다. DevOps 접근법을 채택하면 정말로 효율이 개선될 거라고 생각합니다. 우선, 이러한 단계 중 많은 부분을 자동화할 수 있어 시간을 확실히 단축할 수 있습니다.
현재 프로세스를 중단하자는 것이 아니라, 현재 우리가 진행하고 있는 프로세스를 방해하지 않으면서 약간의 변화로 더 효율적인 프로세스를 만들 수 있다고 생각해요.
개선의 여지가 있는 몇 가지 영역을 살펴보도록 하겠습니다.
Andy: 처음부터 시작할 수도 있겠네요. 새 기능을 시작할 수 있게 코드에 레이블을 달려면 시간이 오래 걸립니다. 개발자에게 가서 빌드와 테스트를 어디까지 진행할 수 있는지 물어보아야 합니다. 이러한 작업 속도를 높이는 방법을 아신다면 귀 기울여 듣겠습니다.
또한 빌드 자체에 배정된 시간이 없네요. 현재는 한나절이 걸리는 작업인데요. 시간을 늘려주시면 좋겠습니다.
Amita: 개발 팀은 제가 테스트해야 하는 새 빌드가 있는지 알 수 있는 스프레드시트를 항상 업데이트해 주지는 않습니다. 이 부분을 해결할 방법만 있다면 시간이 절약될 것입니다.
Mara: 좋아요! DevOps가 이러한 모든 문제를 해결해줄 거라 생각해요.
Andy: 지금은 프로세스를 변경할 시간이 없습니다. Irwin이 하는 말 들으셨잖아요. 지금 비상 사태라고요!
Mara: 이해합니다. 일단은 하던 대로 하죠. 단, 모두들 프로세스에서 맡은 역할과 개선 방안을 생각해 보세요. 현재 프로세스를 진행하면서 사소한 변경 사항을 적용해 보도록 하겠습니다. 그러면 기존의 프로세스를 방해하지 않으면서 DevOps가 도움이 될지 확인할 수 있을 거예요. 저는 이 맵과 성능 메트릭을 계속 사용할 거예요. 우리가 Azure DevOps 방식을 채택한다면 수치를 다시 논의해 보죠. 나중에 VSM을 업데이트할 수도 있을 겁니다.