기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 개발 가치 스트림 맵 생성
다음은 개발 가치 스트림 맵(DVSM)을 생성하는 단계입니다.
+ [1단계: 가치 스트림 식별](#step-1)
+ [2단계: 시작점과 종료점 정의](#step-2)
+ [3단계: 관련된 팀 식별](#step-3)
+ [4단계: 참가자 교육](#step-4)
+ [5단계: 가치 스트림 단계 매핑](#step-5)
+ [6단계: 각 단계의 속도와 품질 평가](#step-6)
+ [7단계: 제약 조건 식별](#step-7)
+ [8단계: 지속적으로 개선](#step-8)
## 1단계: 가치 스트림 식별
가치 스트림 매핑은 고객에게 가치를 전달하는 데 중점을 둡니다. 이 가치 스트림은 최대한 좁은 범위로 정의해야 합니다. 이상적으로는 단일 [피자 2개 팀](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)이 개발 및 운영을 포함하여 비즈니스부터 IT에 이르기까지 모든 개인을 포함하는 경우 이 팀이 고객에게 전달할 수 있는 가치의 범위를 포괄합니다. 조직이 이미 가치 스트림 및 제품 팀으로 구성된 경우 개발 가치 스트림은 단일 가치 스트림 및 관련 제품 팀입니다. 그렇지 않은 경우 개발 가치 스트림이 수십 개의 팀과 수백 명의 사람을 통과할 수 있습니다. 그래도 괜찮습니다.
예를 들어 적절한 가치 스트림은 보험 조직의 고객 대면 클레임 입력 인터페이스일 수 있습니다. 이 인터페이스에서는 비즈니스부터 IT에 이르기까지 모든 부서의 팀에서 협업해야 합니다. 전체 클레임 부서를 평가하는 범위는 고객에게 전달하는 가치가 아니라 조직에 초점을 맞추기 때문에 너무 광범위합니다.
## 2단계: 시작점과 종료점 정의
비즈니스가 결과물을 정의하고 우선순위를 지정한 시점이 가치 스트림 맵의 시작점이 해당되며, 그러면 시작할 준비가 된 것입니다. 각 팀에는 *준비* 상태에 대한 자체 정의가 있습니다. 조직에서 이 용어를 정의하는 방법에 대한 자세한 내용은 [Walking Through a Definition of Ready](https://www.scrum.org/resources/blog/walking-through-definition-ready)(Scrum 블로그 게시물)를 참조하세요. 대부분의 경우 *준비* 상태는 결과물이 일반 백로그에서 벗어나 스프린트 백로그에서 사용 가능하거나 칸반 보드에 추가되었음을 의미합니다. DVSM에는 백로그, 개선, 우선순위 지정 또는 팀의 *준비* 상태 정의를 충족하는 데 필요한 기타 단계가 포함되어서는 안 됩니다.
**참고**
백로그에 소요된 시간과 우선순위 지정 및 개선 프로세스가 개발 가치 스트림 맵의 범위를 벗어나더라도 이러한 태스크로 인해 조직에서 상당한 지연이 발생할 수 있습니다. 동일한 린 프로세스를 사용하여 이러한 활동에 대해 별도의 가치 스트림 맵을 생성할 수 있습니다.
가치 스트림 맵의 종료점은 팀의 *완료* 정의입니다. 조직에서 이 용어를 정의하는 방법에 대한 자세한 내용은 [Definition of Done](https://www.leadingagile.com/definition-of-done/)(Leading Agile 블로그 게시물)을 참조하세요. *완료*는 성공적으로 결과물을 계측하고 검증했음을 의미합니다. 이상적으로는 프로덕션 및 모니터링에서 최종 고객에게 제품을 성공적으로 구현, 작동 및 채택했음을 보여주는 성과물을 포함합니다.
## 3단계: 관련된 팀 식별
DVSM은 고객에게 특정 가치를 제공하는 데 필요한 모든 사람, 프로세스 및 기술에 걸쳐 확장됩니다. 고객에게 가치를 전달하기 위해 이 팀에 종속성이 있는 경우 DVSM 프로세스에 팀을 포함시킵니다. 팀이 고객에게 결과물을 전달하는 과정에서 상호 작용하거나 프로세스 또는 결과물과 관련된 티켓을 받거나 결과물을 완료하는 능력에 영향을 미치는 경우 팀은 *종속*된 것으로 간주됩니다. 매핑 프로세스 중에는 새로운 종속성이 나타나는 경우가 많으므로 모든 팀을 미리 식별해야 한다는 부담을 갖지 마세요. 예상 팀의 상위 수준 목록부터 시작합니다.
개발 가치 스트림 맵을 생성할 때 일반적으로 포함되는 팀은 다음과 같습니다.
+ Product
+ 업무
+ 개발
+ 화질
+ 인프라
+ CI/CD 플랫폼
+ 작업
+ 아키텍처
+ 사이트 신뢰성 엔지니어링(SRE)
+ 변경 및 릴리스
+ 보안
이러한 팀을 대표할 수 있는 5\~8명 이하의 참가자로 구성된 그룹 크기를 목표로 합니다. 각 팀을 적절하게 대표하기 위해 8명이 넘는 참가자가 필요한 경우 별도의 매핑 연습에서 더 작은 그룹으로 완료할 수 있는 섹션으로 맵을 구분합니다. 그런 다음 섹션을 어셈블하여 처음부터 끝까지 개발 가치 스트림의 전체 맵을 빌드할 수 있습니다.
## 4단계: 참가자 교육
팀이 DVSM을 생성하는 데 사용할 도구를 선택합니다. 스티키 메모가 있는 화이트보드, 온라인 화이트보드 애플리케이션, Microsoft Visio 또는 Microsoft Excel을 사용할 수 있습니다. 협업 단계에 대해 하나의 도구를 선택한 다음 공식 프레젠테이션을 위해 맵을 다른 도구로 이동할 수 있습니다. 협업 단계의 도구를 선택할 경우 모든 참가자가 직접 참석할지 아니면 세션에 원격 참석자를 포함할지 고려합니다. 일부 참석자가 원격으로 참가한 경우 모든 참가자에게 동등한 기여 기회를 부여하는 애플리케이션을 선택할 수 있습니다.
참가자에게 도구와 프로세스를 안내합니다. 참가자를 준비하고, 모든 참가자가 참여하며 가치 스트림 맵에 단계와 데이터를 독립적으로 추가할 것이라는 기대치를 설정합니다. 책임은 개발 가치 스트림 매핑 프로세스의 성공과 속도에 매우 중요하며, 협업은 DVSM이 단일 스레드가 되지 않도록 하는 데 도움이 됩니다. 필요한 경우 선택한 도구에 대한 교육을 제공합니다.
참가자에게 기본 프로세스에 대해 교육하고 예약된 매핑 세션 전에 선택한 도구에 액세스할 수 있는지 확인합니다. 이렇게 하면 매핑 세션 중에 지연을 방지하고 팀 담당자가 최대한 빨리 기여와 참여를 시작할 수 있습니다.
## 5단계: 가치 스트림 단계 매핑
참가자와 함께 가치 스트림의 시작점과 종료점 사이에 발생하는 모든 단계를 식별합니다. 시작점과 종료점을 식별하여 프로세스를 시작하고 처음 몇 개 단계를 정의하는 작업을 함께 수행할 수 있습니다. DVSM이 커지기 시작하고 참가자가 더 편안해지면 참가자에게 보드에 상자와 데이터를 독립적으로 추가하도록 요청합니다. 모든 단계를 고려하기 위해 SDLC에 대한 지식을 사용하여 '그렇다면 다음 단계는 무엇인지' 질문합니다.
특히 이러한 태스크에 여러 소유자가 포함된 경우 참가자에게 더 큰 태스크를 관리 가능한 단계로 나누도록 요청합니다. 그러나 단계 단위가 너무 작아지지 않도록 해야 합니다. 단계가 너무 많으면 맵을 완료하고 가치 스트림에서 가장 중요한 제약 조건을 식별하기 어려울 수 있습니다.
개발 가치 스트림 맵을 생성할 때 일반적으로 포함되는 단계는 다음과 같습니다.
+ 개발
+ 유닛 테스트
+ 통합 테스트하기
+ 기능 테스트
+ 회귀 테스트
+ 보안 검증
+ 성능 테스트
+ 사용자 승인 테스트
+ 결함 워크플로
+ 변경 자문 위원회(CAB) 승인
+ 변경 티켓
+ 요청 티켓 및 SLA
+ 설명서
+ 아키텍처 검토
+ 데이터 검토 및 승인
+ 인프라 프로비저닝
+ 네트워크 및 방화벽 변경 사항
+ 프로덕션 배포
+ 로깅 및 관찰성 오케스트레이션
+ 스모크 테스트
+ 프로덕션 인시던트 워크플로
단계를 순차적으로 배치하고 프로세스 흐름 화살표로 연결합니다. 개발 중에 예외나 오류가 발생하지 않는 경우 프로세스 흐름인 *성공 경로*를 식별합니다. 또한 제품이 개발 프로세스의 단계에서 실패한 경우 발생하는 흐름인 *실패 경로*도 식별합니다.
## 6단계: 각 단계의 속도와 품질 평가
이 단계에서는 각 단계를 소유한 사람을 결정하고 해당 단계의 속도와 고품질 결과를 생성하는 빈도를 평가합니다. 누가 해당 작업을 수행하는지, 누구에게 전달되는지, 문제 때문에 얼마나 자주 다시 전송되는지 질문합니다.
먼저 각 단계의 소유자를 식별합니다. *소유자*는 단계에서 작업을 수행할 책임이 있는 팀입니다. 맵에서 소유권을 더 쉽게 식별할 수 있도록 각 팀에 다른 색상을 할당할 수 있습니다. 단계에 소유자가 여러 명 있는 경우 각 팀이 자율 데이터를 제공하고 핸드오프를 적절하게 고려할 수 있도록 해당 단계를 여러 개의 작은 단계로 나눕니다.
가치 스트림 맵의 모든 단계에서 단계 소유자에게 다음 정보를 제공하도록 요청합니다. 데이터는 시스템이나 데이터 소스에서 가져오는 것이 아니라 입증되지 않은 평균 시나리오에서 가져와야 합니다. 종종 DVSM 범위에서 이 데이터를 가져와 정규화하는 데 많은 노력이 필요합니다. 또한 데이터는 종종 부정확하거나 추적하거나 측정하기 어려운 요소를 포함하지 않습니다. 사용하는 시스템을 개선하는 것이 목표이므로 작업을 소유한 사람을 신뢰하여 다음 지표를 자신 있게 파악합니다.
+ **리드 타임(LT)** - 소유자가 작업을 수락하는 시점부터 인계하는 시점까지, 시작부터 종료까지의 단계 지속 시간입니다. 여기에는 결과물 작업에 소요된 모든 시간 및 대기 시간과 같은 모든 가동 중지 시간이 포함됩니다. 리드 타임의 일환으로 팀 간의 SLA 및 핸드오프 프로세스를 추적해야 합니다.
+ **프로세스 시간(PT)** - 중단이나 가동 중지 시간이 없다고 가정할 때 한 사람이 작업을 수행하는 데 걸리는 시간입니다. 이를 *가치 추가* 시간이라고도 하며, 이는 결과물에 가치를 추가하는 데 소요된 시간을 측정한 값입니다.
+ **완전하고 정확한 백분율(%CA)** - 단계가 정확한 작업 또는 데이터를 전달하고 재작업이 필요하지 않으며 다시 보낼 필요가 없는 시간의 백분율입니다. 부정확한 결과물의 예로, 다운스트림 단계에서 보고한 대로, 잘못된 데이터, 잘못된 양식, 버그, 문제, 결함 또는 인시던트가 있습니다.
모든 팀이 참여하고 한 팀이 다른 팀을 대신하여 발언하지 않는 것이 중요합니다. 각 팀은 팀이 소유한 단계에 대한 데이터를 제공하고 속도와 품질 모두에 상당한 영향을 미칠 수 있는 핸드오프를 논의할 수 있는 자율성을 보유해야 합니다. 이로 인해 매우 많은 사람과 대화하여 데이터를 수집할 수 있습니다.
## 7단계: 제약 조건 식별
속도와 품질에 상당한 영향을 미치는 제약 조건을 식별합니다.
+ 속도 관련 제약 조건은 리드 타임과 프로세스 시간 사이에 격차가 가장 큰 단계에서 발생합니다. 이는 대기 시간 손실과 같이 단계에서 상당한 시간 낭비가 있음을 나타냅니다.
+ 품질 관련 제약 조건은 완전하고 정확한 점수 비율이 낮은 단계에서 발생합니다. 이는 결함을 해결하기 위해 반복 작업에서 상당한 노력과 시간이 손실됨을 나타냅니다.
이러한 단계는 소프트웨어 개발 프로세스의 속도와 품질을 개선할 수 있는 가장 큰 기회를 제공합니다.
가치 스트림에서 모든 단계에 대한 리드 타임 또는 프로세스 시간을 추가하여 전체 가치 스트림에 대한 누적 리드 타임 또는 프로세스 시간을 얻을 수 있습니다. 또한 모든 단계의 완전하고 정확한 점수 백분율을 곱하여 평균을 결정할 수 있습니다. 그러면 시스템에서 작업하는 데 걸리는 시간과 지정된 단계에서 수정할 가능성을 이해하는 데 도움이 될 수 있습니다.
## 8단계: 지속적으로 개선
개발 가치 스트림 맵에서 제약 조건을 식별하고 우선순위를 지정한 후 이를 사용하여 소프트웨어 개발 프로세스를 개선할 수 있습니다. 이해관계자 및 단계 소유자와 협력하여 핸드오프, 시간 낭비 및 과도한 처리를 제거하여 속도와 품질을 개선합니다.
변경 사항을 구현한 후 단계 소유자와 함께 DVSM을 다시 검토하고 변경 사항이 성공했는지 평가합니다. 변경 사항에 따라 DVSM을 업데이트한 다음 새로운 제약 조건을 식별하고 우선순위를 지정하여 지속적인 개선을 촉진합니다. 맵의 다른 부분에 새 제약 조건이 나타나거나 제약 조건이 낮은 우선순위에서 높은 우선순위로 에스컬레이션되는 것이 일반적입니다.