[소프트웨어 아키텍처] 체크리스트를 활용한 프로젝트 관리

체크리스트 활용은 효과가 큽니다. 그러나 소프트웨어 업계에서는 체크리스트를 잘 활용하지 않습니다. 소프트웨어의 경우 사람의 생명을 다루는 일을 하는 부분이 아니기 때문에 체크리스트 활용이 활발한 편은 아니라고 볼 수 있습니다.

체크리스트에 적합한 프로세스

• 순서나 종속된 작업이 없는 프로세스
• 에러가 발생하기 쉽거나 누락되어 다음으로 넘어가기 쉬운 단계가 있는 프로세스

체크리스트 작성시 주의사항

• 만사를 체크리스트 하려고 하지 말기
• 아키텍트는 프로세스 내부의 필요한 모든 단계를 포착하되, 가능한 체크리스트를 최소화 하는 것이 좋다.
• 두툼한 체크리스트는 개발자가 보려고 하지 않는다.

효과적인 체크리스트 3인방

개발자 코드 완료 체크리스트

개발자 코드 완성도 체크리스트는 소프트웨어 개발자가 코드를 ‘완료’했다고 말할 때 사용하기 좋은 도구 입니다. ‘완료된 것의 정의’를 정의할 떄에도 유용합니다. 개발자가 이 체크리스트의 모든 항목을 완료했다면 실제로 코딩을 완료 했다고 당당히 외칠수 있습니다.

개발자 코드 완성도 체크리스트에 포함되는 내용

• 자동화 도구에 포함되어 있지 않은 코딩 및 포멧팅 표준
• 자주 간과되는 항목(예 : 로그 속에 파묻힌 예외)
• 프로젝트에 특정한 표준
• 특별한 팀 지침이나 절차

단위/기능 테스트 체크리스트

단위/기능 테스트 체크리스트는 아마도 가장 효과적인 체크리스트 중 하나일 것 입니다. 이 체크리스트에는 대다수 개발자가 테스트를 잊기 쉬운, 다소 특이한 엣지 케이스 테스트가 들어 있습니다. QA팀 사람들은 어떤 테스트 케이스에서 이슈를 발견할 때마다 이 체크리스트에 추가합니다.

이 체크리스트는 코드를 상대로 실행 가능한 모든 종류의 테스트가 포함되어 있어 분량은 가장 많은 편 입니다. 가능한 완전 코딩을 보장해서 개발자가 체크리스트 점검을 마치면 기본저그로 프로덕션 배포가 가능한 상태로 만드는 것이 목표 입니다. 단위/기능 테스트 체크리스트에 보통 다음과 같은 항목이 포함되어 있습니다.

• 텍스트 필드의 특수 문자와 숫자 필드
• 최솟값/최대값 범위
• 흔치 않고 극단적인 테스트 케이스
• 누락된 필드

여기서도 개발자 코드 완성도 체크리스트처럼 자동화 테스트로 확인 가능한 항목은 체크리스트에서 제거를 합니다.

단위/기능 테스트 체크리스트의 경우 개발자와 테스터의 간극을 좁히는 데 효과적이라고 볼 수 있습니다. 완전한 테스트를 수행하는 개발팀이 많을 수록 테스트팀도 작업이 용이해지고 체크리스트에 없는 특정 비즈니스 시나리오에 집중할 수 있씁니다.

소프트웨어 릴리스 체크리스트

소프트웨어를 프로덕션에 릴리스하는 작업은 소프트웨어 개발 라이프 사이클에서 가장 에러가 발생하기 쉬운 부분이므로 체크리스트를 작성하면 큰 도움이 됩니다. 빌드 및 배포 실패를 예방하는 데에도 탁월한 효능이 있고 소프트웨어 출시 관련 리스크도 크게 줄어듭니다.

소프트웨어 릴리스 체크리스트는 배포가 실패하거나 이슈가 발생할 때마다 새로운 에러와 사건을 해결하면서 계속 바뀌므로 가장 변화가 많은 체크리스트 입니다.

이 체크리스트는 일반적으로 다음과 같은 내용을 포함 합니다.

• 서버 또는 외부 구성 서버의 설정 변경
• 프로젝트에 추가된 서드파티 라이브러리(JAR, DLL 등)
• 데이터베이스 업데이트 및 해당 데이터베이스의 마이그레이션 스크립트

아키텍트는 빌드/배포가 실패하면 근본 원인을 분석하고 그 내용을 그때그때 소프트웨어 릴리스 체크리스트에 추가 합니다. 그래야 다음번에 빌드/배포할때 이미 확인된 문제가 되풀이 되지 않습니다.