서브태스크

한 건으로 등록된 일이 사흘짜리인 경우가 흔했습니다. 처리할 일을 하나로 끊어 등록한 항목을 티켓이라 하는데, 그 티켓의 상태가 사흘 동안 진행 중에 머물러 있습니다. 상태 칸이 세 가지뿐이니 시작했는지 끝났는지만 알 수 있고, 그 사이에 어디까지 왔는지는 화면에 없습니다.

그래서 물어보는 것이 유일한 방법이었습니다. 데일리 회의에서 "아직 하고 있어요" 라는 답이 사흘 반복되고, 듣는 쪽은 그 답이 순조롭다는 뜻인지 막혀 있다는 뜻인지 구별할 수 없습니다. 사흘째에 물어봤더니 첫날부터 다른 팀 응답을 기다리고 있었다는 사실이 드러나는 일이 있었습니다.

나눠 맡기도 어려웠습니다. 티켓에 담당자 칸이 하나뿐이니 두 사람이 앞뒤를 나눠 하려면 티켓을 둘로 쪼개야 하고, 쪼개면 원래 하나였던 일의 관계가 사라집니다. 서브태스크는 이 두 문제를 티켓을 쪼개지 않고 푸는 장치입니다. 한 건이라는 사실을 그대로 두면서 안쪽에 진행과 담당을 따로 둡니다.

한 티켓 안에 실제로 손이 가는 순서대로 항목을 매답니다. 항목마다 채우는 것은 넷입니다.

1. 한 줄 제목입니다. 한 동작이 보이게 적습니다. "API 만들기" 는 범위가 안 보이고, "문서 목록 조회 API 추가" 는 무엇이 끝나면 완료인지가 제목에서 읽힙니다. 나중에 목록으로 훑을 때 제목만 보고 판단하게 되니 이 줄이 실제 값을 결정합니다.
2. 담당자입니다. 서브태스크마다 따로 지정할 수 있다는 점이 이 단위의 실제 쓸모입니다. 화면 작업과 서버 작업을 두 사람이 나눠 맡아도 티켓은 한 건으로 남습니다.
3. 상태입니다. 티켓의 상태와 별개로 움직입니다. 다섯 개 중 셋이 완료면 화면에 그만큼 표시되고, 사흘 동안 같은 답을 듣던 자리가 숫자 하나로 바뀝니다.
4. 크기입니다. 반나절에서 하루 안에 끝나는 정도로 자릅니다. 하루를 넘기면 그 항목이 다시 사흘짜리와 같은 문제를 만들고, 반나절보다 작으면 항목 수가 늘어 관리에만 시간이 듭니다.

넣지 않는 것도 정해 둡니다. 작업 크기를 나타내는 스토리 포인트는 티켓에만 붙이고 서브태스크에는 붙이지 않습니다. 양쪽에 다 붙이면 한 주기의 합계에 같은 일이 두 번 들어가고, 그 합계로 계산한 평균이 부풀립니다.

완료 기준도 층이 다릅니다. 팀이 미리 합의해 둔 체크리스트를 완료 정의라 하는데, 이것은 티켓에 걸립니다. 서브태스크는 그 체크리스트를 향해 가는 중간 지점이고, 하나가 끝났다는 것은 다음 항목으로 넘어갈 수 있다는 뜻일 뿐입니다.

쓰는 사람은 그 일을 실제로 할 사람입니다. 이 점이 티켓과 갈리는 자리입니다. 티켓은 무엇을 왜 하는지를 적으니 기획하는 쪽이 쓰고, 서브태스크는 어떤 순서로 손댈지를 적으니 만드는 쪽이 씁니다. 순서를 모르는 사람이 미리 쪼개 두면 실제 작업 순서와 어긋나서, 받은 사람이 지우고 다시 만듭니다.

