이미 소장하고 있다면 판매해 보세요.
|
낭비요소를 제거하고 프로세스를 개선하여 속도 경쟁에서 승리하라.
|
|
한국어판 서문 추천의 말 - 제프 서더랜드 추천의 말 - 켄트 벡 머리말 1장 역사 교환 가능한 부품 대체 가능한 인력 도요다 가문 도요타 생산방식 오노 다이이치 적시생산흐름(Just-in-Time Flow) 자동화 (지도카) 신고 시게오 무재고 생산 무검사 적시 생산방식 린 린 생산방식 / 린 운영 린 공급망 린 제품 개발 린 소프트웨어 개발 시도해 볼 것 2장 원칙 원칙과 실천법 소프트웨어 개발 소프트웨어 개발 린 소프트웨어 개발의 7가지 원칙 원칙 1: 낭비를 제거하라 잘못된 통념: 스펙 조기 확정이 낭비를 줄인다 원칙2 : 품질을 내재화하라 잘못된 통념: 테스팅의 역할은 결함을 발견하는 것이다 원칙 3: 지식을 창출하라 잘못된 통념: 예측을 해야 예측이 가능해진다 원칙 4: 확정을 늦춰라 잘못된 통념: 계획을 세우는 것은 확정하는 것이다 원칙 5: 빨리 인도하라 잘못된 통념: 서두르는 것은 낭비를 낳는다 원칙 6: 사람을 존중하라 잘못된 통념: 유일한 최선의 방법이 존재한다 원칙 7: 전체를 최적화하라 잘못된 통념: 부분으로 나누어 최적화하라 시도해 볼 것 3장 가치 린 해법 구글 컨셉에서 현금까지(From Concept to Cash) 역주> 컨셉 사업성 검토 파일럿 프로젝트 현금 기뻐하는 고객 고객에 대한 깊은 이해 수행할 일에 포커스를 맞춰라 고객중심 조직 리더십 수석 엔지니어 리더십 팀 리더십 공유하기 누구의 책임인가? 완전한 팀 운영 용이성 설계 고객 주문에 의한 개발 프로젝트에서 제품으로 IT 부서와 기업의 협력 책임 시도해 볼 것 4장 낭비 코드를 더 적게 짜라 자라(Zara) 복잡도 모든 기능은 명분을 가져야 한다 최소한의 유용한 기능 집합 복잡한 것을 자동화하지 마라 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장 여정 어디로 가고 싶나요? 차량제어 컴퓨터 장기적 관점 인간 중심 우리가 배워온 것은? 식스시그마 프로세스 리더-실무 작업 팀 리더 도구-결과 제약이론 애로 사슬 관행 가설 훈련 사고 측정 주기 시간 투자 수익 고객 만족 로드맵 시도해 볼 것 |
|
2003년 『Lean Software Development: An Agile Toolkit』을 썼을 때, ‘린(Lean)’이라는 아이디어는 1990년대의 것을 가져온 것입니다. 저희는 제조와 물류에서 탄생한 획기적인 아이디어가 개발에 적용될 수 있기까지 10~20년이 걸린다는 것을 보아 왔습니다. 따라서 저희는 애자일 방법이 소프트웨어 개발에 효과적인 이유를 설명하기 위해, 80년대와 90년대부터 이미 충분히 입증된 린의 개념을 활용하는 것은 시대착오적인 발상이 아니라고 판단하였습니다.
그 전략은 먹혀들었습니다. 『Lean Software Development』는 리더들이 애자일 소프트웨어 개발을 이해하는데 유용하다고 계속해서 느껴온 린 사고에 기반한 사고의 도구들을 제시하고 있습니다. 책을 구입한 많은 개발자들이 그것을 자신의 관리자에게 주었고, 많은 관리자들이 린/애자일 소프트웨어 개발을 도입하려는 동료들에게 그 책을 선물하였습니다. 한편 ‘린’에 관해 예상치 못한 일이 일어났습니다. 최근 2년간 린 이니셔티브가 재조명받기 시작한 것입니다. ‘린’이라는 단어는 원래 90년대에 일본 자동차 제조방식의 특징을 나타내는 단어로 사용되면서 유명해졌습니다. 최근에 혼다와 도요타는 북미 자동차 시장에서 승승장구하고 있는 반면에, 디트로이트의 자동차 회사들은 구조조정을 겪고 있습니다. 예를 들어, 도요타의 수익은 2003년 3월 31일 회계년도 결산시 80억 달러를 넘었고 2004년에는 100억 달러 돌파, 2005년에는 110억 달러, 2006년에는 120억 달러를 기록했습니다. 많은 회사들이 그러한 꾸준하고 지속적인 성공 뒤에 무엇이 있는지 이해하기 위해 ‘린’을 새로운 시각으로 보게 된 것입니다. 린 이니셔티브가 회사의 소프트웨어 개발이나 제품개발 분야에서 시작되는 경우는 거의 없었습니다. 그러나 시간이 지나면서 성공적인 린 이니셔티브는 제조와 물류에서부터 출발하여 개발 부서로 나아가게 되었습니다. 하지만 제조나 기타 운영 부문에서 나온 린 실천법들은 개발에 쉽게 적용하기 어려웠습니다. 따라서 린 이니셔티브는 소프트웨어 개발에 다다르면 급격히 힘이 떨어지곤 했습니다. 린의 근본적인 원칙은 여전히 유효했지만 운영 부문의 실천법이나 지표들을 개발에 적용하는 것은 적절하지 않았습니다. 린 이니셔티브가 소프트웨어 개발 분야에서 힘을 잃고 있을 때, 많은 회사들이 『Lean Software Development』가 그들의 접근 방법을 수정하고 린 아이디어를 개발 조직에 적용하는 사고의 기반을 마련해 주었다고 합니다. 최근 몇 년간 린과 애자일 소프트웨어 개발 방법의 이점이 널리 알려지고 그 효과를 인정받게 되면서, 많은 회사가 그들의 소프트웨어 개발 방법을 바꾸고 있습니다. 저희는 이렇게 새로운 접근을 시도하는 세계 각국의 조직을 방문하였고, 거기서 소프트웨어 개발 방법을 바꾸기 위해 열심히 노력하는 사람들과의 상호작용을 통해 많은 것을 배웠습니다. 저희의 지식이 늘어나면서 동시에 린 소프트웨어 개발을 적용하기 위해서는 더 많은 정보가 필요하다는 요구도 늘어났습니다. 저희는 사람들을 일일이 직접 만나는 것보다 새로운 책 한 권을 씀으로써 더 많은 사람들에게 저희가 배운 것을 공유할 수 있다고 생각했습니다. 그래서 저희는 저희의 경험을 바로 이 책 『린 소프트웨어 개발의 적용: 속도 경쟁에서 승리하기』에 요약하였습니다. 이 책은 린 소프트웨어 개발을 구현하는 방법에 대한 ‘요리책’이 아닙니다. 전판과 마찬가지로 린 원칙을 어떻게 당신의 분야에 맞게 고쳐서 적용할 것인지에 대한 사고의 도구들을 소개합니다. 이 책은 지난 책의 연장선 상에서 출발하였으며, 린과 애자일 소프트웨어 개발을 구현하려고 시도할 때 사람들이 맞닥뜨리는 이슈와 문제들에 대해 더 깊이 파고듭니다. 이 책을 『Lean Software Development』의 속편으로 생각할 수도 있겠습니다. 그 책에 있는 내용을 반복하는 대신에 저희는 다른 관점을 취했습니다. 독자들이 린 소프트웨어 개발이 좋은 생각이라는 것을 확신한다고 가정하고, 성공적인 구현을 위한 필수 요소가 무엇인지에 중점을 두었습니다. 구현의 핵심 요소들을 살펴보고, 무엇이 중요하고 무엇이 중요하지 않은지, 왜 그런지에 대해 논의하였습니다. 저희의 목적은 조직이 더욱 효과적인 소프트웨어 개발의 길로 접어들도록 돕는 것입니다. 이 책의 첫 장은 ‘린’의 역사를 돌아보고, 둘째 장은 『Lean Software Development』에서 소개된 린 소프트웨어 개발의 7가지 원칙을 검토합니다. 그 후 ‘가치, 낭비, 속도, 사람, 지식, 품질, 파트너’ 그리고 ‘여정’에 대한 장이 이어집니다. 이 8개 장의 각각은 어떤 조직이 눈앞에 닥친 이슈를 어떻게 다루는지를 보여주는 사례로부터 시작합니다. 그 뒤에 중요하다고 생각되는 주요 주제에 대한 논의, 주제를 설명하는 짧은 이야기 그리고 저희가 자주 듣는 질문에 대한 답이 이어집니다. 각 장은 그 장의 주제들을 더 깊게 탐색하도록 도와주는 연습문제들로 마무리됩니다. -메리 포펜딕과 톰 포펜딕 --- 저자 서문 |