오픈비 : 삽질은없다

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

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

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

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

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

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

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

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

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

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

원문 : http://www.javaworld.com/javaworld/jw-12-2008/jw-12-hudson-ci.html



지속적인 통합(CI)?
소프트웨어 빌드를 만들어내는 절차를 쉽게 하고 안정화 하기 위한 실천방법들의 세트.
CI는 아래와 같은 난관이 있는 개발팀을 도와준다

소프트웨어 빌드 자동화
당신은 버튼을 하나 누른다던가, 혹은 미리 일정을 정해놓고, 그것도 아니면 특정한 이벤트에 대한 반응 같은 식으로 CI를 이용해서 어떤 소프트웨어 구조물(이하 아티팩트, Artifact)의 빌드 프로세스를 실행시킬 수 있다. 만일 당신이 소스로부터 아티팩트를 빌드하고자 할 때, 당신의 빌드 프로세스는 특정 IDE나 컴퓨터, 혹은 특정인에 속박되지 않게 된다. (당연히 속박되어서는 안 된다.)

지속적이고 자동화된 빌드 검증
CI 시스템은 새로운 소스코드나 수정된 소스코드가 체크인 될때마다 끊임없이 빌드가 실행되도록 설정될 수 있다. 이 말은, 어떤 소프트웨어 개발팀이 주기적으로 신규 코드나 수정된 코드를 체크인 하는 동안, CI 시스템이 새로운 코드가 빌드를 깨뜨리는지의 여부를 지속적으로 검증할 수 있다는 뜻이다. 이로인해 개발자들이 상호의존적인 컴포넌트들의 변경에 대해 각각 점검해야만 하는 필요성을 줄여준다.

지속적이고 자동화된 빌드 테스트
빌드 검증의 확장에 해당하는 이 프로세스는, 신규 코드나 수정된 코드가 미리 정의된 빌드 아티팩트의 테스트 스위트 실패를 일으키지 않는다는 것을 보증해 준다. 실패(Failures)는 빌드 검증과 테스트 둘 다에 있어 해당 작업이 실패했다는 '통지(notification)'를 관련 부서들에게 보내게 되는 방아쇠(...trigger)가 된다.

빌드 후속 절차 자동화
한 소프트웨어 아티팩트의 빌드 생명주기에서는 빌드 검증과 테스트가 완료된 다음에도 문서 생성, 소프트웨어 패키징, 그리고 해당 아티팩트들을 실행환경이나 소프트웨어 저장소로 전개(deploy)하는 것 같은 자동화될 수 있는 추가적인 작업이 필요할 수 도 있다. 이런 형태로 아티팩트들이 사용자들이 사용할 수 있도록 신속히 만들어 질 수 있다.