재작업 감소

일반적으로 자주 배포할수록 피드백을 신속하게 받을 수 있어 개발팀은 좀 더 일찍 실수를 찾아 문제를 해결할 수 있다. 하지만 이터레이션을 짧게 한다고 해서 실수가 방지되는 것은 아니다. 보통 개발팀에서는 기능 하나를 구현할 때마다 서너 차례에 걸쳐 재작업하곤 한다. 개발자는 그 이유가 고객은 직접 사용할 수 있는 것을 얻기 전까지는 원하는 것이 무엇인지 모르기 때문이라고 주장한다. 그렇지만 나는 이러한 주장에 동의하지 않는다. 예제를 활용한 명세를 이용하면 일반적으로 개발팀은 한 번의 시도로 목표에 다다를 수 있다. 그렇게 함으로써 많은 시간을 아낄 수 있고 개발 프로세스가 좀 더 예측 가능하고 믿을 수 있게 바뀐다.

런던에 있는 영국 스카이 방송사의 스카이 네트워크 서비스(SNS, Sky Network Services ) 그룹에서는 복잡한 비즈니스 워크플로와의 통합이 필요한 광대역 및 전화 통화 공급 소프트웨어를 개발하는 일을 담당하고 있다. 이 그룹은 6개의 팀으로 구성돼 있으며, 각 팀에서는 여러 해에 걸쳐 예제를 활용한 명세를 사용해 오고 있다. 그곳에 근무하는 선임 애자일 자바 개발자인 라케쉬 파텔(Rakesh Patel)은 “저희는 저희가 말한 납기를 대부분 지키고 있습니다”라고 전한다. 그리고 스카이 네트워크 서비스 그룹은 회사 내에서 명성이 자자한 편이다. 파텔은 잠시 다른 조직에서 일한 적이 있는데, 두 팀을 이렇게 비교했다.

다른 조직의 경우 스프린트가 끝날 때쯤에야 개발자가 테스터에게 소프트웨어를 넘기고, 테스터는 잘못된 부분을 찾아내서 다시 개발자에게 되돌려 보내는 식입니다. 그렇지만 이곳 스카이 네트워크 서비스 그룹에서는 그렇게 혼란스럽게 일하지 않습니다. 어떤 문제가 있다면 그건 개발 과정 중에 테스트를 녹색으로 만드는 데 문제가 있다는 것입니다. 개발 과정에서 해당 문제를 찾아낼 수 있다는 얘기죠.

미국 내 대형 보험사의 집계 애플리케이션을 개발하는 그룹인 린독(LeanDog) 역시 다른 팀과 마찬가지로 재작업이 현저하게 줄었다는 사실을 발견했다. 린독에서 개발하는 애플리케이션은 메인프레임과 웹 서비스를 통한 통합 사용자 인터페이스를 제공하는데, 이해관계자가 미국 전역에 흩어져 있어 매우 복잡한 상황이다. 팀의 변화를 도왔던 린독의 애자일 코치인 롭 파크(Rob Park)에 따르면 프로젝트 초기에는 요구사항의 각종 기능적 차이에 시달렸다고 한다. 그는 다음과 같이 이야기했다.

문제를 파악하려고 했을 때 저희에겐 명확한 설명이 필요했습니다. 그리고 뭔가 다른 방법을 써야 한다는 사실을 깨달았습니다.

팀은 예제를 활용한 명세를 도입했으며, 결과적으로 명세가 훨씬 더 좋아지고 재작업이 줄어들었다. 스토리 카드로 작업을 시작할 때만 해도 개발자는 비즈니스 분석가에게 질문할 사항들이 있었다. 하지만 “저희가 주고받는 질문의 양은 현저히 줄었고 질문의 성격 또한 달라졌습니다”라고 파크는 말했다. 그에게 예제를 활용한 명세의 가장 유용한 측면은 “명세를 만들어가는 동시에 스토리를 이해하고 스토리가 어떻게 확장될지 파악하게 된다는 것”이다.

또한 많은 팀에서 개발 초기 단계에 요구사항을 더욱 명확하게 만들기 위해 예제를 활용한 명세를 이용했을 때 제품 백로그 관리가 더 수월해진다는 사실을 발견했다. 예를 들어, 너무 모호하거나 필요한 기능의 차이가 큰 스토리를 일찍 식별하면 나중에 생길 문제를 예방할 수 있다. 예제를 활용한 명세가 없다면 보통 이터레이션 중간에 문제가 발견되어 프로젝트의 흐름이 끊기고 별도의 시간을 들여 재검토하게 되는데, 규모가 큰 기업에서는 이러한 범위를 결정하는 이해관계자가 시간을 내기란 쉬운 일이 아니다.

예제를 활용한 명세는 팀이 이터레이션 중간에 생기는 문제를 줄이는 협력적인 명세화 절차를 구축하는 데 기여한다. 또한 예제를 활용한 명세는 짧은 이터레이션에 적합하기 때문에 문서를 작성하느라 몇 달을 소요하지 않아도 된다.

미국 플로리다의 웨스톤에 위치한 얼티밋 소프트웨어(Ultimate Software )의 글로벌 탤런트 매니지먼트 팀에서는 재작업량이 줄었다는 점을 가장 큰 이점으로 꼽는다. 협력적인 명세화 과정은 개발 노력을 집중하는 데 상당한 효과가 있었다. 얼티밋 소프트웨어의 선임 개발자인 스콧 베르거(Scott Berger)는 다음과 같이 이야기했다.

스토리를 팀에 전달하기 전에 제품 책임자와의 회의를 통해 테스트 시나리오를 검토함으로써 참여 그룹(제품 책임자, 개발자, 테스터)에서는 불확실한 요구사항이나 누락된 요구사항을 명확하게 식별할 수 있습니다. 때로는 회의의 결과로 스토리가 취소되기도 합니다. 이를테면, 테스트 시나리오를 통해 시스템 내에 숨겨진 복잡성이나 요구사항 충돌이 밝혀진 경우가 그렇습니다. 그러한 회의를 하고 나면 전체 기능을 거의 재설계하자는 결정이 내려집니다. 제품 책임자에게는 스토리를 개발하는 도중에 중단시키거나 취소하지 않는 대신 명세를 다시 작성하고 재편할 수 있는 기회가 생기는 셈입니다. 이런 회의를 통해 쓸데없는 일이 줄어들고 모호하고 누락된 명세가 최소화되기 때문에 더 생산적이고 효율적으로 일할 수 있습니다. 또한 팀 전체가 기대하는 바에 대한 공감대를 형성할 수 있습니다.

대부분의 팀은 요구사항을 잘못 이해했거나 사용자의 기대치를 소홀히 해서 생긴 재작업을 현저하게 줄였거나 전부 없앴다. 이 책에서 설명하는 실천법은 팀이 비즈니스 사용자와 더욱 긴밀하게 업무를 진행하게 하고 결과물에 대해 이해한 바를 서로 공유하도록 돕는다.