LD is characterized by seven lean principles that are elaborated into 22 Lean Software Development tools.
Eliminate Waste
Tool 1: Seeing Waste—You should looking for waste in these parts of your development process:
◗ Partially done work (e.g., unimplemented designs);
◗ Extra processes (steps in your process that do not add value);
◗ Extra features (things for which the customer did not ask);
◗ Task switching (people assigned to multiple projects);
◗ Waiting (for hand-offs);
◗ Motion (hand-offs);
◗ Defects.
Tool 2: Value Stream Mapping—Identify all the steps in your process that add value to the product, and for each of those steps, identify how much time is required to add the value and how much time is wasted in waiting. Note that some steps that do not directly add value are necessary (e.g., Configuration Management mitigates risks).
Amplify Learning
Tool 3: Feedback—Design your process so that participants receive feedback as often as possible. For example:
◗ Test early and often;
◗ Show users the evolving system;
◗ Prototype instead of analyzing.
Tool 4: Iterations—Iterative time-boxed development is the best way to converge on the ultimate solution. Often this results in negotiation of project scope or duration. But such negotiation is good if done early in the project, when adjustments are less painful.
Tool 5: Synchronization—Every development method results in synchronization problems (e.g., collective code ownership can result in multiple people changing the same program at the same time.) The authors recommend several synchronization mechanisms for software projects.
Tool 6: Set-Based Development—When faced with a difficult problem, it is often good to think about the solution space instead of specific solutions. The authors recommend these steps:
◗ Develop multiple options (e.g., brainstorming ideas);
◗ Communicate constraints;
◗ Let the solution emerge.
Decide as Late as Possible
Tool 7: Options Thinking—In financial markets, you can purchase options that, for a price, allow you to delay making a decision until a later date. The same model can be used in Agile software development. By incurring some added cost, options can be held open, allowing decisions to be delayed until more information is available.
Tool 8: The Last Responsible Moment—Options Thinking (Tool 7) delays commitment to a decision until the last responsible moment. The authors define that as “the moment at which failing to make a decision eliminates an important alternative” .
Tool 9: Making Decisions—Good decisions are more likely to be made when the options can be narrowed by the application of a set of rules. The authors recommend that decisions in software development always be made in light of the seven lean principles
Deliver as Fast as Possible
Tool 10: Pull Systems—The best way to ensure that each team member knows exactly what he or she should do each day is to ensure that the environment provides automatic prompting. For example:
◗ Short iterations with well-defined deliverables provide near-term targets for people to work toward.
◗ Daily stand-up meetings keep everyone aware of progress toward that target.
◗ Information radiators (publicly posted charts) keep everyone aware of the big picture.
Tool 11: Queuing Theory—Much waste can be attributed to people waiting for constrained resources. The authors suggest using queuing theory to analyze all bottlenecks in your software process and determine ways to minimize the cycle time.
Tool 12: Cost of Delay—In many software projects, the cost of delaying delivery (even when it is significant) is often invisible to the project team and sometimes to managers. The authors recommend developing a financial model for the project that will allow all stakeholders to make appropriate trade-off decisions, especially when cost and delivery date are in conflict.
Empower the Team
Tool 13: Self-Determination—The people who do the work are in the best position to improve their processes and eliminate waste. Although Quality Circles have fallen out of favor, this philosophy still has value in guiding process improvement efforts.
Tool 14: Motivation—Motivating a project team to perform well has many dimensions. The authors stress that the team must have:
◗ Purpose—A shared goal that they all believe in.
◗ Belonging—They feel that each person is a part of the team.
◗ Safety—Mistakes are corrected without punishing people.
◗ Competence—The team feels they able to complete their tasks.
◗ Progress—Each person can see regular progress on the project.
Tool 15: Leadership—Project management and technical leadership are two distinct skill sets. A successful team needs both, and it is rare for those two attributes to exist in the same person.
Tool 16: Expertise—Every software project requires a variety of expertise (e.g., domain, user interface, database, project management, writing). This tool is about identifying communities of expertise and ensuring that they are available to the project.
Build Integrity In
Tool 17: Perceived Integrity—Perceived Integrity is the system’s integrity from customers’ viewpoint. Do they perceive it to be useful and well designed? With appropriate interaction between the team and customer, the team can be sure they build the right system.
Tool 18: Conceptual Integrity—Conceptual Integrity is an important component of Perceived Integrity (Tool 17). Building the system right (as differentiated from building the right system) involves such concepts as architecture, consistency, and elegance.
Eliminate Waste
Tool 1: Seeing Waste—You should looking for waste in these parts of your development process:
◗ Partially done work (e.g., unimplemented designs);
◗ Extra processes (steps in your process that do not add value);
◗ Extra features (things for which the customer did not ask);
◗ Task switching (people assigned to multiple projects);
◗ Waiting (for hand-offs);
◗ Motion (hand-offs);
◗ Defects.
Tool 2: Value Stream Mapping—Identify all the steps in your process that add value to the product, and for each of those steps, identify how much time is required to add the value and how much time is wasted in waiting. Note that some steps that do not directly add value are necessary (e.g., Configuration Management mitigates risks).
Amplify Learning
Tool 3: Feedback—Design your process so that participants receive feedback as often as possible. For example:
◗ Test early and often;
◗ Show users the evolving system;
◗ Prototype instead of analyzing.
Tool 4: Iterations—Iterative time-boxed development is the best way to converge on the ultimate solution. Often this results in negotiation of project scope or duration. But such negotiation is good if done early in the project, when adjustments are less painful.
Tool 5: Synchronization—Every development method results in synchronization problems (e.g., collective code ownership can result in multiple people changing the same program at the same time.) The authors recommend several synchronization mechanisms for software projects.
Tool 6: Set-Based Development—When faced with a difficult problem, it is often good to think about the solution space instead of specific solutions. The authors recommend these steps:
◗ Develop multiple options (e.g., brainstorming ideas);
◗ Communicate constraints;
◗ Let the solution emerge.
Decide as Late as Possible
Tool 7: Options Thinking—In financial markets, you can purchase options that, for a price, allow you to delay making a decision until a later date. The same model can be used in Agile software development. By incurring some added cost, options can be held open, allowing decisions to be delayed until more information is available.
Tool 8: The Last Responsible Moment—Options Thinking (Tool 7) delays commitment to a decision until the last responsible moment. The authors define that as “the moment at which failing to make a decision eliminates an important alternative” .
Tool 9: Making Decisions—Good decisions are more likely to be made when the options can be narrowed by the application of a set of rules. The authors recommend that decisions in software development always be made in light of the seven lean principles
Deliver as Fast as Possible
Tool 10: Pull Systems—The best way to ensure that each team member knows exactly what he or she should do each day is to ensure that the environment provides automatic prompting. For example:
◗ Short iterations with well-defined deliverables provide near-term targets for people to work toward.
◗ Daily stand-up meetings keep everyone aware of progress toward that target.
◗ Information radiators (publicly posted charts) keep everyone aware of the big picture.
Tool 11: Queuing Theory—Much waste can be attributed to people waiting for constrained resources. The authors suggest using queuing theory to analyze all bottlenecks in your software process and determine ways to minimize the cycle time.
Tool 12: Cost of Delay—In many software projects, the cost of delaying delivery (even when it is significant) is often invisible to the project team and sometimes to managers. The authors recommend developing a financial model for the project that will allow all stakeholders to make appropriate trade-off decisions, especially when cost and delivery date are in conflict.
Empower the Team
Tool 13: Self-Determination—The people who do the work are in the best position to improve their processes and eliminate waste. Although Quality Circles have fallen out of favor, this philosophy still has value in guiding process improvement efforts.
Tool 14: Motivation—Motivating a project team to perform well has many dimensions. The authors stress that the team must have:
◗ Purpose—A shared goal that they all believe in.
◗ Belonging—They feel that each person is a part of the team.
◗ Safety—Mistakes are corrected without punishing people.
◗ Competence—The team feels they able to complete their tasks.
◗ Progress—Each person can see regular progress on the project.
Tool 15: Leadership—Project management and technical leadership are two distinct skill sets. A successful team needs both, and it is rare for those two attributes to exist in the same person.
Tool 16: Expertise—Every software project requires a variety of expertise (e.g., domain, user interface, database, project management, writing). This tool is about identifying communities of expertise and ensuring that they are available to the project.
Build Integrity In
Tool 17: Perceived Integrity—Perceived Integrity is the system’s integrity from customers’ viewpoint. Do they perceive it to be useful and well designed? With appropriate interaction between the team and customer, the team can be sure they build the right system.
Tool 18: Conceptual Integrity—Conceptual Integrity is an important component of Perceived Integrity (Tool 17). Building the system right (as differentiated from building the right system) involves such concepts as architecture, consistency, and elegance.
Tool 19: Refactoring—Programmers should improve the software any time they see the opportunity to do so. Refactoring refers to redesign of the system to improve the program’s Perceived and Conceptual Integrity (Tools 17 and 18).
Also, after many changes have been made to software, it tends to become brittle. (That is, over time, it becomes more and more difficult to make any changes to the software without breaking it in unforeseen ways.) Brittle code is a Conceptual Integrity problem that Refactoring remedies.
Tool 20: Testing—Testing provides an important feedback mechanism. (See Tool 3.) Both validation (ensuring the right system is built) and verification (ensuring the system is built right) must be done throughout the development process, not just at the end. That way, the team gets the feedback they need to ensure their system’s integrity, both Perceived (Tool 17) and Conceptual (Tool 18).
See the Whole
Tool 21: Measurements—The authors focus on the various problems associated with measurement (e.g., suboptimization) and their sources. In essence, this tool is about focusing measurement where it is effective: at higher-level aggregations of data. This focus has the dual benefit of protecting individual engineers from management’s abuse of their personal data and focusing attention on data that is useful to the organization as a whole.
Tool 22: Contracts—Contracts are a fact any time the supplier and customer are different companies. Because these relationships can be so complex and varied, the authors discuss a variety of contractual arrangements and the positive and negative effects of each.
References
- Poppendieck, M., and T. Poppendieck, Lean Software Development: An Agile Toolkit, Reading, MA: Addison-Wesley, Inc., 2003.
- Cockburn, A., Agile Software Development, Reading, MA: Addison- Wesley, Inc., 2002.
0 comments:
Post a Comment