조엘 테스트 체크 리스트
- 소스코드 관리 시스템을 사용하고 있습니까?
- 한방에 빌드를 만들어낼 수 있습니까?
- 일일 빌드를 하고 있습니까?
- 버그 추적 시스템을 운영하고 있습니까?
- 코드를 새로 작성하기 전에 버그를 수정합니까?
- 일정을 업데이트하고 있습니까?
- 명세서를 작성하고 있습니까?
- 조용한 작업 환경에서 일하고 있습니까?
- 경제적인 범위 내에서 최고의 성능 도구를 사용하고 있습니까?
- 테스터를 별도로 두고 있습니까?
- 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
- 무작위 사용 편의성 테스트를 수행하고 있습니까?
5분 내로 간단하게 소프트웨어 회사의 현 주소를 진단할 수 있는 체크리스트이다. 무조건적으로 모든 상황에서 적용할 수 있는 것은 아니지만 일반적으로 12점 만점에 가까울때 일관성 있게 제품을 출시할 수 있는 잘 훈련된 팀이라고 볼 수 있다.
소스 코드 관리 시스템을 사용하고 있습니까? 소스 코드 관리 시스템은 빌드용 소스 코드와 작업용 소스 코드를 분리 시킬수 있다는 장점만 있는 것이 아닌 듯 하다. 아직 모든 버전 관리 시스템을 사용해 보진 않았지만, 일반적으로 git과 svn을 사용하고 있다. git은 개인 코드를 관리하고 저장하는 용도로 svn은 업무용으로 사용하고 있다.
한방에 빌드를 만들어낼 수 있습니까? 잘 이해할 수 없는 부분인것 같다. 아직 대형 조직에서 대형 프로젝트를 진행해본 경험은 없지만, 일반적으로 체크아웃 후 코딩을 수행하고 모든 팀원의 소스를 커밋 후 합쳐진 코드를 빌드하고 컴파일하고 최종 패키징을 생성하고 해당 파일을 배포 방법에 따라 마무리를 할것이다. 예시로 이러한 길고 긴 패키징 과정이 한방에 진행되지 않는다면 실수하기가 쉬워진다는 것을 지적하고 있다. 또한 아무도 소스코드를 건드리지 않는 밤에 스크립트로 패키징 과정까지 한방에 진행할 수 있는 도구를 추천한다.
일일 빌드를 하고 있습니까? 소스코드 관리 시스템을 사용하다 보면, 빌드가 깨진 문제성 코드를 우연히 체크인하는 경우가 생긴다. 개발자가 새로 만든 소스파일을 자신의 컴퓨터에서 컴파일하는 데 성공하고 퇴근했다. 이때 소스 파일을 코드 저장소에 커밋하는 작업은 잊어먹었다. 이렇게 되면 후에 직원들은 일을 진행할 수 없게 된다. 아직까지 빌드가 깨진다는 경험은 하지 못했다. 하지만 조엘 온 소프트웨어에서는 일일 빌드를 체크함으로써 어떤 종류의 빌드 깨짐 현상도 은근 슬쩍 넘어가지 못하게 확인하는 작업의 필요성을 강조하고 있다. 대규모 팀을 운영할 경우에는 빌드 깨짐 현상을 확인하고 곧바로 수정하기 위해 점심시간에 일일 빌드를 수행하는 방법을 추천한다. 또 누가 됐든 빌드를 깨버린 개발자는 다른 사람이 빌드를 깨는 일이 생길 때까지 빌드를 도와주는 벌칙을 추천한다. 이러한 벌칙은 빌드를 깨지않게 추천하는 당근과 채찍이다. 또 모든 사람들이 번갈아가며 빌드 절차를 익힐 수 있는 좋은 제도라고 소개한다.
버그 추적 시스템을 운영하고 있습니까? 팀원이 단 한명일지라도 모든 버그를 체계적으로 분류한 버그 관리 시스템을 사용하지 않고 코드를 개발하면 품질 나쁜 코드를 양산한다. 어느정도 동감하는 말이다. 많은 개발자들이 관리체계 문서 작성에 인색하고 나 또한 그렇다. 나 조차도 버그는 내가 기억하기 때문에 나중에 수정하면 된다는 생각으로 넘어가는 일이 많기 때문에 버그 관리 체계는 꼭 필요하다고 생각한다.
책에서 추천하는 버그 관리 시스템의 항목은 다음과 같다.
- 버그를 재현하기 위한 완벽한 단계
- 예상 수행 결과
- 관찰한 (버그로 간주되는) 실제 수행 결과
- 수정을 맡을 개발 책임자
- 수정했는지 여부
버그 추적 소프트웨어가 너무 복잡해서 오히려 업무에 방해가 된다면 위에서 소개하는 항목만 뽑아서 문서를 작성하기를 추천한다.
- 코드를 새로 작성하기 전에 버그를 수정합니까? 조엘 온 소프트웨어 책을 읽으며 1~4장 통틀어 가장 재밌게 읽었던 부분이다. 마이크로소프트 윈도우용 워드 첫 버전은 대표적인 살인 행군이라고 알려져있다고 한다. 이 프로젝트는 영원히 끝나지 않을 듯이 보였으며, 일정이 계속 늦춰졌다. 전체 프로젝트 팀은 아까운 시간을 허비했고, 프로젝트 기간은 계속, 계속, 계속해서 연장됐으며, 스트레스는 말도 못할 지경이었다고 한다. 최종적으로 이 워드는 4년 정도가 지나서야 가까스로 출시됐고, 마이크로소프트는 팀 전체를 멕시코 휴양지로 보낸다음 심각하게 자기 반성을 했다고 한다.
MS는 PM이 일정을 재촉한 나머지 개발자가 형편없는 코드라도 구현해서 서둘러 끝내려고 했다는 사실을 알았다. 정식 일정에 버그 수정 단계를 넣지 않았기 때문에 발생한 문제였다. 버그 개수를 낮게 유지하려는 어떤 시도도 없었으며, 오히려 상황을 나쁘게 만드는 시도만 판을 쳤기 떄문이다. 예를 들어 텍스트 행 높이를 계산하는 코드를 작성했던 개발자는 일부러 return 12;로 만들어놓고 자신이 만든 함수가 잘못됐다는 버그 보고서가 오기를 기다렸지만, 기도 안차게 관련 내용을 받지도 못했다고 한다. 일정은 기껏 기능이 버그로 바뀌기를 기다리는 점검항목에 불과했고 프로젝트가 끝난 다음에 이런 관례를 무제한 결함 양산 방법론이라 부르게 됐다고 한다. 이러한 문제를 해결하기 위해 MS는 전사적으로 무결점 방법론이라는 기법을 도입했고 개발자는 콧방귀를 꼇다. 관리자 명령만으로 버그 수를 줄일 수 있다고 생각하는 관리 기법처럼 보였기 떄문이다.
일정을 업데이트하고 있습니까?
명세서를 작성하고 있습니까? 모든 사람이 명세서 작업에 동감은 하지만 솔선수범 하는 사람은 없다. 대다수의 개발자는 문서 작성을 싫어하기 때문이다. 하지만 설계단계에서 문제를 발견하면 텍스트 몇 줄만 수정하는 방법으로도 쉽게 해결할 수 있다. 하지만 코딩 완료 후에 문제를 수정하면 서로의 감정도 상허고 시간낭비는 물론이거니와 비용도 급격히 상승하게 되어 실제로 문제를 수정하는 작업 자체에 저항이 생긴다.
조용한 작업 환경에서 일하고 있습니까? 지식 노동자에게 조용한 작업공간을 주고 사생활을 보장함으로써 얻는 생산성 향상은 많은 문헌에 나와있다고 한다…이상!
경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
테스터를 별도로 두고 있습니까?
프로그래머 채용 인터뷰 떄 코딩 테스트를 합니까?
무작위 사용 편의성 테스트를 수행하고 있습니까?
출처 : 조엘 스폴스키 지음, 박재호 이해영 옮김, 『 조엘 온 소프트웨어, 유쾌한 오프라인 블로그 』, 에이콘(2005.5), 3장 인용