- Taschenbuch: 230 Seiten
- Verlag: Addison-Wesley Professional; Auflage: 01 (8. Mai 2003)
- Sprache: Englisch
- ISBN-10: 0321150783
- ISBN-13: 978-0321150783
- Größe und/oder Gewicht: 17,5 x 1,5 x 22,9 cm
- Durchschnittliche Kundenbewertung: 3 Kundenrezensionen
- Amazon Bestseller-Rang: Nr. 35.941 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
- Komplettes Inhaltsverzeichnis ansehen
Andere Verkäufer auf Amazon
+ kostenlose Lieferung
+ kostenlose Lieferung
Lean Software Development: An Agile Toolkit for Software Development Managers (Englisch) Taschenbuch – 8. Mai 2003
|Neu ab||Gebraucht ab|
Wird oft zusammen gekauft
Kunden, die diesen Artikel gekauft haben, kauften auch
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
Wenn Sie dieses Produkt verkaufen, möchten Sie über Seller Support Updates vorschlagen?
Lean Software Development: An Agile Toolkit Mary Poppendieck Tom Poppendieck Forewords by Jim Highsmithand Ken Schwaber *Adapting agile practices to your development organization *Uncovering and eradicating waste throughout the software development lifecycle *Practical techniques for every development manager, project manager, and technical leaderLean Software Development: An Agile Toolkit Lean software development: applying agile principles to your organization In Lean Software Development, Mary and Tom Poppendieck identify seven fundamental "lean" principles, adapt them for the world of software development, and show how they can serve as the foundation for agile development approaches that work. Along the way, they introduce 22 "thinking tools" that can help you customize the right agile practices for any environment. Better, cheaper, faster software development. You can have all three--if you adopt the same lean principles that have already revolutionized manufacturing, logistics and product development.*Iterating towards excellence: software development as an exercise in discovery *Managing uncertainty: "decide as late as possible" by building change into the system.*Compressing the value stream: rapid development, feedback, and improvement *Empowering teams and individuals without compromising coordination *Software with integrity: promoting coherence, usability, fitness, maintainability, and adaptability *How to "see the whole"--even when your developers are scattered across multiple locations and contractors Simply put, Lean Software Development helps you refocus development on value, flow, and people--so you can achieve breakthrough quality, savings, speed, and business alignment.
Lean Software Development: An Agile Toolkit
Mary Poppendieck Tom Poppendieck
Forewords by Jim Highsmithand Ken Schwaber
- Adapting agile practices to your development organization
- Uncovering and eradicating waste throughout the software development lifecycle
- Practical techniques for every development manager, project manager, and technical leader
Lean software development: applying agile principles to your organization
In Lean Software Development, Mary and Tom Poppendieck identify seven fundamental "lean" principles, adapt them for the world of software development, and show how they can serve as the foundation for agile development approaches thatwork. Along the way, they introduce 22 "thinking tools" that can help you customize the right agile practices for any environment.
Better, cheaper, faster software development. You can have all threeif you adopt the same lean principles that havealready revolutionized manufacturing, logistics and product development.
- Iterating towards excellence: software development as an exercise in discovery
- Managing uncertainty: "decide as late as possible" by building change into the system.
- Compressing the value stream: rapid development, feedback, and improvement
- Empowering teams and individuals without compromising coordination
- Software with integrity: promoting coherence, usability, fitness, maintainability, and adaptability
- How to "see the whole"even when your developers are scattered across multiple locations and contractors
Simply put, Lean Software Development helps you refocus development on value, flow, and peopleso you can achieve breakthrough quality, savings, speed, and business alignment.Alle Produktbeschreibungen
Kunden, die diesen Artikel angesehen haben, haben auch angesehen
Dieses Produkt bewerten
1-3 von 3 Rezensionen werden angezeigt
Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.
field. And what can I say, it is an eye opener. It gives you the theoretic
background and principles how to succeed in software development. It doesn't offer
a method or a process, but the foundation and tools you need to understand how
SW development should be (and unfortunately it most of the time isn't that way).
So in my eyes it's a much more timeless and important book, as it doesn't try to
give us a new methodology but the fundations we needed and haven't had. After reading
this book you understand why waterfall and all the heavy weight stuff simply can't
work and never will. No matter how hard we try.
Sie gehen von Prinzipien des "Lean Manufacturing" aus, übersetzen die Prinzipien in die Domäne der Anwendungsentwicklung. Sie weisen explizit darauf hin, dass ein einfaches Übernehmen der Praktiken aus anderen Domänen nur fehlschlagen kann, und geben sich deshalb viel Mühe, die richtigen Analogien für Praktiken aus dem Lean Manufacturing in der Anwendungsentwicklung zu finden.
Wenn das jetzt sehr kompliziert klingt, so ist es das Buch dafür überhaupt nicht.
In sieben Kapiteln werden die "Lean Principles" vorgestellt:
1. Eliminate Waste (whatever gets in the way of rapidly satisfying a customer need is waste)
2. Amplify learning (Development is an exercise in discovery, while production is an exercise in reducing variation)
3. Decide as late as possible (Delaying decisions is valuable because better decisions can be made when they are based on fact, not speculation)
4. Deliver as fast as possible (Design, implement, feedback, improve. The shorter these cycles are, the more can be learned.)
5. Empower the team (lean practices use pull techniques to schedule work and contain local signaling mechanisms so workers can let each other know what needs to be done.)
6. Build integrity in (Integrity comes from wise leadership, relevant expertise, effective communication, and healthy discipline.)
7. See the whole (When individuals or organizations are measured on their specialized contribution rather than overall performance, suboptimization is likely to result.)
Es gibt viele einleuchtende Analogieschlüsse und Erklärungen, die so manches Aha-Erlebnis hervorrufen.
Ein Beispiel dazu: Der Durchsatz eines Systems hängt von der Größe der Pakete ab. Kleinere Pakete (= kürzere Servicezeiten) bedeuten gemäß der Warteschlangentheorie, dass das System kürzere Antwortzeiten hat, weil sich die Wartschlangen des Systems nicht aufschaukeln. Das ist halt einmal so. Übertragen auf Anwendungsentwicklung heißt das, dass man in kurzen Iterationen schneller mehr Funktionalität umsetzen kann als in längeren Iterationen, d.h. die Produktivität lässt sich dadurch einfach steigern.
Schritt für Schritt lernen die Autoren dem Leser die Bausteine des agilen Baukastens: Seeing Waste, Value Stream Mapping, Feedback, Iterations, Synchronization, Set-Based Development, Options Thinking, Last Responsible Moment, Making Desicions, Pull Systems, Queuing Theory, Cost of Delay, Self Determination, Motivation, Leadership, Expertise, Perceived Integrity, Conceptual Integrity, Testing, Refactoring, Measurements, and Contracts
Jedes dieser Themen ist spannend erläutert und mit vielen Literaturhinweisen versehen.
Oder besser: gleich die Originale lesen und eigene Schlüsse ziehen:
- Taiichi Ohno: Toyota Production System
- Donald Reinertsen: Managing the Design Factory
- James Womack, Daniel Jones, Daniel Roos: The Machine that changed the World
Die hilfreichsten Kundenrezensionen auf Amazon.com
A previous reviewer laments the authors' distaste for CMMI and PMI. For instance:
"Between PMI and CMM certification programs, a heavy emphasis on process definition and detailed, front-end planning seemed to dominate everyone's perception of best practices...spending a lot of time and getting the requirements right upfront was the way to do things `right the first time'...CMM, in its eagerness to standardize process, leaves out the heart of discovery and innovation..." Spot on.
As a PMP with CMMI experience, I couldn't agree more with the Poppendiecks' observations and concerns. They go on to say, "This is not to say that CMM and PMI are bad, but only that for anyone who has lived through the lean revolution, they tend to give the wrong flavor to a software development program." That "wrong flavor" is called "waterfall."
Of course there are Level 5 Agile shops out there, and the author's recognize that "CMM is not supposed to dictate approach, but only assess..." But here's the problem: "CMM programs...may standardize on less than ideal practices...they may be better implemented separate from--and after--process improvements."
This book is a must read for software development managers and other business execs pursuing the promise of an Agile company (vs. IT shop). I'll definitely be passing out a few copies!
I am glad I did. It is exactly the kind of book I like to read about software engineering - it is written by somebody with lots of hands on experience, it describes new and interesting techniques for producing high quality software, and it has plenty of references for further reading.
It is written by Mary and Tom Poppendieck, but I get the feeling that most of the input comes from Mary. She has solid experience with software development in many roles and places. In addition, she also has extensive experience with manufacturing, and one of the biggest pluses with this book is how she shows how to transfer principles and practises from lean manufacturing to software development. The type of development they advocate is squarely in the agile camp (obvious from the subtitle as well).
There are seven chapters on seven lean principles, with 22 "thinking tools" with specific practices or principles. If you are familiar with Extreme Programming (for example through Kent Beck's first XP book), you will recognize a lot of the ideas in the thinking tools. Examples are: Feedback (tool 3), Iterations (tool 4), Options Thinking (tool 7), Refactoring (tool 19) and Testing (tool 20).
However, the value for me was the many ideas from manufacturing that I had not previously read about in the agile literature. Examples are: Value Stream Mapping (tool 2), Set-Based Development (tool 6), Pull Systems (tool 10) and Cost of Delay (tool 12)
There is actually so much good material in this book that I will have to concentrate on just a few examples. The first lean principal is Eliminate Waste. "Waste is anything that does not add value to a product, value as perceived by the customer". This is a great starting point, and one that has many implications. Examples of waste in software development are: extra features (that are not needed now), task switching, waiting, motion (for example document hand-offs), and of course defects. With this definition of waste, a value stream map helps you to see waste by mapping where value is added, and where there is waiting etc as a product is developed.
Another interesting part is tool 10 in chapter 4 (Deliver as Fast as Possible). Here the authors describe how pull systems work (you set things up so workers can figure out for themselves what needs to be done, instead of telling them what to do). They continue with an example of a pull system, the simple and ingenious Kanban card system used in Japan, and show how a similar system can be used for software development.
The use of pull systems goes hand in hand with the theme in chapter 5 - Empower the Team. The idea here is that the front-line workers are the ones that know best how things should be done, and they should be empowered to act on this knowledge. Most of this material is covered in regular books on business improvement, and there wasn't much new material here for me. So for me, this was the least interesting chapter, together with the parts on contract negotiation in chapter 7 (simply because I am not involved in any contract negotiations).
Another theme in the book is to not sub-optimize. There is a good example from the manufacturing world, where a video tape machine was run at full capacity. The utilization of the machine was maximized, but that did not maximize company profit. It is tempting to break up a task in smaller tasks, and then optimize each task individually. But as the authors show, that is very often a bad strategy. A good analogy from the book is when they point out that Lance Armstrong, winner of Tour de France for many years, only won 4 out of 21 daily stages, even though he was the eventual winner. Had he tried to win each daily stage, he probably would not have won the whole race.
There are also many good examples in the book. I particularly liked the one about HP printers. By waiting to do the final electrical configuration of the printer until after it was ordered, it was much easier to match the supply of printers in a certain configuration with the demand. It cost a bit more to do the configuration so late, but that was more than off-set by the savings of not having to forecast exactly how many printers in a certain configuration that were needed at different locations.
I also found many interesting nuggets of information about software development sprinkled through the book. The diagram on page 18 for example shows how experienced designers work out a solution to an ill-defined design problem by repeatedly moving between high level and low level design activities. I had never seen this described before, but immediately recognized that that is how I work too (as opposed to a straight top-down approach). This too explains why I think you should also keep coding even if you are an architect - because to find the best solution you must alternate between high and low levels of design.
Another good part was their diagnosis of the problems with CMM and ISO9000. They write that both programs have a bias towards documenting and thus standardizing existing process, rather than improving the process, even though it is not the intent of either. I agree completely.
This is a practical book, and there are lots of good (and well described) ideas that can be used in software development. It is well worth getting, both for developers, managers and project leaders. Recommended.