월간 웹 2007년 5월호 기획자 컬럼에 정현주님의 글이 실렸네요. 애자일을 언급하신 부분이 있어서 부분 인용을 합니다.
그렇다면, 나를 둘러싼 기획/개발자들은 어찌하여 협업을 본인을 규정하는데 과감하게 들여오게 되었을까? 곰곰이 이를 따져보니 근 1년 동안 우리가 '애자일'이라는 협업의 언어를 체득하게 되었다는 데 생각이 미치게 되었다. 내가 정의하는 애자일이란 '서비스를 만들기 위해 모인 사람들이 공통의 언어를 사용해 서비스 가치를 정의하고 측정하고 개발하는 방법'인데, 여기에는 서비스를 사용하게 될 이용자까지 포함한다. 작년 이 즈음, 블로그 기획 개발자가 모두 모여 상대에 대해 칭찬하고 싶은 점, 고쳐주었으면 하는 점을 이야기하고 개발이 진행되는 단위 단위마다 공유할 수 있는 형식을 세우고 실행을 약속했는데 그것이 어느새 1년이 지난 것이다.
처음에는 낯선 형식이 속도를 제한할 뿐 아무런 가치를 주지 못하고 있다고 생각하기도 했지만 '업무를 주 단위로 쪼갠다', '주 단위로 진행속도를 체크한다', '사용자가 경험하는 가치로 개발단위를 구분한다' 등의 약속한 '형식'을 지켜가다 보니 좋은 서비스라는 가치를 얻게 되었고 서로간에 '신뢰하는 마음'을 갖게 되었고 그래서 본인의 직업적 정체성을 그와 같이 표현하게 되었다고 내 마음대로(?) 뿌듯해 하면서 해석해 보았다.
--정현주, 월간 웹 2007년 5월호 p.40
보통 사람들은 생각하기에 소프트웨어 조직의 최대 병목은 개발 속도라고 생각하기 쉽습니다. 저도 예전엔 그렇다고 믿었습니다. 그런데 경험을 하다보니 그렇지 않은 경우도 많았습니다. 오히려 최대 병목은 개발 속도나 기획 속도 등 단일한 기능조직 내에서의 속도가 아니라 개발과 기획의 연결 고리에서 찾을 수 있었습니다.
제약조건 이론(TOC)이라는 것이 있습니다. 간단하게 말하면 쇠사슬의 강도는 그 쇠사슬에서 가장 약한 연결고리가 결정한다는 이야기입니다. 여러개의 고리 중 하나가 플라스틱으로 되어 있다면 다른 나머지를 모두 강철로 바꾼다고 해도 전체 강도는 나아지지 않습니다. (제약조건 이론의 입문 서적으로는 "더 골"을 권합니다. 너무 재미있어서 밤샘을 할지도 모르니 조심하시길.)
(이미지 출처는 알라딘)
바꿔말하자면, 개발팀의 속도가 최대 병목이 아닌데 그 팀의 속도를 높히는 것이 조직의 성과에는 크게 도움이 되지 않는 상황이 종종 있었다는 것이죠. 그래서 저는 이제 어떤 소프트웨어 개발 조직을 처음 컨설팅할 때 "기술적 문제"라고 클라이언트가 이야기를 해도 우선은 의심을 해봅니다. 정말 개발팀의 기술적 문제이고 개발 속도의 문제일까. (물론 개발 속도가 빨라지면 조직이 더 많은 학습을 더 빨리 할 수 있다는 장점이 있긴 하나, 충분 조건은 아닙니다. 개발 속도가 빨라지는 것이 조직의 학습으로 직결되지 못하는 조직이 많습니다.)
그런데 TOC 이론에서는 현 시스템의 최고 병목을 해결하고 나면 끝이 아니고, 새로운 전체 병목이 부상한다고 말합니다. 그래서 항상 시스템의 병목을 찾고 해결하는 노력을 놓치지 말아야 한다고 합니다. 분명 개인커뮤니티팀도 새로운 병목들을 만났을 것이고 그 병목을 해결하느라 땀을 흘리고 있으리라 생각합니다.
개인커뮤니티팀이 지금까지 보여준 성과를 바탕으로 앞으로도 더 많은 성장과 발전을 기대하겠습니다. 화이팅!
--김창준