برنامه‌نویسی افراطی: پذیرش تغییر

I came across this book in the Bibliography section of Scott Berkun's "The art of Project Management". First, the structure. Well, this book is under 200 pages. So when Beck talks about keeping what is essential, he is surely applying it while writing books. Second, the content. The book takes the reader from understanding business risks associated with software development, to understanding the changing economics of software development & why XP can fit the demands of an ever changing business scenario. The book then establishes what XP is, what are its features, what are the activities, who are the X players & then links the roles, activities, & features together across each phase in a typical XP project. While Beck is persuasive about the usefulness of XP, he has also included a chapter at the end of the book which talks about projects where using XP may not be advisable. And yes, such a project is an outsourced development project. XP presents many interesting features. Traveling light - or code & tests together being all you need - sounds like a dream; nano-releases - or doing a daily or hourly build so that at any time you have a full system working, no matter the completeness of desired functionality - , building a system story by story, & going back & revisiting scope ever so often are all features that can be immensely valuable to the business & to the project team. As a result of all this, & more such practices, XP resembles to an extent Darwinian evolution in some ways. Trying many things & keeping what works, designing for today's needs & changing that with tomorrow's requirements tomorrow but not today can be seen as interesting commonalities between Darwinian evolution & XP! Overall, I think the book is great introduction to XP. I'd have liked case studies as well to understand how well good theory fits general projects of any kind, but this book does not cite too many such projects. Nevertheless, pick it up if you want to understand what the XP evolution is all about. S! Extreme Programming - Die revolutionäre Methode für Softwareentwicklung in kleinen Teams......Page 3 Für meinen Vater......Page 5 9 Zurück zu den Grundlagen......Page 7 12 Managementstrategie......Page 8 17 Designstrategie......Page 9 25 Wann man XP nicht ausprobieren sollte......Page 10 Stichwortverzeichnis......Page 11 Vorwort......Page 13 Einleitung......Page 15 Zu diesem Buch......Page 16 Was ist XP?......Page 17 Was ist genug?......Page 18 Gliederung......Page 19 Danksagung......Page 20 Teil 1 Das Problem......Page 21 1 Risiko: Das Grundproblem......Page 23 Unser Ziel......Page 25 2 Eine Entwicklungsepisode......Page 27 3 Die ökonomische Seite der Softwareentwicklung......Page 31 Beispiel......Page 33 Abhängigkeiten zwischen den Variablen......Page 35 Auf den Umfang konzentrieren......Page 38 5 Kosten von Änderungen......Page 41 6 Fahren lernen......Page 47 Kommunikation......Page 49 Einfachheit......Page 50 Feedback......Page 51 Mut......Page 53 Die Werte in der Praxis......Page 54 8 Grundprinzipien......Page 57 9 Zurück zu den Grundlagen......Page 63 Programmieren......Page 64 Testen......Page 65 Design entwerfen......Page 68 Schlussfolgerung......Page 70 Teil 2 Die Lösung......Page 71 10 Kurzer Überblick......Page 73 Das Planungsspiel......Page 74 Metapher......Page 76 Testen......Page 77 Programmieren in Paaren......Page 78 Gemeinsame Verantwortlichkeit......Page 79 40-Stunden-Woche......Page 80 Kunde vor Ort......Page 81 Programmierstandards......Page 82 Das Planungsspiel......Page 83 Metapher......Page 84 Refactoring......Page 85 Programmieren in Paaren......Page 86 Fortlaufende Integration......Page 87 Kunde vor Ort......Page 88 Schlussfolgerung......Page 89 12 Managementstrategie......Page 91 Messdaten......Page 92 Coaching......Page 93 Terminmanagement......Page 94 Intervention......Page 95 13 Strategie hinsichtlich der Arbeitsumgebung......Page 97 Geschäftsseite......Page 101 Was tun?......Page 102 Wahl der Technologie......Page 103 Was passiert, wenn es schwierig wird?......Page 104 15 Planungsstrategie......Page 105 Das Planungsspiel......Page 106 Iterationsplanung......Page 111 In einer Woche planen......Page 116 Fortlaufende Integration......Page 117 Gemeinsame Verantwortlichkeit......Page 119 Programmieren in Paaren......Page 120 Die einfachste Lösung......Page 123 Wie funktioniert das Design durch Refactoring?......Page 126 Was ist das Einfachste?......Page 128 Wie kann das funktionieren?......Page 129 Rolle der Bilder im Design......Page 131 Systemarchitektur......Page 133 18 Teststrategie......Page 135 Wer schreibt Tests?......Page 137 Weitere Tests......Page 139 Teil 3 XP implementieren......Page 141 19 XP übernehmen......Page 143 20 XP anpassen......Page 145 Testen......Page 146 Planung......Page 147 Entwicklung......Page 148 In Schwierigkeiten?......Page 149 Erforschung......Page 151 Iterationen bis zur ersten Version......Page 153 In Produktion gehen......Page 154 Wartung......Page 155 Tod......Page 157 22 Rollenverteilung......Page 159 Programmierer......Page 160 Kunde......Page 162 Terminmanager......Page 164 Coach......Page 165 Berater......Page 166 Big Boss......Page 167 23 Die 20:80-Regel......Page 169 24 Was macht XP schwierig?......Page 171 25 Wann man XP nicht ausprobieren sollte......Page 175 Festpreis......Page 179 Outsourcing......Page 180 Insourcing......Page 181 Abschlussbonus......Page 182 Frameworks......Page 183 Kommerzielle Produkte......Page 184 27 Schlussfolgerung......Page 185 Erwartung......Page 186 Philosophie......Page 187 Geisteshaltung......Page 188 Prozesse......Page 189 Menschen......Page 190 Projektmanagement......Page 192 Programmierung......Page 194 Sonstiges......Page 195 Kunde......Page 197 Version......Page 198 E......Page 199 I......Page 200 M......Page 201 P......Page 202 R......Page 203 V......Page 204 X......Page 205 Z......Page 206 Ins Internet: Weitere Infos zum Buch, Downloads, etc.......Page 0 © Copyright......Page 207 Extreme Programming (xp) Was Conceived And Developed To Address The Specific Needs Of Software Development Conducted By Small Teams In The Face Of Vague And Changing Requirements. This New Lightweight Methodology Challenges Many Conventional Tenets, Including The Long-held Assumption That The Cost Of Changing A Piece Of Software Necessarily Rises Dramatically Over The Course Of Time. Xp Recognizes That Projects Have To Work To Achieve This Reduction In Cost And Exploit The Savings Once They Have Been Earned. You May Love Xp Or You May Hate It, But Extreme Programming Explained Will Force You To Take A Fresh Look At How You Develop Software.--jacket. Foreword -- Preface -- Chap. 1. Risk : The Basic Problem -- Chap. 2. A Development Episode -- Chap. 3. Economics Of Software Development -- Chap. 4. Four Variables -- Chap. 5. Cost Of Change -- Chap. 6. Learning The Drive -- Chap. 7. Four Values -- Chap. 8. Basic Principles -- Chap. 9. Back To Basics -- Chap. 10. Quick Overview -- Chap. 11. How Could This Work? -- Chap. 12. Management Strategy -- Chap. 13. Facilities Strategy -- Chap. 14. Splitting Business And Technical Responsibility -- Chap. 15. Planning Strategy -- Chap. 16. Development Strategy -- Chap. 17. Design Strategy -- Chap. 18. Testing Strategy -- Chap. 19. Adopting Xp -- Chap. 20. Retrofitting Xp -- Chap. 21. Lifecycle Of An Ideal Xp Project -- Chap. 22. Roles For People -- Chap. 23. 20-80 Rule -- Chap. 24. What Makes Xp Hard -- Chap. 25. When You Shouldn't Try Xp -- Chap. 26. Xp At Work -- Chap. 27. Conclusion. Kent Beck. Includes Bibliographical References (p. 167-176) And Index. Beck wants to encourage readers to re-examine their preconceptions of how software development ought to occur. He does just that in this overview of Extreme Programming, a controversial approach to software development which challenges the notion that the cost of changing a piece of software must rise dramatically over the course of time.