oder
Loggen Sie sich ein, um 1-Click® einzuschalten.
oder
Mit kostenloser Probeteilnahme bei Amazon Prime. Melden Sie sich während des Bestellvorgangs an. Erfahren Sie mehr
Alle Angebote
Möchten Sie verkaufen? Hier verkaufen
Planning Extreme Programming (XP)
 
Größeres Bild
 
Den Verlag informieren!
Ich möchte dieses Buch auf dem Kindle lesen.

Sie haben keinen Kindle? Hier kaufen oder eine gratis Kindle Lese-App herunterladen.

Planning Extreme Programming (XP) [Englisch] [Taschenbuch]

Kent Beck , Martin Fowler
4.5 von 5 Sternen  Alle Rezensionen anzeigen (4 Kundenrezensionen)
Preis: EUR 30,99 kostenlose Lieferung. Siehe Details.
  Alle Preisangaben inkl. MwSt.
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Auf Lager.
Verkauf und Versand durch Amazon.de. Geschenkverpackung verfügbar.
Nur noch 3 Stück auf Lager - jetzt bestellen.
Lieferung bis Mittwoch, 30. Mai: Wählen Sie an der Kasse Morning-Express. Siehe Details.
‹  Zurück zur Artikelübersicht

Produktbeschreibungen

Amazon.co.uk

Programming continues to refuse to be engineering. This is why there are so many cancelled projects, cost and time overruns and customer dissatisfaction. Planning Extreme Programming offers a way to run small-to-medium size programming projects in such a way as to produce the required product on time and to budget.

To achieve this the authors focus away from complex, report-led planning to a people-oriented process which treats programming like a craft project. Extreme Programming starts by recognising reality: start right and you'll finish right. In fact the authors specifically argue against overtime, increasing manpower on late projects and other such attempts to increase productivity as evidence of failure. They start by breaking projects into stories (or features), insist on customer involvement, iterate relentlessly over a timescale of weeks, set short-term targets based on the evidence of previous iterations and--in a break with traditional practices--absolutely insist on customer involvement at every stage, including signing off each story.

The claimed results of applying the XP approach is a better product with fewer bugs as well as the ability to meet agreed deadlines and budgets. Pretty impressive claims for a book that reads like a set of obvious, common-sense rules. Astonishingly, the only planning tool required is a box of index cards and the right attitude. You are even recommended to avoid spreadsheets. Perhaps, then, the real success of Extreme Programming rests on its implicit acknowledgement that programming is a craft, and not engineering. What can you say? It works. Read it and then implement it. -- Steve Patient

Amazon.com

The Extreme Programming (XP) paradigm has developers doing things like programming in pairs, writing tests to verify all code, and continuously refactoring designs for improved performance. Written by two of its inventors, Planning Extreme Programming shows you how to implement XP by using a simple, effective process. This remarkably short (yet remarkably useful) title will give any XP manager or programmer a perspective on delivering software that meets the needs of customers better.

Simplicity is the watchword of the XP software process. This book is virtually devoid of traditional software-engineering jargon and design diagrams, and yet does a good job of laying the foundation of how to perform XP--which is all about working with a customer to deliver features incrementally.

