일민형이 지난 애자일 논쟁^[각주:1]을 지켜보다 애자일 선언으로 마무리했다. 한동안 잊고 살았던 애자일 선언을 다시 만나는 순간이었다. 나는 특정 애자일 방법론에 대해서는 잘 모른다. 또한, 애자일 프랙티스에 대해서도 경험이 많지 않다. 그럼에도 불구하고, 애자일 선언을 처음 본 순간 바로 이거다 싶었다. 실무에서 프로젝트를 수행한 햇수가 늘어날 수록 공감하는 지수는 더욱 높아진다.


흥미로운 사실은 우리 프로젝트에서도 고스란히 선언문에 적힌 내용을 체험할 수 있었다는 점이다. 짧게 공유하고자 한다.

Individuals and interactions over processes and tools
프로젝트 초기에 나는 CI 환경 구비만 잘 되고, 단위 테스트만 하면 CI 즉, 지속적인 통합이 가능할 것이라고 보았다. 그러나, 툴은 분명 한계가 있었고, 프로세스 실현은 그리 간단하지 않았다. 우리는 이번 프로젝트에서 처음으로 손발을 맞춘 팀이다. 당연히 프로세스가 몸에 밴 팀은 아니다.^[각주:2] 프로세스 익히느라 일정을 늦출 수는 없는 일이다.

여기서 나는 해결책이 필요했다. 결국 개개인의 특성 파악으로 들어갔다. 우린 모두 개성을 지닌 존재이다. 프로젝트를 하면 종종 그 사실을 잊어버린다. 우선 각자 자신이 만들어야 할 산출물을 그리고, 해당 산출물을 통한 다른 사람과의 관계를 표현하게 했다. 작업자와 산출물 사이에 선을 그으면 행위가 나타난다. 나는 이를 문맥도(context diagram)이라 칭하면 모두에게 편한 방식으로 그려오게 했다. 흥미롭게도 대부분 관리자인 나와는 달리, 주변 다른 개발자의 관계를 완벽하게 알지는 못했다. 나는 그 부분을 찾아서 그려주었다. 이후에 Individuals and interactions이 정형화된 부분에 대해서는, 이를 프로세스로 정의해서 공유했다. 그 과정을 이미 중간 중간에 여기 저기에 공유했다. 개발자들은 다른 사람의 일에 관심이 없던 것이 아니었다. 전체를 볼 수 있는 사람이 서로 협력이 필요함을 알게만 해준다면 문제는 스스로 해결되었다.

Working software over comprehensive documentation
종종 RUP 혹은 CBD를 적용하는 경우 유스케이스 명세서 혹은 유스케이스 기술서를 작성하는 경우를 흔히 볼 수 있다. 빠른 시간 내에 UI 스토리보드를 작성할 수 있는 잘 아는 업무가 아니라면, 유스케이스 목록만 작성하고 UI 설계부터 시작하라고 권해주고 싶다. 우리 프로젝트는 릴리즈를 두 번으로 잡았는데 최초 릴리즈는 프로젝트 착수후 10주만이었다. 짧은 릴리즈 기일 때문에 우리는 최소한의 문서작업만 했다. 결과는 성공적이었다. 그 후 우리는 공식적인 릴리즈를 세 번으로 늘렸고, 하나의 릴리즈 주기 안에서도 또 릴리즈를 했다. 소소한 개선 요청을 반영하는 즉시 릴리즈를 했다.

Customer collaboration over contract negotiation
대표적인 contract negotiation 중에 하나는 요구사항 확정이다. 고객은 잘 모르던 시절(프로젝트 초기)에 정한 것을 바꾸지 못하도록 개발팀이 우는 소리 하는 것이 억울할 것이다. 반대로 개발팀은 프로젝트 막판에 고객들이 제멋대로 요구사항을 확확 바꾸는 것에 가슴이 답답하다. 앞서 언급한 감정들은 사실 터놓고 더 나은 방식으로 협업을 하면 해결할 수 있다.  앞서 언급한 릴리즈 사례를 다시 인용하겠다. 우리는 한번 릴리즈한 프로그램에 대해서, 고객들이 이를 사용하면서, 수시로 요청사항을 올리게했다. 그 내용을 해결한 후 이를 모아서 짧은 주기로(보통 수일 간격) 릴리즈를 했다.

결론, 일상의 협업(Customer collaboration)은 요구사항을 가지고 된다 안된다 하는 긴장감 넘치는 협상(Customer collaboration over contract negotiation)을 점차 없애 버렸다. 프로젝트가 반도 끝나지 않은 지금 고객과 개발팀은 거의 한 팀에 가깝다. 참고로 우리는 발주자와 수행자가 처음만나, 100% 계약관계로 묶인 SI 프로젝트를 수행중이다. :)

Responding to change over following a plan
나는 반복의 중요성을 여러 차례 언급했다. 보통 프로젝트 초기에 복잡다단한 WBS를 작성하는 일이 많다. 더구나 어떤 PMS는 최초에 등록한 사항을 변경하기 어렵게 하는 경우도 있다. 프로젝트는 모험의 연속이다. 모험은 필연적으로 변화를 수반하고, 계획을 변경하기 마련이다. 우리는 반복을 통해 우리가 해결해야 할 문제를 더 잘 알게 된다. 다행스럽게 나는 변경하기 힘든 계획 때문에 고생하는 프로젝트에 승선했던 경험이 많다. 그래서, 처음부터 유연성과 확장성을 고려한 계획^[각주:3]을 세웠다. 거장한 형용사를 붙였지만, 고객의 경영진에 보고할 진척의 기준인 WBS는 목표 혹은 마일스톤 중심으로 대략적으로 작성했다. 그리고 각 스프린트(2 ~ 6주 간격)별로 상세한 작업목록을 담은 계획서를 별도로 활용했다. 실제 계획서 양식은 The One Page Project에서 제시한 방법, Scrum의 백로그 등을 몇 차례 개정하면서 만들어 쓰고 있다.

관련글: 스크럼(Scrum) 적용 일지