인수 조건

"다 됐어요" 라는 말의 뜻이 사람마다 달랐던 게 출발점입니다. 만드는 쪽은 화면이 뜨고 버튼이 눌리면 다 된 것으로 봤고, 요구한 쪽은 그 화면이 자기가 떠올린 대로 동작해야 다 된 것으로 봤습니다. 두 사람이 서로 다른 그림을 보고 있다는 사실은 완성된 화면을 함께 여는 날에야 드러났습니다.

요구 단위를 한 문장으로 적는 방식이 자리 잡은 뒤에도 이 문제는 남았습니다. "외부 고객에게 문서를 공유할 때 링크에 만료일을 걸고 싶다" 는 문장은 왜 만드는지를 분명히 말해 주지만, 어디까지 되면 끝인지는 말해 주지 않습니다. 만료된 링크를 연 사람에게 무엇이 보여야 하는지, 만료일을 나중에 바꿀 수 있어야 하는지가 문장 어디에도 없습니다. 개발자는 그 빈칸을 자기 판단으로 채우고, 요구한 사람은 다른 판단으로 채워 두고 있었습니다.

빈칸이 만드는 비용은 검수 자리에서 한꺼번에 청구됩니다. 다 만들었다고 넘어온 기능을 열어 보고 "이건 이렇게 되면 안 되는데요" 라는 말이 나오면, 그때부터는 만드는 일이 아니라 고치는 일이 됩니다. 이미 짠 구조 위에 조건을 얹는 작업이라 처음부터 알고 만들었을 때보다 오래 걸립니다.

인수 조건은 이 확인을 만들기 전으로 옮기려고 붙는 칸입니다. 검수에서 나올 질문을 미리 문장으로 적어 두고, 그 문장에 서로 동의한 상태에서 개발을 시작합니다. 하는 일은 검수와 같고 시점만 앞인데, 그 차이가 고치는 비용과 만드는 비용을 가릅니다.

한 줄은 어떤 상황에서 무엇을 하면 어떻게 되는지를 담고, 그대로 해 봤을 때 맞는지 틀리는지가 바로 갈리도록 씁니다. 세 토막으로 나눠 보면 빠진 칸이 눈에 보입니다.

1. 상황 — 이 조건이 적용되는 전제입니다. "만료일을 7일로 설정한 링크를" 처럼 값을 적습니다. 값이 없으면 확인하는 사람마다 다른 조건에서 열어 보게 됩니다.
2. 행동 — 사용자가 하는 동작입니다. "8일째 되는 날 열면" 처럼 적습니다. 화면 안쪽에서 무엇이 돌아가는지가 아니라 사람이 하는 일을 적습니다.
3. 결과 — 그래서 무엇이 보이거나 달라지는지입니다. "만료 안내 화면이 뜬다" 처럼 눈으로 확인되는 것을 적습니다.

앞의 예를 이 틀에 맞춰 적으면 이런 줄들이 나옵니다.

• 만료일을 7일로 설정한 링크를 8일째 되는 날 열면 만료 안내 화면이 뜬다.
• 만료된 링크를 연 사람에게는 문서 제목과 본문이 모두 보이지 않는다.
• 링크를 만든 뒤에도 만료일을 바꿀 수 있고, 바꾼 값은 이미 배포된 링크에 바로 적용된다.

자주 비는 자리는 잘 풀렸을 때가 아니라 어긋났을 때입니다. 만료일을 어제 날짜로 넣으면 어떻게 되는지, 만료 직전에 문서를 열어 둔 사람이 그대로 보고 있으면 어떻게 되는지 같은 엣지 케이스가 여기 들어갑니다. 드물게 일어나지만 판단이 필요한 상황이라, 적어 두지 않으면 개발자가 혼자 정하게 됩니다.

반대로 이번에 하지 않을 것을 한 줄로 못 박아 두면 범위 다툼이 줄어듭니다. "만료된 링크의 재발급은 이번 범위가 아니다" 라고 적어 두는 식입니다.

줄 수는 세 개에서 일곱 개가 흔합니다.

