열 jako 상태

카나반 보드는 작업을 가시화합니다. 모든 작업은 카드로 표현됩니다. 카드는 왼쪽에서 오른쪽으로 이동하여 상태를 나타내는 열을 통과합니다.

기본 열은 다음과 같습니다. 백로그 → 선택된 → 진행 중 → 검토 → 완료

하지만 정확한 열은 문제가 없습니다. 중요한 것은 모든 카드가 정확한 현재 상태를 가지고, 그 상태는 해당 시스템에서 작업하는 모든 사람이 볼 수 있어야 한다는 것입니다.

카드가 나타내는 것

카드는 독립적으로 완료할 수 있는 작업 단위를 나타냅니다. 프로젝트가 아니며, 목표도 아닙니다. 완료 기준이 명확한 특정한, 범위가 있는 것입니다.

좋은 카드: 생산 서버에서 SSH 키를 회전합니다. 모든 서버에서 새로운 키가 authorized_keys에 표시되고, 구 키가 제거되면 완료됩니다.

나쁜 카드: 보안 개선. (이것은 작업이 아니라 프로젝트입니다. 분리하십시오.)

WIP 제한

다이어그램에서 진행 중 상태 열에 WIP 제한: 3이 표시되어 있습니다. 이意味은 동시에 3개 이상의 카드가 진행 중에 있을 수 없습니다. 네 번째 카드를 끌어오려면, 먼저 하나를 완료해야 합니다.

이것은 제한이 느껴집니다. 실제로 제한입니다. WIP 제한은 시작한 것을 완료하기 전에 새로운 것을 시작하지 않도록 합니다. 이 문제가 중요한 이유는 후에 섹션에서 설명합니다.

작업 카드 스코핑

카나반에서 가장 어려운 스킬은 보드를 그리는 것이 아닙니다. 카드를 스코핑하는 것입니다. 너무 크면 In Progress에서 몇 주 동안 차지하며 다른 작업을 막습니다. 너무 작으면 보드가 소음으로 가득찼습니다.

분리된 작업이 괜찮아요

다학문적인 작업이 있는 모든 곳에는 기능적 작업 센터가 있습니다. 베이커리는 페이스트리, 빵, 양념, 프론트 카운터가 있습니다. 제품 스튜디오는 디자인, 콘텐츠, 빌드, 오픈이 있습니다. 건물 프로젝트는 프레임, 배관, 전기, 마감이 있습니다. 이러한 센터는 전문성이 요구되기 때문에 집중된 소유권이 필요하기 때문에 존재합니다.

카나반은 이러한 구분을 없애지 않습니다. 이들을 가시화하고 명확하게 합니다.

핸드오프 카드

작업 단위가 한 작업 센터에서 다른 작업 센터로 이동할 때, 예를 들어 디자인 자산이 페이지를 조립하기 전에 복사본을 작성해야 하는 경우, 핸드오프 카드가 함께 이동합니다. 다운스트림 센터에서는 백로그에서 카드를 보게 됩니다. 그들이 용량이 있을 때까지 기다렸다가 그들을 끕니다. 이메일이 필요하지 않습니다. 조정 회의가 필요하지 않습니다. 카드는 신호입니다.

다이어그램이 보여주는 것

★ 티켓은 디자인 (In Progress: 시각적 자산)에서 시작합니다. 디자인 팀이 자신의 부분을 완료하면 핸드오프 카드가 생성되고 ★ 티켓이 빌드 센터의 백로그에 나타납니다. 빌드가 그들을 끕니다. 그런 다음 오픈스가 그들을 끕니다. 각 센터는 자신의 작업 보드를 가지고 있습니다. 각 보드는 현재 작업만 보여줍니다. 그러나 ★은 모든 작업을 통과하며 모든 사람이 그 위치를 볼 수 있습니다.

이것은 슈퍼마켓 인사이트가 조직에 적용되는 것입니다: 각 작업 센터는 상자입니다. 카드는 업스트림 작업이 끌리고 소비될 때만 다운스트림 상자에 재고됩니다.

핸드오프 설계

핸드오프 카드는 작업 센터 간 계약서입니다. 받는 팀이 회의 없이 행동할 수 있도록 충분한 컨텍스트를 포함해야 합니다.

시작하지 않아도, 끝내세요.

WIP는 Work In Progress의 약자입니다. WIP 제한은 특정 열에 한 번에 있을 수 있는 카드 수를 설정하는 것입니다.

이것은 제한이 들리네요. 그게 바로 포인트입니다.

제한이 도와주는 이유

