더 나은 업무 배치

예제를 활용한 명세의 또 한 가지 중요한 이점은 다양한 소프트웨어 개발 활동을 짧은 반복주기에 배치할 수 있다는 것이다. 개인적인 경험과 이 책에 실린 사례를 봤을 때 스크럼을 적용하려는 팀이 겪는 가장 흔한 걸림돌은 작업을 한 이터레이션 내에 완료하지 못한다는 것이다. 많은 팀이 “지난 세상”에서 익힌 개념을 놓지 못한다. 즉, 개발을 먼저 끝내고, 테스트를 마친 후, 제품을 배포할 수 있을 만큼 갈고 닦는 것에 익숙하다. 이런 습관 때문에 개발이 단계적으로 완료된다는 착각이 생겨난다. 사실 테스트와 결함 수정까지 이어져야 진짜 일이 끝나는데 말이다. 스크럼 보드의 “완료” 열은 개발자가 뭔가를 완료한 것 같다는 의미이고, “완료-완료” 열의 의미는 테스터가 동의했다는 의미다. 그리고 이런 식으로 다른 의미의 완료가 단계별로 계속 이어진다(“완료-완료-완료” 열이 있다는 소리도 들었다). 업무가 자주 이런 패턴에 빠지기 때문에 테스트의 결과가 다음 주기에 영향을 주게 되어 변동 가능성이 커지고 개발 프로세스가 예측하기 어려워진다.

예제를 활용한 명세는 이 같은 문제를 해결한다. 이 책에서 설명한 실천법을 통해 팀에서는 모두가 이해하고 객관적으로 측정 가능한, 명확한 목표를 수립할 수 있다. 결과적으로 많은 팀에서 분석, 개발, 테스트 활동이 좀 더 잘 배치된다는 사실을 발견하게 된다.

향상된 업무 배치의 좋은 예로 영국의 대형 웹사이트 중 하나인 유스위치(uSwitch)를 들 수 있다. 유스위치는 기능이 완료된 시점을 파악하는 데 어려움을 겪고 나서 2008년에 예제를 활용한 명세를 도입했다. 웹사이트 구축 프로젝트에 참여한 개발자인 스티븐 로이드(Stephen Lloyd)는 “특정 기능의 개발을 끝내고 QA 부서로 넘기면 QA 부서에서는 곧바로 저희에게 특정 시나리오에서 테스트하는 것을 빠뜨렸다고 이야기하곤 했습니다. 이것은 저희에게 많은 문제를 일으켰습니다”라고 말했다. 하지만 예제를 활용한 명세를 적용해 그와 같은 문제를 극복했다. 로이드는 이제 팀 차원에서 더 잘 통합됐고 비즈니스상의 요건을 더 잘 이해하게 됐다고 이야기했다. 또한 이 같은 프로세스의 개선으로 소프트웨어의 품질도 향상됐다. 웹사이트 구축 프로젝트에 참여한 또 다른 개발자인 헤멀 쿤타왈라(Hemal Kuntawala)는 이렇게 언급했다.

웹사이트에서 전체적으로 오류 발생률이 눈에 띄게 줄어들었습니다. 이전에 비해 문제를 해결하는 시간도 훨씬 더 짧아졌고요. 실제 웹사이트에서 문제가 생기더라도 보통 몇 시간 내에 문제를 해결할 수 있습니다. 이전에는 이런 문제를 해결하는 데 며칠 또는 몇 주가 걸렸죠.

전문 보험사인 비즐리(Beazley)의 개발팀 또한 업무 배치가 향상됐다는 것을 경험했다. 미국에서 일하는 비즈니스 분석가는 영국에 있는 개발자, 테스터와 함께 일하고 있다. 그들은 한 이터레이션이 끝날 때 소프트웨어가 완성됐음을 보장하기 위해 예제를 활용한 명세를 적용했다. 비즐리의 개발팀 리더인 이안 쿠퍼(Ian Cooper)는 다음과 같이 이야기했다.

