 |
추천의 글 (Kent Beck)
소프트웨어 개발은 많은 링크들로 이루어진 사슬이며, 전체 효과성을 향상시키기 위해서는 전체 사슬을 바라봐야 할 필요가 있습니다. 이 책은 프로그래머에 국한하지 않고 관리자, 스폰서, 고객, 테스터, 디자이너를 포함한 소프트웨어 개발에 참여하는 모든 사람들을 대상으로 쓰여졌습니다. 이 책에서 제시한 원칙들은 결국 소프트웨어 개발에 관련된 모든 사람들에게 영향을 미치게 됩니다. 이 책은 개발의 큰 그림을 보고자 하는 사람들을 대상으로 하고 있습니다.
영향력을 가진 아이디어는 이론과 경험 모두에 뿌리를 두고 있어야 합니다. 이 책은 린 생산방식에서 검증된 아이디어들을 재해석하여 이론과 실천법을 설명하고 이것들을 소프트웨어 개발에 적용합니다. 제조 분야의 많은 기본적 문제들은 소프트웨어 개발의 문제이기도 합니다. 불확실성과 변화를 다뤄야 하고, 지속적으로 프로세스를 개선해야 하며 고객에게 가치를 제공해야 합니다.
이 책이 여러분에게 제공하는 것은 무엇일까요? 첫째, 다양한 이론을 제공합니다. 이 이론들은 소프트웨어 개발을 어떻게 개선할 수 있는지 다양한 사고방식을 제공합니다. 둘째, 이론이 실제 프로젝트에 적용된 사례를 이야기해주고 있습니다. 셋째, 이야기 속에서 얻은 이론과 교훈을 여러분의 독특한 상황에 적용할 때 도움을 줄 자극적인 질문들을 제공합니다.
메리는 이러한 자료를 내놓을 수 있는 유일한 적임자입니다. 그녀는 린 생산방식을 직접 경험하였으며, 운영방식을 바꾸어 폐쇄 위기의 공장을 구해냈습니다. 또한 프로그래머와 관리자로서의 소프트웨어 개발도 경험하였습니다. 제가 메리의 세미나에 참석한 적이 있습니다. 준비한 강의자료를 발표하는 그녀의 힘과 자신감은 저를 무척 즐겁게 하였습니다. 저는 이 책에서 그 때와 같이 올곧은 그녀의 목소리를 들을 수 있습니다.
만약 포펜딕 부부의 이전 책인 『린 소프트웨어 개발』을 읽으셨다면 이 책이 그것을 구현하기 위한 새로운 길잡이가 되어줄 것입니다. 이전 책에서 다룬 이론을 되풀이하고 있지만 아이디어를 실제 상황에 적용하기 위한 노력을 기울였습니다. 그 결과 읽기쉽고 실무적인 지침들을 제공하고 있는데, 이 지침들은 여러분의 개발 환경을 변화시키는데 도움을 줄 잠재력 있는 아이디어들을 안내해 줄 것입니다.
이 책은 실천가를 위한 책입니다. 실천가는 최고의 행복을 추구하는 방향으로 자신의 행동을 일치시키려 합니다. 만약 여러분이 그런 실천가라면 저는 긍정적 변화 에너지와 아이디어의 근원으로 이 책을 강력히 추천합니다.
낭비요소를 제거하고 프로세스를 개선하여 속도 경쟁에서 승리하라.
우리가 흔히 들어왔던 도요타 방식하면 흔히 간판 시스템, JIT 시스템 등을 떠올리기 마련이다. 하지만 진정한 도요타 방식은 고유한 기업문화와 철학에서 나온다. 눈 앞에 이윤을 추구하기보다는 고객과의 신뢰, 종업원의 육성, 부품 개발 업체와의 협력 등 장기적인 철학에 기초하여 의사 결정을 한다. 이러한 철학을 바탕으로 각 프로세스 단계에서 낭비를 제거하여 리드 타임을 줄이고 안전성을 개선하면서 사기를 높여, 다른 경쟁 회사보다 월등히 높은 품질과 생산성을 이룩한 것이다. 이 책은 린이라고 불리는 도요타 생산 방식을 소프트웨어 개발의 세계로 들여온 책이다. 내용면에서 소프트웨어를 효율적으로 개발하기 위한 프로세스 개선에 중점을 두고 있지만, 동시에 소프트웨어 개발 업계에서 개발자와 고객이 함께 만들어 나가야 할 철학을 제시하고 있다.
이 책은 린과 애자일 소프트웨어 개발을 구현하려고 할 때 맞닥뜨리는 이슈와 문제들에 대해 깊이있게 파고든다.
소프트웨어 개발에서의 딜레마는 품질과 일정이라는 서로 양립하기 어려운 목표를 달성하는 것이다. 촉박한 일정을 좇다 보면 품질 활동을 할 여력이 부족하고, 품질 활동을 강조하다 보면 일정이 많이 소요된다는 것이 그동안의 통념이지만, 이 책은 이런한 통념을 단번에 뒤집는다. 속도의 경쟁력을 갖춘 회사는 그들의 경쟁사에 비해 현저한 비용 우위를 가질 뿐만 아니라 결점율이 극단적으로 낮다. 이 책에서 제시하는 7가지 원칙과 풍부한 실제 사례, 그리고 당장 실천 가능한 도구들을 활용하여 이 두마리 토끼를 모두 잡아 보자. 저자는 자동차 제조업체인 도요타의 혁신사상을 소프트웨어 개발에 적용하려고 노력하였고 이미 『린 소프트웨어 개발』을 통해 수많은 회사를 컨설팅하였다. 이 책은 린 원칙을 어떻게 당신의 분야에 맞게 고쳐서 적용할 것인지에 대한 사고의 도구들을 소개하며, 다양한 사례와 고민할 주제들을 던져준다.
Mary Poppendieck
메리 포펜딕은 30년 이상의 IT 경험을 가진 운영 및 제품 개발에 능숙한 리더입니다. 그녀는 기업 공급망 관리 시스템부터 디지털 미디어에 이르는 다양한 솔루션의 개발 팀의 리더를 맡아왔습니다. 3M 에서 있을 당시 처음으로 Just-in-Time 린 생산 시스템을 구축하기도 하였습니다. 메리는 소프트웨어 개발에 린 기법을 적용하고 있는 Poppendieck LLC 의 대표를 맡고 있습니다.Tom Poppendieck
톰 포펜딕은 25년의 경력을 가진 기업 분석가이자 아키텍트이며 애자일 프로세스 멘토입니다. 현재 그는 조직이 린 원칙과 툴을 소프트웨어 개발 프로세스에 적용하는 것을 돕고 있습니다.
포펜딕 부부가 쓴 『린 소프트웨어 개발』은 2004년 졸트 소프트웨어 개발 생산성 상을 수상하였습니다.
엄위상
포항공과대학교 기계공학과와 광주과학기술원 기전공학과를 졸업했으며, 현재 LG전자 생산연구원 시스템엔지니어링 그룹에 근무한다. 6σ Master Black Belt, CSQE, PSP Instructor authorized by SEI.
심우곤 http://www.wgshim.com
아주대학교 정보통신전문대학원 박사과정을 수료하고, 현재 LG전자 생산연구원 시스템엔지니어링 그룹에서 근무한다. 번역서로 『XML 포켓 컨설턴트』(정보문화사), 『자바의 또 다른 멋진 도구 Ant(앤트)』(인포북), 『사용자스토리』(인사이트)가 있다. http://www.wgshim.com
한주영 http://blog.jooyunghan.com
포항공과대학교 산업공학과에서 석사학위를 취득했으며, 현재 LG전자 생산연구원 시스템엔지니어링 그룹에 근무한다. 번역서로 『사용자스토리』(인사이트)가 있다.
추천의 말 - 제프 서더랜드
추천의 말 - 켄트 벡
머리말
1장 역사
교환 가능한 부품 대체 가능한 인력
도요다 가문
도요타 생산방식
오노 다이이치
적시생산흐름(Just-in-Time Flow)
자동화 (지도카)
신고 시게오
무재고 생산
무검사
적시 생산방식
린
린 생산방식 / 린 운영
린 공급망
린 제품 개발
린 소프트웨어 개발
시도해 볼 것
2장 원칙
원칙과 실천법 소프트웨어 개발
소프트웨어
개발
린 소프트웨어 개발의 7가지 원칙
원칙 1: 낭비를 제거하라
잘못된 통념: 스펙 조기 확정이 낭비를 줄인다
원칙2 : 품질을 내재화하라
잘못된 통념: 테스팅의 역할은 결함을 발견하는 것이다
원칙 3: 지식을 창출하라
잘못된 통념: 예측을 해야 예측이 가능해진다
원칙 4: 확정을 늦춰라
잘못된 통념: 계획을 세우는 것은 확정하는 것이다
원칙 5: 빨리 인도하라
잘못된 통념: 서두르는 것은 낭비를 낳는다
원칙 6: 사람을 존중하라
잘못된 통념: 유일한 최선의 방법이 존재한다
원칙 7: 전체를 최적화하라
잘못된 통념: 부분으로 나누어 최적화하라
시도해 볼 것
3장 가치
린 해법 구글
컨셉에서 현금까지(From Concept to Cash) </역주>
컨셉
사업성 검토
파일럿 프로젝트
현금
기뻐하는 고객
고객에 대한 깊은 이해
수행할 일에 포커스를 맞춰라
고객중심 조직
리더십
수석 엔지니어
리더십 팀
리더십 공유하기
누구의 책임인가?
완전한 팀
운영 용이성 설계
고객 주문에 의한 개발
프로젝트에서 제품으로
IT 부서와 기업의 협력
책임
시도해 볼 것
4장 낭비
코드를 더 적게 짜라 자라(Zara)
복잡도
모든 기능은 명분을 가져야 한다
최소한의 유용한 기능 집합
복잡한 것을 자동화하지 마라</h4
7대 낭비
미완성 작업
가외 기능(Extra Features)
재학습
이관(Handoffs)
작업 전환
지연
결함
가치흐름도 그리기
준비
가치흐름을 선택하라
시각표의 시작과 끝을 결정하라
가치흐름의 소유자를 확인하라
간결하게 유지하라
사례
사례 1
사례 2
사례 3
사례 4
진단
미래의 가치흐름도
시도해 볼 것
5장 속도
빨리 인도하라. 페이션트키퍼(PatientKeeper) 社
시간,: 보편적 가치기준
대기행렬 이론
Little의 법칙
변동과 가동률
주기 시간(cycle time) 줄이기
일이 균일하게 도착하도록 하라
진행중인 작업의 수를 최소화하라
진행중인 작업의 크기를 최소화하라
일정한 리듬을 가져라
일을 할 수 있는 만큼으로 제한하라
풀 스케줄링 (Pull Scheduling)을 사용하라
요약
시도해 볼 것
6장 사람
경영 시스템 보잉 777
W. 에드워즈 데밍
좋은 프로그램들이 실패하는 이유
팀
팀은 어떻게 만들어지는가?
전문적 지식
리더십
책임 기반의 계획과 통제
시각적 작업 공간
자기지시적 업무
간판
안돈
대시보드
인센티브
성과 평가
평가 순위
보상
지침1: 승진의 체계는 이론의 여지가 없도록 하라
지침2: 연간 급여 인상의 비중을 낮춰라
지침3: 통제 범위보다는 영향 범위를 근거로 보상하라
지침4: 돈보다 더 나은 동기 유발자를 찾아라
시도해 볼 것
7장 지식
지식 창출 랠리
문제가 정확히 무엇인가?
과학적 사고
지식 추적
A3 보고서
인터넷 시대
적시 확정
집합 기반 설계
사례1: 의료 장비 인터페이스 설계
사례2: 적목 감소
사례3: 플러그인 방식의 인터페이스
왜 낭비가 아닌가?
리팩터링
레거시 시스템
문제 해결
잘 정의된 접근 방법
1. 문제를 정의한다
2. 상황을 분석한다
3. 가설을 세운다
4. 실험을 실시한다
5. 결과를 확인한다
6. 후속조치를 취하고 표준화한다
개선 이벤트
대 그룹 개선 이벤트
시도해 볼 것
8장 품질
피드백 폴라리스(Polaris) 프로그램 (주 2)
릴리스 계획
아키텍처
이터레이션(Iteration)
준비
계획수립
구현
평가
변동: 사용자 인터페이스
규범(Discipline)
5 S
표준
코드 리뷰
짝짓기
실수 방지
자동화
테스트 주도 개발
단위 테스트 (혹은 프로그래머 테스트로도 불림)
스토리 테스트 (인수 테스트로도 불림)
사용성 테스팅과 탐색적 테스팅
특성 테스트
형상 관리
지속적 통합
중첩된 동기화
시도해 볼 것
9장 파트너
시너지 위급상황!
오픈소스
글로벌 네트워크
외주
인프라
트랜잭션
개발
계약
T5 계약
PS 2000 계약
관계형 계약
시도해 볼 것
10장 여정
어디로 가고 싶나요? 차량제어 컴퓨터
장기적 관점
인간 중심
우리가 배워온 것은?
식스시그마
프로세스 리더-실무 작업 팀 리더
도구-결과
제약이론
애로 사슬
관행
가설
훈련
사고
측정
주기 시간
투자 수익
고객 만족
로드맵
시도해 볼 것
xviii쪽 첫 째 단락 6째줄
'지성를' ---> '지성을'
---> '지성를'을 '지성을'로 고칩니다. -위키북스-
p.66쪽
그 팀 멤버들은 전부터 같이 일한 적이 있었다. ---> 그 팀 멤버들은 전에도 같이 일한 적이 있었다.---> '전부터'를 '전에도'로 수정합니다. -최재훈-
p.66쪽
그동한 ---> 그동안
p.73쪽
그 보다는 ---> 그보다는
p.93쪽
을때(이것의 ---> 을 때(이것의
p.95쪽
걸리는 지 ---> 걸리는지
p.95쪽
옮겨가기 까지 ---> 옮겨가기까지
p.95쪽
만족시키기 까지의 ---> 만족시키기까지의
p.98쪽
작성되었을때는 ---> 작성되었을 때는
p.109쪽
이 시나리오 에서 ---> 이 시나리오에서---> 이상 띄어쓰기 정정 -최재훈-
p.115쪽
장애 발생를 ---> 장애 발생을
p.123쪽
짧아으면서도 ---> 짧으면서도
p.240쪽 맨 마지막 줄에서
향후 커미터ㅕ까지 ---> 향후 커미터까지---> -임세영-
281쪽 Astels, David 의 책 관련
수상도서 ---> 졸트상 수상도서---> 수상도서는 졸트상 수상도서를 말합니다. -강석천-
286쪽 밑에서 두번째 줄
도요타 생산방식--->'방' 글자가 깨진 문자로 표시되어 있습니다. -강석천-
288쪽 'Developing Products in Half the Time' 의 설명중
아직도 쾌속 제품 개발에 대한 고전으로 ---> 여전히 쾌속 제품 개발에 대한 고전으로---> '아직도'를 '여전히'로 정정합니다. -강석천-
도서 소개자료
위키북스
새로 낸 책
 |
곧 낼 책
 |
 |
 |
 |