듀얼 트랙 애자일

예전에는 탐색을 다 끝낸 다음에 개발을 시작했습니다. 한 달 동안 고객을 만나고 화면을 그려 무엇을 만들지 정한 뒤 개발팀에 넘겼습니다. 순서만 보면 깔끔한데 실제로는 두 군데가 어긋났습니다.

하나는 탐색하는 동안 개발팀이 논다는 것입니다. 한 달 치 일감이 비니 전에 하던 것을 마저 하거나 급하지 않은 정리 작업을 붙잡습니다. 다른 하나는 반대 방향입니다. 구현이 시작되면 탐색이 멈춥니다. 석 달짜리 구현이 도는 동안 아무도 그다음에 무엇을 만들지 확인하지 않고, 구현이 끝나는 날 한 달짜리 탐색이 처음부터 다시 시작됩니다.

그래서 회의는 늘 같은 모양이었습니다. 개발팀이 "이번 건 다음 주면 끝나는데 그다음은 뭐예요" 하고 물으면 기획 쪽에서 "아직 인터뷰 중이라 2주는 더 걸려요" 하고 답합니다. 개발팀을 2주 놀릴 수는 없으니 확인이 덜 된 항목을 급하게 꺼내 넘기고, 두 달 뒤에 그 기능을 쓰는 사람이 거의 없다는 것을 알게 됩니다. 확인할 줄 몰라서가 아니라 기다리게 할 수 없어서 건너뛴 것입니다.

듀얼 트랙 애자일은 이 순서를 두 줄로 펼칩니다. 탐색과 구현을 앞뒤로 잇는 대신 같은 기간에 나란히 돌리고, 탐색이 구현보다 한 칸 앞서 걷게 합니다. 짧게 반복하며 방향을 고쳐 가는 애자일 개발이 구현 쪽에서만 돌아가던 것을 탐색 쪽까지 끌고 온 셈입니다.

탐색 트랙과 개발 트랙을 같은 주기 안에 겹쳐 두고, 탐색 트랙이 다음 주기에 만들 것을 이번 주기에 확인합니다. 한 바퀴는 다섯 단계입니다.

1. 팀을 둘로 쪼개지 말고 시간을 쪼갭니다. 탐색 트랙은 무엇을 왜 만들지 정하는 프로덕트 매니저와 디자이너, 그리고 개발자 한 명이 주에 몇 시간씩 붙는 모양이 보통입니다. 개발자가 빠지면 만들 수 없는 안이 통과해 버립니다.
2. 이번 주기의 탐색 대상을 한두 개만 고릅니다. 다음 주기에 개발 트랙이 집어 갈 후보입니다. 네 개를 동시에 보면 어느 것도 못 끝낸 채 주기가 끝납니다.
3. 무엇이 참이어야 그 안이 통과인지를 가설로 적습니다. 참인지 거짓인지 가릴 수 있게 적은 추측이라는 뜻이고, "예시 문서를 먼저 띄우면 첫 문서 작성 비율이 34퍼센트에서 40퍼센트로 오른다" 처럼 숫자와 기준이 함께 들어가야 합니다.
4. 가장 싼 방법으로 확인합니다. 화면만 임시로 구현한 프로토타입을 다섯 명에게 보여 주거나, 사용자를 관찰하고 물어 근거를 모으는 사용자 리서치를 한 주 돌립니다. 여기서 떨어진 안은 개발 트랙으로 넘어가지 않고 버려집니다. 열 개 중 아홉 개가 여기서 걸린다고 보면 맞습니다.
5. 통과한 안만 앞으로 만들 후보를 모아 둔 제품 백로그 맨 위로 올립니다. 다음 스프린트가 열리면 개발 트랙이 그것을 집어 만들고, 탐색 트랙은 그사이에 다음 후보를 확인합니다.

4주 주기라면 1~4주 차에 탐색 트랙이 A안을 확인하는 동안 개발 트랙은 지난 주기에 통과한 B안을 만듭니다. 5주 차가 되면 개발 트랙은 A안으로 넘어가고 탐색 트랙은 C안을 잡습니다. 두 트랙이 한 칸씩 어긋난 채로 계속 돌기 때문에 개발 트랙 앞에 확인이 끝난 일감이 늘 한 주기 분량 쌓여 있습니다.

