WIP 제한이란 무엇입니까?
애자일 개발에서 WIP(진행 중인 작업) 제한은 워크플로의 각 상태에 존재할 수 있는 최대 작업량을 설정합니다. 진행 중인 작업량을 제한하면 팀 워크플로우에서 비효율성을 쉽게 식별할 수 있습니다. 상황이 심각해지기 전에 팀의 제공 파이프라인 병목 현상을 분명히 확인할 수 있습니다.
WIP 제한이 중요한 이유는 무엇입니까?
그럼 지금쯤 "좀 더 자세히 알고 싶습니다!"라고 말하기를 바랍니다.
WIP 제한은 팀이 더 작은 작업 집합에 집중하도록 하여 처리량을 개선하고 '거의 완료' 작업량을 줄입니다. 근본적인 수준에서 WIP 제한은 '완료' 문화를 촉진합니다. 더 중요한 점은 WIP 제한이 블로커와 병목 현상을 드러낸다는 사실입니다. 어떤 기존 작업이 병목 현상을 일으키는지 명확하게 알 수 있으면 팀은 차단 이슈에 대해 모두 협력하여 파악하고 구현하고 해결할 수 있습니다. 막힌 부분이 해소되면 팀 전체의 작업이 다시 흐르기 시작합니다. 이러한 이점은 가치 증대가 고객에게 더 빨리 전달되도록 보장하므로 WIP 제한은 애자일 개발에서 중요한 도구입니다.
개발 중에는 "다른 이슈 처리를 시작하는 동안 이 이슈 처리는 잠시 중단하겠다."라고 생각하기 쉽습니다. 두 가지 이슈가 미해결 상태라는 것은 두 가지 다른 것 사이에서 컨텍스트를 전환하거나 팀원 간에 작업을 이관한다는 것을 의미합니다. 한 가지 이슈 처리 속도를 늦추고 다른 이슈 처리 속도를 높인다는 것은 무료가 아닙니다. 시간이 걸리고 집중력이 떨어집니다. 완료하지 않고 새 작업을 시작하는 것보다 원래 문제를 해결하는 것이 거의 항상 좋습니다. 즉, WIP 제한은 자신의 흐름을 방해하지 않도록 합니다.
마지막으로 WIP 제한은 만성 유휴 또는 과부하 영역을 가리킵니다. 팀은 작업 중인 특정 영역이 아니라 전체 프로세스에서 비효율성을 파악할 수 있습니다.
WIP 제한은 처음 접하는 팀에게는 생소하게 느껴질 것입니다. 처음 몇 번의 반복에서 시간을 내서 논의하세요. 팀이 WIP 제한에 도달한 시점과 그 이유를 파악합니다. 먼저 WIP 제한을 임의로 조정하려는 유혹을 뿌리치세요. 이 제한에 대한 위반에 일관성이 있으면 WIP 제한이 너무 제한적이거나 팀의 프로세스가 비효율적이라는 신호입니다.
애자일 팀에 WIP 제한 사용
이제 그 가치를 알았으면 기본적인 사항을 살펴보겠습니다.
새 워크플로를 시작할 때 팀에서 각 상태에 대한 WIP 제한을 결정하도록 합니다. 몇 번의 스프린트 동안 각 상태의 평균 작업 항목 수를 모니터링한 후 WIP 제한을 설정하는 것이 좋습니다. 다음은 일반적인 소프트웨어 개발 팀에서 사용하는 WIP 제한이 설정된 애자일 보드 예시입니다.
위의 경우 코드 검토에 WIP 제한이 설정되었습니다. 열이 한계를 초과하기 때문에 배경이 빨간색으로 변했습니다.
이슈가 완료 단계에 도달하면 할 일이 남아 있지 않으므로 WIP 제한이 필요하지 않습니다. 위의 칸반 보드에서 '할 일'은 해당 스토리를 제품 소유자와 팀이 충분히 검토했음을 의미합니다. 개발 팀은 작업 항목에 대한 처리를 시작할 때 작업을 '할 일'에서 '진행 중'으로 가져옵니다. 개발 팀의 각 팀원을 최대한 활용할 수 있도록 '할 일' 상태인 작업을 충분하게 유지하는 것이 모범 사례입니다. '할 일' 상태에 겨우 충분한 스토리만 유지하여 제품 소유자는 요구 사항을 구체화할 때 너무 앞서 나가지 않고 프로그램은 변화에 더 잘 대응할 수 있습니다.
'진행 중' 상태에는 현재 개발 중인 작업을 나열합니다. 이 경우 WIP 제한의 목표는 모두 할 일이 있지만 그 누구도 멀티태스킹을 하지 않도록 하는 것입니다. 위 보드에서 '진행 중' 항목의 한계는 4개이며, 현재 해당 상태에는 3개의 항목이 있습니다. 팀에 더 작업을 수행할 수 있는 수용 작업량이 있음을 알 수 있습니다. 모범 사례로, 일부 팀에서는 최대 WIP 제한을 팀원 수보다 적게 설정합니다. 좋은 애자일 관행을 위해 여분을 정착시키려는 발상입니다. 개발자가 항목을 완료했지만 팀이 이미 WIP 한도에 도달한 경우 몇 개의 코드 검토를 완료하거나 일부 페어 프로그래밍을 위해 다른 개발자를 추가해야 할 때입니다.
'코드 검토' 상태는 완전히 작성했지만 코드 베이스에 병합하기 전에 검토해야 하는 스토리를 나타냅니다. 시기 적절한 코드 검토는 품질을 확립하고, 새로운 혁신을 시장에 더 빨리 출시하며, 열린 브랜치를 줄여 병합을 용이하게 하고, 엔지니어링 팀 전체에 지식을 확산시키는 모범 사례입니다. 이 상태의 항목은 다음과 같은 몇 가지 이유로 긴급하게 조치를 취해야 합니다.
- 팀원이 새 코드를 체크인하므로 코드는 멈춰있지 않습니다.
- 개발자가 원래 코드를 작성할 때 얻은 컨텍스트를 잃지 않습니다.
- 릴리스를 위해 기능을 기본 브랜치에 병합할 수 있습니다.
WIP 제한은 검토하지 않은 코드가 쌓이지 않도록 합니다.
위 보드에서는 팀의 코드 검토가 너무 많아 이를 나타내기 위해 열이 빨간색으로 바뀌었습니다.
- 팀이 더 이상 이 제한에 도달하지 않도록 필요에 따라 WIP 제한을 높입니다. ('부채 한도'처럼?)
- 누구나 "백그라운드 작업"이 많아 여유 시간이 없습니다.
- 팀원들은 병목 지점으로 몰리기 보다 가만히 앉아서 더 많은 작업을 작업을 끌어오길(Pull) 기다립니다.
- 엔지니어링 관행이나 팀 프로세스를 개선하기보다 고질적인 병목 지점에 인력과 시간을 더 투입하기를 선호합니다.
WIP 제한을 사용하는 애자일 팀의 4가지 목표
새로운 활동과 마찬가지로 WIP 제한은 처음에는 생소할 수 있습니다. 여기서 목표는 팀을 중기적으로 최적화하는 것이며 단기적인 어색함은 실제로 좋은 현상입니다. 이로 인해 팀은 프로세스에서 몇 가지 문제점을 느낄 수 있습니다. 팀에서 몇 주 동안 WIP 제한을 사용한 후 필요에 따라 조정합니다. 팀이 계속 WIP 제한에 도달했기 때문에 이 제한을 높이려는 마음이 들지만 떨쳐내세요. 가능하면 팀을 교육하고 각 구성원에게 새로운 기술을 제공하거나 개발 프로세스의 일부 측면을 보다 효율적으로 만들어서 수용 작업량을 늘릴 수 있는 기회를 포착하세요.
목표 1: 일관되게 개별 작업의 크기를 지정합니다. 요구 사항과 사용자 스토리를 분류할 때는 개별 작업을 16시간 이하로 유지하는 것이 중요합니다. 이렇게 하면 팀이 자신 있게 추정할 수 있는 능력이 향상되고 병목 현상을 방지하는 데 도움이 됩니다. 파이프라인을 막는 큰 작업 항목처럼 팀의 속도를 늦추고 WIP 제한을 악화시키는 것은 없습니다.
진행 중인 작업 제한이 팀에 효과가 있으면 이슈의 사이클 타임이 줄어듭니다. 사이클 타임은 이슈를 완료하는 데 걸리는 시간입니다. 자세한 내용은 Atlassian의 애자일 메트릭에 대한 페이지를 참조하세요.
목표 2: 팀의 기술에 WIP 제한을 매핑합니다. 위의 예에서는 팀 구성원이 비슷한 기술 집합을 가지고 있다고 가정합니다. 팀에 전문가가 있는 경우 전문가 참여하면 진행 중인 작업 한도가 다를 수 있습니다. 전문가의 작업에 맞는 상태를 만듭니다. 해당 상태에서 병목 현상이 발생하면 기회를 사용하여 다른 팀원에게 전문가의 기술 집합에 대한 추가 역량을 추가하고 팀 전체에서 흐름을 늘리도록 교육하십시오.
목표 3: 유휴 상태를 줄입니다. 팀원에게 여유 시간이 생기면 업스트림 또는 다운스트림의 팀 동료를 돕도록 권장합니다. 팀의 전반적인 생산성에 기여하고 그 과정에서 무언가를 배울 것입니다!
목표 4: 지속 가능한 엔지니어링 문화를 보호합니다. 진행 중인 작업 제한으로 인해 개발자가 특정 상태에서 작업 과부하를 피하기 위해 작업을 서둘러야 하는 것은 아닙니다. 제품의 품질과 코드베이스의 상태를 보호하는 견고한 애자일 엔지니어링 관행을 지원하기 위한 것입니다.
팀에서 WIP 제한을 구현할 준비가 되었다면 칸반 보드 템플릿을 사용하여 무료로 시작하세요.
