프로토 타잎을 만드는 것이 그리 간단한 작업은 아닐것이다.
그러나 우리는 고객이 원하고 만들려고 하는 시스템이 무엇인지 알고 있었고  고객도 스스로 우리가 무엇을 할 수 있는지 알고 있었다.
따라서 우리는 아이템의 변경보다는 기존 시스템을 확장한 모델을 프로토타잎으로 만들었다.
지금은 다른회사에서 다른 일을 하고 있는 예전의 후배회사를 찾아가 다짜고짜 이번 사업이 이러하며 현재 하드웨어 구축중으로 내가 필요한것은 모션 인식을 바탕으로 운동량을 측정하는 게임이라고 설명하고 간단하게 만들어 달라고 부탁했다.
그러면 어떻게든 사업을 따와서 같이하자고 꼬신것이다.
이후에 토요일, 일요일에는 전모 사원과 함께 제안서 작업을 하고 위에는 제안서 작업이 마무리된때에 보고하였다.
그걸 왜하느냐? 부터 온갖 반응이 나왔지만 해야 한다고 우기고는 설득하기에 이르러 결국 설득이 완료되었을때 파트장이신 부장님을 내편으로 만들 수 있었다.
이때 연구소에서 헬스케어만 전문 연구하신 모 연구원의 도움이 매우 컸다.
이후 프로젝트 제안을 듣기위해 오신 미국 현지 법인 담당자 3분과의 미팅을 통해 짧게 나마 우리가 생각하는 비즈니스 모델을 설명하고 이렇게 만든다면 수익발생을 기대할 수 있다고 설득하였다.

문제는 우리회사의 인지도 였다. 한국 본사의 자회사와 같이 일하길 원했던 그들은 첫날 우리의 이야기를 들어 줬고.. (물론 숙소에 가서 아침에 납치해오다시피 하기도 했지만...)
2일째 오전에는 그 회사로 가서 설명을 들으신뒤에 다시 우리회사로 오셨다.
3분의 담당자중 1분은 이전의 프로토타잎 개발 PM으로써 우리의 역량을 알고 계신분이었고
나머지 2분중에 1분은 당시의 팀장님과 친구사이였던 덕에 다수결에 따라 우리가 사업을 획득하게 된다.

문제는 다음이다.
프로젝트의 규모가 지나치게 당시의 직급에 비해 커서 상급자가 PM으로 오게 되면서 방법론으로 수많은 언쟁과 설득이 오고가게 되었지만 결정적으로 BP사의 담당직원이 PMO의 승인없이 당사의 또 다른 BP사의 직원을 무단으로 휴가를 보내고 그것에 문제제기한 본인만 배제된체 프로젝트는 시작되었다.

이때가 시련의 시작이었던 것같다.
지나친 애자일 사랑(숭배)은 주변인에게 압박으로 다가가고 결국 그것이 나에게 독이 되었던 것이다.
그리고 결정적인 사건은 그에게 명분을 주는 역할 밖에는 되지 못했다.

이후에 현재 프로젝트의 프로토타잎 프로젝트에서 필요한 하드웨어를 납품하러 들어갔다가 그곳에서 어떤 일을 하는지 알고는 2007년 특허 등록을 위해 작성하였던 증강현실 프로토타잎을 꺼내들고는 급히 담당매니저를 다시 만나 설득하였다.

"단순히 하드웨어만 납품하는 것은 저를 낭비하는 것이니 옆에서 참관만이라도 할 수 있도록 해당 업체 룸에서 작업할 수 있도록 도와달라"는 내용이었다.
또한 "하드웨어만 하지 않고 궃은일도 맡겠다."는 개인적인 일욕심이 앞섰다.

담당 매니저님께서는 장시 고민하시고는 프로젝트의 참관과 일정 부분 맡아 달라는 말씀을 하셨고 프로젝트를 선듯 주셨다. (지금도 매우 고맙게 생각합니다.)

