Implementing Lean Software Development From Concept to Cash
by Mary Poppendieck; Tom Poppendieck
Lean Software Development: An Agile Toolkit
by Mary Poppendieck; Tom Poppendieck
Agile Testing: A Practical Guide for Testers and Agile Teams
by Lisa Crispin; Janet Gregory
Agile Project Management with Scrum
by Ken Schwaber
Growing Object-Oriented Software, Guided by Tests
by Steve Freeman; Nat Pryce
Agile Estimating and Planning
by Mike Cohn
This succinct book explains how you can apply the practices of Lean software development to dramatically increase productivity and quality. Based on techniques that revolutionized Japanese manufacturing, Lean principles are being applied successfully to product design, engineering, the supply chain, and now software development. With The Art of Lean Software Development, you'll learn how to adopt Lean practices one at a time rather than taking on the entire methodology at once. As you master each practice, you'll see significant, measurable results. With this book, you will:
Understand Lean's origins from Japanese industries and how it applies to software development
Learn the Lean software development principles and the five most important practices in detail
Distinguish between the Lean and Agile methodologies and understand their similarities and differences
Determine which Lean principles you should adopt first, and how you can gradually incorporate more of the methodology into your process
Review hands-on practices, including descriptions, benefits, trade-offs, and roadblocks
Learn how to sell these principles to management
The Art of Lean Software Development is ideal for busy people who want to improve the development process but can't afford the disruption of a sudden and complete transformation. The Lean approach has been yielding dramatic results for decades, and with this book, you can make incremental changes that will produce immediate benefits. "This book presents Lean practices in a clear and concise manner so readers are motivated to make their software more reliable and less costly to maintain. I recommend it to anyone looking for an easy-to-follow guide to transform how the developer views the process of writing good software." -- Bryan Wells, Boeing Intelligence & Security Sytems Mission System "If you're new to Lean software development and you're not quite sure where to start, this book will help get your development process going in the right direction, one step at a time." -- John McClenning, software development lead, Aclara
Average Amazon.com® Rating: ![]()
![]()
![]()
![]()
Based on 6 Ratings
Too Lean An Intro to Lean - 2009-03-18
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
This is a concise work weighing in at around 120 pages. Its point is to give people a 30,000 foot overview of many things relating to Lean software development, and it's absolutely targeted to technical and business decision makers who are trying to learn a bit about how they can benefit from Lean.
The problem with the book's approach is that the authors fly past points so quickly that there's not enough serious discussion of the crucial topics central to Lean. I also think the authors spent the majority of the book covering topics which aren't specific to Lean. I'm all over source control, continuous integration, test driven design/development, etc., but these are fundamentals for many other methodologies or approaches. The authors don't spend enough time hitting hard the concepts of eliminating waste, value stream mapping, tight cycles, etc.
Worse yet, in the authors' attempts to give only high-level coverage of concepts they do a bad job of describing some critical issues. As an example, I screamed, literally, when I found this passage in their section on Reuse Existing Software:
"Software reuse exists in many different forms, each of which affects codebase size differently:
* Copying source code from one component to another reduces coding time and debugging, but it actually increases codebase size."
Dudes. Really. Copy and Paste development is awful for so many reasons. An increase in codebase size is utterly the last issue you should be talking about when discussing why you should never do it. Instead, focus on the impact of copy/paste on code complexity, violation of DRY principles, the loss of clarity, increased dependencies, and the replication of bugs throughout your codebase.
This isn't an awful book, and the authors generally did a good job laying out the material. I also loved that they included a good intro to Kanban. The problem is a lack of focus and a sacrifice of vital information in an attempt to turn an introduction to Lean into some sort of 30 minute infomercial.
Lean development - 2009-03-12
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
I saw this book on the shelf in the local book store. I had read several things by the Poppendiecks on Lean Development; O'Reilly publishes high quality books, and so I bought it. I like the book with a few mild disappointments. First, the book is thin - about 120 pages. That is fine, but the publisher made it thin by using tiny print. Why do they do that? Second, the chapter that taught me the most was the final one. I didn't like waiting to the end to find the best part of the book.
The authors start the book with the Standish Group Chaos study. I didn't think anyone did that any more. The publisher or editor should have removed that section. Then they move into descriptions of Agile methods and Lean methods. They have plenty of good material here. If you are in management and do not recognize these terms, this book is for you. The authors give proper credit to Tom and Mary Poppendieck.
I didn't like their description of the Waterfall or serial model. I have seen that model work quite well in many projects under the right circumstances. A description of how to pick a model depending on the circumstances would have been good here.
The major part of the book (chapters 3-8 of a 9-chapter book) describes the main practices of Lean software development. The authors present the practices in the order they recommend the reader adopt them. The practice and their recommended order of adoption are:
Practice 0: Source code management and scripted builds
Practice 1: Automated testing
Practice 2: Continuous integration
Practice 3: Less code
Practice 4: Short iterations
Practice 5: Customer participation
There is little that is new in this book. Its good points are that, even with the tiny print, it is brief, to the point, and gives the reader a path to follow to work lean practices into an existing organization. If you are unfamiliar with lean or haven't considered it for a while, pick up this book.
Good, brief overview of lean systems development - 2009-03-08
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
This two-hour read is a brief, 5,000 foot view of lean systems development. The substance of the book is in less than a hundred 1.5 spaced pages. It is to the point and concise, almost to a fault.
The book focuses almost exclusively on four key ideas and two "old-hat" SDLC era ideas that clearly communicate the essence of the lean philosophy:
1. Source code management
2. Automated tests
3. Continuous (unit and system) integration
4. Less code (huh?)
5. Short iterations
6. Customer participation (duh!)
I also found their brief discussion of the origins of lean systems development practices in Toyota's development process for the Prius to be unusually insightful.
Although the book is lacking in-depth details of "how tos," but is strong on substance. In other words, you will not gain working knowledge of nitty gritty details of how to implement lean processes, but you will get a crystal clear idea of the underlying principles behind lean. Which to me is a huge plus because it increases the shelf life of my twenty-five dollar purchase beyond the next toolkit, SCM system, and the next fad. I believe that focusing on the underlying principles rather than implementation details is the authors intent.
With that caveat about what to expect from this thin volume in mind, I highly recommend the book.
5 Practices for Lean Software Development - 2009-02-27
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
I agree with the authors review, that this is a only for people new to lean or agile development.
That being said, it has an excellent set of practices for people wanting to adopt agile programming practices. Starting with Source Control Management, and Scripted Builds (the Zero Level Practice they say all teams must do before anything else), each following chapter adds an additional practice. Automated Testing, Continuous Integration, "Less Code", Short Iterations and Customer Participation. Each practice is explained with pros and cons and how you can implement it into your process.
It was a very quick read and I plan on sharing it with my team soon.
A Brief Introduction/Review of All That's New in Software Development - 2009-03-19
Reviewer Rating: ![]()
![]()
![]()
![]()
![]()
In a brief 128 pages, this Afternoon Read provides an excellent introduction, or review of everything that has happened in Software Development since about 1970, when Royce's Waterfall Model was the dominant view of how to efficiently engineer software. It describes the relationship between Lean Software Development models and developments in the Japanese manufacturing industry, describes the major distinction between Lean and Agile Development practices, as well as those of XP, SCRUM, etc. In addition to the high-level business/software development strategies, that are contrasted, this succinct introduction to modern Software Engineering Practices, provides basic instruction in six modern development methods which have streamlined and regularized this industry.
These are:
1.Source Code Management/Revision Control Systems
2.Automated Testing
3.Continuous Integration
4.Less Code/Refactoring
5.Short Iterations
6.Customer Participation
This compact summary of Modern Software Development Practices is perhaps
best directed to someone new to significant development efforts (perhaps
someone who has taken isolated programming and data structure courses), or needs a review of modern practices before choosing a methodology for a particular significant development effort. It is the very best summary of current Software Engineering that can be read in a few hours.
--Ira Laefsky
Top Level Categories:
Software Engineering
Sub-Categories:
Software Engineering > Agile Computing
Software Engineering > Testing and Debugging
Some information on this page was provided using data from Amazon.com®. View at Amazon >