본문 바로가기

B3:책 Books/기술 Tech

익스트림 프로그래밍

반응형
한글제목(Korean)
익스트림 프로그래밍

영문제목(English)
Title in English

ISBN
8991268102
교보문고 , yes24

기간(Reading in)
2006/09/01-2999/12/31

평가(5단계,Rate)
★★★★★

관련서적(Similar Books)
사용자 스토리 : 고객 중심의 요구사항 기법, ISBN:8991268137

요약(Summary)

- 가치, 원칙, 실천방법(가치와 원칙을 연결하는 다리역할)
- 가치 : 의사소통, 단순성, 피드백, 용기, 존중
- 원칙 : 인간성, 경제성, 상호이익, 자기유사성, 개선, 다양성, 반성, 흐름, 기회, 잉여, 실패, 품질, 아기 발걸음, 받아들인 책임
- 기본실천방법
    함께 앉기: 의사소통을 최적화하는 수준에서 팀 구성원이 함께 앉는 방식을 결정하는 것
    전체 팀 : 말콤 글래드웰의 저서 "The Tipping Point"에서 제시하는 팀의 적정인원 12~150. 150이 한계.
    정보를 제공하는 작업공간 :
    활기찬 작업 : 자기를 잘 돌보는 것이 활력 넘치는 작업으로 복귀하는 가장 빠른 방법이다.......아픈데도 일하러 오는 것은 일에 대한 헌신을 보여주는 것이 아니다. 팀을 돕는 일이 아니기 때문이다.(p.79)
    짝 프로그래밍 : [장점] 서로 일에 집중하도록 해 준다/ 브레인스토밍한다/ 생각을 명료하게 다듬어준다/막힐 때 서로 주도권을 교체하여 짜증을 덜 나게 해 준다/팀 실천방법을 서로 지키도록 노력한다(p.80)
    스토리 :
    일주일별 주기 :
    분기별 주기 :
    여유 : 팀이 실제로 할 수 있으리라 자신하는 분량만 서명하라(p.88)
    10분 빌드 :
   지속적 통합 :
   테스트우선 프로그래밍 :
   점진적 설계 : 최적의 설계시점이란 경험에 비추어 결정된다(p.94)
- 보조실천방법
   진짜고객 참여 : 여러분의 시스템에 따라 인생과 사업이 다라지는 사람들을 팀의 일원이 되게 한다(p.105)
   점진적 배치/ 팀 지속성/팀 크기 줄이기/근본 원인 분석/코드 공유/코드와 테스트/단일 코드 기반/매일 배치/범위 협상 계약:긴 계약 하나에 서명하기보다 짧은 계약 여러 개를 여러 번에 걸쳐 서명함으로써 위험도를 낮추어라(p.116)/사용별 지불/
- 계획짜기 : 범위를 관리하기
   계획짜기는 모두 함께 해야 하는 일이다......계획을 짤 때는 팀에 속한 모든 사람이 참여해야 한다.(p.146)
- 테스트 : 일찍, 자주, 자동화
   모든 결함을 제거하는 일은 불가능하다. MTBF를 한 달에서 일 년으로 늘리려면 엄청난 비용이 든다. 그리고 그 간격을 우주왕복선에 탑재되는 코드에 필요한 것처럼 한 세기로 늘리려면 천문학적인 비용이 든다. (p.151) 개발의 다른 목표는 팀에 대한 신뢰가 합리적으로 자라날 수 있는 수준까지 결함의 발생을 줄이는 것이다.(p.152)
- 설계하기:시간의 가치
   불행하게도, 소프트웨어 설계는 물리적 설계 활동에서 온 메타포들 때문에 족쇄가 채워져 있다. 50층짜리 마천루가 있을 경우, 그 위에 50층을 추가할 수는 없다. 이미 모든 공간을 세 놨기 때문이다. 큰 빌딩을 잭으로 들어 올리고 기반을 더욱 튼튼한 것으로 갈아 치울 방법은 없다(p.160)
- 테일러주의와 소프트웨어
   테일러주의식 사회공학의 첫 번째 단계는 계획과 실행의 분리다......테일러주의식 사회공학의 두 번째 단계는 품질 부서를 따로 두는 것이다.(p.192)
   품질 조직을 별도로 둔다는 점에서 많은 소프트웨어 개발 조직이 바로 테일러주의자다. (심지어 그 사실을 자랑스러워하기도 한다.) 품질 부서를 따로 두는 일은 우리가 품질을 정확히 공학(엔지니어링)이나 마케팅이나 판매만큼 중요하게 여긴다는 메시지를 전달한다. 그러나 그렇게 하면 공학 부서의 누구도 품질에 대해서는 책임을 지지 않게 된다......품질과 공학을 조직구조에서 분리한다면 품질부서가 하는 일의 성격이 건설적이 아니라 징벌적이 되어 버린다.(p.193)
- 도요타 생산 시스템
   TPS(Toyota Production System)의 정신적 지도자인 오노 다이이치는 과잉생산의 낭비가 가장 큰 낭비라고 말한다......소프트웨어 개발은 과잉생산의 낭비로 가득 차 있다. (p.197)
- 시간이 지나도 변치 않는 프로그래밍 방식
   건축가 크리스토퍼 알렉산더는 사람들이 자신을 위해 자신의 기후와 문화와 자기 필요에 유일하게 꼭 맞는 공간을 설계하고 짓는 법을 알았던, 그리 오랜 옛날은 아닌 시절에 대해 이야기 했다......건축가는 일을 빨리 끝내거나 건축상을 타고 싶을 뿐, 핵심 정보를 놓치고 있다. 그 정보는 바로 의뢰인이 어떻게 살기를 원하는가다. 알렉산더는 이 목표를 이루기 위한 수단으로 건축의 패턴을 수집해서, 집을 설계하고 지을 때 반복해서 일어난다고 알려진 문제점에 대한 좋은 해결방법으로 정리했다. 패턴은 절대로 그 자체가 목적이 아니었으며, 전문 설계가와, 설계된 공간에서 살며 일할 사람 사이에서 힘의 균형을 잡는 수단이었다.(p.215)
   


이 책을 읽은 다른 사람들(Other Readers)


목차(Table of Contents)
1장_ XP란 무엇인가?
1부 XP 탐험하기
2장_ 운전하는 법 배우기
3장_ 가치, 원칙, 실천방법
4장_ 가치
5장_ 원칙
6장_ 실천방법
7장_ 기본 실천방법
8장_ 시작하기
9장_ 보조 실천방법
10장_ 전체 XP 팀
11장_ 제약 이론
12장_ 계획 짜기: 범위를 관리하기
13장_ 테스트: 일찍, 자주, 자동화
14장_ 설계하기: 시간의 가치
15장_ XP 확장
16장_ 인터뷰
2부 XP의 철학
17장_ 창조 이야기
18장_ 테일러주의와 소프트웨어
19장_ 도요타 생산 시스템
20장_ XP 적용하기
21장_ 순수성
22장_ 해외 개발
23장_ 시간이 지나도 변치 않는 프로그래밍 방식
24장_ 공동체와 XP
25장_ 결론
주석을 단 참고문헌
철학
마음가짐
창발적인 프로세스
시스템
사람들
프로젝트 관리
프로그래밍
기타
반응형