완료 정의

"그거 다 됐어요" 라는 말은 사람마다 다른 뜻으로 쓰입니다. 개발자에게는 코드를 다 짰다는 뜻이고, 품질을 점검하는 쪽에는 테스트까지 통과했다는 뜻이고, 기획자에게는 고객이 실제로 쓸 수 있게 됐다는 뜻입니다. 같은 문장이 세 가지로 읽히니 같은 회의에서 세 사람이 다른 그림을 그린 채 헤어집니다.

그 차이는 꼭 보름쯤 뒤에 드러납니다. 스프린트 리뷰에서 기획자가 "지난주에 됐다던 알림 기능 보여 주세요" 라고 하면 개발자가 "코드는 다 됐는데 아직 배포는 안 했어요" 라고 답하는 장면입니다. 아무도 거짓말을 하지 않았는데 일정은 밀립니다. 다음 주에 붙일 일을 이미 정해 뒀으니 덜 끝난 일이 그 위에 쌓입니다.

완료 정의는 이 말의 뜻을 팀 밖이 아니라 팀 안에서 미리 하나로 맞춰 두는 장치입니다. 끝났다고 부를 수 있는 상태를 문장으로 적어 벽에 붙여 두면, "다 됐어요" 는 더 이상 각자의 느낌이 아니라 그 목록을 통과했다는 보고가 됩니다. 개인의 기준을 신뢰할 필요가 없어지는 대신 목록 하나만 신뢰하면 됩니다.

무엇을 넣을지는 팀마다 다르지만, 들어가는 항목은 대개 네 갈래로 모입니다.

1. 코드 — 변경한 코드를 동료가 확인했는지를 봅니다. 보통 코드 리뷰를 한 명 이상에게 받고 승인이 남아 있어야 합니다. 코드 리뷰는 합치기 전에 동료가 변경 내용을 읽고 의견을 다는 절차입니다.
2. 테스트 — 새로 만든 기능에 테스트가 붙었는지, 그리고 원래 잘 돌던 기능이 깨지지 않았는지를 봅니다. 회귀 테스트가 전부 통과한 상태를 조건으로 두는 팀이 많습니다.
3. 배포 — 만든 것이 고객이 쓰는 환경까지 올라갔는지를 봅니다. 여기까지 넣지 않으면 "다 만들었지만 아무도 못 쓰는" 작업이 완료로 집계됩니다. 기능을 꺼 둔 채로 먼저 올리는 팀이라면 꺼진 상태로 올라간 것을 완료로 볼지도 이 자리에서 정해 둡니다.
4. 남기기 — 무엇이 바뀌었는지를 기록하고, 고객을 직접 대하는 쪽에 알렸는지를 봅니다. 고객 문의를 받는 사람이 바뀐 화면을 모르고 있으면 그 변경은 회사 밖에서 사고가 됩니다.

항목을 고를 때 지키는 조건은 셋입니다. 첫째, 보는 사람마다 답이 갈리지 않아야 합니다. "코드가 깔끔한가" 는 판정이 갈리고 "리뷰 승인이 하나 이상 있는가" 는 갈리지 않습니다. 둘째, 모든 작업에 똑같이 걸려야 합니다. 이 작업만 예외로 두기 시작하면 목록이 곧 장식이 됩니다. 셋째, 짧아야 합니다. 스무 줄짜리 목록은 아무도 끝까지 확인하지 않아서, 보통 일곱에서 열 줄 사이로 잡습니다.

쓰는 쪽은 일을 직접 하는 팀입니다. 위에서 내려보내면 지켜지지 않습니다. 배포까지를 완료로 넣을지, 문서를 필수로 할지는 그 팀의 사정에 달렸고, 그 사정을 아는 사람은 그 일을 하는 사람뿐입니다. 기획자와 디자이너도 쓰는 자리에 함께 앉지만 항목을 마지막에 정하는 쪽은 개발팀입니다. 목록이 지켜지는지는 매일 그 절차를 밟는 사람들이 쥐고 있기 때문입니다. 스크럼을 쓰는 팀이라면 보통 회고에서 손봅니다. 이번 주기에 빠뜨려서 문제가 된 것을 한 줄 더하거나, 아무도 안 지키는 줄을 빼는 식입니다.