새 작업을 시작하지 않고 이전 작업을 완료하지 않으면 컨텍스트 스위칭 세금을 지불해야 합니다. 작업의 컨텍스트를 로드하고 이전 작업의 일부를 언로드해야 합니다. 이전 작업으로 돌아가면 다시 로드해야 합니다. 지식 작업에 대한 로드 비용은 시간이 아니라 초 단위로 측정됩니다.

WIP 제한은 작업이 쌓이지 않게 막아주고, 더 중요한 일도 해주는데, 그것은 바로 병목을 드러내게 해주기 때문이다.

병목이 드러난다

리뷰 열에 WIP 제한이 2로 설정되어 있고, 항상 2로 유지되고 있다면, 이는 신호이다: 리뷰는 생산보다 더 느리다. 더 많은 작업이 In Progress에 완료되었지만, 리뷰에 의해 소비되지 못하고 있다. WIP 제한이 없는 경우, 보드에는 '완료되었지만 검토를 기다리는' 카드가 쌓이고, 병목이 보이지 않는다. WIP 제한이 있는 경우, In Progress 열에 새로운 카드가 추가되지 못하고, 전체 팀이 제약을 인식할 수 있다.

이것은 실패가 아니다. 정보이다. 시스템은 당신에게 리뷰를 개선하라고, 직원을 고용하라고, 짝을 지어 작업하라고, 배치 크기를 줄이라고 말해주고 있다. 단순히 더 많은 작업을 밀어붙이는 것이 아닌.

Little's 법칙(구어로)

처리 시간(카드가 시작에서 완료까지 걸리는 시간) = 작업 중인 것(WIP) ÷ 완료된 카드 수(단위 시간당 처리량). hiring을 하지 않고 처리 시간을 줄이고 싶다면, WIP를 줄여야 한다. 덜 많은 것이 동시에 진행되면, 각 작업이 더 빨리 완료될 수 있다.

R = (W × C) + T

WIP 제한은 세 가지 변수를 보호한다. 1986년에 효율성 컨설턴트 Brian Tracy가 그 이름을 지었다.

R = (W × C) + T

- R: 결과: 원하는 결과

- W: 목표 명확성: 원하는 것이 무엇인지 얼마나 정확하게 알고 있는가(0-10)

- C: 집중: 초점을 맞춘 노력의 강도(0-10)

- T: 방해받지 않고 작업한 시간(중단되지 않은 시간)

W와 C는 왜 곱셈으로 나타나는가

목표의 명확성과 집중은 독립적이지 않다. 모호한 목표에 높은 집중을 가지고 있다면, 잘못된 방향으로 빠르게 움직인다. 완벽한 목표 명확성에 집중이 없다면, 아무것도 생산되지 않는다. 그들은 상호 작용하는데, Tracy가 그들을 곱셈으로 나타내게 된 이유이다. 각 변수에 9/10을 할당하면 R = 81 + T, 3/10을 할당하면 R = 9 + T이다. 이 차이는 단순히 덧셈이 아니다.

왜 T가 더해지는가

방해받지 않은 시간당 1시간의 추가는 결과에 선형적으로 반영된다. T는 W와 C의 상호작용을 복제할 수 없다. 단순히 곱셈의 곡면 위에 쌓이는 것이다. 이는 처음으로 할 일은 W와 C를 개선하는 것이 아니라 더 많은 시간을 투자하는 것이 아님을 설명한다.

Kanban 보드가 각 변수에 어떤 영향을 미치는가

- W: 명확한 카드(명확한 제목, 측정 가능한 인수 기준, 단일 소유자)로 W를 개선한다. 모호한 카드는 자동으로 W를 낮추게 한다.

- C: WIP 제한은 집중을 강요한다. Active 열에 하나의 카드만 남게 되면, 하나의 문제에 완전히 집중할 수 있다. Active 열에 세 개의 카드가 남게 되면, C는 세 가지로 분산된다.

- T: 포도모노 블록 & 캘린더 보호는 T를 측정하는 방해받지 않은 시간을 만듭니다. 타임어는 장식이 아닙니다: 그것은 T를 실시간으로 추적합니다.

트레이시가 W, C, & T가 모두 최적화될 때 어떤 문제도 30분 내에 해결할 수 있다고 주장했습니다. 칸반 보드는 모든 세 가지를 동시에 최적화하는 데 필요한 도구입니다.

보드 읽기

보드 상태에서 병목 현상을 읽는 연습을 하십시오.

Agile이 아니라. 워터폴이 아니라.

Agile은 방법론입니다. 워터폴은 방법론입니다. 칸반은 시스템입니다.

방법론은 어떻게 작업할지 지시합니다. 시스템은 작업에 대해 진실을 설명합니다. 칸반은 두 주간 스프린트, 일일 스탠드업, 회고를 할지 지시하지 않습니다. 그것은 한 가지를 말합니다: 작업을 가시화하고 WIP를 제한하고 끌어내세요.

