1부 이념과 태도<br/><br/>1장 21세기의 소프트웨어 개발<br/>고참 개발자 <br/>새로운 현실 <br/><br/>2장 애자일 <br/>절차적인 관점에서의 애자일 원칙 <br/>기술적인 관점에서의 애자일 원칙 <br/>애자일을 따른다는 것 <br/> 게임 체인저 <br/> 피플 임파워먼트 <br/> 프로페셔널의 진화 <br/>애자일 매니페스토 <br/> 애자일 매니페스토의 원칙들 <br/>애자일 격변기 <br/>애자일 행오버 <br/> 부분적인 전환 <br/> 애자일 코치 <br/> 새로운 기술적 실행 관례에 대한 거부감 <br/> 소프트웨어 프로젝트를 바라보는 편협한 시각 <br/> 나쁜 소식만 있는 것은 아니다 <br/>애자일과 소프트웨어 장인정신 <br/>요약 <br/><br/>3장 소프트웨어 장인정신 <br/>더 나은 비유 <br/>위키피디아에서의 정의 <br/>좀더 주관적인 정의 <br/>짧은 정의 <br/>정의 이상의 의미 <br/>공예, 사업, 엔지니어링, 과학 또는 예술 <br/>소프트웨어 장인정신의 토론 이력 <br/> 소프트웨어 장인정신 모임 <br/> 경계를 지나 <br/> 장인 교환 프로그램 <br/> 소프트웨어 장인 커뮤니티 <br/> 소프트웨어 장인정신 매니페스토 <br/> 매니페스토 <br/> ‘동작하는 소프트웨어뿐만 아니라, 정교하며 솜씨 있게 만들어진 작품을’ <br/> ‘변화에 대응하는 것뿐 아니라, 계속해서 가치를 더하는 것을’ <br/> ‘개별적으로 협력하는 것뿐만 아니라 프로페셔널 커뮤니티를 조성하는 것을’ <br/> ‘고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를’ <br/> 생산적 동반자 관계가 될 준비가 안 된 고객 <br/> 매니페스토의 문제점 <br/>요약 <br/><br/>4장 소프트웨어 장인의 태도<br/>내 커리어의 주인은 누구인가 <br/> 고용자?피고용자 관계 <br/>끊임없는 자기계발 <br/> 독서, 많은 독서 <br/> 블로그 <br/> 기술 웹사이트 <br/>팔로우할 리더 찾기 <br/> 소셜미디어 <br/>끊임없는 훈련 <br/> 카타 <br/> 펫 프로젝트 <br/> 오픈 소스 <br/> 페어 프로그래밍 <br/>사회 활동: 다른 개발자들과 어울리기 <br/> ‘개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을’ <br/>의도한 발견 <br/>일과 삶의 균형 <br/> 시간 만들기 <br/> 집중: 뽀모도로 기법 <br/> 균형 <br/>요약 <br/><br/>5장 영웅, 선의 그리고 프로페셔널리즘<br/>‘아니오’라고 말하는 방법 배우기 <br/> 재앙의 기억 <br/> 교훈 <br/> 프로답게 행동하기 <br/>대안 제시 <br/> 뜻밖의 실용적인 대안 <br/>깨어 있는 관리자 <br/>요약 <br/><br/>6장 동작하는 소프트웨어<br/>동작하는 소프트웨어만으로는 부족하다 <br/>정원 돌보기 <br/>보이지 않는 위협 <br/> 자신이 만든 소프트웨어에 인질이 되는 상황 <br/> 평범한 개발자가 아닌 장인을 고용하라 <br/>시간에 대한 잘못된 인식 <br/> 기술적 부채에 대한 이야기 <br/> 우리는 올바른 것을 하길 원한다 <br/> 시간적 여유가 없는 바쁜 팀 <br/> 내겐 없는 여유, 다른 누군가에겐 있는 여유 <br/> 단위 테스트 작성은 별개의 업무인가 <br/> 효율적인 시간 활용 <br/> 몇 개월 후 <br/>레거시 코드 <br/> 태도의 변화 <br/> 고객과 개발자 모두의 만족 <br/>요약 <br/><br/>7장 기술적 실행 관례<br/>올바른 일 vs 올바른 실행 <br/>상황 논리 <br/>익스트림 프로그래밍의 역사 <br/>실행 관례와 가치 <br/> 실행 관례를 통한 가치 창출 <br/> 자동화된 테스트 <br/> 테스트 먼저 <br/> 테스트 주도 개발 <br/> 지속가능한 통합 <br/> 페어 프로그래밍 <br/> 리펙토링 <br/>책임감 <br/>실용주의 <br/>요약 <br/><br/>8장 길고 긴 여정<br/>브라질 어느 십대 소년의 이야기 <br/>결단과 집중 <br/> 어디로 가야 할지 모른다면 <br/>투자로서의 일터 <br/> 당부의 말 <br/>자율성, 통달, 목적의식 <br/>회사 안에서의 커리어 <br/>요약 <br/><br/>2부 완전한 전환<br/><br/>9장 인재 채용<br/>전형적인 채용 공고 <br/>인터뷰할 시간이 없다는 변명 <br/>틀에 박힌 직무 요건 <br/> 참고 정보로 필요한 직무 요건 <br/> 일은 단순히 일이 아니다 <br/>추천 채용 <br/>커뮤니티의 활용 <br/>효과적인 선별 조건의 정의 <br/>적극적인 리쿠르팅 <br/>요약 <br/><br/>10장 소프트웨어 장인 면접하기<br/>비즈니스 협상 <br/>생산적인 파트너십을 알아보는 방법 <br/> 회사 입장에서의 관점 <br/> 지원자 입장에서의 관점 <br/>바람직한 면접 방법 <br/> 올바른 집중 <br/> 마인드 맵핑 대화 <br/> 페어 프로그래밍 면접 <br/> 개인 컴퓨터를 지참한 면접 <br/> 맞춤형 면접 <br/>번트 홈런 <br/>기존 팀을 위한 채용, 새로운 팀을 위한 채용 <br/>사전 면접용 코딩 시험 <br/>지원자와 회사 모두 면접을 어떻게 하는지 알아야 한다 <br/>개발자 채용 면접은 개발자가 보아야 한다 <br/>요약 <br/><br/>11장 잘못된 면접 방식<br/>똑똑한 척하는 면접관을 세운다 <br/>수수께끼식 질문을 던진다 <br/>답을 모르는 질문을 한다 <br/>지원자를 바보로 만든다 <br/>인터넷 접속을 막는다 <br/>종이에 코드를 작성하게 한다 <br/>알고리즘 문제를 낸다 <br/>전화 면접을 한다 <br/>요약 <br/><br/>12장 낮은 사기의 대가<br/>애자일 행오버: 낮은 사기 <br/>그저 ‘출퇴근’만 하는 개발자들로 인한 대가 <br/>낮은 수준의 동기가 만드는 제약 <br/>개발자들에게 열정을 불어넣기 <br/>요약 <br/><br/>13장 배움의 문화<br/>잘못된 방향으로 동기 부여하기 <br/>배움의 문화 만들기 <br/> 북 클럽에 가입하기 <br/> 테크 런치 진행하기 <br/> 그룹 토론회에 참여하기 <br/> 업무 교환하기 <br/> 얼마 동안만 업무 교환하기 <br/> 그룹 코드 리뷰하기 <br/> 코딩 실습하기 <br/> 사용할 기술은 가능한 자유롭게 선택하기 <br/> 내부 학습 모임을 만들기 <br/> 회사에서의 펫 프로젝트 시간을 허용하기 <br/> 외부 기술 커뮤니티와 교류하기 <br/>아무도 참여하려 하지 않는다면 <br/> 모범을 보여라 <br/> 관심을 보이는 사람들에게 집중하라 <br/> 강제하지 마라 <br/> 모두를 변화시키려 들지 말라 <br/> 모임에 대한 약속을 제때하라 <br/> 허락을 구하지 마라 <br/> 투덜대지 마라 <br/> 리듬을 만들라 <br/>요약 <br/><br/>14장 기술적 변화의 실행<br/>회의론의 종류 <br/>준비 <br/>기술적 변화를 시작하는 방법 <br/> 신뢰를 쌓으라 <br/> 전문성을 확보하라 <br/> 모범을 보여 사람들을 이끌라 <br/> 신중하게 싸울 곳을 정하라 <br/> 점진적으로 반복, 관찰, 수용하라 <br/>두려움과 자신감 부족 <br/>상사를 설득하는 방법 <br/>팀이 TDD를 수용하도록 설득하는 방법 <br/>회의론을 상대하는 방법 <br/> 상아탑 아키텍트 <br/> 권한과 책임 <br/> 피해망상 <br/>이 모든 것을 다 챙겨야만 하는가 <br/>요약 <br/><br/>15장 실용주의 장인정신<br/>품질은 선택사항이 아니다 <br/>좋은 품질은 비싸고 시간이 오래 걸릴까 <br/> 테스트 주도 개발이 항상 필요할까 <br/>리펙토링 <br/>소프트웨어 개발 방법의 한 가지 예 <br/>비즈니스 돕기 <br/> 단순하고 빠른 솔루션 <br/>소프트웨어 프로젝트는 우리를 위한 것이 아니다 <br/>비범함과 평범함 <br/>단순한 설계를 위한 네 가지 원칙 <br/> 디자인 패턴 <br/> 패턴을 위한 리펙토링 <br/>장인정신과 실용주의 <br/>요약 <br/><br/>16장 소프트웨어 장인으로서의 커리어<br/>장인의 길 <br/> 정직과 용기 <br/>커리어의 진전 <br/> 다른 커리어 사다리 <br/>여정과 이정표 <br/> 커리어 만들어 나가기 <br/> 원하는 바를 모른다면 어떻게 해야 할까 <br/>다양성 <br/>소프트웨어 장인의 사명 <br/><br/>부록 소프트웨어 장인정신에 대한 오해와 설명<br/> 소프트웨어 장인과 소프트웨어 개발자 <br/> 장인정신 != 엘리트주의 <br/> 견습생, 숙련공, 마스터 <br/> 마스터 장인 <br/> 근시안적 개념으로 보는 시선 <br/> 장인정신과 XP <br/> 실행 관례와의 관계 <br/> 애자일 코치와 관리자 <br/> 소프트웨어 도제 제도 <br/> 비유로 인한 문제

