Gør som tusindvis af andre bogelskere
Tilmeld dig nyhedsbrevet og få gode tilbud og inspiration til din næste læsning.
Ved tilmelding accepterer du vores persondatapolitik.Du kan altid afmelde dig igen.
Rigor Without the Mortis Many people (especially agilists) associate a high-ceremony software development process with a dead project (i.e., rigor mortis), and this association is not entirely incorrect. Our approach aims to put back the rigor while le- ing out the mortis-that is, we can do rigorous analysis and design without killing the project with an excessively high-ceremony approach. The goal of this book is to describe that process in full detail. Agility in theory is about moving ahead at speed, making lots of tiny course corrections as you go. The theory (and it's a good one) is that if you spend months or years producing dry specifications at the start of the project and then "e;set them in concrete,"e; this doesn't necessarily (and in practice, doesn't) lead to a product that meets the c- tomer's requirements, delivered on time and with an acceptably low defect count. It's likely that the requirements will change over time, so we need to be prepared for that, and it's likely that a lot of the original requirements will turn out to be wrong or new requirements will be discovered after the requi- ments "e;concrete"e; has set. Agile methods answer this problem in a number of different ways, but the overriding principle is to break things down into smaller chunks and not to go setting anything in concrete (least of all your requirements specs).
Matt's Preface This book illustrates how to get from use cases to working, maintainable source code in as few steps as possible . . . but without cutting the essential corners. It's also about how to minimize the amount of rework you need to do once you've gotten to source code. Learning by Doing In this book we've tried to capture the essential qualities of Doug's ICONIX training courses- that is, the "e;magic qualities"e; of learning by doing. The ICONIX Jumpstart courses are very practical and hands-on; they draw students in by encouraging them to learn new skills by practicing, often on the real projects that they'll be returning to once the course is finished. This idea of learning by doing has long been recognized as an optimal form of education. Even at the start of the twentieth century, John Dewey, an American psychologist and edu- tional reformer, recognized that learning from experience gives rise to increasing productivity. The key is to engage the brain with practical tasks rather than to fall into the all-too-familiar "e;study trap"e; of rote learning. Memorizing long lists of names or API functions might help someone score highly on a test, but it isn't the same as understanding a subject in depth. For one thing, people tend not to retain information for very long if they've simply memorized it.
"e;Extreme Programming Refactored: The Case Against XP"e; is meant to provide an independent look at Extreme Programming. It is meant to cut through the marketing hype of Extreme Programming and expose a number of weaknesses with this approach to software development. It tries to draw a distinction between true "e;agility"e; in a software process and "e;fragility"e; inherent in techniques such as oral documentation. Extreme Programming (XP) is a consummate mix of good goals, some good advice, and lots of bad advice. The goals and the good advice draw people in; the bad advice can potentially cause projects to fail. The XPers' theory is that when applied together, this mixture of rules will somehow magically be safe. XP therefore represents a high-risk process, wrapped in a "e;feel-good"e; methodology. The marketing, hype, and earnest self-assurance of its authors will convince many project leaders to try out XP on their next project. In "e;Extreme Programming Refactored: The Case Against XP"e; into a more viable process, Rosenberg and Stephens are not attempting to define a new methodology, as there are plenty of those in the World already. Instead, they will be examining XP in the context of existing methodologies and processes such as RUP, ICONIX, Spiral, RAD, DSDM, etc - and showing how XP goals can be achieved using these existing processes (with a slight emphasis on RUP and ICONIX), using software wisdom that has been tried and proven to work again and again.
Tilmeld dig nyhedsbrevet og få gode tilbud og inspiration til din næste læsning.
Ved tilmelding accepterer du vores persondatapolitik.