Tämä sivusto käyttää evästeitä palvelujen toimittamiseen, toiminnan parantamiseen, analytiikkaan ja (jos et ole kirjautunut sisään) mainostamiseen. Käyttämällä LibraryThingiä ilmaiset, että olet lukenut ja ymmärtänyt käyttöehdot ja yksityisyydensuojakäytännöt. Sivujen ja palveluiden käytön tulee olla näiden ehtojen ja käytäntöjen mukaista.
"This remarkable book combines practical advice, ready-to-use techniques, anda deep understanding of why this is the right way to develop software. I haveseen software teams transformed by the ideas in this book." --Mike Cohn, author of Agile Estimating and Planning "As a lean practitioner myself, I have loved and used their first book for years.When this second book came out, I was delighted that it was even better. If youare interested in how lean principles can be useful for software developmentorganizations, this is the book you are looking for. The Poppendiecks offer abeautiful blend of history, theory, and practice." --Alan Shalloway, coauthor of Design Patterns Explained "I've enjoyed reading the book very much. I feel it might even be better than thefirst lean book by Tom and Mary, while that one was already exceptionallygood! Mary especially has a lot of knowledge related to lean techniques inproduct development and manufacturing. It's rare that these techniques areactually translated to software. This is something no other book does well(except their first book)." --Bas Vodde "The new book by Mary and Tom Poppendieck provides a well-written andcomprehensive introduction to lean principles and selected practices for softwaremanagers and engineers. It illustrates the application of the values andpractices with well-suited success stories. I enjoyed reading it." --Roman Pichler " In Implementing Lean Software Development, the Poppendiecks explore moredeeply the themes they introduced in Lean Software Development. They beginwith a compelling history of lean thinking, then move to key areas such asvalue, waste, and people. Each chapter includes exercises to help you apply keypoints. If you want a better understanding of how lean ideas can work withsoftware, this book is for you." --Bill Wake, independent consultant In 2003, Mary and Tom Poppendieck's Lean Software Development introduced breakthrough development techniques that leverage Lean principles to deliver unprecedented agility and value. Now their widely anticipated sequel and companion guide shows exactly how to implement Lean software development, hands-on. This new book draws on the Poppendiecks' unparalleled experience helping development organizations optimize the entire software value stream. You'll discover the right questions to ask, the key issues to focus on, and techniques proven to work. The authors present case studies from leading-edge software organizations, and offe...… (lisätietoja)
There is a lot to the book. I think it will take me multiple readings to get my head around all of their ideas. I read the book over the course of about a month. I wish that I had been able to read the whole thing in one big chunk, but that wasn't feasible.
The book begins with a chapter on the history of Lean production and its origins at Toyota. I was familiar with the broad outlines of Lean production, but there was a lot of interesting detail I didn't know.
The second chapter describes the adaptation of Lean to software development and lays out the seven principals of Lean development.
* Eliminate Waste * Build Quality In * Create Knowledge * Defer Commitment * Deliver Fast * Respect People * Optimize the Whole
The next five chapters go into detail on Value, Waste, Speed, People, Knowledge, and Quality. As you may have noticed, those mostly but not completely correspond to the Seven Principals. Value and Waste both seem to correspond to "Eliminate Waste." Deferring commitment is address in the speed and knowledge chapters. Optimize the Whole is addressed in various places, including People, and Quality.
The last two chapters are entitled Partners, and Journey. Partners has some really interesting ideas on how to structure incentives so that everyone--individuals, teams, contractors, even partner companies, are all aligned to create synergies and increase value for all parties involved.
The Journey offers ideas on how to begin using Lean methods in your environment. It builds on the "Try This" sections that end each chapter.
There are a lot of really interesting ideas in this book. I've been thinking a lot about how I want to apply them.
One thing that I've realized is that I'm not as clear as I need to be on how my team provides value. And that really matters, because that should be driving decisions about what we do. My team builds automated testing tools that are used internally at a company that makes "Application Delivery Networking" hardware. We also operate the test systems. We used to write automated tests, but now that is mostly done by another group. So what is our primary contribution of value? Is it the capabilities that we deliver to the team that writes the tests? Is it the results that come out of the test systems that we operate? When I have to make trade-offs between those two tasks, which one should be more important?
Another point that Lean has driven home for me is that my team has too much work in progress. We have lots of ideas that we'd like to implement. We also get lots of requests from people. If we meet our goals for the current Sprint (which is far from certain at this point), we will complete about 150 story points worth of work for this release. I already have 145 story points queued up for the next release--and that's with only half of the backlog items estimated. My "high priority" list of work to do after the stuff in the queue is equally large, with equally incomplete estimates.
One of the ideas that I liked and am going to be thinking about is using automation to remove low-skilled, repetitive tasks, especially if they are mistake-prone. There was a list of examples of automation:
* One Click Build * Scheduled Builds * Build Result Notification * One-Step Release * Bullet-Proof Installation
Things that I would add to this include:
* Build Acceptance Test * Automated Unit Tests * Scheduled Regression Test Runs
Ironically, for a team that is all about automation of other people's tasks, we haven't automated a lot of our own work. We have an automated build script, but not everyone understands how to use it, we don't do scheduled builds, we don't have a notification system or automated build acceptance tests, we don't have a one-step release process, and we don't do scheduled regression test runs. We do have automated unit tests, and we do have a fairly good installation script, but only for part of the system.
When we did our last release, we had trouble getting a build out and getting everyone notified. At the review of our last sprint, people had trouble demoing some of the work because not all the boxes were set up the same way. We need some automation here.
Moving forward, I'm going to start devoting some time out of our weekly team meeting to discussing the Lean principals and figuring out how we can apply them. ( )
"This remarkable book combines practical advice, ready-to-use techniques, anda deep understanding of why this is the right way to develop software. I haveseen software teams transformed by the ideas in this book." --Mike Cohn, author of Agile Estimating and Planning "As a lean practitioner myself, I have loved and used their first book for years.When this second book came out, I was delighted that it was even better. If youare interested in how lean principles can be useful for software developmentorganizations, this is the book you are looking for. The Poppendiecks offer abeautiful blend of history, theory, and practice." --Alan Shalloway, coauthor of Design Patterns Explained "I've enjoyed reading the book very much. I feel it might even be better than thefirst lean book by Tom and Mary, while that one was already exceptionallygood! Mary especially has a lot of knowledge related to lean techniques inproduct development and manufacturing. It's rare that these techniques areactually translated to software. This is something no other book does well(except their first book)." --Bas Vodde "The new book by Mary and Tom Poppendieck provides a well-written andcomprehensive introduction to lean principles and selected practices for softwaremanagers and engineers. It illustrates the application of the values andpractices with well-suited success stories. I enjoyed reading it." --Roman Pichler " In Implementing Lean Software Development, the Poppendiecks explore moredeeply the themes they introduced in Lean Software Development. They beginwith a compelling history of lean thinking, then move to key areas such asvalue, waste, and people. Each chapter includes exercises to help you apply keypoints. If you want a better understanding of how lean ideas can work withsoftware, this book is for you." --Bill Wake, independent consultant In 2003, Mary and Tom Poppendieck's Lean Software Development introduced breakthrough development techniques that leverage Lean principles to deliver unprecedented agility and value. Now their widely anticipated sequel and companion guide shows exactly how to implement Lean software development, hands-on. This new book draws on the Poppendiecks' unparalleled experience helping development organizations optimize the entire software value stream. You'll discover the right questions to ask, the key issues to focus on, and techniques proven to work. The authors present case studies from leading-edge software organizations, and offe...
Google Books — Ladataan...
(4.33)
1
The book begins with a chapter on the history of Lean production and its origins at Toyota. I was familiar with the broad outlines of Lean production, but there was a lot of interesting detail I didn't know.
The second chapter describes the adaptation of Lean to software development and lays out the seven principals of Lean development.
* Eliminate Waste
* Build Quality In
* Create Knowledge
* Defer Commitment
* Deliver Fast
* Respect People
* Optimize the Whole
The next five chapters go into detail on Value, Waste, Speed, People, Knowledge, and Quality. As you may have noticed, those mostly but not completely correspond to the Seven Principals. Value and Waste both seem to correspond to "Eliminate Waste." Deferring commitment is address in the speed and knowledge chapters. Optimize the Whole is addressed in various places, including People, and Quality.
The last two chapters are entitled Partners, and Journey. Partners has some really interesting ideas on how to structure incentives so that everyone--individuals, teams, contractors, even partner companies, are all aligned to create synergies and increase value for all parties involved.
The Journey offers ideas on how to begin using Lean methods in your environment. It builds on the "Try This" sections that end each chapter.
There are a lot of really interesting ideas in this book. I've been thinking a lot about how I want to apply them.
One thing that I've realized is that I'm not as clear as I need to be on how my team provides value. And that really matters, because that should be driving decisions about what we do. My team builds automated testing tools that are used internally at a company that makes "Application Delivery Networking" hardware. We also operate the test systems. We used to write automated tests, but now that is mostly done by another group. So what is our primary contribution of value? Is it the capabilities that we deliver to the team that writes the tests? Is it the results that come out of the test systems that we operate? When I have to make trade-offs between those two tasks, which one should be more important?
Another point that Lean has driven home for me is that my team has too much work in progress. We have lots of ideas that we'd like to implement. We also get lots of requests from people. If we meet our goals for the current Sprint (which is far from certain at this point), we will complete about 150 story points worth of work for this release. I already have 145 story points queued up for the next release--and that's with only half of the backlog items estimated. My "high priority" list of work to do after the stuff in the queue is equally large, with equally incomplete estimates.
One of the ideas that I liked and am going to be thinking about is using automation to remove low-skilled, repetitive tasks, especially if they are mistake-prone. There was a list of examples of automation:
* One Click Build
* Scheduled Builds
* Build Result Notification
* One-Step Release
* Bullet-Proof Installation
Things that I would add to this include:
* Build Acceptance Test
* Automated Unit Tests
* Scheduled Regression Test Runs
Ironically, for a team that is all about automation of other people's tasks, we haven't automated a lot of our own work. We have an automated build script, but not everyone understands how to use it, we don't do scheduled builds, we don't have a notification system or automated build acceptance tests, we don't have a one-step release process, and we don't do scheduled regression test runs. We do have automated unit tests, and we do have a fairly good installation script, but only for part of the system.
When we did our last release, we had trouble getting a build out and getting everyone notified. At the review of our last sprint, people had trouble demoing some of the work because not all the boxes were set up the same way. We need some automation here.
Moving forward, I'm going to start devoting some time out of our weekly team meeting to discussing the Lean principals and figuring out how we can apply them. (