소프트웨어 개발자가 추구해야 할 가치와 태도를 여러 경험을 통해 이야기한다. 내가 경험했던 그 프로젝트가 왜 고달팠었는지 또는 왜 즐거웠었는지 이해하게 되고, 마치 내 얘기인 것 같아서 때론 공감하면서 어떨 땐 뜨끔하며 단숨에 읽게 된다. 좀 더 나은 개발자가 되기 위한 여정에 서서 스스로를 돌아보고, 제대로 가려면 어떻게 가야 할 지 생각해 볼 시간을 주는 책이다.
레진엔터테인먼트 개발자_ 강소리

소프트웨어 개발자로서 올바르게 살아왔느냐에 대한 궁금증을 품게 된다면 이 책을 추천하고 싶다. 현재 스킬에 목마르거나 소통에 문제가 있는 개발자가 있다면 현실적으로 냉정하게 판단할 수 있는 도움을 줄 것이다. 국내에서 쉽게 들을 수 없는 경험을 기반으로 쉽게 풀어 설명하는 스프트웨어 장인의 이야기라 생각한다.
피키캐스트 개발자_ 김헌기

지금까지 개발을 하며 프로젝트에서 경험했고 어설프게나마 이해했던 내용들을 목차에서 보고 오랜만에 집중해서 읽을 수 있었다. "Scrum, XP, TDD를 한다는 것이 Agile 하다고 할 수 있는가?" 라는, 최근 5년간 애자일 방식으로 일을 하며 느꼈던 개인적인 고민들이 정리가 되는 느낌이다. 개발자로서 나와 직원으로서 나, 왜 이일을 하고 있는지를 다시 생각하게 하는 좋은 기회였다.
쿠팡 개발자_ 이걸

기술의 급속한 변화에 신속한 적응이 필요한 동네에서의 십수 년, 여전히 느끼는 조바심은 주니어의 그것과 크게 다르지 않다. 그런데 현실은 시니어의 변화된 사회적 책임까지 안아야 한단다. 저자의 글을 읽다 보면 "나만 이런 고민을 한 게 아니군", "나도 저런 방법을 시도해 봐야지" 하게 된다. 비슷한 입장에 있는 업계 동료들에게 진심으로 권하고 싶은 책이다.
휴레이포지티브 개발자_ 정미영

매일 오후 퇴근 전 팀원들과 하는 스탠딩 미팅에서 책의 인상 깊었던 구절을 소리 내어 읽어주기도 했다. 팀 리더가 된 지금의 나에게 팀 운영, 팀원 채용과 면접에 대한 훌륭한 조언만으로도 이 책은 충분한 역할을 해주었다. 여러분이 프로그래머로서 일 하는 동안 수시로 이 책을 펼쳐 훌륭한 선배의 조언과 경험담을 들었으면 한다.
파킹스퀘어 개발자_ 황용대