1장. 생산성이 10배 이상이라고 알려진 전설의 프로그래머
__작업 시간 변동성 데이터
__동질성 유지하기
__작업 시간 표의 실제 의미 파악하기
__한 가지 프로그래밍 언어만 고집하지 않은 경우
__기준 집단에 대한 의문
__이것은 개발 노력에 관한 것만은 아니다
__속도가 느린 프로그래머들이 더 신중할까?
__부차적인 요소가 중요할 수 있다
__생산성의 정의에 관한 재논의
__실제 사람들은 어떻게 일을 할까?
__그래서 어떻게 해야 하나?
__핵심
__참고 문헌
2장. 한 가지 지표로는 생산성을 측정할 수 없다
__각 프로그래머의 생산성을 측정하는 것은 과연 무엇이 잘못됐는가?
__왜 사람들은 개발자의 생산성을 측정하고 싶어할까?
__한 가지 생산성 지표만 사용하는 것이 왜 잘못될 수밖에 없을까?
____생산성은 넓은 범위의 개념이다
____한 가지 지표로 단순화하거나 한 가지 측면의 구성 요소들을 조합하는 것은 어렵다
____교란 변수들
__대신 구글에서 무엇을 했나?
__핵심
__참고 문헌
3장. 생산성을 측정해서는 안 되는 이유
__의도치 않은 결과
__생산성에 관한 설명
__변화에 대응하기
__측정자 역할을 하는 관리자
__핵심
4장. 소프트웨어 엔지니어링에서 생산성 정의하기
__소프트웨어 생산성의 짧은 역사
__일반 문헌 용어
____생산성
____수익성
____성과
____효율성과 효과성
____품질의 영향
__소프트웨어 생산성에 대한 통합된 정의
__요약
__핵심
__감사의 말
__참고 문헌
5장. 소프트웨어 개발 생산성 프레임워크
__소프트웨어 개발의 생산성 측면
____속도
____품질
____만족도
__렌즈
__생산성 프레임워크 시작! 목표, 질문, 지표를 구체화하기
____첫 번째 예: 개입을 통한 생산성 개선
____두 번째 예: 미팅이 어떤 식으로 생산성에 영향을 미치는지 이해하기
__주의 사항
__핵심
__참고 문헌
◈ 이 책의 구성 ◈
이 책은 다섯 가지 주제로 구성된다. 우선, 생산성을 측정할 때 어려운 점을 이야기하면서 시작할 것이다. 다음으로 생산성을 각 구성 요소로 세분화하는 데 초점을 맞춰 이야기를 진행하고, 생산성 요소를 규명하고 생산성에 대한 다른 관점을 부여할 수 있도록 내용을 이어갈 것이다. 생산성은 보통 측정하기 어렵다. 하지만 생산성의 일부 측면을 측정하는 데 집중한 특정 사례 연구도 포함했다. 마지막으로 생산성을 증대하는 데 효과가 있는 지침에 관한 이야기로 책을 끝낼 것이다.
◈ 지은이의 말 ◈
독일의 다그스튤(Dagstuhl에서 있었던 일주일간의 워크숍에서 이 책은 시작됐다. 세미나는 두 가지 이유에서 개최됐다. 하나는 1980년대와 1990년대 이후로 많은 것이 변했다는 점이고, 또 다른 하나는 현대 소프트웨어 엔지니어의 생산성을 높이려면 무엇이 필요한지 재조명해 봐야 하는 시기였기 때문이다.
그럼 1980년대와 1990년대 이후로 무엇이 변했을까? 오늘날의 소프트웨어 팀과 엔지니어는 전세계적으로 활동한다. 또한 소프트웨어 엔지니어는 국경을 넘고 시간대를 넘어서 협력하며 신속하게 변화하는 소프트웨어 개발 업무를 한다. 종종 엔지니어는 스택 오버플로(Stack Overflow와 깃허브(GitHub 같은 소셜 코딩 도구를 사용하기도 하고 노트북이나 개인용 전자기기에서 작업을 하기도 한다. 오늘날의 소프트웨어 엔지니어는 전례 없는 복잡한 작업을 하고 클라우드 안에서 큰 시스템을 구축하기도 한다. 또한 단일 저장소에 수백만 줄(가끔 몇십억 개의 코드를 저장할 수 있고, 하루에도 몇십 번씩 소프트웨어를 배포할 수 있다. 이들은 웹 검색이나 블로그, 질의 사이트나 소셜 네트워킹 사이트 등과 같은 대화 채널을 평균 11.7개가량 사용한다. 1984년에는 소프트웨어 엔지니어는 직접 만나거나 전화 통화를 통해 대화해야 했다. 사람과 컴퓨터의 상호작용(HCI, Human-Computer Interaction, 컴퓨터 보조 공동 작업(CSCW
