아래는 소프트웨어 팀이 얼마나 업무를 잘 수행하고 있는지 판단하는 조엘의 비공식적인 평가테스트 방법이다.
소스코드 관리시스템을 사용하고 있습니까?
소스코드 관리시스템을 사용하지 않으면, 다른 프로그래머가 무엇을 했는지 알 길이 없으며, 실수르 쉽게 되돌릴 수 없다.
한방에 빌드를 만들어낼 수 있습니까?
빌드 프로세스가 한 단계로 끝나지 않을 경우, 실수하기가 쉽다.
출시 날짜가 가까워질 수록 ‘마지막’ 버그를 수정하고 최종 EXE 파일을 생성하는 사이클을 짧게 유지해야 한다.
일일 빌드를 하고 있습니까?
빌드가 꺠진 문제성 코드를 우연히 체크인하는 경우, 다른 직원을 작업을 진행할 수 없게된다.
버그 추적시스템을 운영하고 있습니까?
팀원이 단 한명일지라도 모든 버그를 체계적으로 분류한 버그 시스템을 사용하지 않고 코드를 개발하면, 품질 나쁜 코드를 양산하기 마련이다.
유용한 버그 데이터베이스가 되기 위해서는 버그마다 최소한 다음과 같은 항목들을 포함해야 한다.
버그를 재현하기 위한 완벽한 단계
예상 수행 결과
관찰한 (버그로 간주되는) 실제 수행 결과
수정을 맡을 개발 책임자
수정했는지 여부
코드를 새로 작성하기 전에 버그를 수정합니까?
일반적으로 버글르 수정하는 시기를 뒤로 미루면 미룰수록, 수정과정에서 더 많은 시간과 돈이 들어간다.
출시 후에 버그를 바견핟나면, 문제가 더 커져서 수정 작업에 막대한 비용을 지불해야 할 것이다.
수정해야 할 버그가 많을 때는 일정도 불안정하다.
일정을 업데이트하고 있습니까?
코드를 출시하기에 앞서 사업에 제대로 굴러가게하려면 수많은 계획과 관련된 결정사항들이 필요하다.
일정은 어떤 기능까지 구현할지를 결정하며, 우선 순위가 낮은 기능을 골라서 featuritis에 그치지 않게 해야한다.
명세서를 작성하고 있습니까?
설계 단계에서 문제를 발견하면 텍스트 몇 줄만 수정하는 방법으로도 쉽게 해결할 수 있다.
코딩 완료 후에 문제를 수정하면 서로 감정도 상하고 시간낭비는 물로이거니와 비용도 급격히 상승하게 되어, 그 결과 실제로 문제를 수정하면 서로 감정도 상하고 시간낭비는 물론이거니와 비용도 급격히 상승하게 되어, 그 결과 실제로 문제르 수정하는 작업 자체에 저항이 따른다.
명세에서 출발해서 만든 소프트웨어가 아니라면 일반적으로 설계는 형편없으며 일정은 통제를 벗어나기 마련이다.
조용한 작업 환경에서 일하고 있습니까?
지식 노동자는 ‘무아지경’이라는 흐르메 빠져들어야 생산성을 최대로 발휘할 수 있다.
‘무아지경’으로 빠져들기가 쉽지 않고, ‘무아지경’ 상태가 깨지기가 너무나도 쉽다.
경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
테스터를 별도로 두고 있습니까?
프로그래머 채용 인터뷰 떄 코딩 테스트를 합니까?
반드시 지원자가 코드를 작성해보게 하자.
무작위 사용편의성 테스트르 수행하고 있습니까?
무작위 사용편의성 테스트(hallway usability test): 복도를 지나는 옆 사람을 낚아채서 방금 막 장성한 코드를 사용해보게 하는 기법
5명만 붙잡아서 이런 테스트를 수행하면, 코드에 존재하는 사용편의성 문제를 대략 95%까지 찾아낼 것이다.