읽는 쪽은 셋입니다. 작업을 끝내려는 사람이 마지막에 훑고, 완료 보고를 받는 기획자가 같은 목록으로 확인하고, 벨로시티처럼 완료된 작업만 세는 지표를 계산할 때 기준으로 씁니다. 벨로시티는 한 주기에 팀이 끝낸 작업량의 평균인데, 완료 정의가 느슨한 주기와 빡빡한 주기가 섞이면 이 숫자의 편차가 커집니다. 최근 세 주기가 32·30·34 처럼 붙어 있으면 다음 계획의 근거가 되지만 12·40·25 면 아무것도 보장하지 못합니다.

새로 만들 때는 처음부터 완벽하게 쓰려 하지 않습니다. 지금 팀이 실제로 지키고 있는 것 서너 줄로 시작해서, 사고가 날 때마다 한 줄씩 늘리는 편이 오래갑니다. 반대로 이상적인 목록을 먼저 적으면 첫 주부터 지키지 못하는 줄이 생기고, 한 줄이 무시되는 순간 나머지도 같이 힘을 잃습니다.

"이건 완료 정의를 못 넘겨서 이번 스프린트에는 못 넣습니다."

기능은 돌아가지만 목록 중 하나를 통과하지 못했다는 뜻입니다.

"완료 정의에 배포까지 넣을지 이번 회고에서 정합시다."

목록 자체를 고치자는 제안입니다.

"완료 정의는 모든 작업에 같고, 인수 조건은 이 작업에만 붙는 겁니다."

두 문서의 역할이 섞이는 것을 바로잡는 말입니다.

페이지덱의 개발팀은 완료 정의를 여덟 줄로 두고 있습니다. 태오가 알림 설정 기능을 끝냈다고 올렸을 때 지현이 목록을 같이 훑었고, 여덟 줄 중 고객 지원팀 공지 한 줄이 비어 있었습니다. 기능 자체는 운영 환경에 올라가 있었지만 문의를 받는 쪽은 화면이 바뀐 줄 몰랐습니다.

그 주기에는 그 작업을 완료로 세지 않고 다음 주기로 넘겼습니다. 대신 회고에서 공지를 누가 언제 하는지를 한 줄로 더 적었습니다. 민서는 디자인 쪽 항목을 하나 넣자고 제안했는데, 판정이 갈릴 수 있다는 이유로 대신 "디자인 시안과 화면을 한 번 대조했는가" 로 문장을 바꿔 넣었습니다.

목록이 길수록 품질이 올라간다고 보는 경우가 많습니다. 확인할 것을 더 적으면 더 꼼꼼해진다는 생각은 자연스럽습니다. 하지만 목록이 길어지면 확인 자체가 일이 되고, 사람들은 훑어보는 척만 하게 됩니다. 열다섯 줄짜리 목록을 쓰는 팀에서 실제로 확인되는 줄은 늘 앞쪽 몇 줄입니다. 그러면 뒤쪽 줄은 적혀 있다는 이유로 안심만 주고 아무것도 막지 못합니다. 목록이 여덟 줄에서 열다섯 줄로 늘어난 뒤 오히려 배포 사고가 늘었다면 대개 이 상태입니다. 지키지 못할 줄을 빼는 편이 목록 전체를 살립니다.

한번 정하면 바꾸지 않는 규칙으로 읽는 것도 흔합니다. 기준이 자주 바뀌면 기준이 아니라는 감각 때문인데, 이 문서는 팀의 현재 능력을 적은 것이라 능력이 바뀌면 같이 바뀌어야 합니다. 자동 배포 장치를 갖추기 전과 갖춘 뒤의 팀은 배포 항목을 같은 문장으로 둘 수 없습니다. 고치지 않고 두면 두 방향으로 망가집니다. 이미 당연해진 줄이 남아 시간을 잡아먹거나, 새로 생긴 위험을 막는 줄이 없어 같은 사고가 반복됩니다.