소프트웨어 크리에이티비티 2.0

소프트웨어 개발 분야에서 필요한 창의력을 다루고 있는 책이다. 도대체 소프트웨어 공학과 컴퓨터 프로그래밍에서 창의력이 차지하는 역할은 무엇일까? 이 책의 저자는 소프트웨어 개발이란 근본적으로 복잡한 문제를 해결하는 활동이며, 복잡한 문제를 해결하려면 창의력이 필요하다는 생각을 바탕으로 소프트웨어 창의력에 대해 말하고 있다.

소프트웨어 개발을 창의력이라는 주제에 대해 관리자, 학계, 실무자라는 다양한 입장에서 살펴보고 탐구한 이 책은 창의력이 조직과 소프트웨어 분야에서 차지하는 비중과 역할을 살펴보고 있다. 또한 다른 분야에서 배우는 창의력과 창의력을 기르는 방법도 소개함으로써 소프트웨어 개발자들을 돕고 있다.

저자 : 로버트 L. 글래스 (Robert L. Glass)

로버트 L 글래스는 지금까지 50여 년 동안 전산 분야에서 파란만장한 경험을 쌓아왔으며, 1954년에서 1957년 사이 항공우주 업계, 노스 아메리칸 사에서 3년 동안 일한 경험을 시작으로 밥은 소프트웨어 부문에서 진정한 선구자 중 한 명으로 거듭났다.

노스 아메리칸 사에서 근무한 경험이 계기가 되어 에어로젯-제네랄과 보잉과 같은 우주항공 회사에서 계속 일하게 되었으며, 그 이후 시애틀 대학교의 소프트웨어 공학 대학원에서 교편을 잡았고 소프트웨어 공학 연구소에서 1년을 보냈다. 초창기 밥은 워싱턴 대학교에서 도구에 초점을 맞춘 연구를 몇 년 정도(1970년 - 1972년) 진행했다.

밥은 25권이 넘는 다양한 서적과 90편이 넘는 전문 논문을 작성하는 방법으로 전산 학계가 내놓은 발견을 평가하고 이를 실무에 실질적인 가치가 있도록 만드는 전환 작업에 초점을 맞추기 위한 여러 가지 시도를 해왔다. 로버트 L 글래스는 친자 두 명과 양자 두 명의 아버지이며, 정보 시스템 관련 학계에서 활약하는 아이리스 베세이와 결혼했다.

역자 : 박재호

