TOC 화들짝 하게 했던 그 이야기.

TOC 화들짝 하게 했던 그 이야기가 NHN 개인커뮤니티팀과 애자일 가 여기서도 등장합니다. 강력한 추천 도서인 The Goal 과 함께 말이죠.

전 The Goal 을 너무 재미있게 읽어서 연속 세번을 읽었습니다. 그 다음 씨리즈인 It's not luck 과 Necessary But not sufficient 까지도요.

부분최적화는 순간에는 좋아 보일지 모르지만 전체적으로는 크게 도움이 되지 않습니다. 게다가 최적화라는 환상에 사로잡혀 정작 중요한 다른 것이나 그 최적화가 부른 다른 병목들을 감지 못하게되는것 같습니다.

SI 프로젝트에서도.. 우리 회사에서도.. 개발에 정말 많은 최적화 - 툴, 방법론 등등 - 을 하는 것 같지만 정작 중요한 고객이 원하는 소프트웨어를 약속한 시기에 딜리버리하기 위한 전체 프로세스에 대한 고려는 좀 적지 않나 합니다.

분리된 분석/설계단계는 정확할 수 없고 나중에 가면 대부분 바뀌거나 변경된다는 인식을 많은 사람들 (윗분들도!!)하고 있으면서도 정작 개발부분에서 만회하자는 생각인건지 아니면 분석/설계는 이만하면 됐으니 개발부분을 손대보자 하는 것인지 모르겠습니다. ㅎㅎ
예전부터 느꼈던 것지만 너무 문장의 표면적인 의미에만 집중하는 것 같기도 하구요(갑자기 또 회사를 씹기 시작합니다 ㅎㅎ). continuous integration 이라는 문장과 그때 뭘쓰더라라는 것에만 포커스를 맞추고 그저 툴의 보급만을 힘쓰는 회사를 보면서 "진짜는 그게 아니라, 툴 따위는 없어도 단순한 쉘 스크립트로 빌드/릴리즈 프로세스를 구축하더라도 지속적으로 여러 코드를 통합하고 테스트해서 문제점을 조기에 발견하고 더 커져서 빚 더미에 깔리기 전에 해결하자. 덤으로 언제든지 최신 버전의 시스템을 별로 오랜 시간이 걸리지 않고도 릴리즈 할 수 있는 의식(!!)을 전파하자. 더 나아가 분석/설계/개발로 전체 프로세스를 나누었던 기존의 방법을 매 통합마다 할 수 있는 기민한 프로세스로 진화해가자!!" 라고 외치고 싶습니다.

소심해서 못 외치죠. -_-a