새로운 기술적 실행 관례에 대한 거부감

그 반대의 측면도 있다. 고객을 제대로 돕는 매우 훌륭한 애자일 코치나 컨설팅 업체도 있다. 그런데 XP를 도입할 때 일이 헝클어진다. 두 명이 짝을 지어 개발하는 페어 프로그래밍 도입을 제안하면 바로 그 자리에서 거부하는 회사들이 많다. 두 명이 한 코드를 작성하는 것을 완전한 인건비 낭비라고 보기 때문이다. 테스트 코드를 먼저 작성하는 테스트 주도 개발 방법론에 대해서도 거부한다. “QA 팀이 있는데 뭐하러 그렇게 합니까?”라고 되묻는다. “개발자가 테스트까지 하는 것은 시간 낭비입니다. 테스트는 아시아와 인도에 아웃소싱 비용을 내고 따로 진행하고 있습니다.”.

개발자 스스로 이러한 방식들을 거부하기도 한다. 이런 개발자들은 두 사람이 짝을 지어 코딩할 때 어떤 효과들이 있는지 잘 모른다. 자신의 부족함을 파트너 개발자에게 보이는 것이 싫을 수도 있다. 테스트 코드를 작성하는 의미도 모를 수 있다. 언젠가 역량이 쌓이고 훌륭한 개발자가 되면 완전무결한 코드를 작성할 수 있을 테고, 테스트는 초보 개발자들이나 필요한 것이라고 주장할지도 모른다.

자동화한 테스트에 투자하지 않는다면 지속적인 코드 통합(integration)은 크게 의미가 없다. 컴파일이 된다는 것 정도만 확인할 수 있을 뿐이다. 설계를 단순화하고 코드에 공동의 오너십을 갖는 것도 힘들어진다(오류를 빨리 발견할 수 없어서 다른 사람의 코드에 손대기가 부담스러워진다). 관리자들은 보통, 복잡한 설계/아키텍처 패턴을 많이 알고 있고 전체 시스템이 어떻게 돌아가는지 파악하고 있는 이들이 바로 고참 개발자, 경험 많은 개발자라고 생각한다.

고참 관리자가 기술적 실행 관례들의 도입을 거부한다면, 생산되는 코드 자체의 품질에 관심을 기울이는 것이 왜 그토록 중요한지 교육을 통해 아주 강력한 증거를 보여줄 필요가 있다. 실무 개발자 수준에서 거부되고 있다면 마찬가지로 교육이 필요하다. 이러한 교육은 XP에 경험이 많은 개발자가 옆에 붙어서 하나하나 시범을 보이는 방식이 될 때가 많다. 이렇게 해도 납득시킬 수 없다면 새로운 기술과 실행 관례를 배우는 데 열정적이고 마음이 열린 개발자를 채용하는 것을 고려해야 한다.