맡은 일은 간단했다.
증강현실에 사용될 테스트 장비의 선정과 카메라를 설치할 수 있는 크래들 만들기였다.

여기서도 애자일의 사상으로 접근하였다.

먼저 장비를 선정하는데 있어 주어진 요구사항은 "Nvidia 9800급 고사양 하드웨어이면서 작은것"으로 몇가지 타잎이 검토되었는데 문제는 크기를 웹에서 본다고 해서 그것을 가늠하고 결정하기 어렵다는 것이다.
실재 물건을 사올 수 있으면 좋으련만 한정된 예산으로는 무리였다.

그래서 생각한 것이 3면의 사진을 출력하여 제원표에 있는 그대로 "종이접기"한 것이다.
종이 접기한 본체의 크기를 보시자 금새 결정되었고 요구사항의 모호함은 사라졌다.
이어서 크래들이 문제였고 크래들은 기계공학과 출신 회사 선배들을 찾아가서 이리 저리 노하우를 습득하고 청계천과 종로 일대를 뒤지고 모형 사이트에서 얻은 Mockup 기술을 익혀나가 결국 3종류의 크래들을 완성하였다.

크래들을 먼저 보여드리고 각각 세세한 부분은 바로 그자리에서 드라이버와 벤치로 고쳐버리면서 그렇게 몇개월의 프로젝트를 고객의 만족을 받으면서 마쳤다.

이후 정식 프로젝트가 현재 추진하고 있는 프로젝트로 여러가지 시행착오는 있었지만 애자일하게 프로젝트를 수행하고 있기는 하다.

이제 정리 한번 해보자.

첫째, 애자일은 무엇인가에 대한 답이다.

애자일 선언에서는 다음과 같이 이야기한다.
프로세스나 도구에 앞서 개인과 상호 협력을
종합적인 문서화에 앞서 작동하는 소프트웨어를
계약 협상에 앞서 고객과의 협력을
계획 준수에 앞서 변화에 대한 대응을
우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다.

즉, 이터레이션만 두고 변화에 맞춰 계획을 변경하는 것이나 애자일 프래틱스를 잘 준수하는 것이나 CI툴을 통해 리팩토링하는 것이나 자동화된 문서 체계를 갖는 것이나 자동화된 테스트 체계를 갖는다고 해서 애자일이 아니다.
애자일은 상호간의 협력과 작동하는 제품, 변화에 따른 능동적인 계획변경과 실행인것이다.
다시말해 애자일은 "가치"와 "철학"이지 "정형화된 방법론"이 아니다.
지금까지 내가 걸어온 길이 애자일하다라고 할 수 있는 이유도 바로 상기 선언에 비추어 한점 부끄럼 없기 때문이다.
다시말해 지금 다른 사람들이 특히, 이글을 보는 분들중에서 자신의 팀이 애자일하지 않다고 할 수 있는 팀은 몇개나 될까?

둘째, 애자일을 어떻게 추진해야 하는가?에 대한 답이다.
애자일을 추진하기위해서 수많은 프래틱스를 수행하고 계획만 변경하면 될까?
흔히 대기업의 QA수준의 하향식 또는 상향식 애자일 수행은 내가 2009년 프로젝트에서 겪은 바와 같이 필연적으로 실패의 길로 갈 확률이 굉장히 높아진다.
애자일을 수행하기 앞서 나는 가장 먼저 해야 할 일이 바로
"사람에 대한 이해와 사람의 다름을 인정하고 사람을 존중해야 한다"고 생각한다.
그리고 매단계별 "회고"를 도입하기 바란다.

