태스크

목록의 한 줄이 너무 커서 시작점이 안 보이던 문제에서 나왔습니다. "카드를 등록한 사용자가 다음 결제에서 번호를 다시 입력하지 않는다" 라는 한 줄에는 카드 정보를 안전하게 저장하는 서버 작업, 등록 화면, 결제 화면에서 저장된 카드를 고르는 부분, 실패했을 때의 처리가 전부 들어 있습니다. 한 줄이니까 담당자도 한 명인데, 그 한 명이 나흘 동안 무엇을 하고 있는지가 밖에서 보이지 않습니다.

그래서 데일리 회의가 같은 모양으로 반복됐습니다. "카드 등록 하고 있습니다" 라는 답이 사흘째 나오고, 듣는 쪽은 절반쯤 왔는지 이제 시작인지 알 수 없습니다. 도와줄 여지도 없습니다. 한 줄을 둘로 나눠 두 사람이 잡을 방법이 없기 때문입니다. 막혀 있다는 사실도 늦게 드러납니다. 나흘째에 "서버 쪽이 예상보다 복잡했다" 는 말이 처음 나오는 식입니다.

쪼개는 층을 하나 더 두면서 이 문제가 풀렸습니다. 요구를 사용자 관점 한 문장으로 적은 단위가 유저 스토리이고, 그 아래에 실행할 수 있는 크기까지 내려온 항목이 놓입니다. 한 층이 늘어난 이유는 순서를 정하는 시점과 만드는 시점이 다르기 때문입니다. 무엇을 먼저 할지는 스토리로 이야기해야 한눈에 들어오고, 이번 주 개발은 이 층까지 내려와 있어야 시작됩니다.

쪼개는 기준은 크기와 내용 두 가지입니다. 한 사람이 하루에서 사흘 안에 끝낼 수 있어야 하고, 무엇을 어떻게 만드는지가 적혀 있어야 합니다. 스토리가 왜와 무엇을 적는 자리라면 이쪽은 어떻게를 적는 자리입니다.

앞의 카드 등록 스토리는 보통 이렇게 갈립니다.

1. 카드 정보를 토큰으로 바꿔 저장하는 서버 작업. 결제 대행사 연동이 여기 붙습니다.
2. 카드를 등록하는 화면. 입력칸과 검증 문구가 여기 들어갑니다.
3. 결제 화면에서 저장된 카드를 고르는 부분.
4. 실패했을 때의 처리. 카드가 거절되거나 저장된 카드가 만료된 경우입니다.

쪼개는 축은 기능의 계층으로 잡습니다. 서버, 화면, 예외 처리처럼 나누면 각 항목이 끝났는지 혼자 판정할 수 있습니다. 설계·구현·테스트처럼 단계로 나누는 방식은 피합니다. 설계가 끝났다는 말이 무슨 상태인지 사람마다 다르고, 테스트만 남은 항목은 앞 항목이 끝나야 시작되므로 두 사람이 나눠 잡을 수 없습니다.

항목마다 담당자는 한 명이고 상태는 하나입니다. 둘이 같이 잡는 항목이 생기면 그것은 아직 쪼개지지 않은 것입니다.

한 가지 규칙이 이 층을 쓸 만하게 만듭니다. 항목이 전부 끝나면 스토리가 끝나야 합니다. 네 개를 다 닫았는데 스토리의 완료 조건이 충족되지 않으면 쪼개기가 틀렸다는 뜻이고, 그때 빠져 있는 것은 대개 예외 처리나 검수입니다. 팀이 미리 합의해 둔 체크리스트인 완료 정의를 항목 단위가 아니라 스토리 단위로 두는 이유가 여기 있습니다.

이 단위가 실제로 쓰이는 자리는 넷입니다.

