본문 바로가기
실용주의프로그래머

Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드

by redcrow 2008. 4. 13.
Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드
(원제 : Ship it! : a practical guide to successful software projects )
 
자레드 리차드슨, 윌리엄 그월트니 주니어| 최재훈 역| 위키북스| 2007.08.09 | 270p | ISBN : 9788995856468
===================================================================================================

요즘 많이 번역되는 실용주의 책(사실 실용주의관점의 책이 나오기 시작한 것은 외국도 우리나라와 별반 다르지 않습니다)들을 읽다보면 다들 느끼시는 것이겠지만  특별한 내용이라고 생각되는건 책 전체에서 몇 꼭지 되지 않는것처럼 보입니다. 그래서인지 몇몇 책들의 서평에서 너무 쉽다는 말이 자주 보이기도 합니다.
이 책의 경우 '실용주의 프로그래머'와는 다른 책이지만 일정부분 겹치는 이미지가 있어서이기 때문인지도 모르겠습니다.

그 이유를 곰곰히 생각해보면 몇가지 오해가 있기 때문인것 같습니다.

첫번째 이유는 누구나 공감하는 문제이기 때문입니다.
책 내용자체가 현장에서 겪는 문제들을 해결하기 위해 실제 적용한 방법들을 기술한 내용이기 때문에 쉽게 공감하고 쉽게 읽혀집니다. 책마다 다르겠지만 이 책의 경우 넉넉잡아 두시간이면 다 읽을 수 있습니다.
하지만 한번이라도 저자가 제시하는 내용을 적용하려는 시도를 해본 사람들은 이게 읽는것처럼 간단한 문제가 아니라는것을 곧 알게 됩니다.
기존 프로세스를 변경할 때의 일어나는 관리조직과의 불협화음, 참여구성원들의 반발등 단순한 변화임에도 불구하고 넘어야 할 산이 한두개가 아니기 때문이죠.
그렇다고 그 산만 넘는다고 평지가 펼쳐질지는 적용하려는 본인도 확신할 수 없습니다.

두번째는 이론이 아닌 현실에 발을 딛고 있는 현장 기술자들에 의해 씌여졌기 때문에 쉽게 씌여져 있기 때문입니다.
문제의식, 문제를 해결하기 위한 제안, 적용 경험, 실제 적용을 위한 방안 등의 순서로 현장의 개발자가 직접 시도해 볼 수 있게 친절하게 설명해줍니다. 너무나 쉽게 씌여져서 있어서 일면 가치없어 보인다는 모순에 빠져버리게 되는거죠..

세번째 이유는 소프트웨어 개발을 쉽게 할 수 있는 뭔가 특별한 방법이 있다고 믿는 개발자가 많다는 것입니다. 그래서 책도 구입하는것이겠죠?
Programatic Programmer 앤디 헌트가 말하듯 소프트웨어를 개발하는 '올바른 방법'은 없고 '잘못된 방법'만이 있습니다. 그런 기대들이 '새로울 것도 놀라울 것도 없다' 라는 평을 낳게 하는게 아닌가 하는 생각이 듭니다.

이 책은 소프트웨어를 개발하는 올바른 방법을 제시하지 않습니다.
소프트웨어 개발을 좀더 편하게 할 수 있고 나쁜 길로 빠지지 않게하기 위한 도구와 인프라스트럭처 사용을 제안하고 '예광탄 개발'이라는 프로젝트 기술을 소개합니다.
이러한 도구나 방법이 우리가 수행하고 있는 프로젝트에 적합할 지는 아무도 모릅니다. (형상관리,빌드관리야 요즘 누구나 하는것이니까 제외하더라도 말이죠..)
이 책의 저자들도 적용하고 검증한 후에야 독자인 우리에게 제시하는 걸테니까요.

책의 첫머리에 아리스토텔레스의 말이 씌여져 있습니다.
현재의 우리는 반복적으로 하는 행동의 결과이다. 그러므로 탁월함이란 행동이 아니라 습관이다
훌륭한 습관만이 탁월한 제품을 만들어 낸다고 합니다. 이 책에서 제시하는 방법이든 자신이 찾아낸 방법이든 적용해보고 최적화해서 습관화 한다면 그것이 프로젝트에 적합한 프로세스가 될것입니다.

책은 가이드일 뿐, 정상에 오르기 위해서는 우리 스스로 걸어야 합니다.


* 역자분에게는 죄송하지만 역서에 대한 사소한 불만
요즘 번역서들을 보면 본문의 내용은 해치지 않으면서 문화차이에서 오는 간극을 줄이기 위해 역자의 각주를 달아주는 친절한 번역서가 많은데 그런 의미에서 이 책은 조금 불친절 하지 않나 싶습니다.

1. 예가 잘 기억이 안나서 한가지만..
"좋은 프로세스엔 신성한 소 같은 건 없습니다." - 본문 134P
인도에서 소는 신성불가침의 존재. 이 글을 읽는 사람이라면 다 알만한 내용이라 생각한다면 큰 문제는 없겠지만 우리나라에서는 잘 안쓰는 말이죠..