방법론의 문제

Agile은 주로 소프트웨어 개발을 위한 반복적인 제품 개발 팀에 잘 어울り지만,固定要件과 알려진不知지의 프로젝트에 잘 어울리는 워터폴은 건설, 하드웨어 제조와 같은 분야입니다. 서로 다른 주기 시간과 '완료'의 정의가 적용되는 교차 분야 작업에 대해 명확하게 매핑되지 않습니다.

디자인 센터와 오픈 센터를 같은 스프린트 리듬에 강제로 넣는 것은 범주 오류입니다. 콘텐츠 생성을 위한 두 주의 스프린트가 로지스틱스 작업에 인공적 긴장감을 생성하고, 협소 지역 팀에 적합한 스탠드업 의식이 독립적인 솔로에게 오버헤드를 생성합니다.

작업 수행에 대한 공통 지대 찾기

Un 접근 방식: 작업이 필요한 작업 찾기. 작업을 수행할 수 있는 사람 또는 파트너 찾기. 그 위에 프로세스를 강요하지 마십시오: 작업이 공유된 가시성 시스템을 통해 자신의 프로세스를 나타내게 해주세요.

이것은 프로세스의 부재가 아닙니다. 그것은 올바른 양의 프로세스입니다: 조정에 충분하지만, 작업의 가치가 오버헤드를 초과하는 조정 오버헤드를 생성하지 않습니다.

구축하지 마십시오. 구입하지 마십시오. 성장시키지 마십시오.

작업 카드가 생성되기 전에 질문하세요: 이 것이 존재해야 할까요? 작업을 구축하는 것은 영원적으로 소유됩니다. SaaS에 구독하는 것은 영원적으로 의존합니다. 포크된 오픈 소스 의존성은 영원적으로 유지됩니다.

결정 트리: 이것을 성장시킬 수 있습니까? 지속 가능한 능력을 생성하는 프로세스, 기술, 관계를 선호하십시오. 성장할 수 없는 경우: 이것을 구입할 수 있습니까? 80%의 문제를 해결하는 오프 더 셀프 도구를 선호하십시오. 구입할 수 없는 경우: 만들어주세요. 그리고 그것을 만들 때 소유하게 되는 것을 알아챍세요.

대다수의 조직은 이 순서를 역행합니다. commodity 도구가 잘 해결하는 문제에 대해 custom 인프라를 구축하고, 그 후에 유지 관리를 위해 헤매입니다. Kanban은 이러한 것을 가시화합니다: 귀하의 백로그에 있는 모든 카드는 구축하기로 선택한 것입니다. 정직한 질문은 그것이 백로그에 있어야 한다고 할까요?

구축 / 구입 / 성장

결정 프레임워크를 적용하십시오.

Design a Board

Put it together. You'll design a kanban system for a specific cross-functional scenario.

Scenario

A small studio is relaunching their product with a new brand. The work involves four centers:

- Design: new logo, visual identity, product photography, page layouts

- Content: rewritten product descriptions, landing page copy, email announcement

- Build: updated website, new checkout flow, redirects from old URLs

- Ops: updated payment processor settings, fulfillment partner briefing, analytics reconfiguration

The relaunch has a hard deadline: a trade show in 45 days where the new brand goes public.

솔로가 시로

대다수의 조직에서는 칸반의 목적이 관리 계층을 가로지르는 작업의 가시성을 제공하는 것입니다. 관리자가 시로를 연결합니다. 칸반은 조정 비용을 줄입니다.

UN 모델에서는 관리자가 없습니다. 솔로는 독립적으로 기업을 운영합니다: 디자인 솔로, 빌더 솔로, 작가 솔로, 오페라 솔로 등 각 솔로는 기본적으로 시로입니다. 그들은 연결된 org 차트가 없습니다. 보고 관계가 없습니다. 관리자가 조정을 강요하지 않습니다.

칸반은 조정 계층이 됩니다. 솔로가 작업을 전달하는 것을 강요하지 않고 시로를 완전히 독립적으로 유지하지 않습니다. 그들은 공유 보드에서 카드를 놓는 것으로 작업을 전달합니다. 수신 솔로는 작업량을 갖출 때까지 기다리고 카드를 가져옵니다.

이것이 칸반은 UN 모델에 더 잘 적합하는 이유입니다: 공유 주기, 공동 회고, 동기화된 계획이 필요하지 않습니다. 각 솔로는 자신의 작업량 제한을 설정하고,自己的 사이클 타임을 설정하고, 작업이 완료되는 기준을 설정합니다. 카드 수준에서 조정이 발생하며, 프로세스 수준에서 조정이 발생합니다.