회사에서 글을 하나 적으라고 해서, 적다보니 아래와 같은 글이 되어버렸습니다.
한번씩 읽어보시고 생각하시는 바를 답글로 부탁드립니다. 제게 많은 도움이 될 것입니다.
-----------------------------------------------------------------------------------------
* Agile과 프로젝트의 현실
고객 만족이란 무엇일까? 지난 프로젝트에서 난 매우 슬픈 경험을 했다.
Agile 프로세스를 프로젝트에 적용하여, 2주마다 고객의 검토를 받고 고객의 눈높이에 맞는
제품을 만들었으며, 그들의 참여를 유도했다. 지난 4번의 프로젝트에서 적극적이지 않았던 그들이 변화하는 것을 보면서, 난 매우 기뻤다.
고객과의 협동은 어느때보다 좋았으며, 모든 것이 훌륭했다. 하지만, 중반 이후, 문제가 터지기 시작했다. 고객사의 상위기관에서 기존에 2주마다 검토한 모든 내용에 대해
문제를 제기했다. 또한 실 사용자들 또한 이미 검토된 내용에 대해 신뢰하지 않았다. 결국 우리는 또다시 요구사항을 받아들일 수 밖에 없었다.
어떤 파트는 최초 요구사항에 2배나 더 되는 요구사항을 추가로 작업 할 수 밖에 없었다. 작업한 내용을 확인했던 고객은 언제 그랬냐는 듯 나몰라라 발을 뺐다.
결국, Agile은 수행했지만 더 힘든 프로젝트가 되어 버렸다. 프로젝트 후반, 2주 동안에개발자들은 과거 어느 때보다 보다 많은 작업을 완료해야 했다. 당시에는 정말이지 기운이 빠졌다.
또한 고객도 "우리도 어쩔 수 없다" 라는 말을 되풀이하여, 일정과 시간으로 프로젝트를 압박했다. 말 그대로 프로젝트의 어느 누구도 행복하지 않은 상황이었다.
하지만, 신기한 일이 일어났다. 프로젝트가 종료하고 고객 모두가 칭찬 일색으로 프로젝트를 띄워주기 시작했다. 그 계기는 IFSS도, Agile도, PM의 멋진 완료 보고도,
상위기관의 시원한 의사결정도, 개발자의 훌륭한 생산성도, 품질도 아니었다. 단지 종료보고 하루전, 한 PL이 만든 99장의 PPT 자료 덕분이었다.
하루만에 나온 그 99장의 PPT를 말그대로 고객을 감격 시켰다. 고객은 그 PPT를 여기저기 들고 다니며, 개발팀을 치켜세웠다. 또한 자신이 얼마나 관리를 잘했는지
PR하고 다녔다.
[학부모 서비스 프로젝트의 애자일 회고]
도대체 무엇이 문제였을까? 모든 것이 훌륭해 보였다.
Agile은 기존 일하는 방법에 비해 무척 팬시해 보인다. 모든 낭비를 제거한 프로세스, 서양에서 유행하는 선진 프로세스, 즐겁게 일하는 개발팀,
본인이 가진 문제점에 대해 항상 도움을 줄 수 있는 팀원, 효율을 위해 시간제한(Timebox)이 있는 실천방법들, 보다 나은 팀을 만들기 위한 회고,
게다가 주 40시간 근무 까지 Agile에서 사용하는 모든 수식어들은 마치 우리가 현재 일하는 곳을 다른 세계로 만들어 줄 것 같은 환상을 심어 주기 충분하다.
하지만, 우리가 항상 접하는 IT 현실은 호락호락하지 않다.
사실 Agile은 방법론이라고 이야기하기도 쉽지 않다. 우리가 아는 기존의 방법론은
어떤 역할의 사람이 어떤 단계에서 무슨일을 하는지 매뉴얼에 나와있어야 한다. 하지만, Agile은 스탠드 업 미팅같은 프랙티스들의 틀 안에서 이것을 사람의 자율에 맡긴다. 기존에 우리가 가진 잣대로 Agile을 바라보면, 물음표가 열 개정도 필요하다. 난 현재 수행하는 프로젝트에서 Agile을 방법론화 해보기 위해 노력하고 있다. 하지만, 나는 이 시도가 좀 위험해 보인다. 추정에 시간을 쏟다보면 어느 시점 부터는 시간을 쏟을수록 추정이 더부정확해 지듯이,
너무나 다양한 요소들을 고려하여 그 틀을 만들었을때, "자율과 신뢰" 라는 가장 중요한 Agile의 테마가 깨져 버릴 수도 있다. 필요한 수준까지만 이를 정리하고 싶지만, 그렇게 한다면 아마도 기존의 방법론을 옹호하는 사람들과의
차이를 줄이기는 쉽지 않을 것이다. (이러한 시도들은 많이 있어왔다. 대표적으로 Scott W. Ambler 가 Agile을 RUP와 결합시킨 http://agilemodeling.com/ 같은 케이스가 있다.)
먼저, 기존 Agile에서 이야기하는 역할자들이 우리 프로젝트 현실에서 어떤 한계를 갖게 되는지 이야기 해 보고 싶다.
첫번째로 Agile에서 말하는 Product Owner 는 보통 사용자가 원하는 화면을 그릴 수 없는 것은 물론이거니와 기능에 대해 설명해 줄 수도 없다. 게다가 이 Product Owner 는
본인이 검수 담당자 이지만, 본인이 검수를 할때 자신이 속한 기관의 상위기관 또는 하위기관의 사용자의 의견을 무시하고 검수할 수가 없다.
항상 책임을 지기 어려운 상황에 놓여있다. 프로젝트에서 무엇인가 의사결정을 원할 때 그 결정을 내리기 위해 많은 시간이 소모되기 일쑤이다. 그러다보면,
자연스레 시간은 소모되고 Product Owner는 결정권자가 아닌 병목(bottle neck)이 되어버린다. 의사결정권자가 애물단지로 전락하는 순간이다.
두번째로, Scrum Master에게 팀을 최대한 보호해 줄 권한이 없다. (본래Scrum Master는 Iteration 기간 동안 외부의 압력으로부터 팀을 보호한다. 팀이 일에만 집중 할 수 있도록
만들 수 있어야 한다. 또한 개발팀이 해결할 수 없는 문제점에 대해 해결하거나, 해결할 수 있도록 노려해야 한다.)과연 이 역할이 누구에게 가능하리란 말인가?
마지막으로 , Cross Functional 팀(역할자 별 리더를 중심으로 단계별 모든 작업을 함께 수행하는 팀)을 만들 수 없다. 현실은 그렇지 않지만 대부분의 개발팀은 설계, 개발자의 분리를 지향한다.
다양한 이해관계에 의해 설계자는 개발을 수행하기 거부하고, 개발자는 설계를 수행하길 원하지 않는다. (실제로 설계자와 개발자를 분리하려는 시도는 회사차원에서 볼 때 여러가지 이익을
가져올 수도 있다. 북미의 많은 IT회사들이 이를 이용하여, Off-shore Development 라는 것을 수행 하고 있다.) Agile에서 이야기하는 Cross Functional 팀을 조직하기에는 우리의 현실이
차갑기만 하다.
위와 같은 역할자별 한계를 벗어나, 환경적인 요인을 살펴본다면,
PMBOK에서 이야기하는 Quality를 이루는 3요소 즉 비용, 시간, 일의 범위는 정삼각형이 되는 일은 존재하지 않는다. Agile에서 모든 프랙티스가 이루어지기 위한 행복한 환경은 꿈같은 이야기로 느껴진다.제약 조건이 Scope 에서 비용과 스케줄로 변경되는 패러다임의 변화. 즉, 고객이 원하는 가치에 따라 처음 정했던 기능이 늘어나기도,
줄어들이도 하는 변화는 쉬이 일어나지 않는다. 아니, 보다 정확히 말하면 늘어나기는 한다. 궁극적으로 개발하기로 했던 기능을 잘라내는 결정은 고객을 설득하여
수행하기 매우 어렵다. 차리리 거한 술과 비싼 밥을 먹이고 고객이 좋아하는 노래를 불러 주는 것이 보다 효과적일지도 모른다.
[애자일의 패더다임 쉬프트 출처 : http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=10365&tth=DYN&tt=siteemail&iDyn=2]
위와 같은 역할별 제약 조건과 환경 때문에, Agile 을 시도하려는 여러가지 시도는 이상을 좇는 뜬구름 잡는 이야기로 치부되기 일쑤다.
하지만, 현실에서 이를 가지고 프로젝트에 접근하는 것은 의외로 매우 쉽다. Agile은 우리의 PM들이 듣고 싶어하는 이야기를 하기 때문이다.
"낭비를 제거한다(Lean Software development)", "필요한 만큼(Barely Enough)의 문서를 작성한다(XP)"라는 말을 우리의 PM들이 10년 이상 프로젝트를 수행하며 몸으로 느끼는
"일부를 제외한 모든 문서는 소용이 없다"라고 생각하는 PM들에게 가뭄뒤 단비같은 존재다. 게다가 다양한 상황에 적용하기도 정말 편리하다. "현실에 적응(Adoptation)해 나간다" 라는 개념은, Agile은 어떤 상황에서도 통하는 Silver Bullet이라고
받아들이도록 한다. Agile이 문서가 없다 라고 생각하는 것은 매우 위험한 오해이다. Agile 또한 정보공학을 기반으로 한다. 줄이자는 것이지, 하지 말자는 것이 아니란 뜻이다.
위에 언급한 문제점들과 오해로 인해 적용하기 쉬운 프로세스라는 현실들을 알고 있지만, 이런 현실에도 불구하고 난 Agile이 우리 Software 개발 산업의 미래라는 생각에는 변함이 없다.
그 이유는 다음과 같다.
첫번째로 Agile은 보다 현실에 가까운 접근 방법을 준다. 하드웨어 제품을 만들때처럼 전체 공정을 자동화하는 라인을 만드는 것이 불가능한 소프트웨어 공정에서 소프트웨어의 특성을 인정하고, 사람이 존재한다는
것을 배려하며, 그들 사이의 관계를 보다 사람관계 답게 만드는 것, 그것이 바로 Agile이다. 기존의 방법론의 메뉴얼에 나와있는 내용 처럼 "설계자는 설계 단계에서 물리 모델링을 모델링 툴을
이용하여 작업해야 한다"라는 접근보다 "담당자는 설계를 수행할때 상황에 따라 고객을 포함한 팀과 논의하여 기능 중심으로 작업해야 한다" 라고 말하는 것이 보다 현실에 맞지 않는가?
전자는 과학적인 관리법을 제안한 테일러식(Taylor, Frederick Winslow, 1856 ~ 1915) 접근 방법이다.
[교과부 나이스 유지보수팀의 회고]
두번째로 Agile은 돈만 주고 나몰라라 하는 고객을 의무와 책임의 함정으로 몰아 세운다. 계획 단계부터 팀의 일거수 일투족을 팀과 함께 보고 토의하고 느끼게 만드는 실천법들은
고객을 팀의 일부로 끌어들이고, 감시자(Inspector)역할에서 프로젝트의 도우미(Helper)역할로 바꿔준다.이것은 커다란 패러다임의 변화이다. 더이상 우리는 고객을 경계하지 않아도 되고,
프로젝트 성공이라는 공동의 목표를 향해
그들과 함께 고민 할 수 있다. 하지만 이를 위하여, 프로젝트 초기에 고객에게 그 역할을 수행하도록 만드는 것은 PM을 포함한 프로젝트의 몫이다. 지난 프로젝트에서는 이터레이션을 수행하면서, 중간 중간에 상위기관의 고객과 실 사용자의 의견을 듣는 것을 수행하지 않았다. 이것이 커다란 위험을 초래했다.
[학부모 서비스 프로젝트의 고객 시연]
세번째로 Agile은 팀내에서 돕는 것을 당연하게 만든다. 스탠드업 미팅은 팀원끼리 서로의 상태를 확인하고 어려운 점을 돕기 위한 자리이다. 대부분의 프로젝트에서 업무가 명확히 분리된 개발자들 사이에
"서로 도와라" 라고 말하는 것은 쉽지 않다. 개발자들은 마치 생전 처음본 이성과 "서로 사랑해라" 라고 말하는 것과 비슷하게 느낄 것이다. 그만큼 자신의 일에 좇기는 사람들에게 서로를 돕게 만드는 것은 어렵다
게다가 6~8년정도 경력이 찬 개발자들은 대부분 "모른다" 라는 말을 매우 꺼려한다. 혼자서 문제를 안고 가다가 그 사람을 믿던 관리자들의
발등을 찍는 경우가 빈번하다. 쉬운 이야기를 상대방과 아무렇지 않게 나눌 수 있다는 것은 곧 어려운 이야기 또한 꺼낼 수 있게 만든다. 점증적인 방법으로 사람과 사람 사이의 방어막을 걷어낸다.
네번째로 프로젝트 담당자들에게 신뢰를 심어준다. 관리자에게는 한 명, 한 명을 관리하고 싶은 욕심을 걷어낸다. 누가 무엇을 하는지 물어보지 않아도 알 수 있기 때문이다. 또한 관리를 하기위한 데이터를
제공한다. "다음과 같은 상황이기 때문에, 내가 이렇게 해야 팀에 더 도움이 될 것이다" 라는 관리의 정당한 이유를 만든다. 또한 개발자들에게는 "Iteration 기간 동안 내가 열심히 일하고 있으니 건드리지 마시오"
라는 간판을 벽에 달고 있는 현실을 만든다. 때문에, 작업이 할당되어 있는 개발자에게 관리자가 부가적인 작업을 요청하고 싶다면, 모두가 납득할 수 있는 훌륭한 이유를 준비해야 한다. 과거처럼 묻지마
"그냥 해" 방식은 관리를 못하는 것을 증명하는 꼴이 된다. 또한 사람은 힘든 일을 겪고 있을때 현실보다 보다 부정적으로 생각하는 경향이 있다. 명확하게 자신이 할일을 눈에 보이게 하는 일은 사람의 마음을 안정시킨다.
마지막으로 Agile은 쉽게 시작할 수 있다.이를 준비하는데, 매뉴얼을 읽어보거나 문서를 사전에 작성해야 하는 일등은 일어나지 않는다. 그저 고객이 승인하면, Agile을 경험한 코치 한 명과 함께 해보면 된다.(물론 우리 주위에 그런 코치가 별로 없다.)
"고객에게는 제품을 빨리 보여줄테지만, 대신에 처음엔 좀 당신 기대에 못미칠 것이다. 앞으로 당신 이야기를 듣고 점점 반영해 나가겠다. 대신에 우리좀 많이 도와줘라" 라고 하면 된다.
이터레이션마다 현재 상태가 문제가 있다고 팀이 판단한다면 팀이 모두 함께 이야기하여 그 문제점을 개선한다. 극단적으로 이터레이션이 짧지 않은 한 이 모든 것은 프로젝트 대부분 사람들에게 도움이 된다.
물론, Agile 이라는 것이 유행 일 수도 있다. 이미 북미에서는 일부에서 Agile에 대한 회의론이 일고 있으며, 실질적으로 현재 상태의 Agile에 대한 심각한 토의들이 일어나고 있다. 하지만, 과거 우리의 철학들이 그래 왔듯이,
Agile은 우리가 일하는 환경을 "사람이 사는 곳" 처럼 만들기 위한 고민 중 한 가지라고 생각한다. 어느 순간 잊어버리거나 책에만 적어놓아 멀어진 사람사이의 가치 즉, 커뮤니케이션과 호흡의 중요성을 Agile이 다시금 깨우쳐 주고 있다.
Agile을 통하거나, 통하지 않거나 "사람이 사는 곳"을 만들기 위해 항상 고민해 보는 것은 커다란 가치가 있지 않을까?
최근 덧글