2. 이상한 말이 너무 많아요 - 나만 모르나 ㅡㅡ;;
예를 들면..
"팀을 만들어나가는 기법 대다수는 주말 철회라던가 워크숍 같이 고립된 행사들입니다." - 본문 183 page
"어떤 종류의 프로세스는 가상 연회를 제공하는데, 거기서 여러분은 수백 개의 업무처리기법과 수십 개의 역할 중에서 취사선택해야 합니다." - 본문 132page


========================================================
요기부터는 그냥 목차랑 개인적인 정리내용입니다.

1장 서론
"현재의 우리는 반복적으로 하는 행동의 결과이다. 그러므로 탁월함이란 행동이 아니라 습관이다"
훌륭한 습관만이 탁월한 제품을 만들어 낸다.
올바르지 않은 습관을 습관이라는 이유만으로 유지하고 있지는 않은지 찾아보라. 그리고 좋은 습관을 갖도록 노력하라

2장 도구와 인프라스트럭처

견고한 개발 인프라스트럭처가 여러분의 업무능률을 향상 시켜줄 것이다. 이 말이 핵심적이다.
자신의 프로젝트에 적합하고 업무능률을 향상시킬 각종 도구(소스관리,자동빌드,자동테스트,이슈트랙커,기능트랙커)를 찾아 업무에 활용하기 위한 팁들을 제시한다.

- 버전관리
- 빌드스크립트 만들기
- 지속적인 빌드
- 이슈추적하기
- 기능추적하기
- 테스트 작성하고 돌리기(ㅋㅋ)

[1] 모래 상자(SANDBOX) 안에서 개발하기
[2] 자산을 관리하세요
[3] 빌드를 스트립트화하세요.
[4] 자동으로 빌드하세요.
[5] 이슈를 추적하세요.
[6] 기능을 추적하세요.
[7] 테스트 장비를 사용하세요.
[8] 도구를 선택하는 방법
[9] 실험하지 말아야 할 때

3장 실용주의적 프로젝트 기술

이 장은 프로젝트 구성원들과 매끄럽게 그리고 생산적으로 프로젝트를 진행하기 위한 협력기법에 대해 말한다.
혼자만 열심히 한다고 프로젝트가 성공하지 않는다는건 누구나 아는 사실이다. 하지만 동료들과 협력해서 열심히 하는사람을 보기는 쉽지않다. 협력을 하기 싫어서가 아니라 협력하는 방법을 몰라서 일지도 모른다.

[10] 목록에 따라 일하세요.
[11] 기술 리더
[12] 매일 협력하고 의사소통하기 - 일일회의
[13] 코드를 모두 검토하세요 - 코드검토
[14] 코드 변경 통지 보내기
[15] 모두 통틀어서

4장 예광탄 개발

* 새로운 프로세스의 적용
고객이나 최종 사용자는 개발시에 어떤 프로세스를 사용하든 신경 쓰지 않습니다. 그들은 여러분이 제대로 된 제품을 전달할 수 있는지, 다음에도 똑같이 잘 할 수 있는지 여부에만 관심을 가집니다. - 본문 133page
맞는 말이지만 최종사용자가 일반사용자가 아닌 기업사용자의 경우 이야기가 달라진다.
아직 IT아웃소싱의 이전 형태를 지닌 기업의 경우 IT전문기업에게 개발을 맡긴 경우라도 품질,프로세스에 대해 여전히 관심을 갖는다.
물론 저자의 의도는 어떤 프로세스를 사용하는지는 중요하지 않다는 의미로 한말이겠지만 말이다.
 
프로세스가 갖춰야 할 진짜 조건
 - 여러분에게 맞는 방법인가
 - 지속가능한가

5장 일반적인 문제와 해결방법

[16] 도와주세요! 코드를 인수 받았어요.
[17] 테스트할 수 없는 코드를 테스트하기
[18] 기능에 문제가 계속 발생합니다.
[19] 테스트? 우리는 더 이상 테스트를 활용하지 않습니다.
[20] 하지만 저는 된다구요!
[21] 코드를 통합할 때 골치 아픕니다.
[22] 제품을 안정적으로 빌드하지 못합니다.
[23] 고객이 불만을 표출합니다.
[24] 불한당 개발자가 있습니다.
[25] 관리자가 불만스러워 합니다.
[26] 팀이 협동을 못합니다.
[27] 핵심적인 부분에 대한 “내부의 지지”를 얻지 못합니다.
[28] 새로운 실천방법이 도움이 안 됩니다
[29] 자동화된 테스트가 없습니다.
[30] 우리는 신참 개발자들이고 이끌어줄 사람이 없습니다.
[31] “죽음의 행진” 프로젝트에 참여하고 있습니다.
[32] 피쳐 크리프(FEATURE CREEP) 현상이 일어납니다.
[33] 프로젝트가 끝날 기미가 안 보입니다.

'실용주의프로그래머' 카테고리의 다른 글

Progmatic Programmer (4)  (0) 2007.09.03
The Progmatic Programmer ( 1 ~ 4 )  (0) 2007.09.03

댓글