The terminology in the book is commonsensical. (In the terms of XP, each iteration adds certain new features, or stories. It's up to the customer to decide what functionality is more important and will be delivered first. By never letting a working build get out of sight, the XP process virtually ensures that software will be close to what the customer wants.)

Early chapters borrow analogies from everyday experience--like planning a trip or driving a car--to set the stage for XP process planning. The book has plenty of advice for dealing with the stakeholders (customers) of a project. Because of confidentiality agreements, however, we don't get many details from the real world, although the discussion is anchored by a hypothetical project for planning the Web site of the future for travel, with some specifics.

There is plenty of advice for planning projects, based on individual and team "velocity" (a measure of productivity) and the like--practical suggestions for running daily, short status meetings (in which all of the participants stand up, to keep them short). Clearly, there's a culture that surrounds many XP teams, and this text does a good job of conveying some of this to the reader.

At fewer than 150 pages, Planning Extreme Programming is notably concise, and that's probably the whole point. Most shops today work on Internet time, which doesn't wait for extensive project analysis and design documents. In XP, you create working software from the very start. This book is an essential guide to anyone who's working in XP shops or who might be interested in what this innovative, iterative software process can offer. --Richard Dragan

Topics covered:

  • Introduction to planning
  • Risk management in software
  • "Driving" as a metaphor for software development
  • Roles for software development: business vs. technical people
  • Four variables for project planning: cost, quality, time, and scope
  • Predicting future programmer productivity, based on past performance
  • Project scope and estimation
  • The XP process: software releases, iterations, stories, collecting, and writing stories (features)
  • Hints for ordering features
  • Tips on planning and status meetings
  • Using visual graphs to monitor project progress
  • Tracking and fixing bugs
  • Project red flags

Kurzbeschreibung

In this timely follow-up to Extreme Programming Explained, software engineering gurus Kent Beck and Martin Fowler show exactly how to plan your next software project using Extreme Programming (XP). Planning is a vital element of software development -- but all too often, planning stops when coding begins. Beck and Fowler show how to make software projects far more manageable through a series of simple planning steps every project manager and team leader can easily perform "every day. The book follows XP projects from start to finish, presenting successful planning tactics managers and team leaders can use to adjust to changing environments more quickly and efficiently than ever before. This book is full of war stories and real-world analogies, and offers actionable techniques on virtually every page. It will be invaluable for every project manager called upon to deliver reliable, high-value code in "Internet time."

Synopsis

In this timely follow-up to Extreme Programming Explained, software engineering gurus Kent Beck and Martin Fowler show exactly how to plan your next software project using Extreme Programming (XP). Planning is a vital element of software development -- but all too often, planning stops when coding begins. Beck and Fowler show how to make software projects far more manageable through a series of simple planning steps every project manager and team leader can easily perform >every day. The book follows XP projects from start to finish, presenting successful planning tactics managers and team leaders can use to adjust to changing environments more quickly and efficiently than ever before. This book is full of war stories and real-world analogies, and offers actionable techniques on virtually every page. It will be invaluable for every project manager called upon to deliver reliable, high-value code in "Internet time."

Buchrückseite

"XP is the most important movement in our field today. I predict that it will be as essential to the present generation as the S.E.I. and its Capability Maturity Model were to the last."

--From the foreword by Tom DeMarco

The hallmarks of Extreme Programming--constant integration and automated testing, frequent small releases that incorporate continual customer feedback, and a teamwork approach--make it an exceptionally flexible and effective approach to software development. Once considered radical, Extreme Programming (XP) is rapidly becoming recognized as an approach particularly well-suited to small teams facing vague or rapidly changing requirements--that is, the majority of projects in today's fast-paced software development world.

Within this context of flexibility and rapid-fire changes, planning is critical; without it, software projects can quickly fall apart. Written by acknowledged XP authorities Kent Beck and Martin Fowler, Planning Extreme Programming presents the approaches, methods, and advice you need to plan and track a successful Extreme Programming project. The key XP philosophy: Planning is not a one-time event, but a constant process of reevaluation and course-correction throughout the lifecycle of the project.

You will learn how planning is essential to controlling workload, reducing programmer stress, increasing productivity, and keeping projects on track. Planning Extreme Programming also focuses on the importance of estimating the cost and time for each user story (requirement), determining its priority, and planning software releases accordingly.

Specific topics include:

  • Planning and the four key variables: cost, quality, time, and scope
  • Deciding how many features to incorporate into a release
  • Estimating scope, time, and effort for user stories
  • Prioritizing user stories
  • Balancing the business value and technical risk of user stories
  • Rebuilding the release plan based on customer and programmer input
  • Choosing the iteration length
  • Tracking an iteration
  • What to do when you're not going to make the date
  • Dealing with bugs
  • Making changes to the team
  • Outsourcing
  • Working with business contracts

In addition, this book alerts you to the red flags that signal serious problems: customers who won't make decisions, growing defect reports, failing daily builds, and more. An entire chapter is devoted to war stories from the trenches that illustrate the real-world problems many programmers encounter and the solutions they've devised.

0201710919B04062001

Über den Autor

Kent Beck consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Agitar Software, he is the author of many Addison-Wesley titles. Martin Fowler is the Chief Scientist of ThoughtWorks, an enterprise-application development and delivery company. He's been applying object-oriented techniques to enterprise software development for over a decade. He is notorious for his work on patterns, the UML, refactoring, and agile methods. Martin lives in Melrose, Massachusetts, with his wife, Cindy, and a very strange cat. His homepage is http://martinfowler.com.

Prolog. Abdruck erfolgt mit freundlicher Genehmigung der Rechteinhaber. Alle Rechte vorbehalten.

This is a book about planning software projects. We are writing it mostly for project managers--those who have to plan and track the correspondence of the planning with reality. We also are writing it for programmers and customers, who have a vital role to play in planning and developing software. Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn't even be happy if it did, because by the time the software gets there, the customers don't want what was planned; they want something different.

Like so many, we enjoy Eisenhower's quotation: "In preparing for battle I have always found that plans are useless, but planning is indispensable." That's why this isn't a book about plans; it's about planning. And planning is so valuable and important, so vital, that it deserves to go on a little every day, as long as development lasts.

If you follow the advice in this book, you are going to have a new problem to solve every day--planning--but we won't apologize for that, because without planning, software development inevitably goes off the rails. The scope of this book is deliberately narrow. It covers how to plan and track software development for XP projects. It's based on our experience as consultants and coaches, together with the experience of the growing band of early adopters who are using XP.

As a result this isn't a book about the whole of project management. We don't cover typical project manager jobs such as personnel evaluation, recruiting, and budgeting. We don't address the issues of large projects with hordes of developers, nor do we say anything about planning in the context of other software processes, or of planning other activities. We think there are principles and techniques here that everyone can use, but we have stuck to the parts of the process we know--getting everybody on the team pointed in one direction, discovering when this is no longer true, and restoring harmony.

XP (Extreme Programming) is a system of practices (you can use the m-word if you want to; we'd rather not, thank you) that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs.

XP isn't just about planning. It covers all aspects of small team software development--design, testing, implementation, deployment, and maintenance. However, planning is a key piece of the XP puzzle. (For an overview of XP, read Extreme Programming Explained: Embrace Change. While you're at it, buy copies of all of the rest of our books, too.)

XP addresses long projects by breaking them into a sequence of self-contained, one- to three-week mini-projects. During each iteration

  • Customers pick the features to be added.
  • Programmers add the features so they are completely ready to be deployed.
  • Programmers and customers write and maintain automated tests to demonstrate the presence of these features.
  • Programmers evolve the design of the system to gracefully support all the features in the system.

Without careful planning, the process falls apart.

  • The team must choose the best possible features to implement.
  • The team must react as positively as possible to the inevitable setbacks.
  • Team members must not overcommit, or they will slow down.
  • The team must not undercommit, or customers won't get value for their money.
  • Team members must figure out clearly where they are and report this accurately, so that everyone can adjust their plans accordingly

The job of the daily planner is to help keep the team on track in all these areas.

We come by our project planning ideas by necessity. As consultants, we are usually introduced to projects when they are mostly dead. The projects typically aren't doing any planning, or they are drowning in too much planning of the wrong sort.

The resulting ideas are the simplest planning ideas we could think of that could possibly work. But above all, remember all the planning techniques in the world, including these, can't save you if you forget that software is built by human beings. In the end keep the human beings focused, happy, and motiviated and they will deliver.

Kent Beck, Merlin, Oregon
Martin Fowler, Melrose, Massachusetts http://www.martinfowler.com
July 2000

I have a cunning plan.
--Baldrick, Blackadder


0201710919P04062001
‹  Zurück zur Artikelübersicht

Datenschutzerklärung von Amazon.de Versandbedingungen von Amazon.de Umtausch- & Rücknahme bei Amazon.de