적는 사람은 그 작업을 요구한 쪽입니다. 대개 프로덕트 매니저가 초안을 잡는데, 혼자 완성하지는 않습니다. 요구한 사람이 혼자 적으면 만드는 쪽이 아는 제약이 빠집니다. 초안을 놓고 개발자와 검수 담당이 한 줄씩 읽으며 "이건 어떻게 확인해요" 를 묻는 자리에서 실제 문장이 만들어집니다.

읽는 사람은 셋입니다.

1. 만드는 사람 — 어디까지 하면 되는지를 여기서 확인합니다. 조건에 없는 것은 이번에 하지 않아도 되니, 범위가 넓어지는 것을 막는 근거로도 쓰입니다.
2. 검수하는 사람 — 출시 전에 품질을 확인하는 품질 보증 담당은 이 목록을 그대로 확인 항목으로 옮깁니다. 조건 한 줄이 확인 한 번이 됩니다.
3. 나중에 고칠 사람 — 반년 뒤에 이 화면을 손대는 사람은 목록을 보고 원래 무엇을 지키려던 화면인지 알게 됩니다.

시점은 개발을 시작하기 전입니다. 조건이 비어 있는 작업은 크기를 매길 수 없어서 스프린트에 담기 어렵습니다. 개발 중에 조건을 더하면 할 일이 늘어난 것이므로 계획에 반영하거나 다음 작업으로 미룹니다.

"인수 조건에 없는 항목이라 이번 범위는 아니에요. 따로 스토리로 빼 두겠습니다."

요청을 거절하는 말이 아니라 순번을 뒤로 옮기자는 말입니다.

"여기 조건이 '빠르게 뜬다' 로만 돼 있는데, 몇 초를 말하는 건가요."

참인지 거짓인지 가릴 수 없는 문장이니 숫자로 바꿔 달라는 요청입니다.

"인수 조건은 다 통과했는데 공통 기준이 남아서 이번 주기엔 못 넣어요."

팀이 모든 작업에 똑같이 적용하는 완료 정의, 그러니까 리뷰나 배포 같은 절차가 아직 안 끝났다는 뜻입니다.

페이지덱에서 이 문장들이 오가는 자리는 다음 주기에 할 일을 다듬는 회의입니다. 지현이 링크 만료 기능의 조건 세 줄을 읽어 주면 태오가 줄마다 어떻게 확인할지를 되묻습니다. "만료 안내 화면이 뜬다" 에서 태오가 그 화면이 어디 있느냐고 묻자 민서가 아직 없다고 답했고, 그 자리에서 화면을 그리는 일이 같은 작업 안으로 들어왔습니다. 조건을 읽지 않고 넘어갔다면 개발이 끝난 뒤에야 빈 화면이 발견됐을 일입니다.

만드는 방법을 지시하는 칸으로 읽는 경우가 가장 많습니다. 조건을 자세히 적을수록 어긋날 여지가 줄어드니 아예 구현 방법까지 적어 두고 싶어지는 겁니다. 하지만 이 칸에 적는 것은 밖에서 확인되는 결과이지 안에서 돌아가는 방법이 아닙니다. 만료 여부를 어디에 저장하는지는 만드는 쪽이 정할 일이고, 만료된 링크를 열면 본문이 보이지 않는다가 확인할 일입니다. 방법까지 박아 두면 더 나은 방법이 있어도 조건을 어기게 되어 못 쓰고, 방법만 지킨 채 결과가 어긋나도 조건은 통과한 것으로 보입니다.

조건이 많을수록 안전하다고 여기는 것도 흔합니다. 빠뜨려서 겪은 일이 있으면 다음부터는 생각나는 것을 전부 적게 되는데, 스무 줄짜리 목록은 아무도 끝까지 읽지 않습니다. 필요한 것은 이 작업이 끝났는지를 가르는 줄뿐이고, 그 수는 대개 일곱을 넘지 않습니다. 넘는다면 작업 크기를 손봐야 한다는 뜻인데, 그대로 두면 한 주기 안에 못 끝내는 작업이 됩니다.