포항공과대학교 컴퓨터공학과 학부와 포항공과대학교 대학원 컴퓨터공학과를 졸업했다. 블로그 '컴퓨터 vs 책'(http://jhrogue.blogspot.com)을 운영하고 있다. 지은 책으로 『IT EXPERT, 임베디드 리눅스』(한빛미디어, 2002), 『열씨미와 게을러의 리눅스 개발 노하우 탐험기』(한빛미디어, 2008) 등이 있고, 옮긴 책으로 『The Art of Project Management : 마음을 움직이는 프로젝트 관리』(한빛미디어, 2006), 『리눅스 디바이스 드라이버, 개정5판』(한빛미디어, 2005), 『리눅스 문제 분석과 해결』(에이콘, 2006), 『조엘 온 소프트웨어 : 유쾌한 오프라인 블로그』(에이콘, 2005), 『소프트웨어 컨플릭트 2.0』(위키북스, 2007), 『초난감 기업의 조건』(에이콘, 2007) 등이 있다. http://jhrogue.blogspot.com

역자 : 이해영

포항공과대학교 컴퓨터공학과 학부와 퍼듀대학교 전자계산학과 대학원을 졸업했다. 오랫동안 소프트웨어 개발에 종사하다가, 2009년 현재 미국에 있는 소프트웨어 개발 회사에서 지역화 전문가 겸 프리랜서 번역가로 일하고 있다. 옮긴 책으로 『조엘 온 소프트웨어: 유쾌한 오프라인 블로그』, 『리눅스 디버깅과 성능 튜닝』, 『리눅스 문제 분석과 해결』, 『The Art of Project Management: 마음을 움직이는 프로젝트 관리』, 『소프트웨어 컨플릭트 2.0』, 『초난감 기업의 조건』 등이 있다.

1 규율 대 유연성

1.1 소프트웨어 분야의 진정한 헨리 포드를 찾습니다!
1.2 소프트웨어 자동화, 가능할까 사기일까?
1.3 프로그래머는 정말로 '통제불능'일까?
1.4 체계는 나쁜 말일까? 소프트웨어 생명주기 이야기
1.5 소프트웨어 설계 위조하기
1.6 애자일 프로그래밍, 유연성이 무르익다
1.7 교정원 연필에 얽힌 황당한 사건
1.8 파루틴 지수
1.9 체계와 창의력이라는 기묘한 단짝

2 정형 기법 대 경험 기법

2.1 논쟁을 명백히 밝혀보자
2.2 죄책감 없이 소프트웨어 개발하기
2.3 정형 기법: 극적인 (성공, 실패) 이야기 하나
2.4 정형 기법을 넘어서
2.5 정형 기법에 대해서 독자들이 보낸 의견

3 최적화와 만족화

3.1 BIEGE 원칙으로 문제를 해결하라
3.2 충분한 소프트웨어
3.3 땜빵을 옹호하며
3.4 미하일 고르바초프와 소프트웨어 생산성 (!?)

4 정량 추론 대 정성 추론

4.1 측정하지 못하면 관리하지 못한다. 정말?
4.2 수학과 전산학자
4.3 의사결정에서 직관의 역할
4.4 숫자도 숫자 나름이다

5 프로세스 대 제품

5.1 좋은 프로세스가 좋은 제품을 내놓을까?
5.2 좋은 프로세스가 좋...1 규율 대 유연성

1.1 소프트웨어 분야의 진정한 헨리 포드를 찾습니다!
1.2 소프트웨어 자동화, 가능할까 사기일까?
1.3 프로그래머는 정말로 '통제불능'일까?
1.4 체계는 나쁜 말일까? 소프트웨어 생명주기 이야기
1.5 소프트웨어 설계 위조하기
1.6 애자일 프로그래밍, 유연성이 무르익다
1.7 교정원 연필에 얽힌 황당한 사건
1.8 파루틴 지수
1.9 체계와 창의력이라는 기묘한 단짝

2 정형 기법 대 경험 기법

2.1 논쟁을 명백히 밝혀보자
2.2 죄책감 없이 소프트웨어 개발하기
2.3 정형 기법: 극적인 (성공, 실패) 이야기 하나
2.4 정형 기법을 넘어서
2.5 정형 기법에 대해서 독자들이 보낸 의견

3 최적화와 만족화

3.1 BIEGE 원칙으로 문제를 해결하라
3.2 충분한 소프트웨어
3.3 땜빵을 옹호하며
3.4 미하일 고르바초프와 소프트웨어 생산성 (!?)

4 정량 추론 대 정성 추론

4.1 측정하지 못하면 관리하지 못한다. 정말?
4.2 수학과 전산학자
4.3 의사결정에서 직관의 역할
4.4 숫자도 숫자 나름이다

5 프로세스 대 제품

5.1 좋은 프로세스가 좋은 제품을 내놓을까?
5.2 좋은 프로세스가 좋은 제품을 내놓을까? 두 번째 의견
5.3 위대할 뻔한 이야기
5.4 소프트웨어 프로세스, 잡다한 생각 몇 가지
5.5 프로세스 대 사람, 좋은 제품 만들기
5.6 CMM을 적용한 결과 둘러보기
5.7 제품 대 프로세스, 언제 무엇에 집중할까?

6 지적인 업무 대 사무적인 업무

6.1 소프트웨어 만들기, 쉬울까? 어려울까?
6.2 소프트웨어 업무, 지적일까 사무적일까...... 아니면 창의적일까?
6.3 아주 그릇된 이유로 혁신 개념 사들이기

7 이론 대 실무

7.1 이론이 먼저일까? 실무가 먼저일까?
7.2 다시 생각하는 이론 대 실무
7.3 이론과 실무, 심난한 예제
7.4 뒝벌의 비상
7.5 이론 대 실무, 다양한 유감
7.6 소프트웨어 실무가 소프트웨어 이론을 앞서는 부문 정리

8 업계 대 학계

8.1 흥미 대 유용성
8.2 개인 대 팀
8.3 유행어 둘
8.4 이해와 인정과……정형 기법
8.5 구조적 연구라고?
8.6 말하기 대 듣기
8.7 미적미적 위원회
8.8 엄밀성 대 실용성

9 재미 대 진지

9.1 재미와 권태
9.2 오픈소스, 돌아온 재미
9.3 특이한 프로젝트
9.4 잃어버린 재미를 찾습니다

10 소프트웨어 조직과 창의력

10.1 그리스 대 로마, 판이한 소프트웨어 문화
10.2 통제와 기업 문화
10.3 혁신과 관리
10.4 창의력과 전략 정보 시스템
10.5 창의력 대 법

11 창의력과 소프트웨어 기술

11.1 정보 시스템을 구현하는 창의적인 기법
11.2 창의력과 소프트웨어 설계, 빠진 고리
11.3 사례 연구, 창의력이 현실을 만나다

12 소프트웨어 역사와 기념비적인 사건

12.1 첫 번째 기념비적인 사건
12.2 이후 '은총알' 사건
12.3 창의력 대 절차화

13 조직적인 창의력
14 창의적인 사람
15 컴퓨터와 창의력
16 창의력 모순
17 항상 그랬다
18 상승적 결론
19 기타 결론

A 특별 부록(로버트 L. 글래스 대담 기사)
B 특별 부록(성공/실패 조건)
C 베타리더 한마디