1. 주기 계획입니다. 이번 주기에 담을지 말지는 스토리로 정하고, 담기로 한 스토리를 그 자리에서 쪼갭니다. 쪼개 보고 나서 생각보다 크다는 것을 알게 되면 그 스토리를 다시 뺍니다. 주기에 담기로 한 것을 모아 둔 목록이 스프린트 백로그이고, 실제로 그 안을 채우는 것이 이 항목들입니다.
2. 데일리 회의입니다. 어제 닫은 항목과 오늘 잡을 항목을 말합니다. 같은 답이 사흘 반복되는 일이 사라지고, 이틀 넘게 안 닫히는 항목이 보이면 그 자리에서 막힌 이유를 묻습니다.
3. 분업입니다. 한 스토리를 두 사람이 나눠 잡을 때 나누는 선이 이 항목입니다. 서버 쪽을 태오가 잡고 화면 쪽을 다른 사람이 잡는 식으로 갈라도 서로 기다리는 시간이 짧습니다.
4. 남은 양 파악입니다. 닫힌 항목 수와 남은 항목 수로 이번 주기의 진행을 봅니다.

페이지덱이 저장 카드 기능을 만들 때가 그랬습니다. 지현이 스토리 하나로 적어 왔고, 계획 회의에서 태오가 네 개로 쪼갰습니다. 쪼개고 보니 결제 대행사 연동이 이틀이 아니라 나흘짜리였고, 그 자리에서 이번 주기에는 카드 등록까지만 하고 결제 화면 선택은 다음으로 미루기로 정했습니다. 쪼개지 않았다면 이 판단이 주기 마지막 날에 나왔을 것입니다.

민서가 그린 등록 화면 시안이 늦어진 주에도 이 단위가 값을 했습니다. 화면 항목만 멈춰 있고 서버 항목은 그대로 진행돼서, 다음 주에 시안이 나온 뒤 하루 만에 붙었습니다.

"이 스토리 태스크로 쪼갰어요? 나흘짜리면 안 들어옵니다."

실행 단위로 나눠 보기 전에는 이번 주기에 담을 수 있는지 판단이 안 된다는 말입니다.

"서버 태스크는 제가 잡을게요. 화면은 시안 나오면 붙이겠습니다."

한 스토리 안에서 나눠 잡을 선을 정하는 말입니다.

"이 태스크 이틀째 그대로인데 막힌 데 있나요?"

항목 단위로 보이니까 멈춘 지점을 바로 짚는 질문입니다.

페이지덱에서 이런 말이 나오는 자리는 계획 회의와 데일리 회의입니다. 계획 회의에서는 쪼개는 일이 담을지 말지를 정하는 근거가 되고, 데일리 회의에서는 쪼개 둔 덕분에 진행이 숫자로 보입니다. 둘 다 쪼개기를 미리 해 뒀을 때만 성립합니다. 주기가 시작된 뒤에 쪼개면 계획 회의에서 내렸어야 할 판단이 사흘 뒤로 밀립니다.

닫힌 항목 수를 진척으로 읽는 경우가 가장 많습니다. 여덟 개 중 여섯 개가 닫혔으면 75퍼센트 온 것처럼 보이니 자연스러운 오해입니다. 하지만 사용자에게 가는 것은 스토리 단위라서, 여섯 개를 닫고 두 개가 남았으면 그 스토리는 아직 0입니다. 이 숫자를 바깥에 보고하기 시작하면 팀은 닫기 쉬운 항목부터 집는 쪽으로 움직이고, 정작 어려운 두 개가 마지막 날까지 남습니다.

잘게 쪼갤수록 좋다고 보는 것도 흔합니다. 작으면 관리가 쉬워 보이는데, 30분짜리 스무 개로 나누면 목록을 옮기고 상태를 바꾸는 일 자체가 하루에 한 시간씩 듭니다. 하루에서 사흘이라는 폭은 그 관리 비용과 보이는 정도가 균형을 맞추는 자리입니다. 반대로 쪼개기가 부담스러워 통째로 두는 팀은 데일리 회의에서 같은 답이 반복되는 상태로 돌아갑니다.