Checklist Driven Development

사람들은 맡은 일을 시작할 때에는 그 일을 완벽하게 마치고자 하는 습성이 있습니다. 에러가 없도록, 모든 요구 사항이 충족되도록. 하지만 시간이 지날 수록 완벽하게 끝내고자 하는 마음은 뒷전으로 가고, 어느새 일을 빨리 끝내기에 급급하죠. 배포하기 전 작성하는 체크리스트에 이런 상황이 적나라하게 드러납니다. 저는 그런 상황을 미리 정해진 체크리스트로 방지할 수 있다고 생각했습니다. 몸이 체크리스트를 못 만들면 체크리스트에 몸을 맞춰야 합니다.

목적

  • 요청자 또는 기획과의 간극을 최소화
  • 요구사항에 대한 구현 가능 여부를 신속히 파악 *근거 보충 필요
  • 이슈 및 의문에 대한 취합이 비교적 빠르게 이루어짐 *근거 보충 필요

주기

프로젝트 문서를 생성한 후

기존 방식

  1. 기획문서 확인
  2. 스토리 및 AC 정의
  3. 스토리 포인트 산정
  4. 작업자 할당
  5. 작업
  6. 체크리스트 산정 *
  7. 체크리스트 체크 및 통합 테스트
  8. 배포

새로운 방식

  1. 기획문서 확인
  2. 스토리 및 AC 정의
  3. 체크리스트 산정 *
  4. 스토리 포인트 산정
  5. 작업자 할당
  6. 작업
  7. 체크리스트 체크 및 통합 테스트
  8. 배포

실험, 회고

01/13(목), 01/21(금)

기획문서 → 스토리 정의 → AC 정의 → Checklist 작성 → 스토리 포인트 정의 → 작업

전반적으로 작업자들의 평이 좋았다.

좋았던 것

  • 길잡이같이 갈 길을 정해두는 것 같았다.
  • 할 것이 명확했다.
  • 중간에 투입되어도 할 일이 무엇인지 빠르게 파악할 수 있었다.
  • 체크리스트가 디테일하게 나온다.

아쉬웠던 거

  • 우리가 할 건 이거야 하고 넘어가는 부분이 있을 수도 있음
  • 체크리스트 디테일 정도에 대한 의문

만약 안했다면?

  • 체크리스트 작성 시 내 일이다라는 생각이 들 수 있다.
  • 널널하게 작성했을 듯
  • 되는 것만 체크할 수도 있음

02/24(목)

기획문서 → 스토리 정의 → AC 정의 → Checklist 작성 → 스토리 포인트 정의 → 작업

07/11(월), 07/18(월)

RDS 통합 작업

  1. 체크할 것들이 너무 많다.
  2. 체크리스트를 먼저 작성하자 생각했다.
  3. 하다보니 템플릿이 생겼다.
  4. 배포 전
  5. 배포 당일
  6. 배포 후

순서

  1. 배포 전
  2. 배포 당일
  3. 배포 후

좋았던 점

  • 배포 당일이라는 상상을 하면서, 그것을 기준으로 생길만한 문제를 나열함.
  • 실제 배포 당일에 불안함이 없었다.

아쉬웠던 점

  • 체크리스트에 빠진게 있었다.
  • 동시에 다른 것들이 빠져있지 않을까 불안했다.
  • 가이드가 있었다면, 빠지지 않았을까 하는 생각이 들었다.

피드백

  • 사용자 스토리의 Actor 를 인프라 기준으로 작성한다.
  • 기획문서는 인프라에 적용되지 않는다.
  • 배포라는 단어를 릴리즈로 변경한다.