쓰는 시점은 착수 직전입니다. 주기 시작 회의에서 티켓을 다 쪼개 두고 싶은 유혹이 있지만, 셋째 주에 할 티켓을 지금 쪼개면 그 사이에 앞 작업의 결과가 바뀌어 순서가 달라집니다. 그때 다시 쪼개게 되니 처음 쪼갠 시간이 버려집니다.

읽는 쪽은 셋입니다. 같은 티켓에 붙은 동료는 앞 항목이 끝났는지를 보고 자기 차례를 압니다. 데일리 회의에서는 말로 하던 진행 보고를 이 항목들이 대신합니다. 제품 매니저는 막힌 자리를 특정할 때 봅니다. 사흘째 같은 항목에 머물러 있으면 그 항목 이름이 곧 막힌 이유를 가리킵니다.

주기 단위 보드에서는 층이 갈립니다. 스프린트 보드의 열을 오가는 것은 티켓이고, 서브태스크는 그 티켓 카드 안에서 움직입니다. 보드에 서브태스크를 직접 올리면 카드가 세 배로 늘어 전체를 볼 수 없게 됩니다.

개수에 상한을 두는 편이 낫습니다. 한 티켓에 일곱 개를 넘기면 그것은 티켓이 너무 큰 것이고, 서브태스크를 늘리는 대신 티켓을 둘로 나눕니다. 나누면 두 티켓이 각자 다섯 개 안쪽으로 정리됩니다.

"서브태스크 다섯 개 중 둘이 남았어요."

말로 하던 진행 보고를 항목 수로 대신한 것입니다.

"이 티켓은 제가 화면, 태오가 서버로 나눠 둘게요."

담당을 항목별로 갈라 한 건을 유지한다는 뜻입니다.

"서브태스크가 아홉 개예요. 티켓을 쪼개는 게 맞습니다."

항목 수가 티켓 크기의 문제를 가리킨다는 지적입니다.

페이지덱은 착수하는 사람이 직접 쪼갭니다. 지현이 티켓에 무엇을 왜 하는지까지 적어 두고, 태오가 그 티켓을 받아 그날 서브태스크를 만듭니다. 처음에는 지현이 미리 쪼개 두었는데, 태오가 받은 뒤 지우고 다시 만드는 일이 반복돼 규칙을 바꿨습니다.

한 번은 이 항목들이 막힌 자리를 그대로 보여 준 적도 있습니다. 결제 연동 티켓의 서브태스크 넷 중 첫째가 사흘 동안 그대로였고, 항목 이름이 "결제사 테스트 계정 발급 요청" 이었습니다. 태오가 할 수 있는 일이 아니라 기다리는 일이었고, 지현이 그 이름을 보고 결제사에 직접 연락했습니다.

잘게 쪼갤수록 좋다고 보는 경우가 가장 많습니다. 항목이 많으면 진행이 세밀하게 보이니 관리가 잘 되는 것처럼 느껴집니다. 그런데 항목마다 만들고 상태를 옮기고 닫는 손이 들어갑니다. 30분짜리 항목 스무 개를 만든 티켓에서는 일하는 시간보다 항목을 옮기는 시간이 더 들고, 며칠 지나면 아무도 상태를 갱신하지 않게 됩니다. 갱신되지 않는 항목 목록은 없는 것보다 나쁩니다. 화면에는 둘이 완료라고 적혀 있는데 실제로는 넷이 끝나 있으니, 읽는 사람이 그 숫자를 믿지 않게 됩니다.

서브태스크가 다 끝나면 티켓이 끝난다고 보는 시각도 자주 나옵니다. 안에 든 것이 다 닫혔으니 자연스러운 판단입니다. 하지만 서브태스크는 착수하는 사람이 자기 작업 순서대로 적은 것이고, 완료 정의에 있는 항목이 빠져 있을 수 있습니다. 코드 리뷰나 운영 반영이 목록에 없는데 다섯 개가 다 닫혀 있으면, 티켓을 완료로 옮긴 뒤에 그 두 가지가 남습니다. 티켓의 완료는 서브태스크 개수가 아니라 완료 정의로 판정합니다.