개발 가치 흐름 맵 생성

다음은 개발 가치 흐름 맵 (DVSM) 을 만드는 단계입니다.

• 1단계: 가치 흐름 식별

• 2단계: 시작점과 끝점 정의

• 3단계: 관련 팀 식별

• 4단계: 참가자 교육

• 5단계: 가치 흐름 단계 매핑

• 6단계: 각 단계의 속도 및 품질 평가

• 7단계: 제약 조건 파악

• 8단계: 지속적인 개선

1단계: 가치 흐름 식별

가치 흐름 매핑은 고객에게 가치를 전달하는 데 중점을 둡니다. 이 가치 흐름은 가능한 한 좁게 정의해야 합니다. 이상적으로는 개발 및 운영을 포함하여 현업 부서에서 IT에 이르는 모든 개인을 포함한다면 두 판씩 한 팀이 고객에게 제공할 수 있는 서비스 범위를 포괄하는 것이 좋습니다. 조직이 이미 가치 흐름과 제품 팀으로 구성되어 있는 경우 개발 가치 흐름은 단일 가치 흐름과 관련 제품 팀입니다. 그렇지 않다면 개발 가치 흐름은 수십 개의 팀과 수백 명의 인력을 거치게 될 것입니다. 괜찮습니다.

예를 들어 보험 회사의 고객 대면 청구 입력 인터페이스가 적절한 가치 흐름일 수 있습니다. 이 인터페이스에는 비즈니스에서 IT에 이르기까지 모든 부서의 팀이 협업해야 합니다. 전체 청구 부서를 평가하는 범위는 고객에게 제공되는 가치가 아니라 조직에 초점을 맞추기 때문에 너무 광범위할 수 있습니다.

2단계: 시작점과 끝점 정의

가치 흐름 맵의 시작점은 비즈니스가 결과물을 정의하고 우선 순위를 정하고 결과물을 시작할 준비가 된 시점입니다. 각 팀은 준비에 대한 고유한 정의를 가지고 있습니다. 조직에서 이 용어를 정의하는 방법에 대한 자세한 내용은 Ready의 정의 살펴보기 (스크럼 블로그 게시물) 를 참조하십시오. 대부분의 경우 준비란 결과물이 일반적인 백로그에서 벗어나 스프린트 백로그에서 사용할 수 있거나 칸반 보드에 추가되었음을 의미합니다. DVSM에는 준비 완료라는 팀의 정의를 충족하는 데 필요한 백로그, 개선, 우선 순위 지정 또는 기타 단계가 포함되어서는 안 됩니다.

참고

백로그에 소요되는 시간과 우선 순위 지정 및 개선 프로세스는 개발 가치 흐름 맵의 범위를 벗어나지만 이러한 작업으로 인해 조직에 상당한 지연이 발생할 수 있습니다. 동일한 린 프로세스를 사용하여 이러한 활동에 대해 별도의 가치 흐름 맵을 생성할 수 있습니다.

가치 흐름 맵의 끝점은 팀이 정의한 '완료'입니다. 조직에서 이 용어를 정의하는 방법에 대한 자세한 내용은 완료 정의 (Leading Agile 블로그 게시물) 를 참조하십시오. 완료란 결과물을 성공적으로 계측 및 검증했음을 의미합니다. 제품이 성공적으로 구현, 작동 및 채택되었음을 보여주는 생산 및 모니터링 단계에서 최종 고객에게 전달하는 것이 가장 좋습니다.

3단계: 관련 팀 식별

DVSM은 고객에게 구체적인 가치를 제공하는 데 필요한 모든 인력, 프로세스 및 기술로 확장됩니다. 고객에게 가치를 제공하는 데 있어 DVSM 팀에 의존하는 팀이 있다면 팀을 DVSM 프로세스에 포함시키십시오. 고객에게 전달되는 과정에서 결과물과 상호 작용하거나, 프로세스 또는 결과물과 관련된 티켓을 받거나, 결과물을 완료하는 데 영향을 미치는 팀은 의존도가 높은 팀으로 간주됩니다. 매핑 프로세스 중에 새로운 종속성이 나타나는 경우가 많으므로 모든 팀을 미리 파악하는 것에 대해 걱정하지 마세요. 먼저 예상 팀을 개괄적으로 나열해 보세요.

개발 가치 흐름 맵을 만들 때 일반적으로 포함되는 팀은 다음과 같습니다.

• 제품

• 업무

• 개발

• 화질

• 인프라

• 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을 업데이트한 다음 새로운 제약 조건을 식별하고 우선 순위를 지정하여 지속적인 개선을 추진하십시오. 새로운 제약조건이 맵의 다른 부분에 나타나거나 제약조건이 낮은 우선순위에서 높은 우선순위로 올라가는 경우가 흔합니다.