[Agile] 대규모 집단에서의 애지일개발방식 적용에 대한 고민

대규모 소프트웨어를 개발을 위해,

노련한 개발자들이 치밀한 계획을 수립한다고 해도,

계획을 구성하는 각각의 요소들이 조금씩 틀어지기 마련입니다.

스펙, 일정, 역할, 인원, 우선순위, 작업방식, 리더, 구성원...

바뀌지 않는 것은 '계획이 틀림없이 바뀔 것이다'라는 구성원들의 믿음 정도일 겁니다.

계획을 수립하는 순간,

매일매일 계획이 틀어지는 것을 지켜보는 것은 상당한 스트레스입니다.

그래서 아예 계획보다 변화에 대응하라고 조언하는 애자일 선언문이 더욱 그럴듯해 보입니다.

http://agilemanifesto.org/

위의 선언문은 2001년 미국 유타주에서 개발자 몇 명이 만든 애자일 소프트웨어 개발 선언입니다.

미국에서는 14년 전에 나왔고,

한국에서는 2000년대 중반에 소개되었습니다.

http://agilemanifesto.org/iso/ko/

위의 사이트에서 한국어버전도 찾아볼 수 있습니다.

영어, 한국어 말고도 온갖 언어로 번역되어 있습니다.

그만큼 여러 나라에서 인기를 끌고 있다는 것이겠지요.

애자일이 강조하는 요소는,

- 개인과 상호작용

- 소프트웨어 자체

- 고객과 협력

- 변화에 대응

위의 구문들만 보면 문제될 것은 없습니다.

하지만, 위의 요소를 기존에 중요하다고 여긴 가치와 비교하여 좀 더 파괴력을 가졌지요.

- 공정과 도구

- 문서

- 계약협상

- 계획

위의 단어들은 프로젝트를 진행할때 너무나 중요한 단어들입니다.

저 단어들과 상반되는 룰을 프로젝트에 적용하는 것은,

프로젝트를 위험에 빠뜨리는 무모한 요인처럼 느껴질 수도 있습니다.

물론, 고작 열 손가락 안에 드는 인원으로 개발하는 프로젝트에는,

아무 어려움 없이 무모하게 스크럼을 짜서 스프린트할 수 있습니다.

(스크럼이나 스프린트는 http://storycompiler.tistory.com/137 참고)

실제로 스크럼을 짜서 업무성과가 수직상승한 예는 주변에 널려 있습니다.

하지만, 대규모 프로젝트에서도 가능할까요?

막강한 의사결정권자와 촘촘한 중간관리자가 포진해있는 관료조직은,

정형화된 조직구조와 고착화된 시스템운용방식이 있을텐데요,

애자일 개발방법으로 전환하면 여러가지 파격적인 시도들이 이뤄질 겁니다.

우선 거대 프로젝트를 많아야 열명 남짓한 작은 프로젝트 수십개 혹은 수백개로 쪼개는게 좋겠네요.

그리고 각 프로젝트 별로 참여자를 뽑아야겠죠.

(뽑는 방식을 고민하는 것도 즐거운 일이겠네요)

그 중에는 디자이너와 개발자와 평가자가 한팀이 되어 활동하는 프로젝트도 있을테고,

고객이나 경영자가 한 팀으로 참여한 프로젝트도 있겠죠.

이런 방식으로 문제에 기민하게 대응하게 되어,

좀 더 좋은 소프트웨어를 개발할 확률이 높아집니다.

물론, 팀은 해체되고 조직의 구성원이 뒤죽박죽이 되니,

인사권이나 평가권에 큰 변화가 있겠네요.

각각의 프로젝트에는 독립적인 위상이 부여되고,

일방적인 명령하달에 의한 개발우선순위 변경은 없어져야 할 겁니다.

프로젝트의 운명을 결정하는 것은,

프로젝트에 참여하는 사람들에게 주어질 것입니다.

프로젝트에 대해 가장 잘 아는 사람에게 결정권을 주면,

좀 더 좋은 소프트웨어를 개발할 확률이 높아진다고 믿습니다.

연중 계획은 의미가 없어지고, 매달 계획이나 그보다 작은 단위의 계획과 실천이 중요하겠죠.

개략적인 방향으로서 연중 계획은 필요하겠지요.

수많은 프로젝트가 함께 유기적으로 행동해야하는 경우라면,

일정과 내용에 대해서는 모두의 합의가 있어야하니까요.

하지만, 세부적인 계획과 실천은 짧은 사이클을 타며 기민하게 동작하는게 좋겠죠.

그 편이 좀 더 유연한 소프트웨어를 개발할 확률이 높아질테니까요.

중간관리자의 역할은 여러가지 측면에서 바뀔지도 모르겠네요.

프로젝트에 직접 참여하는 중간관리자는,

노련한 개발자로서 활동하게 되겠지요.

아키텍쳐를 그리고 코딩을 하면서 프로젝트에 직접적으로 기여할겁니다.

프로젝트를 관리하는 중간관리자는,

다수의 프로젝트의 애로사항을 체크하여 개발에 장애가 되는 요소를 없애줘야겠지요.

그렇게 해야 소프트웨어 개발에 박차를 가할 수 있겠지요.

평가는 프로젝트에 참여한 사람들이 다면적으로 진행할 수 있겠네요.

프로젝트의 성공을 위해 다음에도 함께하고 싶은 사람이 있을테고,

반대로 함께하면 안되는 사람도 여실히 드러날 수 있습니다.

언제나 평가와 관련된 부분은 조심할 수 밖에 없기 때문에,

여기서 함부로 논의할만한 주제는 아닌 것 같네요.

하지만, 어쨌든 프로젝트가 끝나고 다음 프로젝트가 계속될 때도 함께한다면,

그 구성원은 서로를 신뢰하고 믿는다는 증거이겠죠.

대규모 프로젝트에 언제나 완벽한 판단을 하는 천재가 있다면,

그 사람의 견해를 언제나 따르면 됩니다.

하지만, 그런 사람이 없다면,

수평적인 의견을 종합하여 의사결정을 하는 방법도 고민해봐야합니다.

대규모 프로젝트에 있는 수많은 소규모 프로젝트의 구성원 모두가 의사결정에 보탬이 되면 좋겠죠.

투명한 정보공개에 자유로운 의사표현이 더해져,

좀 더 나온 결과를 선택하여 더 나은 소프트웨어를 개발할 확률이 높아지겠죠.

어쨌든 대규모 프로젝트에 애자일을 적용하는 것은 쉬워보이지 않습니다.

특히 관료화된 집단에는 집단의 이익과 대치되는 변화가 필연적으로 따라오기 때문에,

자기파괴를 통한 재탄생이 쉽지만은 않겠죠.

성공적으로 거대집단에 애자일 프로세스를 적용한 사례를 찾아봐야겠네요.

각각 집단의 관습에 따라 수많은 수정버전이 있겠군요.

이 모든게 더 나은 소프트웨어를 만들기 위한 고민이라고 생각합니다.

고민의 결과를 조금씩 실생활에 적용해보고 시행착오를 겪으면,

경험적으로 더 나은 방법을 찾을 수 있으리라 생각합니다.

끝_