무엇을 만들어야 할지가 불확실하고, 같은 팀이 같은 제품을 계속 맡는 상황에 맞습니다. 신규 영역에 들어가는 팀이나 이탈 원인을 아직 모르는 팀은 후보 열 개 중 아홉 개가 틀릴 수 있어서, 확인 없이 만들면 구현 시간의 대부분을 버리게 됩니다. 반대로 이미 답이 정해진 일에는 값을 하지 않습니다. 계약서에 기능 목록이 박힌 수탁 개발이나, 법이 바뀌어 반드시 고쳐야 하는 화면에는 확인할 것이 없습니다.

한계는 대체로 사람 수에서 옵니다. 탐색 트랙에 붙는 사람이 개발 트랙에도 붙어 있으면, 마감이 걸린 쪽이 시간을 전부 가져갑니다. 배포 전 주에 인터뷰가 밀리는 일이 매 주기 반복되면 두 트랙이 아니라 개발 트랙 하나만 도는 상태입니다. 탐색에 쓰는 시간을 주 단위로 못 박아 두는 팀이 많은 이유입니다.

탐색이 한 주기 앞서 걷는다는 조건도 잘 깨집니다. 확인이 늦어져 다음 주기 일감이 비면 개발 트랙은 어차피 아무거나 집게 되고, 두 트랙으로 나눈 의미가 사라집니다.

"이번 스프린트 개발 트랙은 B안 구현이고, 탐색 트랙에서는 C안 프로토타입 돌립니다."

같은 주기에 두 가지가 동시에 돌아간다는 것을 확인하는 말입니다.

"C안은 아직 디스커버리 통과 못 했어요. 다음 스프린트 대상은 A안입니다."

확인이 끝나지 않은 안은 개발 트랙으로 내려보내지 않겠다는 뜻입니다.

"탐색 트랙이 한 주기 밀렸는데 개발팀 다음 주 일감이 비어요."

두 트랙의 간격이 무너져 개발이 대기 상태가 된다는 말입니다.

페이지덱에서는 스프린트가 열릴 때마다 지현이 두 줄짜리 표를 띄웁니다. 왼쪽은 이번에 만들 것, 오른쪽은 이번에 확인할 것입니다. 태오는 왼쪽만 보면 되고, 민서는 오른쪽 화면을 그려 고객 다섯 명에게 보여 줍니다. 지현은 주 중간에 한 번 오른쪽 결과를 정리해 다음 주기에 무엇을 넘길지 정합니다.

막히는 자리는 대개 오른쪽입니다. 배포가 걸린 주에는 태오가 탐색 회의에 들어오지 못하고, 만들기 어려운 안이 통과해 다음 주기에 되돌아옵니다. 그래서 페이지덱은 탐색 회의를 배포 다음 날로 옮겼습니다.

두 트랙을 두 팀으로 읽는 경우가 가장 많습니다. 트랙이라는 말이 선로처럼 들리니 기획팀과 개발팀을 따로 두라는 뜻으로 오해하기 쉽습니다. 실제로는 한 팀 안에서 시간을 나누는 것이고, 두 트랙에 같은 사람이 겹쳐 들어갑니다. 팀을 정말로 갈라 놓으면 탐색 결과를 문서로 넘기는 단계가 생기고, 그 순간 예전의 앞뒤 순서로 돌아갑니다. 정한 이유를 모른 채 구현하는 상황도 따라옵니다.

탐색 트랙을 개발이 시작되기 전의 준비 단계로 읽는 것도 비슷한 오해입니다. 순서대로 설명을 들으면 탐색이 먼저고 개발이 나중처럼 보입니다. 하지만 두 트랙은 시작과 끝이 같은 기간을 공유하고, 탐색은 제품이 사는 내내 멈추지 않습니다. 준비 단계로 취급하면 초기 몇 주만 탐색하고 그 뒤로는 만들기만 하게 되어, 반년 뒤 로드맵이 다시 감으로 채워집니다.