소프트웨어 개발방법론의 함정 [전규현]을 읽고서..

얼마전 ZDNet에서 "소프트웨어 개발방법론의 함정"
이란 컬럼을 읽었습니다.
(http://www.zdnet.co.kr/ArticleView.asp?artice_id=20091129180815)
꼭 블러그 읽어보시기 바라며 글을 보고 느낀점이 있어서
몇자 적고자 합니다.

• MNH는 프로젝트에서 꼭 사용합시다.

MNH뜻은 (Maven+Nexus+Hudson)를 축약한 제가 만든 용어
입니다. ^^
현재 프로젝트 사이트가 waterfall를 하던 agile을 하던 아니면
대기업에서 전설로 내려오는 일을 위한 일을 하는 방법론을
사용 하던 간에 이제 빌드 자동화에 대한 투자는 제발
좀 합시다.
빌드 자동화를 한다는 것은 사실 쉽지만은 않습니다.
(현재 제가 진행 하고 있는 프로젝트에서도 많은 시행착오를
경험하고 있습니다. ) 하지만 투자할 가치가 충분 합니다.
tomcat에서 개발한 프로그램이 다른 WAS에서도 잘 동작
하기를 바라는 생각을 한다면 큰코 다칩니다.
JAVA는 OS 독립적이지만 WAS에 의존적이란걸
아는 분들은 아실것입니다.
처음 부터 maven,nexus,hudson,track,mylyn..
다 적용하지 말고 step by step으로 하나씩
필드에서 적용 하시기 바랍니다.

• 전문적인 조직을 갖추자

대략 90년말 ~ 2003년까지는 막개발의 전성 시대라고
할 수있습니다. 조직에서 개발경험이 많은 사람이
개발 리딩 + 업무 리딩을 했습니다.
(혼자서 WAS 설치+DBMS 설치+모델링+프레임웍
+공통 모듈 완전 멀티플레이어)
심지어 SVN에 사용을 안해서 소스 엉키는 게
일이 였습니다.정말 한국인의 의지로 버틴 시절 이었습니다.
(그 때 생각하니 눈물이...)
하지만 지금은 그때와는 복잡도나 규모로 봤을때
엄청나게 변했습니다.
이제는 한국인의 의지가지고는 불가능하게 되었습니다.
하지만 아직도 우리나라 개발 회사들은
한국인의 의지를 믿고 있습니다.
그 믿음이 엄청난 손실로 돌아 오는 경우를
많이 경험 했습니다.
예를 들어서 어중간한 개발자 10명 보다 비즈니스 로직 7명+테크니컬 파트3명
구성된 조직이 더 생산성이 뛰어 납니다.
조직을 분업하고 서로 간의 협업을 통해서
프로젝트를 구성해야 한다고 생각합니다.

• 정치는 이제 그만

가끔 프로젝트를 하다보면 어떻게 하면 성공적으로 프로젝트를
완수하려는 것보다 다른 요인들이 더 중요하다고 생각할때가 있습니다.
예를 들어서 산으로 가고 있으면 이슈화해서 다시 방향을 잡아야지
뻔히 다른 방향으로 가고 있으면서도 이런저런 이유로
그냥 go 합니다.
정말 미치게 하는건 절벽으로 떨어질 걸 알고
간다는 거죠. 설마 죽기야 하겠어 하는
정신으로 말이죠.
그리고 어설픈 Lip Service는 제발 Shut Up!
상품 관리 파트 PL이 TA 파트에 와서 프레임웍 구성이
잘못된것 같다. 다른 비지니스로직 파트에 가서
업무 로직은 그렇게 하면 안된다. 참...
업무상 조언정도는 할 수 있지만 각 파트별
담당자 롤을 침범해서는 안된다고 생각 합니다.
대부분 이런 사람들이
"나는 멀티 플레이어야 나 이런 사람이야"
하고 쌩 PR을 하는 사람들이죠.
대부분 담배피면서 들은 얘기나 구글링을 해서
겉핥기만 하죠.
최신 트렌드 기사한줄 읽고 "그거 아세요?"
하면서 기선제압하는 사람들...
제발 우리 프로젝트만 집중 합시다.