아브락사스 애플리케이션(Abraxas Applications) 이라는 회사는 고객사에게 소프트웨어를 납품하는 미국의 중간 규모의 개발사이다. 세계적으로 널리 알려진 회사가 아님에도 세 번째 사례로 소개하게 된 이유는 그들이 겪었던 문제들은 처음 애자일을 도입하는 회사들에서 자주 볼 수 있는 패턴들이기 때문이다. 즉, 그들이 가졌던 애자일의 오해와 문제들을 통해서 애자일의 가치들을 다시 한번 되짚어 볼 수 있는 기회가 되기를 바란다.
이 회사의 사례는 2009년 미국에서 개최된 애자일 컨퍼런스에서 브라이언 빅터(Brian Victor)와 노아 제이콥슨(Noah Jacobson)에 의해서 소개되었다. 그들은 초기 애자일 프랙티스(Agile Practice)들을 회사에 소개하고 도입하기 시작했다. (애자일 프랙티스라는 용어가 국내에서는 애자일 실천법 정도로 사용되고 있다. 주로 TDD, CI, 매일 아침 미팅, 회고 등과 같은 작은 애자일의 방법들을 애자일 프랙티스라고 부른다) 이 두 개발자들은 처음 애자일을 도입할 때는 애자일이 소통 프로세스인 것을 모르고 있었다고 밝혔다.
흔히 남이 한다고 해서 따라 하는 경우 큰 효과를 얻기 힘들다. 애자일도 똑같다. 애자일 프로젝트를 성공 시키기 위해서는 무엇보다 애자일 개발 원칙 선언문이라고 불리는 애자일 선언(Agile Manifesto)을 중심으로 애자일 원칙에 대해 팀원 전체가 완벽히 이해하는 것이 중요하다. 이들의 사례에서도 애자일 원칙에 이해 없이 실천법부터 도입했던 것이 애자일을 도입하는데 실패한 이유일 것이다. 또한 개발자 출신으로 시작했던 것이 더 잘할 수 있었던 부분에 장애물이 되었다. 그럼 그들이 애자일을 처음 좌충우돌 도입하기 시작한 사례부터 지금의 성공적 애자일 정착까지 과정을 한번 살펴보도록 하자.
그들이 잘 알지 못했던 사실 “애자일은 소통의 과정”
처음 애자일을 접했을 때 그들에게는 간단해 보였다. 그들은 애자일 관련 정보를 책, 블로그, 문서, 뉴스그룹 등등 다양한 경로를 통해서 얻을 수 있었다. 그리고 이러한 정보는 애자일에 대한 지식이 없던 팀원들과 공유하였다. 그 당시에 그들이 애자일을 이해한 것으로는 TDD, CI, 짧은 반복주기의 릴리즈와 같은 여러 애자일 프랙티스들을 도입하는 거라고 생각했었다. 하지만 애자일에서 프랙티스는 애자일을 구성하는 작은 요소들일 뿐 절대 핵심이 아니다. 그래도 만약 그들이 도입했던 프랙티스(실천법)들이 성공적으로 잘 장착되었다면 그들은 아마 다른 프랙티스를 도입하는 것도 애자일의 옵션을 추가 하는 정도로 생각했었을지도 모른다.
어쨌든 TDD, CI, 짧은 반복주기 같은 개념들은 도입하기에는 쉬웠기에 그들 스스로 이 세 가지 프랙티스들을 도입하여 기존 방식을 대체했다. 하지만 해당 프랙티스들로부터 큰 효과를 얻을 수 있다고 했지만 귀찮고 번거로울 때가 많았다. 즉, 그들은 애자일의 큰 그림인 “애자일은 소통의 과정이다.” 라는 것을 모른 채 애자일을 시작했던 것이다.
애자일의 도입과정
앞서 설명한 두 개발자는 아브락사스 애플리케이션에서 회사 설립 시부터 근무한 개발자들이었다. 그들은 처음에 CruiseControl과 NUnit 이라는 닷넷 시스템의 CI 도구와 TDD 도구를 설치했다. 그리고 주간 릴리즈 미팅을 계획하였다.
그들은 그들이 알고 있는 만큼의 애자일을 도입했다. 그것들이 새롭게 다가왔지만 1년후에 어떤 일들이 벌어질지 그들은 알지 못했다. 그들은 계속 해왔던 대로 고객들과 일주일에 한번씩 회의를 가졌다. 처음 애자일 도입 했을 때는 전체 회사가 한 방안에 앉아서 회의를 진행했기 때문에 피드백 자체가 굉장히 빠르게 이루어졌다.
몇 개월이 흐른 뒤에 그들은 넓은 새로운 사무실로 이사를 했고 새로운 개발자들을 고용했다. 이들 중에는 누구도 애자일 개발에 대한 경험이 없었다. 그 뿐만 아니라 팀 내에서 한번도 애자일 교육을 했던 적이 없었기 때문에 새로운 개발자들에게 개념을 이론적으로 설명을 하고, 현재 팀에서 해오던 방식에 대해서만 설명했다. 당연히 경험에서 나오는 어떤 노하우도 없었다. 관리자와 팀원들 사이에서도 미묘한 갈등이 시작됐다. 왜냐하면 왜 애자일을 해야 하는지 정확하게 설명할 수 없었기 때문이다.
이러한 좌충우돌 경험 속에서 그들은 마침내 애자일 개발경험이 풍부하고 기존 회사에서도 애자일 코치로 활동해오던 한 사람을 고용할 수 있었다. 그는 조직을 도와서 빠르게 잘못된 점들을 점검하고 고쳐나가기 시작했다. 그리고 그는 왜 그런 문제가 생기게 되었는지에 대한 원인까지 이야기 해줌으로써 팀원들에게 정확한 이해를 시켰다.
신뢰와 관리
XP 프랙티스 중에 한 주에 40시간만 일하라는 “지속적인 속도로 일하기(substainable Pace)” 라는 실천법이 존재한다. 즉, 일을 몰아서 야근까지 해가며 무리하게 하지 말라는 것이다. 근무 시간을 늘려 야근을 할 경우에는 팀원들의 사기를 떨어뜨릴 수 있고 결과물의 품질 또한 낮다는 것이 XP에서의 주장이다.
그들의 실수는 이 지속적인 속도로 일하라는 프랙티스의 경우 결과물을 보장하지 못한다고 생각한 점이다. 그리고 고객은 그들의 산출물을 신뢰하지 않을 것이라고 예상했다. 하지만 그들은 이터레이션 계획 미팅에서 어떤 약속을 하는 것이 어려웠다. 즉, 다양한 업무분야의 진행속도를 추정하는 것이 힘들었다. 어떤 때는 기능에 대한 정보가 부족하여 더욱 추정이 힘들었다. 최악의 상황은 4명의 개발자가 한 이터레이션 안에서 4명 모두 스토리를 완성하지 못했을 때였다. 결국 이터레이션이 끝났을 때 고객에게 어떤 결과물도 보여주지 못했다. 그 때는 개발팀이 마치 아무런 일도 하지 않는 것처럼 평가되었다.
아무튼 그들이 잘못 가고 있다는 것을 인지할 만한 몇 가지 것들이 있었다. 첫 번째는 그들 스스로 찾아낸 것이다. 그것은 바로 고객에게 아무런 산출물도 넘겨주지 못한다면 고객으로부터 어떤 신뢰도 얻을 수 없다는 것이다. 비록 개발자들은 내부적으로 코드를 볼 수 있기 때문에 계속 일하고 있다는 것을 증명할 수 있다. 하지만 고객에게는 그럴 수 없다. 그렇기 때문에 고객은 개발팀을 신뢰할 수 없었다. 이러한 악순환은 새로운 애자일 코치가 일정을 계획하고 사용자 스토리를 재작성 하고 나서야 상황이 호전될 수 있었다. 코치는 사용자 스토리들을 개발자들이 충분히 측정하고 완료할 수 있을 정도의 크기로 줄였다. 그는 매일 아침의 스탠드업 미팅에서는 각자 맡은 스토리들의 진행상항에 대해서 물어봤다. 그가 그렇게 한 이유는 만약 스토리의 완성이 늦어질 것 같으면 고객에게 일찍 알려주기 위해서였다.
그들은 애자일을 기술적인 관점에서만 적용하려 했기 때문에 사람 관점의 애자일을 보지 못했던 것이다.
커뮤니케이션
그들은 한 장소에 모여 일했고, 손을 흔들며 서로에게 말을 건네는 것이 가능했다. 이전에는 이 정도의 커뮤니케이션도 진행하기 어려웠기 때문에 이 정도의 환경만으로도 충분하다고 생각했다. 하지만 일하는 동안 각자 자신의 음악을 듣는 것을 좋아했다. 자기가 일하는 환경에서 다른 사람의 불필요한 잡음을 듣기 싫어했다.
회사가 커지면서 팀은 여러 방으로 분리 되었고, 각자 원하는 곳에 파티션을 치고 앉았다. 그들은 모두 다른 이들로부터 방해 받지 않는 자신만의 개발 환경을 원했기 때문에 이에 대해서 어떤 반대 의견도 없었다. 그들은 여전히 일일 스탠드업 미팅을 가졌고 주간 이터레이션 미팅도 가졌다. 그리고 질문이 있을 경우에 다른 방에 들어가서 질문을 하기가 많이 어렵지 않았다. 하지만 점차 그들은 개발 중에 누군가가 갑작스레 와서 질문을 하는 것을 원치 않게 되었다. 그래서 많은 대화가 이메일이나 사내 인트라넷 시스템을 통해 이뤄졌다.
이런 환경은 새로운 스크럼 코치가 오면서 모두 바뀌었다. 먼저 각자 사용하던 헤드폰 사용을 금지했고 떨어져서 일하던 팀원들을 모두 한 방에 모여서 일하도록 했다. 그리고 방에 모두가 듣을 수 있게 음악을 틀었다. 비록 명시적으로 커뮤니케이션의 양을 측정하지 않았지만, 쉽게 의견을 나누거나 질문을 할 수 있게 된 점은 명백했다. 이전에는 대화를 나누기 위해서는 다른 사람의 자리로 걸어가서 손을 흔들어야 했다. 새로운 환경으로 바꾸고 나니 이전 절차가 생각보다 길었었음을 느꼈다. 하지만 지금은 아주 쉽게 질문을 주고 받을 수 있다.
그들은 커뮤니케이션 장벽이 잠재적으로는 문제를 가져올 수 있다는 것을 깨달았다. 팀원들이 서로 멀리 떨어져 있는 경우 대화가 이뤄지기까지 소요되는 시간 이상으로 생산성에 악영향을 미친다는 점을 깨달았다. 보다 원활한 소통 환경을 갖고 있다면 그만큼 개발 생산성을 올릴 수 있음을 기억해두자.
외부 협력사 QA
그들은 자신들이 구축한 자동화된 테스트 시스템이 정말 환상적이라고 생각했다. 코드가 자동화된 테스트 시스템을 통과할 때마다, 그들 스스로의 제품에 반영할 수 있는 자신감이 생겼다. 하지만 아직 테스트 되지 않은 코드가 있었다. 그리고 최종 테스트는 외부 협력업체를 통해서 수행하고 있었다. 외부 협력사에게 1주 단위로 테스트를 의뢰하였고, 테스트 결과도 1주 단위로 받을 수 있었다.
스크럼 코치는 어떤 기능을 수정하면 버그와 같은 테스트 결과를 받는데 3주 정도가 소요되는 것을 알게 되고서는 조치가 필요함을 느꼈다. 그래서 애자일 코치는 외부 협력사의 테스터를 사내로 들어와 테스트 해주길 부탁했다. 그리고 웹 기반으로 사용하던 버그 관리 프로그램을 바로 화이트보드로 바꾸었다. 버그들은 한 시간 정도의 범위 내에서 발견되고 즉시 수정되어 다시 테스트 되었다.
결론은, 가까이서 소통하는 것만큼 좋은 결과는 없었다. 테스터와 가까이 일하면서 그들은 테스트 결과 피드백 주기를 놀랍게 단축시킬 수 있었던 것이다.
애자일 프랙티스의 전도
그들이 새로운 개발자를 채용하게 되면, 새로운 팀원에게 사내의 애자일 프로세스를 설명했다. 그 중 애자일 경험이 없는 개발자는 많은 질문을 했다. 하지만 회사 자체적으로 애자일에 대한 경험이 많이 축적되지 않은 관계로 그들도 애자일 도입에 대한 확신이 없었다. 사내 일부 팀에서는 애자일 프랙티스 도입을 싫어했기 때문에 시늉만 낼 뿐 실제 내부적인 진행은 전과 다르지 않았다. 하지만 그들은 애자일 프랙티스를 한 사람씩 천천히 도입하기 시작했다. 그렇기 때문에 모든 코드가 테스트 가능한 것이 아니었고, 항상 빌드가 통과 되었다는 녹색불이 켜지지 않은 적도 많았다.
이런 프랙티스를 팀 내에 전도시키는 것은 어려운 문제였다. 이를 선호하는 사람들과 반대하는 사람들 사이에 갈등이 발생하기 때문이었다. 결국 애자일 코치의 지시대로 애자일 프랙티스를 전면적으로 도입했다. 하지만 그들은 그들 중에 재능은 있지만 애자일에 반대하는 사람을 잃을 수 있다는 것을 감수해야 했다.
설계
애자일 적용 후 개발을 설계 하는 부분에 문제가 있었다. 무엇보다도 그들이 도입한 TDD의 경우는 테스트 코드를 먼저 작성하면서 설계를 진행한다는 철학이 있었기 때문에 별도의 설계 그룹이 존재하지 않았다. 그렇기 때문에 해당 업무를 맡은 사람에게 설계 권한이 주어졌다.
하지만 팀이 커지면서 이 부분에서 갈등이 발생하기 시작했다. 팀원들마다 선호하는 설계 방식이 있었고 코드를 합칠 때 서로의 설계 방식에 대해서 서로가 굉장히 비판적이 되었다. 그래서 이러한 갈등을 해소하기 위해 생각해낸 방식이 이터레이션을 시작하는 킥오프 미팅에서 각 스토리 별로 충분한 토의를 하기로 했다. 팀원들 모두가 모여 최대한 많은 의견을 나누었다.
지금은 뛰어난 일부 개발자들 주도로 설계가 진행되고, 또한 누구나 의견을 줄 수 있었기 때문에 서로의 설계에 대한 갈등이 없어졌다.
회의
그들은 회의를 가능한 짧게 하려고 노력했다. 매일 아침에 진행되는 스탠드업 미팅은 15분 미만으로 했고, 계획을 세우는 미팅과 결과를 확인하는 주간 이터레이션 미팅은 한 시간 정도였고, 분기별로 진행되는 회고는 두 시간 이내에서 진행했다. 그들은 주 단위 이터레이션 미팅의 경우 한 시간이라는 제한 속에서 커뮤니케이션을 진행해야 했기 때문에 우선 순위를 정하는 정도의 일만 처리할 수 있었다. 그래서 팀원들은 늘 제품에 대한 충분한 대화가 부족하다고 느꼈다.
애자일 코치와 같이 일을 시작하면서 알게 된 것이 있다면 잘 짜인 계획과 미팅들의 중요성이었다. 그들은 이전보다 훨씬 많은 시간을 미팅에 부여했다. 결과는 증가된 시간보다 더 큰 효과를 가져올 수 있었다. 애자일 코치는 한 주마다 이루어지는 이터레이션 미팅을 다음과 같이 수정하였다.
- 킥오프 미팅(2-3시간): 고객들과 기능과 스토리에 대해서 이야기하였고 요구사항을 분석하였고, 업무 리스트를 작성하였다.
- 회고(1시간): 이전 이터레이션을 점검하였고, 필요할 경우 프로세스를 개선했다.
- 릴리즈 계획(1시간, 혹은 필요한 만큼): 긴 제품 계획을 만들었다.
- 리뷰(1-2시간): 완성된 스토리를 고객들에게 전달하고 피드백을 받았다.
스토리의 크기
그들은 어떻게 스토리들을 작성해야 할지 감이 없었다. 처음에는 매우 작게 기술적인 이야기들로 스토리들을 작성했다. 이 때의 문제는 스토리를 통한 고객들과의 대화가 어려웠다는 점이었다. 반대로 고객이 작성한 제품의 기능은 광범위한 범위를 다뤘다. 그래서 그들은 그 요구사항을 듣고 굉장히 긴 스토리들을 작성했다. 이것 또한 문제가 되었다. 긴 스토리의 경우 업무 범위가 크기 때문에 너무 많은 세부 내용을 필요로 했기 때문이었다.
그들은 이러한 경험을 통해서 스토리 크기가 고객과 대화함에 있어 중요한 영향을 준다는 것을 깨달았다. 그래서 지금은 고객과 대화하는데 어려움을 줄이기 위해서 적당한 크기로 만들려고 노력하고 있다. 그들이 찾은 최적의 크기는 이터레이션 별로 여섯 개에서 열두 개 정도의 스토리를 처리할 수 있을 정도이다. 그리고 기술적인 내용은 각 스토리의 서브 업무로 포함하여 진행하였다.
그들이 놓치고 있던 부분들을 애자일 메니페스토에 선언된 애자일 원칙과 비교해서 무엇이 잘못되었는지 정리해보도록 하겠다.
알지 못했던 사실 #1
애자일은 계획 수립을 돕기 위한 메커니즘이지 패널티와 규정을 만들려고는 것이 아니다. 계획 수립을 위한 애자일 방법론을 해서 팀과 고객간의 신뢰를 증진 시킬 수 있다.
그들이 가지고 있었던 문제
고객은 개발팀의 약속을 거의 믿지 않았다. 즉, 고객과 개발팀 사이에 신뢰가 거의 없었음에도 이 점을 인지하지 못하고 있었다. 대표적인 예로 고객은 미팅 때마다 피드백을 주기 보다는 개발팀이 일정 내에 끝내지 못한 것에 대해 비판만 했다.
해결전략
우선 서로에 대한 신뢰를 다시 쌓아야 한다는 점을 깨달았다. 그래서 매일 아침 고객과 팀이 짧은 미팅을 가졌고 이터레이션(XP의 개발주기) 내에 남은 스토리들에 대해 서로 의견을 나누었다. 만약 남아 있는 스토리(업무)들을 모두 완료하기 힘들 경우에는 고객이 다시 우선순위를 정하고 같이 그 문제에 대해서 상의하였다.
애자일 선언문의 원칙
“우리의 최우선 순위는 고객을 만족시키는 것이다.”
알지 못했던 사실 #2
그들은 좋은 커뮤니케이션 환경을 만드는 것이 중요하다라는 것을 전혀 알지 못했다.
그들이 가지고 있었던 문제
그들은 서로 분리된 방에 떨어져 앉아 있었다. 일하는 동안에는 각자 헤드폰으로 음악을 들었다. 그렇게 그들은 조용한 환경을 좋아했다.
해결전략
두 개의 팀이 충분히 보고 들을 수 있도록 한 테이블에 앉아 일했다. 그리고 이야기 주제와 상관없이 최대한 많은 대화를 나누었고 사무실에 흐르는 하나의 음악을 공유했다.
애자일 원칙
“정보전달에 있어 가장 효과적인 방법은 바로 직접 얼굴을 보면서 하는 대화이다.”
알지 못했던 사실 #3
테스트를 진행하기에는 한 주 단위는 너무 길다.
그들이 가지고 있었던 문제
기능구현이 끝나면 주로 외부에 있는 테스터가 테스트를 진행하였는데 매 반복주기(이터레이션)가 종료된 후에 테스트를 진행했다. 따라서 버그를 발견하고 수정하기까지 약 3주의 시간이 소비되었다.
해결전략
기존에 외부에 있던 테스터를 내부로 불러들여 기능구현 완료와 동시에 진행할 수 있는 환경을 만들었다. 그렇게 함으로써 반복주기 마지막에 테스트를 몰아서 하지 않았다.
애자일 원칙
“소프트웨어를 가능한 자주 전달해야 한다.”
알지 못했던 사실 #4
애자일에 대한 팀 전체의 헌신이 없거나 애자일을 추진할 수 있는 핵심 인물이 없다면 팀 구성원들은 본능적으로 새로운 프랙티스에 대해서 거부감이 들기 마련이다.
그들이 가지고 있었던 문제
모든 것에 토론을 진행할 수 있게 하였고, 모든 다른 의견들을 수용했다. 더불어 모든 팀이 필요로 하지 않는 TDD와 CI와 같은 애자일 프랙티스들을 강제 하였는데 결국 이것은 융통성이 없는 집착이 되었다.
해결전략
팀 별로 원하는 것을 부분적으로 도입할 수 있도록 하였다.
애자일 원칙
“팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.”
알지 못했던 사실 #5
팀원들 모두가 프로그램 설계와 아키텍처에 대한 의사결정에 참여하고 의견을 전달할 수 있는 통로를 확보해야 한다. 그럼으로써 향후에 발생할 수 있는 민감한 불만들을 예방할 수 있다.
그들이 가지고 있었던 문제
특정 기능을 구현하기 전에 설계를 진행하는 그룹이 없었다. 그래서 그들은 스토리(업무)를 맡은 사람에 의존하여 시스템을 설계해 나갔다.
해결전략
보통 하나의 사용자 스토리는 여러 업무들로 구성된다. 그래서 그들은 이터레이션이 시작하는 스프린트 계획 미팅에서 다같이 모여 스토리들마다 설계를 정의하였다.
애자일 원칙
“최고의 아키텍처와 요구사항 그리고 설계가 생겨나야 한다.”
알지 못했던 사실 #6
특정 대화나 미팅은 개발팀의 진행을 지원하기 위해서 반드시 수반되어야 한다. 만약 이런 정기적인 미팅들이 없다면 꼭 시간을 할애해서 미팅을 만들어야 한다.
그들이 가지고 있었던 문제
그들은 한번의 미팅으로 많은 일들을 계획하고 의사결정 했다. 그리고 그 때가 고객을 만나는 단 한번의 순간이었다.
해결전략
여러 번의 주기적인 미팅을 각각의 이터레이션에 적절히 배분했다.
애자일 원칙
“고객이나 비즈니스 관련 이해관계자와 개발자는 함께 일해야 한다.”
알지 못했던 사실 #7
사용자 스토리는 팀과 고객이 충분히 이해할 수 있는 크기로 만들어져야 한다.
그들이 가지고 있었던 문제
그들이 작성한 스토리들은 굉장히 작았다. 그래서 스토리가 독립적이지 못하고 항상 다른 스토리와 의존적 관계를 맺었다. 또 다른 스토리는 너무 커서 한 이터레이션 내에 끝낼 수가 없었다.
해결전략
그들은 사용자 스토리들이 2주 주기의 이터레이션에서 6개에서 12개를 처리할 수 있는 크기로 재정의 하였다.
애자일 원칙
“소프트웨어를 개발함에 있어 진행상황을 측정할 수 있음은 가장 중요한 요소 중 하나이다.”