저희는 언제나 단위 테스트를 해왔지만 문제는 단위 테스트는 사용자가 원하는 일을 하느냐가 아니라 소프트웨어가 동작하느냐를 알려주는 것이라는 차이가 있다는 겁니다. 게다가 테스터는 개발과 동일한 이터레이션에서 테스트할 수도 없었습니다. 그래서 테스터는 이전 이터레이션의 테스트 결과를 다음 이터레이션에 피드백했습니다. 하지만 이제 더는 그렇게 하지 않을뿐더러 인수 기준도 훨씬 더 명확하게 이해하고 있습니다.

온라인 광고 사업을 하고 있는 뉴질랜드의 애드 스케일(AdScale.de)의 팀도 비슷한 경험을 했다. 프로젝트를 시작한 지 2년이 지나자 사용자 인터페이스가 복잡해졌고 시스템 통합으로 코드의 규모가 너무 커져서 단위 테스트만으로는 효과적으로 관리할 수 없게 된 것이다. 개발자가 완료했다고 생각하는 일을 테스터에게 넘기고 나면 테스터의 검토 결과에 따라 재작업해야 했다. 테스터와 개발자가 단절됐기 때문에 문제를 파악하는 데 시간이 오래 걸렸다. 지난 이터레이션에서 발생한 문제가 이후의 이터레이션에 영향을 주고, 개발 흐름에 지장이 생겼다. 하지만 예제를 활용한 명세를 도입한 이후로는 개발과 테스트 과정이 좀 더 긴밀해졌다. 프로젝트에서 개발자 및 테스터 역할을 담당한 클레어 맥레넌(Clare McLennan)은 다음과 같이 이야기했다.

피드백이 즉각적이었기에 배포 프로세스에서 받는 압박을 많이 덜 수 있었습니다. 이전에는 기능 목록이 완료 처리되지 않아 개발자는 저희한테 불만이 많았죠. 동시에 저희도 개발자가 잘못된 기능을 수정하지 않아 테스트할 수 없으니 개발자에게 불만이 있었고요. 저희는 개발자를 기다렸고 개발자는 저희를 기다렸습니다. 하지만 이제는 한 시간이면 모든 테스트를 끝낼 수 있으니 그런 문제가 없죠. 어떤 기능이 다음 이터레이션에 다시 등록되는 일은 없습니다.

예제를 활용한 명세를 통해 팀은 기능을 명확하고, 객관적이며, 측정 가능한 방법으로 정의할 수 있다. 또한 피드백 속도가 빨라지고 개발 흐름이 원활해지며, 계획된 업무가 중단되는 것도 방지할 수 있다.

정리

• 제품을 올바르게 만드는 것과 올바른 제품을 만드는 것은 서로 다른 일이다. 성공하려면 두 가지 모두 잘해야 한다.
• 예제를 활용한 명세는 적기에 필요한 만큼의 문서만 제공한다. 이로써 짧은 이터레이션 혹은 흐름 기반의 개발 프로세스를 통해 올바른 제품이 만들어지는 데 이바지한다.
• 예제를 활용한 명세는 소프트웨어 제품의 품질을 향상시키고, 재작업을 현저히 줄이며, 개발팀의 분석, 개발, 테스트 활동을 더욱 원활하게 한다.
• 장기적으로 예제를 활용한 명세는 리빙 도큐멘테이션 시스템을 구축하는 데 기여한다. 프로그래밍 언어 코드가 변경될 때 그 기능에 대한 설명도 함께 변경되어 적절하고 신뢰할 수 있는 문서가 만들어진다.
• 예제를 활용한 명세의 실천법은 짧은 이터레이션 기반 개발 방법(스크럼이나 익스트림 프로그래밍)이나 흐름 기반 개발 방법(칸반)과 가장 잘 어울린다. 그렇지만 일부 아이디어는 RUP(Rational Unified Process), 폭포수 모델과 같은 구조적인 개발 프로세스에도 적용할 수 있으며, 그 결과 많은 비용을 절감한 사례가 있다.