어제 지인과 식사도중 개발자의 실력에 대한 안철수씨의 강연내용 이야기가 나왔습니다. (이런 주제를 이야기 할 수 있는 지인이 있다는건 참 행복한 일이죠)

“현대는 한 사람의 천재가 모든 것을 할수 있는게 아니라 한 사람이 못할 일을 여러 전문가가 함께 모여 만들어가는 시대다”며 “전문가의 실력은 전문 지식 곱하기 커뮤니케이션 능력이다”

Source : “고단한 SW개발자 생태계, 그래도 희망은 있다” - http://goo.gl/i12Z7

전문지식 곱하기 커뮤니케이션 능력이 실력이라니~
개발자는 제대로된 기능을 만들기도 벅찬데, 커뮤니케이션 능력도 배양해야 한다니 쉬운일이 아닙니다.
게다가 현업에서 보면 A개발자와 B영업간에 "뭔 말이 통해야 말을하지~" 하는 푸념을 종종 듣습니다.
하지만, 대부분의 개발자는 자신이 커뮤니케이션 능력이 부족하다고 생각하지 않습니다. 상대방이 논리가 빈약하고 실체가 없는 모호한 대화방식이 아니라, 좀 다른 대화방식으로 이야기하기를 바라는것 뿐이죠 :-)

그럼 개발자와 대화를 이끌어내기 위해서는 어떻게 해야할까요?

얼마전 트위터에서 웃음을 자아냈던 공대생 남친 관리법(http://goo.gl/qvBUC)에서도 보이듯이, 개발자는 개발자스러운 대화방식으로 접근해야 커뮤니케이션이 가능합니다. 개발자는 자신이 이해가능한 합리적인 결과물에 대해서는 큰 이견을 제시하지 않는다는 특성을 가지고 있죠. 꼭 개발자가 아니라도 합리적 내용물을 기반으로 이야기하면 쉬운 대화가 가능합니다.

제 생각에 개발자와 대화하기 가장 좋은 방법은 애자일 실천법 중 하나인 CTIP(Continuous Test & Intergration Platform) 라고 생각됩니다. 지난 몇년간 Agile 기법에 대한 학습과 현업에서 적용결과, 저는 애자일의 핵심이 사람과의 소통인것을 얼마전에야 깨닫게 되었습니다.

혼자 개발하는 문화에 익숙한 개발자는 무엇인가 함께 만들어야만 하는 상황을 만나면, 구성원간 커뮤니케이션에 어려움을 겪습니다. 이때 CTIP를 통한 정적분석도구를 활용한 결과물과 코드커버리지, 그리고 이슈관리도구를 통하여 문제점을 가시화하고 합리적 결과에 기반한 개발자와의 대화를 시도하면 SW개발자와의 쉬운 대화가 가능합니다.

저는 SW개발의 생산성을 향상시키기 위한 최선의 방법은, 좋은 개발문화를 형성하여 개발자간 커뮤니케이션능력을 배양하고, 협업을 통한 시너지가 창출될 수 있도록 유도해주는 것이라고 생각합니다.


Source : 2011 한국소프트웨어 아키텍트 대회
<지속적 테스트와 통합을 위한 SW개발 아키텍처>


<이슈관리시스템을 통한 문제제기>


<위키를 이용한 문서협업>




<SW개발을 위한 공개SW 기반의 지속적 테스트와 통합 아키텍처>


그리고, Agile 2011 Conference가 8월6일 열린다고 합니다. http://pragmaticstory.com/1776 에 트랙에 대한 설명을 해주셨네요. 언젠가는  가 볼 기회가 있겠죠?  :-)

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

우리가 가장 중요하게 여기는 것은

제 시간에, 지속적으로 가치 있는 소프트웨어를 인도함으로

고객을 만족시키는 것이다.

방법론의 변천

1970년대가 되어서야 폭포수 방법론이 등장했고, C 4세대 언어 도구들이 등장한 80년대에는 생명주기 관점에서 소프트웨어 개발 방법을 바라보게 되었다. 90년대가 되어서 반복과 통합된 프로세스를 토대로 하는 RUP가 등장했고, 이를 계승한 컴포넌트 기반 방법론인 CBD가 현재 위세를 떨치고 있다.

이와는 다른 관점에서 나온 방법들이 있다. 카네기 멜론 소프트웨어 공학 연구소에서 나온 업무능력 성숙도 평가 기준(Capability Maturity Model; CMM)은 개발 프로세스 향상을 통해 성공적인 프로젝트 수행이 가능하다고 얘기하고 있고, 중소규모의 개발팀에 적용해서 큰 효과를 보고 있는 XP방법론이 유행하고 있고, XP와 뜻을 같이하는 여러 방법론들의 연합체인 애자일 방법론도 개발자들 사이에서 큰 흐름을 형성하고 있다.


eXtreme Programming (XP)

Kent Beck이 만든 방법론으로 기존의 개발 방법론은 위에서 아래로 진행하는 반면 XP방법론은 아래부터 위로 향하는 습성을 갖고 있다. 농담 삼아 하는 얘기인지 모르지만 프로젝트에서 갈 데까지 간 개발자들이 극한의 상황에서 살아남기 위해서 만들어졌기 때문에 extreme이라는 단어를 붙였다고 한다.

XP에서 얘기하는 내용을 보면 방법론이라기 보다는 개발자 개인 및 팀원 간의 습관이라고 보는 것도 무리가 없다. 그림 8.에서 제일 안쪽에 있는 원은 개인의 실천사항을 얘기하고 있고, 중간의 원은 팀원간의 실천사항을 표현하고 있다. 제일 바깥의 원은 전체 프로젝트에서 일어나는 실천사항을 표현한다.


사용자 스토리가 나오면 스파이크라고 하는 핵심 기술을 빨리 구현해서 보일 수 있는 시범 프로그램을 만들어서 기한내에 완성이 가능한 스토리인지 가늠해 본다. 그 이후 구체적인 계획을 잡고 개발을 하고, 최종적으로 사용자 스토리에 있는 내용을 테스트케이스로 잡아서 고객의 인수테스트를 통과하면 작은 배포버전을 만든다. 보통 이 기간을 2주로 잡고 있으며 2주마다 기능을 추가해서 동작하는 소프트웨어를 만들어간다. 물론 처음에는 아주 기본적이고, 핵심적인 프로그램으로 시작하고, 2주 분량의 기능만 추가해서 진행하기 때문에, 고객은 진행되는 일의 산출물을 보면서 안도하고, 개발자는 동작하는 프로그램의 배포에서 꾸준한 성취감과 동기부여를 얻을 수 있다.

+ Recent posts