애자일Agile, 어디서부터 시작되었을까
0 likes146 views
애자일Agile, 익스트림 프로그래밍Extreme Programming, 도요타 생산 방식Toyota Production System의 연관성에 대한 발표 자료입니다. 각 장 별로 블로그에 설명을 달아 놓았으니 설명이 궁금하신 분들은 https://taptorestart.tistory.com/entry/%E1%84%8B%E1%85%A2%E1%84%8C%E1%85%A1%E1%84%8B%E1%85%B5%E1%86%AF-%E1%84%8B%E1%85%A5%E1%84%83%E1%85%B5%E1%84%89%E1%85%A5%E1%84%87%E1%85%AE%E1%84%90%E1%85%A5-%E1%84%89%E1%85%B5%E1%84%8C%E1%85%A1%E1%86%A8%E1%84%83%E1%85%AC%E1%84%8B%E1%85%A5%E1%86%BB%E1%84%8B%E1%85%B3%E1%86%AF%E1%84%81%E1%85%A1 블로그 글을 보시기 바랍니다.
애자일Agile, 어디서부터 시작되었을까
- 2. 애자일Agile?
- 3. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 출처: https://agilemanifesto.org
- 4. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
- 5. 애자일 소프트웨어 개발 선언 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다: 공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다. 출처: https://agilemanifesto.org
- 6. Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project.
- 7. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential.
- 8. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 출처: https://agilemanifesto.org/iso/en/principles.html
- 9. 애자일 선언 이면의 원칙 우리는 다음 원칙을 따른다: 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
- 10. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다. 작동하는 소프트웨어가 진척의 주된 척도이다. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다. 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다. 출처: https://agilemanifesto.org/iso/ko/principles.html
- 11. History: The Agile Manifesto
- 12. ... Naming ourselves "The Agile Alliance," this group of independent thinkers about software development, and sometimes competitors to each other, agreed on the Manifesto for Agile Software Development displayed on the title page of this web site. ... 출처: https://agilemanifesto.org/history.html
- 13. ... 우리는 "The Agile Alliance(애자일 연합)"이라는 이름 아래, 소프트웨어 개발에 대해 독립적으로 사고하는 사람들이며 때때로 서로 경쟁자이기도 한 이 그룹이, 이 웹사이트의 첫 페이지에 실린 애자일 소프트웨어 개발 선언문에 동의하였다. ... 출처: https://agilemanifesto.org/history.html
- 14. Agile Alliance
- 16. On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened. 출처: https://agilemanifesto.org/history.html
- 17. 2001년 2월 11일부터 13일까지, 유타 주 와사치 산맥에 위치한 스노우버드 스키 리조트의 더 로지에서 열일곱 명의 사람들이 모여 이야기를 나누고, 스키를 타고, 휴식을 취하며, 공통된 기반을 찾으려 노력했고 — 물론 식사도 함께했다. 그 결과 탄생한 것이 바로 애자일 소프트웨어 개발 선언문이다. 익스트림 프로그래밍 (Extreme Programming), 스크럼(SCRUM), DSDM, 적응형 소프트웨어 개발 (Adaptive Software Development), 크리스탈(Crystal), 기능 주도 개발 (Feature-Driven Development), 실용주의 프로그래밍(Pragmatic Programming) 등의 대표자들과 문서 중심의 무거운 소프트웨어 개발 방식에 대안을 찾고자 하는 이들이 한자리에 모였다. 출처: https://agilemanifesto.org/history.html
- 18. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Extreme Programming SCRUM DSDM Adaptive Software Development Crystal Feature-Driven Development Pragmatic Programming SCRUM Extreme Programming Pragmatic Programming SCRUM Extreme Programming Extreme Programming Extreme Programming Extreme Programming Extreme Programming
- 19. Agile Alliance Extreme Programming SCRUM DSDM(Dynamic Systems Development Method) Adaptive Software Development Crystal Feature-Driven Development Pragmatic Programming VS document driven heavyweight software development
- 20. Alliance Extreme Programming Agile SCRUM DSDM Adaptive Software Development Crystal Feature-Driven Development Pragmatic Programming
- 21. SCRUM Ken Schwaber 『Agile Project Management with Scrum』, 2009. Jeff Sutherland 『The Art of Doing Twice the Work in Half the Time』, 2014. "Scrum is based on: Toyota. And, more specifically, Taiichi Ohno’s Toyota Production System." The Art of Doing Twice the Work in Half the Time (p. 22). (Function). Kindle Edition. Sprint Daily Scrum Meeting Sprint Retrospective Meeting
- 22. XP(Extreme Programming) 『Extreme Programming Explained』, 2005. Chapter 18. Taylorism and Software Chapter 19. Toyota Production System Extreme Programming (XP) is about social change. It is about letting go of habits and patterns that were adaptive in the past, but now get in the way of us doing our best work. It is about giving up the defenses that protect us but interfere with our productivity. Beck, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change (XP Series) (p. 26). (Function). Kindle Edition. 익스트림 프로그래밍(XP)은 사회적 변화에 관한 것이다. 과거에는 유용했지만 이제는 최고의 작업을 방해하는 습관과 패턴을 내려놓는 것에 관한 이야기다. 생산성을 방해하면서도 우리를 보호해주던 방어 수단들을 포기하는 것에 관한 이야기다.
- 23. Alliance Extreme Programming Agile SCRUM DSDM Adaptive Software Development Crystal Feature-Driven Development Pragmatic Programming Toyota Production System (Lean Production) Taylorism & Fordism The Division of Labour Production Systems
- 24. 분업 The Division of Labour But though they were very poor, and therefore but indifferently accommodated with the necessary machinery, they could, when they exerted themselves, make among them about twelve pounds of pins in a day. There are in a pound upwards of four thousand pins of a middling size. Those ten persons, therefore, could make among them upwards of forty-eight thousand pins in a day. (...) But if they had all wrought separately and independently, and without any of them having been educated to this peculiar business, they certainly could not each of them have made twenty, perhaps not one pin in a day; 출처: Smith, Adam. An Inquiry into the Nature and Causes of the Wealth of Nations (Crofts Classics) (Function). Kindle Edition.
- 25. 분업 The Division of Labour 하지만 그들은 매우 가난했기 때문에 필요한 기계도 제대로 갖추지 못한 상태였다. 그럼에도 불구하고, 그들이 힘을 합쳐 열심히 일하면 하루에 약 12파운드의 핀을 만들어낼 수 있었다. 중간 크기의 핀은 1파운드당 4,000 개가 넘는다. 따라서 그 열 명은 하루에 48,000개가 넘는 핀을 생산할 수 있었던 것이다. (...) 그러나 만약 그들이 각자 따로따로, 독립적으로 일하고, 이 특수한 작업에 대해 교육도 받지 않은 상태였다면, 각자가 하루에 20개는커녕, 어쩌면 핀 하나도 만들지 못했을 것이다.
- 26. 산업혁명 Industrial Revolution Adam Smith(1723~1790) Beginning in Great Britain around 1760, the Industrial Revolution had spread to continental Europe and the United States by about 1840. 출처: https://en.wikipedia.org/wiki/Industrial_Revolution
- 27. 『The Machine That Changed the World』, 1990 After World War I, Henry Ford and General Motors’ Alfred Sloan moved world manufacture from centuries of craft production—led by European firms—into the age of mass production. Largely as a result, the United States soon dominated the global economy. After World War II, Eiji Toyoda and Taiichi Ohno at the Toyota Motor Company in Japan pioneered the concept of lean production. The rise of Japan to its current economic preeminence quickly followed, as other Japanese companies and industries copied this remarkable system. 출처: Womack, James P.; Jones, Daniel T.. The Machine That Changed the World: The Story of Lean Production-- Toyota's Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry ... That Is Revolutionizing World Industry) (pp. 9-10). (Function). Kindle Edition.
- 28. 『The Machine That Changed the World』 제1차 세계대전 이후, 헨리 포드와 제너럴 모터스의 알프레드 슬로언은 유럽 기업들이 주도하던 수세기 동안의 공예 생산(craft production) 체계를 넘어, 세계 제조업을 대량 생산(mass production)의 시대로 이끌었다. 그 결과 미국은 곧 세계 경제를 지배하게 되었다. 제2차 세계대전 이후, 일본 도요타자동차의 도요다 에이지와 오노 다이이치는 린 생산 개념을 개척했다. 다른 일본 기업과 산업들이 이 놀라운 시스템을 모방하면서, 일본은 빠르게 오늘날의 경제 강국으로 부상하게 되었다.
- 29. 『The Machine That Changed the World』 NA = North America: United States and Canada E = Western Europe, including Scandinavia J = Japan NIC = Newly industrializing countries, principally Korea, Brazil, and Mexico ROW = Rest of the world, including the Soviet Union, Eastern Europe, and China Womack, James P.; Jones, Daniel T.. The Machine That Changed the World: The Story of Lean Production-- Toyota's Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry ... That Is Revolutionizing World Industry) (p. 42). (Function). Kindle Edition.
- 30. 테일러리즘 Taylorism Scientific Management 과학적 관리 Frederick Taylor Time and motion study
- 31. 테일러주의식 사회공학의 첫 번째 단계는 계획과 실행의 분리다. 일하는 방법과 일하는 데 걸리는 시간을 결정하는 사람은 교육받은 공학자다. 작업자들이 주어진 과업을 주어진 방법으로 할당된 시간 동안 충실히 따른다면 모든 일이 잘 될 것이다. 작업자는 기계 부품이다. 그러나 아무도 자신을 부품으로 생각하고 싶어 하지 않는다. (중략) 테일러주의식 사회공학의 두 번째 단계는 품질 부서를 따로 두는 것이다. 테일러는 작업자들은 할 수만 있다면 언제나 '꾀를 부린다' (느리게 일하거나 형편없이 일하지만, 그 사실이 눈치채일 정도는 아니게 일한다)고 생각했다. 그는 품질의 적정 수준을 달성하기 위해 품질 관리 부서를 별도로 만들어 작업자들이 적절한 속도로 일하는지 뿐 아니라 정해진 방식대로 일하는지도 확실하게 했다. 품질 조직을 별도로 둔다는 점에서 많은 소프트웨어 개발 조직이 바로 테일러주의자다. (심지어 그 사실을 자랑스러워하기도 한다.) 품질 부서를 따로 두는 일은 우리가 품질을 정확히 공학engineering이나 마케팅이나 판매만큼 중요하게 여긴다는 메시지를 전달한다. 그러나 그렇게 하면 공학 부서의 누구도 품질에 대해서는 책임을 지지 않게 된다. 책임은 다른 누군가에게 있다. 공학 조직에서 QA를 별도 부서로 둔다면, 공학과 품질은 별개의 활동이며, 병렬적인 활동이라는 메시지 또한 함께 전달하는 셈이다. 품질과 공학을 조직 구조에서 분리한다면 품질 부서가 하는 일의 성격이 건설적이 아니라 징벌적이 되어버린다. 출처: 켄트 벡·신시아 안드레스, 『익스트림 프로그래밍』, 김창준·정지호 옮김, 서울: (주)도서출판인사이트, 2006, p.192-193. XP에서 본 테일러리즘 Taylorism
- 32. 포디즘 Fordism 출처: https://en.wikipedia.org/wiki/Ford_Model_T Model T Over 15 million sold
- 33. 도요타 생산 방식 Toyota Production System 사실 도요타 생산방식은 도요타의 직원들이 다섯 번이나 왜를 반복하고, 이를 과학적으로 접근한 데서 비롯된 산물이다. 다섯 번의 왜를 자문자답함으로써 사물의 인과관계라든가 그 내부에 감춰진 문제의 진정한 원인을 찾아낼 수 있다. (중략) '왜 과잉 생산의 낭비가 발생하지?'라는 의문에는 '과잉 생산을 억제하는 과정이 없다' 라는 첫 번째 답을 풀어내야 '눈으로 보는 관리'에서 간판까지 계속해서 생각을 이어갈 수 있다. 도요타 생산방식은 철저한 낭비 배제를 근본으로 한다. 출처: 오노 다이이치, 『도요타 생산방식』, 김현영 옮김, 서울: (주)미래사, 2004, p.44-45.
- 34. 도요타 생산방식을 적용하려면 먼저 다음과 같은 낭비를 철저히 배제해야 한다. (1)과잉 생산의 낭비, (2)기다림의 낭비, (3)운반의 낭비, (4)가공 그 자체의 낭비, (5)재고의 낭비, (6)동작의 낭비, (7)불량품을 만드는 낭비 출처: 『도요타 생산방식』, p.48. 도요타 생산 방식 Toyota Production System
- 35. 도요타 생산방식의 기본 사상은 '철저한 낭비의 배제'다. 여기에 덧붙여 빼놓을 수 없는 두 기둥이 있다. (1) 저스트 인 타임(Just in time) (2) 자동화自働化 '저스트 인 타임'이란 자동차 한 대를 흐름 작업으로 만들 때 필요한 부품이, 필요한 때에, 필요한 양만큼 생산라인 옆에 도착한다는 말이다. 출처: 『도요타 생산방식』, p.21. 도요타 생산 방식 Toyota Production System
- 36. 기존에는 '앞 공정이 뒤 공정으로 물건을 공급한다'고 생각했다. 생산라인에서 재료를 가공해 부품을 만들고, 이 부품을 모아 또 다른 부품을 만들고, 마지막 조립라인을 거쳐 자동차를 완성하는 과정이 앞 공정에서 뒤 공정으로 흘러가는 흐름 안에서 진행되었다. 그런데 이 생산 흐름을 '뒤 공정이 앞 공정으로 필요한 것을, 필요한 때에, 필요한 양만큼 인수해 간다'고 반대로 생각해 보면 어떨까? '앞 공정은 내어준 양만큼만 만들면' 되지 않을까? 이때 뒤 공정은 앞 공정에서 '무엇을 얼마만큼' 원하는지 확실하게 알려주어야 한다. 그럼 이를 위한 수단을 '간판'이라 칭하고, 각 공정 사이를 돌아다니게 하면서 생산량 즉 필요량을 조절하게 하면 어떨까? 출처: 『도요타 생산방식』, p.22-23. 도요타 생산 방식 Toyota Production System
- 37. '간판'이란 도요타 생산방식의 첫째 기둥을 이루는 저스트 인 타임을 실현하기 위한 관리 수단이다. 사각 비닐 안에 작은 종잇조각을 넣은 형태를 가장 많이 쓰는데, 이 종이에는 '무엇을 얼마만큼 인수하는가', 또한 '무엇을 얼마만큼 만드는가'가 표시되어 있다. 뒤 공정이 앞 공정에 필요한 물품을 필요한 때에 필요한 양만큼 인수하러 가고, 앞 공정은 그 인수된 양만큼만 보충하는 체계가 저스트 인 타임 생산이다. 이 때 뒤 공정이 앞 공정에 인수하러 가는 이 사이를 '인수 정보' 또는 '운반 지시 정보'로서 이어주는 수단이 '인수 간판' 또는 '운반 간판'이다. (중략) 간판은 인간의 의사가 담긴, 이른바 '정보'다. 출처: 『도요타 생산방식』, p.212. 도요타 생산 방식 Toyota Production System
- 38. 간판 看板 かんばん kanban 출처: https://www.atlassian.com/software/jira/templates/kanban
- 39. 저스트 인 타임(Just In Time) 자동차 한 대를 흐름 작업으로 만들 때 필요한 부품이, 필요한 때에, 필요한 양만큼 생산라인 옆에 도착하는 것 '뒤 공정이 앞 공정으로 필요한 것을, 필요한 때에, 필요한 양만큼 인수'해 가는 방식 출처: 『도요타 생산방식』, p.23. 도요타 생산 방식 Toyota Production System
- 40. 스위치만 누르면 자동으로 움직이는 기계는 얼마든지 많다. 최근에는 기계의 성능도 좋아지고 작업 속도도 빨라져 약간의 이상만 발생해도, 예컨대 기계 안에 이물질이 들어가거나 낡아 자칫 오작동을 일으키면 설비나 제품 형태를 망가뜨려 엄청난 불량품이 생산된다. 이러한 자동自動기계로는 불량품 생산을 방지할 수도, 기계가 자동으로 고장을 검사할 수도 없어 곤란하다. 도요타가 단순한 자동화自動化가 아닌 '사람인 변이 붙은 자동화'를 강조하는 까닭은 이 때문이다. 출처: 『도요타 생산방식』, p.25. 도요타 생산 방식 Toyota Production System
- 41. 도요타에서 사람인 변이 붙은 자동기계는 '자동 정지 장치가 부착된 기계'를 뜻한다. 도요타의 어느 공장에 가든, 그것이 새 것이든 헌 것이든 간에 대부분의 기계 설비에는 자동 정지 장치가 부착된다. 예컨대, '정위치 정지 방식'이나 '풀워크 시스템', '바카요케' 등과 같은 안전장치가 그러하다. 이 자동기에 사람인 변을 붙인다는 생각은 관리 측면에서도 변화를 일으킨다. 작업자는 평소 다른 업무를 보다가 무언가 이상이 생겨 기계가 멈춰 섰을 때만 문제를 해결해 주면 된다. 따라서 작업자 한 사람이 기계 여러 대를 관리하므로 인원수가 줄어들고, 생산 효율이 비약적으로 향상된다. 출처: 『도요타 생산방식』, p.26. 도요타 생산 방식 Toyota Production System
- 42. '바카요케(バカヨケ, 바보(バカ) 방지(ヨケ)란 뜻으로, 오작동과 오조작을 검출해 안정성을 확보하는 장치) ' 등과 같은 자동 정지 장치가 부착된 기계를 사용 출처: 『도요타 생산방식』, p.26. 도요타 생산 방식 Toyota Production System
- 43. 자동화自働化 도요타 생산방식의 자동화는 自動化가 아니라 동자에 사람인亻변이 붙은 自働化 도요타에서 사람인 변이 붙은 자동기계는 '자동 정지 장치가 부착된 기계'를 말하며 작업자는 평소 업무를 보다가 무언가 이상이 생기면 기계를 멈추고 문제를 드러냄 출처: 『도요타 생산방식』, p.25~27. 도요타 생산 방식 Toyota Production System
- 44. XP(Extreme Programming) XP가 여타 방법론과 다른 점은 다음과 같다. ·짧은 개발 주기, 개발 초기부터 구체적이고 지속적인 반응을 얻게 해준다. ·점진적 계획 접근방법. XP에서는 전반적인 계획을 빨리 만들고 시작한 다음, 프로젝트의 생애 내내 그 계획이 진화해 가리라 기대한다. ·기능 구현 일정을 유연하게 세워 자주 바뀌는 비즈니스 쪽의 요구에 대응할 수 있는 능력. ·자동화된 테스트에 의존하는 점. 개발의 진전 상황을 관찰하고, 시스템이 진화할 수 있도록 만들고, 초기부터 결함을 잡을 수 있도록 프로그래머, 고객, 테스터들이 자동화된 테스트를 작성한다. ·구두 전달, 테스트, 소스 코드에 의존하여 시스템 구조와 시스템의 의도를 전달하는 점. ·시스템이 존재하는 마지막 순간까지 끝나지 않는 진화적인 설계 절차에 의존하는 점. ·재능은 평범하더라도 열심히 참여하는 개인들 사이의 긴밀한 협력에 의존하는 점. ·팀 구성원들의 단기적 본능과 프로젝트의 장기적 이해관계 둘 다에 함께 적용될 수 있는 실천방법들에 의존하는 점. 출처: 『익스트림 프로그래밍』, p.24-25.
- 45. 애자일 소프트웨어 개발 선언 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다: 공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다. 출처: https://agilemanifesto.org
- 46. XP(Extreme Programming) TPS의 정신적 지도자인 오노 다이이치는 과잉 생산의 낭비가 가장 큰 낭비라고 말한다. 만약 어떤 물건을 만들었는데 그것을 팔지 못하면, 그 물건을 만드는 데 들어간 노력은 사라져 버린다. (중략) 소프트웨어 개발은 과잉 생산의 낭비로 가득 차 있다. 금세 쓸모없어지는 두꺼운 요구사항 문서, 절대 쓰지 않는 정교한 아키텍처, 통합하지도 테스트하지도 않고 실제 출시될 환경에서 실행해 보지도 않은 채 몇 달이나 개발하는 코드, 아무도 읽지 않은 채 시간이 지나 부적절해지거나 혹은 잘못된 정보를 주는 문서가 그것이다. 물론 이런 모든 활동은 소프트웨어 개발에서 중요한 활동들이지만, 낭비를 제거하기 위해 필요한 피드백을 받으려면 우리는 이런 활동들의 결과물을 즉시 사용해야 한다. 예를 들어 요구사항 수집은 요구사항 수집 절차를 더 정교하게 만들 때 개선되는 것이 아니라, 요구사항 세부내용을 만드는 일과 명세된 소프트웨어를 배치하는 일 사이의 경로를 짧게 만들 때 개선된다. 요구사항의 세부 사항을 즉시 사용한다는 말에는, 요구사항 수집이 정적인 문서를 만드는 어떤 단계가 아니라, 개발하는 내내 세부 내용이 필요하기 직전에 그것을 생산하는 활동이라는 뜻이 들어 있다. 출처: 『익스트림 프로그래밍』, p.197.
- 47. XP(Extreme Programming) 한 번에 일주일 분량의 일을 계획하라. 한 주를 시작하는 회의를 열며, 이 회의에서는 다음과 같은 일을 한다. 1. 지금까지 진행된 상황을 검토하는데, 지난주의 실제 진행 정도가 예상 진행 정도를 달성했는지 역시 포함해 검토한다. 2. 이번 주에 구현할 일주일 분의 스토리를 고객이 고르도록 한다. 3. 스토리를 여러 과업으로 쪼갠다. 팀 구성원들은 자기가 할 과업에 서명을 하고, 얼마나 걸릴지 추정한다. 스토리들이 완성되었을 경우 통과할 자동화 테스트들을 작성하는 것으로 한 주를 시작하라. 그것이 끝난 다음에 남은 시간을 스토리들을 완성하고 테스트를 통과할 수 있도록 만드는 데 쓴다. 자기 일에 자부심을 느끼는 팀이라면, 테스트를 겨우 통과하는 정도에 구현을 끝내버리지 않고 스토리를 완전하게 구현하려 할 것이다. 우리 목표는 일주일이 끝나갈 때 배치가능한 소프트웨어를 가지게 되어서 모두 진전이 있었다고 기뻐하는 것이다. 출처: 『익스트림 프로그래밍』, p.84-85.
- 48. XP(Extreme Programming) 테스트 주도 개발에서는 ·오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다. ·중복을 제거한다. 는 두 가지 단순한 규칙만을 따른다. (중략) 또한 위 두 가지 규칙에 의해 프로그래밍 순서가 다음과 같이 결정된다. 1. 빨강 ― 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다. 2. 초록 ― 빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋다. 3. 리팩토링 ― 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복을 제거한다. 빨강/초록/리팩토링은 TDD의 주문과도 같은 것이다. 출처: 켄트 벡, 『테스트 주도 개발』, 김창준·강규영 옮김, 서울: (주)도서출판인사이트, 2005, p.22-23.
- 49. XP(Extreme Programming) 실패하는 테스트를 통과시키기 위해 필요한 만큼만 코딩하는 것은 다음과 같은 사회적 함의도 갖게 될 것이다. ·결함 밀도를 충분히 감소시킬 수 있다면, 품질보증(QA)를 수동적인 작업에서 능동적인 작업으로 전환할 수 있다. ·고약한 예외 상황의 숫자를 충분히 낮출 수 있다면, 프로젝트 매니저가 정확히 추정할 수 있어 고객을 매일의 개발 과정에 참여시킬 수 있다. ·기술적 대화의 주제가 충분히 분명해질 수 있다면, 소프트웨어 엔지니어들은 일일 단위 혹은 주 단위의 협력 대신 분 단위로 협력하면서 일할 수 있다. ·한번 더, 결함 밀도가 충분히 낮아진다면, 새 기능의 선적 가능한 소프트웨어를 매일 갖게 되고, 이를 통해 고객과 새로운 비즈니스 관계에 이를 수 있다. 출처: 『테스트 주도 개발』, p.23-24.
- 50. 저스트 인 타임(Just In Time) 자동차 한 대를 흐름 작업으로 만들 때 필요한 부품이, 필요한 때에, 필요한 양만큼 생산라인 옆에 도착하는 것 '뒤 공정이 앞 공정으로 필요한 것을, 필요한 때에, 필요한 양만큼 인수'해 가는 방식 출처: 『도요타 생산방식』, p.23. 도요타 생산방식 XP(Extreme Programming) 2. 이번 주에 구현할 일주일 분의 스토리를 고객이 고르도록 한다. 3. 스토리를 여러 과업으로 쪼갠다. 팀 구성원들은 자기가 할 과업에 서명을 하고, 얼마나 걸릴지 추정한다. 스토리들이 완성되었을 경우 통과할 자동화 테스트들을 작성하는 것으로 한 주를 시작하라. 출처: 『익스트림 프로그래밍』, p.85.
- 51. 자동화自働化와 눈으로 보는 관리 '눈으로 보는 관리'의 대표가 '안돈'이다. 이는 생산현장에 걸려 있는 '생산라인 정지 표시판'이다. 이상 표시등에 대해 설명하면, 운전 중에는 녹색불이 들어온다. 작업자가 만약 생산라인의 속도를 늦추고자 도움을 요청하면 노란불이 들어온다. 이상을 고치기 위해서 라인정지를 하고자 하면 빨간불이 들어온다. 출처: 『도요타 생산방식』, p.212. 도요타 생산방식 XP(Extreme Programming) 테스트 주도 개발은 두 가지 규칙으로 개발을 진행 첫 번째 규칙은 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성이고, 두 번째 규칙은 중복 제거 첫 번째 실패하는 작은 테스트를 작성(빨강), 두 번째 빨리 테스트가 통과하게끔 만들기(초록), 세 번째 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복을 제거(리팩토링) 순서 각 단계에서 매번 모든 테스트를 실행, 소프트웨어 품질보증에 개발자가 능동적으로 참여 출처: 『테스트 주도 개발』, p.22-23.
- 52. Extreme Programming (XP) is about social change. 익스트림 프로그래밍은 사회적 변화에 대한 것이다. - 『익스트림 프로그래밍』 책의 첫 문장