거꾸로 배우는 소프트웨어 개발(사람과 프로그래머 2)

이 세상의 수많은 소프트웨어 프로젝트를 성공적으로 수행하기 위해서 일반화할 수 있는 공통적인 부분, 누구나 공감할 수 있는 통찰이 있다. 그리고 이 책에서는 그것을 인문학적 영역으로 정의한다. 개발방법론에만 함몰되어 남들이 좋다 하니 그것을 그대로 실천하려는 자세를 벗어나 우리가 누구인지, 우리가 속한 환경의 특성이 무엇인지를 먼저 알아야 하고 그 다음에 적합한 방법론을 선택해야 한다. 이 책이 다루는 주요 내용이다. 기존의 소프트웨어 개발 방법론 책과는 거꾸로 개발 방법론을 배운다.



[대상 독자]

소프트웨어 개발 프로젝트를 이끌어야 하는 초보 관리자

소프트웨어 개발에 관해 공학 외에 인문학적 소양을 갖추고자 하는 개발자

개발 현장을 리얼하게 이해하고자 하는 소프트웨어 프로젝트 관계자

당장 조직의 문제를 실감하고 있는 프로젝트 이해당사자

새로운 개발방법론을 도입하기 위해 학습하고자 하는 개발자나 관리자



소프트웨어 개발 방법론,

그냥 가져다 쓰는 도구가 아니다



소프트웨어 개발 방법론은 해법이 정해져 있는 공학적 이론이 아닙니다. 사람의 문제, 조직의 문제를 훨씬 많이 다루는 인문학적 영역입니다. 그래서 그냥 가져다 쓰다가는 많은 프로젝트가 실패할 수밖에 없습니다. 따라서 이 책은 특정 방법론을 이론적으로 설명하는 방식을 탈피해서 저자가 십수 년간 현장에서 체득한 경험과 평소 다독하며 끊임없는 학습으로 쌓은 인문학적 소양을 바탕으로 소프트웨어 개발 방법론을 학습하고 도입하기 전에 알아야 할 것들을 설득력 있게 제시합니다.



"더 중요한 것은 우리 자신을 아는 것이다. 우리의 체질과 습관을 아는 것에서 시작해야 한다. 우리의 고유한(?) 문제에서부터 출발해서, 그 문제를 풀어가는 데 도움이 될 처방전을 찾는 과정이어야 한다. 현학적인 이론들을 그대로 가져다가 현실에 적용해보는 건 오히려 역효과가 생길 공산이 크다. 특히 개발 조직 외부에서 주로 상층에서 아래로 강요하고 주입하는 방식으로 던져주는 방법론은 대부분 실패한다. 실무자, 담당자들이 감당할 수 있어야 한다. 방법론 도입과 적용과정에서 생겨나는 불편과 부작용을 감당하고 극복해갈 수 있어야만 약효를 얻을 수 있다. 아무리 보약을 지어줘도 쓴 약 먹기 싫어서 몰래 버리기만 하면 몸이 튼튼해질 수가 없다."

<프롤로그_소프트웨어 개발, 제대로 배우자> 중에서



[편집자 코멘트]

어려운 얘기를 써놓지 않았습니다. 누구나 읽고 공감할 수 있는 쉬운 얘기를 써놓았습니다. 무엇보다 블로그 글에서 개발자 출신이 아닌 저도 밑줄 긋고 싶은 말이 참 많았습니다.

이 책을 읽으면서 저자도 조직에 대해, 사람에 대해 참으로 많이 고민했구나를 느꼈습니다. 그리고 평소에 엄청나게 다독하는 습관으로 다져진 인문학적 소양이 더해져 부드럽게 섭취할 수 있는 주제가 가득합니다.



개발자도 봐야 하지만, 오히려 팀장님, 사장님과 같은 관리자가 더 많이 보았으면 합니다. 왜 프로젝트가 실패하는지, 왜 개발자가 중요한지, 왜 방법론이 필요한지 등에 대해 개발자, 관리자가 함께 머리를 맞대고 공감하여 좀더 나은 소프트웨어 개발 환경에 도움을 줄 수 있길 기대합니다.

프롤로그

01 소프트웨어 개발 제대로 배우자

02 개발자는 무엇으로 사는가

03 문명 붕괴 패턴과 너무 비슷한 소프트웨어 붕괴 패턴

04 소프트웨어 진화 전략을 고민해봄 (1)

05 소프트웨어 진화 전략을 고민해봄 (2)_리팩토링

06 즐겁고 행복한 개발자를 위한 3종 세트

Colum01 프로그래밍 언어에 관한 두서 없는 생각



개발 방법론

07 개발 방법론에 대한 오해와 억측

08 복잡한 개발 방법론 따위가 왜 필요할까

09 폭포수 개발 방법론을 위한 변호

10 소프트웨어 솔루션 단기 속성 개발 전략의 위험성

Colum02 전문성의 기준으로 본 전문가 등급 피라미드



개발 조직론

11 개발 방법론은 누구에게 필요한 걸까

12 좋은 소프트웨어 개발 관리자가 되려면_전문성

13 좋은 소프트웨어 개발 관리자가 되려면_시간 관리

14 좋은 소프트웨어 개발 관리자가 되려면_몰입형 업무 환경 조성

15 SCRUM은 소프트웨어 개발 방법론일까?

16 SCRUM 세미나에서 나온 질문들

17 SCRUM이 제대로 도입되려면, 개발 최고 관리자인 사장님이 달라져야 한다

18 소프트웨어 개발은 쌍두마차 야간여행과 같다

19 소프트웨어 프로젝트와 제품에 대한 의식의 흐름

20 협업은 가능한 걸까? 어떻게 해야 가능해질까?

Colum03 Continuous Integration(지속적 통합, CI)은 왜 필요할까?



개발 표준

21 전사적 개발 표준을 정하는 문제와 관련된 어려움

22 문서화 3원칙

Colum04 Coding Style과 Unit Test_ 프로그램을 좀더 실천적으로 배울 수 있는 방법



소스관리 도구

23 전사적 소스 코드 관리 체계 도입과 관련하여

24 왜 한국의 프로그래머들은 소스 형상 관리 도구를 잘 안 쓰는 걸까?

Colum05 좋은 소프트웨어 개발을 위한 최소한의 실천지침



Framework

23 Framework에 대한 두려움 혹은 불안감



TDD

26 소프트웨어 버그의 속성, 세균을 닮았다

27 소프트웨어 개발에서 버그는 정말 어쩔 수 없는 것일까

28 소프트웨어 개발에서 품질 향상은 생산성을 갉아먹는 게 아니다

29 프로그램 오류에 숨겨진 IT 조직 이야기

30 TDD를 도입해야 하는 10가지 결정적인 이유들

31 TDD 도입을 꺼리는 10가지 주요한 이유들

Colum06 소프트웨어 개발자 구인 소개글을 써봤습니다

에필로그

이호종 저자 이호종은 서강대학교에서 전자공학과 학사 및 대학원 석사 과정을 마쳤다. 아남반도체기술, 메타칩스 대표이사, 그리고 현재 ㈜후이즈의 기술이사까지 15년 넘게 통신 및 하드웨어와 소프트웨어 설계 분야에서 개발하고 있다. <잡독일기(雜讀日記)>라는 블로그에 평소 다독하며 끊임없이 학습하여 얻은 지식을 틈틈이 기록하고 있다. 이 책은 저자의 블로그 내용에 기초하여 엮은 글이다.