7种常见的浪费

1. 未完成的任务（Partially done work）  

 

Partially done software development has a tendency to become obsolete, and it gets in the way of other development that might need to be done. But the big problem with partially done software is that you might have no idea whether or not it will eventually work. Sure, you have a stack of requirements and design documents. You may even have a pile of code, which may even be unit tested. But until the software is integrated into the rest of the environment, you don't really know what problems might be lurking, and until the software is actually in production, you don't really know if it will solve the business problem.

 

Partially done development ties up resources in investments that have yet to yield results. In software development these investments are sometimes capitalized, and depreciation starts when the software goes into production. What if the system never makes it into production? Then there is a big investment to write off. Partially done software development can carry huge financial risks. Minimizing partially done software development is a risk-reduction as well as a waste-reduction strategy.

 

部分完成的工作，倾向于被弃置，而且它们还阻碍了其他需要完成的工作。

（译者注：开发部分完成的工作占用了完成其他更有价值的工作的资源）

 

最大的问题是你无法判断部分完成的工作是否真的能够像期望的那样工作。

（译者注：没有完工的软件，谁知道里面有多少bug?)

 

当然你有一堆需求和设计文档，而且还有一堆代码，甚至有单元测试。

但是直到软件集成到其他的环境中，你无法确定有什么隐患，而且直到软件运行在工作环境，你不确定软件是否解决了业务问题。

 

2. 多余的流程(Extra Processes)

 

Do you ever ask, Is all that paperwork really necessary? Paperwork consumes resources. Paperwork slows down response time. Paperwork hides quality problems. Paperwork gets lost. Paperwork degrades and becomes obsolete. Paperwork that no one cares to read adds no value.

 

Many software development processes require paperwork for customer sign-off, or to provide traceability, or to get approval for a change. Does your customer really find this makes the product more valuable to them? Just because paperwork is a required deliverable does not mean that it adds value. If you must produce paperwork that adds little customer value, there are three rules to remember: Keep it short. Keep it high level. Do it off line.

 

Safety-critical systems are frequently regulated and are often required to have written requirements, traceable to code. In this case, formatting the requirements so they can be easily evaluated and checked for completeness may qualify as a value-adding activity. Look for a table-driven or template-driven format that reduces the requirements to a condensed format that both users and developers can rapidly understand and validate.

 

A good test of the value of paperwork is to see if there is someone waiting for what is being produced. If an analyst fills out templates, makes tables, or writes use cases that others are eager to use—for coding, testing, and writing training manuals—then these probably add value. Even so, there should be a constant search for the most efficient, effective means to transmit the information. Consider writing customer tests instead of requirements. In general, delay documenting the details of desired features until the iteration in which they are implemented.

 

3. 多余的功能（Extra features） 

 

It may seem like a good idea to put some extra features into a system just in case they are needed. Developers might like to add a new technical capability just to see how it works. This may seem harmless, but on the contrary, it is serious waste. Every bit of code in the system has to be tracked, compiled, integrated, and tested every time the code is touched, and then it has to be maintained for the life of the system. Every bit of code increases complexity and is a potential failure point. There is a great possibility that extra code will become obsolete before it's used; after all, there wasn't any real call for it in the first place. If code is not needed now, putting it into the system is a waste. Resist the temptation.

 

4. 工作转换（task switching） 

 

Assigning people to multiple projects is a source of waste. Every time software developers switch between tasks, a significant switching time is incurred as they get their thoughts gathered and get into the flow of the new task.[5] Belonging to multiple teams usually causes more interruptions and thus more task switching. This task switching time is waste.

 

The fastest way to complete two projects that use the same resources is to do them one at a time. Say you have two projects that should each take two weeks. If you start one of them, it should be done in two weeks. When it's done, you can start the second project, and it should be done in two weeks. What if you start both projects together and expect people to switch between them? First of all, neither one will be done in two weeks, but will they both be done in four weeks? When you add the switching time, they will probably take closer to five weeks.[6]

 

It is difficult to resist the temptation to start several projects at the same time, but releasing too much work into a software development organization creates a lot of waste, since it actually slows things down. Work moves much faster through a pipeline that is not filled to capacity, as we discuss in the section on queueing theory in Chapter 4, "Deliver as Fast as Possible."

 

5. 等待（Waitting） 

 

One of the biggest wastes in software development is usually waiting for things to happen. Delays in starting a project, delays in staffing, delays due to excessive requirements documentation, delays in reviews and approvals, delays in testing, and delays in deployment are waste. Delays are common in most software development processes, and it seems counterintuitive to think of these delays as a waste. It would seem that at worst, delays are neutral.

 

So what's wrong with waiting? Delay keeps the customer from realizing value as quickly as possible. When a critical customer need arrives in your development organization, the speed with which you can respond is directly related to the systemic delays in your development cycle.

 

For some environments, delay may not loom as large as other problems. However, if you are developing software for an evolving domain, delays in development are more serious. A fundamental lean principle is to delay decisions until the last possible moment so you can make the most informed decision possible. This is an options-based approach to software development, and it is the best way to deal with uncertainty, as we discuss in Chapter 3, "Decide as Late as Possible." You cannot delay decisions, however, if you cannot implement rapidly once a decision is made.

 

6. 走动（Motion）

 

When a developer has a question, how much motion does it take to find out the answer? Are people at hand to help with a technical problem? Is the customer or customer representative readily accessible to answer a question about features? Can the developer find out the results of tests without walking down the hall? Development is an activity that requires great concentration, so walking down the hall takes a lot more time than you might think. It will probably take the developer several times as long to reestablish focus as it took to get the question answered. It is for this reason that agile software development practices generally recommend that a team work in a single workroom where everyone has access to developers, to testers, and to customers or customer representatives.

 

People aren't the only things that move—various artifacts move also. Requirements may move from analysts to designers, and then design documents move from designers to programmers, and then code moves from coders to testers, and so on. Each handoff of an artifact is fraught with opportunities for waste. The biggest waste of all in document handoffs is that documents don't—can't, really—contain all of the information that the next person in line needs to know. Great amounts of tacit knowledge remain with the creator of the document and never get handed off to the receiver. Moving artifacts from one group to another is a huge source of waste in software development.

 

7. 缺陷（Defects） 

 

The amount of waste caused by a defect is the product of the defect impact and the time it goes undetected. A critical defect that is detected in three minutes is not a big source of waste. A minor defect that is not discovered for weeks is a much bigger waste. The way to reduce the impact of defects is to find them as soon as they occur. Thus, the way to reduce the waste due to defects is to test immediately, integrate often, and release to production as soon as possible.