사람에 대한 이해와 사람의 다름을 인정하고 사람을 존중한다면 "개인과 고객과의 상호협력"을 이끌어 낼 수 있다.
스스로 변화되는 것이다.
또한 "진심으로 다가간다면 언젠가는 그 진심은 반드시 보답한다."는 사실을 믿어 주기 바란다.
이건 내 경험이자 내 주변인들의 경험이기도 하다.
현재 모 식품사의 영업팀 과장으로 10년이상을 수많은 고객을 만나는 동기의 이야기도 그러했다.
"처음에는 내가 진심으로 다가가도 고객은 달콤한 말을 하는 사람을 더 좋아했다. 그러나, 시간이 흐르자 결국 찾은 것은 나였다."
그 동기의 이야기는 거짓이 아니다.
실재로 수많은 사람들은 수많은 유형을 가지고 있고 대표적인 유형을 몇개 꼽자면 "정치형", "계산기형", "보스형" 등의 사람들이 있지만 결국 진정성은 모든 유형의 사람을 관통하는 힘이 있다.
단지 시간이 문제일 뿐이다.

따라서, 우리 애자일을 추진하는 사람들은 "사람을 대하는 Mind"를 먼저 가지고 주변인을 설득하는데 설득하려 들지 말라.

그저 하나의 일이 끝나고 나서 일을 주제로 한번 돌아보는 시간을 가져보라.
이건 일을 잘하고 협력하기 위한 첫단추 일뿐이다.
실재로 우리 개발업무를 맡고 있는 사람들의 전유물도 아니다.
병원에서 질병에 대해 다른 과의 의사분들과 토론하고 토의하는 장면을 드라마나 영화에서 종종 볼 수 있다.
사용자 삽입 이미지
영화에서 조종사들끼리 브리핑을 하고 임무 종료후에 디브리핑을 하는 것도 종종 볼 수 있다.
사용자 삽입 이미지
운동경기에서도 마찬가지이다.
우리는 실재로 볼 수 없지만 경기시작전 감독은 선수들과 이번 경기에 사용될 전술을 브리핑하고 작전 타임을 불러 계획을 변경하고 경기후에는 비디오 분석을 통해 디브리핑을 한다.
resize_image
이러한 목표 공유활동은 "문제를 인식"하고 "계획을 변경"할 수 있도록 하며 새로운 방법을 받아 들일 수 있도록 이해관계자를 "설득할 수 있는 기회"를 만들어 준다.

결국 애자일을 리딩하는 사람은 애자일하게 문제를 해결할 수 있고 스스로 원하는 변화를 만들 기회를 가질 수 있다.

가령 배포를 하고난후 난상토론을 통해 그간 업무 수행에서 어떤 점이 잘됐고 잘못된지만 제대로 공유되고 비난이 아닌 문제해결을 위한 회의를 통해 문제 해결 방법을 도출하거나 제안 할 수 있다.

실재로 내가 사용하고 있는 CI 툴인 HUDSON은 이러한 과정을 통해 도출된 아이디어였고 Doxygen도 마찬가지로 현장 실무자들의 아이디어였다.

단지 나는 그것을 채용하고 개발팀원 모두에게 공유했을 뿐이다.

마지막으로 기록하고 싶은 것은
"애자일 프래틱스 또는 도구는 아무것도 아니다. 애자일의 선언대로 그리고 회고를 통해 애자일을 추진하는 과정이 전부다."

애자일은 계획을 바뀌기에 중심을 두면 그것은 애자일이 아니라 그냥 잦은 계획 변경에 불과하고
애자일이 리팩토링에 중심을 두면 그것은 애자일이 아니라 그냥 잦은 배포에 불과하며
애자일이 기존 개발방법과 전혀 다르다고 생각하면 추진할 수 없는 문화이며
규모가 아주 작은 프로젝트라면 오히려 애자일보다 폭포수(Waterfall) 모델이 오히려 효과적일 수 있다.
마지막으로 인간은 감정의 동물이며 감정이 발단이 되어 논리를 만드는 동물임을 잊지말자.

따라서 개발 리더는 모두 알아야 한다. 그리고 상황에 맞게 적용해야 한다.
그것이 애자일 추친의 어려움이다.

=== 끝 ===
2010/07/09 01:11 2010/07/09 01:11

트랙백 주소 :: http://www.wolfpack.pe.kr/trackback/492