WBS와 애자일은 싸우지 않는다

발주사와의 착수 회의다. 고객사 PMO(프로젝트 관리 전담 조직)가 말한다. "월별 마일스톤과 WBS 기반 진척 보고를 요청드립니다." 사무실로 돌아오면 개발 리드가 말한다. "우린 스크럼으로 일해요. WBS는 워터폴 유물 아닌가요?"

PM은 그 사이에 서 있다. 계약과 보고는 WBS를 요구하고 팀은 스프린트로 돌아간다. 많은 PM이 이 상황을 둘 중 하나를 속이는 방식으로 해결한다. 팀에는 안 보이는 곳에서 몰래 WBS를 관리하거나, 고객에게는 스프린트 보드를 WBS처럼 포장해 보여준다. 어느 쪽이든 장부를 두 개 쓰는 셈이고, 장부가 두 개면 반드시 어긋난다.

질문 자체가 잘못됐다

"WBS냐 애자일이냐"는 질문은 성립하지 않는다. 둘은 경쟁 관계가 아니라 다루는 차원이 다르기 때문이다.

WBS는 무엇을 만들 것인가를 분해한 것이다. 이 프로젝트가 인도해야 할 것 전체를 빠짐도 겹침도 없이 구조화한다(1편의 100% Rule이 이것이다). WBS는 일하는 방식에 대해서는 아무 말도 하지 않는다.

애자일은 어떻게 만들 것인가의 실행 방법이다. 정해진 범위를 어떤 리듬으로, 어떤 피드백 주기로 만들어낼 것인가를 다룬다. 스프린트는 일하는 방식이지 범위의 구조가 아니다.

"WBS는 워터폴 유물"이라는 말은 이 둘을 혼동한 것이다. 실제로 PMBok 7판은 라이프사이클을 Predictive(예측형)부터 Adaptive(적응형)까지의 스펙트럼으로 정의하고 상황에 맞게 재단(Tailoring)하라고 말한다. 순수 워터폴도 순수 애자일도 스펙트럼의 양 끝일 뿐이고, 현실의 계약 기반 프로젝트 대부분은 그 사이 어딘가인 하이브리드에 있다.

하이브리드의 실전 구조

장부를 두 개 쓰지 않고 양쪽을 만족시키는 구조는 이렇다.

상위 2~3레벨은 WBS로 고정한다. 인도물과 주요 마일스톤, 계약 단위의 범위는 트리로 구조화하고 베이스라인(3편)을 건다. 이 층은 고객·경영진과의 약속이고 변경통제의 대상이다. 천천히 움직이는 층이다.

최하위 Work Package의 내부는 팀에 위임한다. "정산 모듈(120시간)"이라는 Work Package를 어떻게 구현할지, 몇 개의 스토리로 쪼개고 어느 스프린트에 태울지는 팀의 백로그가 정한다. 이 층은 빠르게 움직이고 고객 보고에 노출되지 않는다.

두 층은 진척 규칙 하나로 잇는다. 스프린트에서 Work Package에 속한 스토리가 완료(Done)되면 그 완료가 Work Package의 진척으로 집계된다(4편의 사건 기반 산정이 여기서도 작동한다). 팀은 스토리 포인트로 말하고 고객은 마일스톤과 SPI로 듣는다. 같은 사실을 두 가지 언어로 말할 뿐 장부는 하나다.

구조를 표로 정리하면 이렇다. 핵심은 Work Package가 두 세계가 만나는 지점이라는 것이다.

Epic과 Story는 애자일의 요구사항 단위다. Epic이 큰 묶음이고 Story가 스프린트에 들어가는 작은 단위다.

진척은 아래에서 위로 흐른다. Story가 Done이 되면 Work Package 진척에 반영되어 EV를 얻고, 그것이 마일스톤과 SPI로 집계되어 고객 보고가 된다. 팀은 위를 올려다볼 필요가 없고 고객은 아래를 내려다볼 필요가 없다.

계약형 프로젝트에서 애자일을 돌리는 법

"계약은 고정인데 애자일이 가능한가"라는 질문에는 세 가지 구분으로 답한다.

• 범위는 고정, 상세는 가변. Work Package 수준의 범위는 계약과 베이스라인으로 고정하되, 그 안의 구현 방식과 스토리 분해는 팀이 스프린트마다 조정한다.
• 마일스톤은 고정, 반복은 자유. 고객과의 검증 지점은 날짜로 약속하고, 그 사이를 몇 번의 스프린트로 채울지는 팀이 정한다.
• 변경은 CR로, 개선은 refinement로. Work Package의 경계를 넘는 요구는 변경통제(3편)로 처리하고, 경계 안의 조정은 백로그 refinement로 처리한다. 이 구분이 무너지면 애자일이라는 이름으로 범위가 새기 시작한다.

양쪽에 할 말도 준비해 둔다. 개발팀에는 이렇게 말한다. "WBS는 일하는 방식을 통제하지 않는다. 우리가 무엇을 약속했는지 기록할 뿐이고 스프린트 안은 전적으로 팀의 것이다." 고객에게는 이렇게 말한다. "스프린트는 내부 실행 단위입니다. 보고는 승인된 인도물과 마일스톤 기준으로 드립니다."

도구가 문제를 다시 만든다

구조는 명쾌한데 현실에서 자주 무너지는 이유는 도구가 한쪽 세계관만 지원하기 때문이다. 스프린트 도구에는 WBS·베이스라인·EVM이 없고, 전통 PM 도구에는 백로그와 스프린트가 없다. 그래서 PM은 두 도구 사이를 손으로 잇다가 2편에서 다룬 문서 두 벌 문제로 돌아간다. 도구를 설계하며 하이브리드를 별도 모드가 아니라 기본 전제로 둔 이유가 이것이다. 상위는 WBS와 베이스라인, 하위는 팀의 실행 리듬을 담되 데이터 모델 하나가 두 언어를 모두 말해야 한다.

WBS와 애자일을 대립시키는 것은 도구와 관성이지 원리가 아니다. 무엇을 만들지의 지도를 쥔 채로 어떻게 만들지의 자유를 주는 것, 하이브리드 시대 PM의 일은 그 두 가지를 동시에 하는 것이다.

PM의 실행 블록

내일 바로 할 일 3가지

1. 현재 WBS에서 팀에 위임할 경계인 Work Package 레벨을 명시적으로 정한다.
2. 백로그의 Epic과 Story를 Work Package에 매핑한다. 매핑되지 않는 스토리가 곧 범위 이슈다.
3. Story가 Done이 되면 Work Package 진척에 어떻게 집계되는지 규칙을 팀과 합의한다.

회의에서 던질 질문

• "이 스토리는 어느 Work Package에 속합니까? 없다면 왜 하고 있습니까?"
• "이 고객 요구는 Work Package 경계 안입니까, 밖입니까?" 안이면 refinement이고 밖이면 CR이다.
• "고객 보고의 마일스톤 날짜와 스프린트 캘린더가 충돌하는 지점이 있습니까?"

좋은 신호와 나쁜 신호

도구가 해결해야 하는 부분

장부가 두 개가 되는 원인은 두 세계관을 각각 지원하는 두 도구였다. wbsgantt를 설계하며 하이브리드를 별도 모드가 아니라 기본 전제로 둔 이유다. 상위에는 WBS·베이스라인·EVM이 있고 Work Package 아래에는 팀의 실행 단위가 붙으며, Done 이벤트가 자동으로 위로 집계된다. 장부가 하나면 번역은 필요해도 두 번 적을 필요는 없다.