Value Stream Maps



팀원대화 내용비고

VSM은 프로세스가 고객에게 가치가있는 위치와 가치를 창출하지 않고 시간을 소비하는 위치를 측정하는 데 도움이됩니다.
우리의 Map은 소프트웨어의 기능 사양으로 왼쪽 위에서 시작합니다.
하나의 기능 만 따라 현재 릴리스주기에서 어떻게 이동하는지 확인합니다.

개발프로세스

 라벨을 만들 수있는 사람이 한 명 있는데 앤디입니다.이메일로 라벨을 요청합니다.
우리는 중앙 집중식 버전 제어 시스템을 사용하므로 Andy는 기존의 모든 코드가 체크인되어 안정 될 때까지 기다렸다가 레이블을 만듭니다.
라벨이 생성되면 작업을 시작할 수 있다는 이메일이 발송됩니다. 이 프로세스는 최대 3일이 걸리며 고객에게는 가치가 없습니다.고객에게 가치가없는 것은 가능한 한 적은 시간이 걸립니다.

필요한 모든 파일에 액세스하면 한 사람이 기능을 코딩하는 데 약 4일이 걸립니다.
소스 제어에 액세스하려면 회사 네트워크에 있어야합니다.이번에는 고객에게 가치가 있습니다.그들은이 기능을 원합니다.

테스트 프로세스

안정적인 빌드가 결정되면 스프레드 시트를 업데이트하여 테스트 할 준비가 된 빌드와 위치를 Amita에 알립니다.
알림을 받으려면 2일이 걸립니다.

Amita는 수동으로 빌드를 테스트합니다.
이 프로세스는 코드베이스가 커질수록 길어집니다.지금은 3일이라고합시다.그런 다음 버그 보고서와 함께 Andy에게 이메일을 보냅니다.테스트는 가치를 추가하므로 필요합니다.
앤디는 버그를 분류하고 작업을 할당하는 데 시간이 걸렸다. Andy가 문제를 이해하고 올바른 개발자에게 전달하는 데 3일이 더 걸릴 수 있습니다.

운영 프로세스

 Amita가 빌드를 승인하면 Tim에게 전달합니다. Tim은 더 많은 테스트를 위해이 빌드를 사전 프로덕션 서버에 배포해야합니다. 종종 사전 프로덕션 서버는 웹 사이트를 실행하는 데 필요한 최신 패치 및 업데이트와 동기화되지 않습니다. Tim이 사전 프로덕션에 배포하고 일부 테스트를 실행하는 데 약 2 일이 걸립니다. 다시 말하지만, 사전 프로덕션에 배포하는 것이 가치를 추가하는 것은 아닙니다.

 빌드가 프로덕션 준비가 된 후 경영진은 배포하기 전에 릴리스를 승인해야합니다. 이것은 회의에서 발생합니다. 릴리스를 만나고 검토하기 위해 리더십을 확보하는 데 4 일이 걸립니다. 

결국 Tim은이 기능을 배포하고이 기능은 VSM의 오른쪽 상단에있는 고객에게 제공합니다. 프로덕션 서버 구성이 드리프트되어 사전 프로덕션과 동기화되지 않은 경우 Tim은 먼저 업데이트해야하며이 작업에는 하루가 걸립니다.

고객 가치 메트릭 계산

 

우리의 효율성은 23% 입니다. (백분율이 높을수록 효율성이 높습니다.)


Where do we go from here?

쓰레기가있는 곳을 정확히 찾아 낼 수 있도록 우리가 지금 어디에 있는지 확인하는 것이 도움이됩니다. 우리는 고객에게 가치가없는 시간을 최소화하고자합니다. DevOps 접근 방식을 채택하여 효율성을 실제로 향상시킬 수 있다고 믿습니다. 우선, 우리는 이러한 많은 단계를 자동화 할 수 있으며, 이는 확실히 시간을 단축 할 것입니다.

저는 현재 프로세스를 중단하라고 제안하는 것이 아니라 현재 진행중인 프로세스를 중단하지 않고 조금씩 더 효율적인 프로세스를 진행할 수 있다고 생각합니다.

개선 할 수있는 몇 가지 영역 만 살펴 보겠습니다.


처음부터 시작하는 것이 좋습니다. 새 기능을 시작할 수 있도록 코드에 레이블을 지정하는 데 오랜 시간이 걸립니다. 나는 개발자들에게 걸어 가서 우리가 빌드하고 테스트 할 수 있도록 그들이 가지고있는 것을 확인하도록 요청해야합니다. 속도를 높이는 방법을 알아낼 수 있다면 내 관심을 끌 것입니다.

또한 빌드 자체에 대한 시간이 없다는 것을 알았습니다. 지금은 반나절이 걸립니다. 시간이 좋아지는 것을 보면 좋을 것입니다.


그리고 dev는 테스트가 필요한 새 빌드가 있음을 알려주기 위해 스프레드 시트를 항상 업데이트하지는 않습니다. 그 부분이 완료되었는지 확인하는 방법이 있다면 시간을 절약 할 수 있습니다.

좋아요! DevOps가 이러한 모든 문제를 해결하는 데 도움이 될 수 있다고 생각합니다.

지금은 프로세스를 변경할 시간이 없습니다. 어윈 들었어요. 우리는 여기서 위기 모드에 있습니다!

이해합니다. 지금은 우리가 항상하는 일을합시다. 그러나 우리 모두는 프로세스에서 우리의 역할과 개선 방법에 대해 생각할 수 있습니다. 현재 프로세스와 병행하여 작은 변경을 시작할 수 있습니다. 이를 통해 DevOps가 우리가 가진 것을 방해하지 않고 우리를 도울 수 있는지 확인할 수 있습니다. 이 맵과 성능 메트릭을 유지하겠습니다. Azure DevOps 방식을 채택하게되면 수치를 다시 살펴볼 수 있습니다. 언젠가는 VSM을 업데이트 할 수 있습니다.
  • No labels
Write a comment…