等待在软件开发过程中的浪费比例应该是最大的。

　　下面这些种等待，在你的项目中是否也发生过呢？

　　（1）等待客户确认

　　（2）等待上司命令

　　（3）等待环境构筑

　　（4）等待前一个阶段的成果物

　　（5）等待Bug修改完毕

　　（6）等待测试结果

　　（7）等待UI设计图

　　（8）等待不知道什么——莫名其妙的等待

　　其实大可不必发生这些等待。

　　首先，要弄明白发生等待的原因，只有这样才能够找到根本去消除一些不必要的等待。

　　等待是怎么发生的呢？

　　第一种等待工序定义错误造成的。

　　为什么两个工序之间需要空闲时间呢？因为这两个工序是由不同的人来完成的。一个人工作的时候另外一个人必须等待。

　　---------------

　　比如：以Bug修改为例，测试人员登记Bug后，开发人员需要分析一下Bug产生原因，进行影响性分析，进而提出解决方案，并修改bug，自己验证后再提交给测试人员确认。

　　整个过程中，测试人员基本处在等待状态。

　　如果说这是因为工序就是这样定的，没有办法，只能等待，那就有些遗憾了。

　　在分析出问题的现象之后应该继续分析问题的实质。

　　之所以回归测试的过程需要等待的原因是流程本身设计有误。也就是说，测试需要等待的流程设计导致了等待的发生。

　　设想一下，如果把测试放在前面，而代码修改放在后面会怎么样呢？

　　也就是说，测试用例是通过自动测试代码来表达的。

　　开发人员只要运行测试代码就可以知道代码的修改是否正确。那么，此时测试代码已经书写完成了的测试人员大可以去做别的工作（比如增加新的测试用例），而无需等待。

　　--------------------

　　再比如，需求文档发送给客户后，需要等待的客户确认，只有等客户确认了之后才能够开始开发工作。

　　这也是工序要求如此，前一工程不完成，后一工序无法开始。

　　其实并不是这样的，这种等待是因为沟通方式选择错误。

　　需求采用文档书写就导致了必须要等待。如果（功能性）需求采用可以工作的原型来展示（也就是说直接开始开发工作，并且用开发出来的成果物向客户展示），那么只要客户确认说OK，就可以直接将原型转成可以工作的软件（比如修改开发版/发布版标志位）。换句话说，需求确认结束，开发也就基本完成了。如果客户说要变更，那就按要求变更，直到客户确认OK即可。

　　至于非功能性需求，如性能、安全、容错等可以通过会议讨论，白板拷贝的方式留下确认，马上进入开发对应，而无需等待。

　　上述两种等待是工序设计错误导致的等待，可以通过调整工序来规避。

　　第二种等待是由于管理不到位造成的。

　　比如：由于没有对需求确认文档进行管理，导致需求细节不明，需要回忆、搜索。在回忆搜索、期间无法进行后续工作所形成的等待就是管理不到位造成的。

　　但是，反过来讲，如果要将所有的确认细节进行文档整理，也是需要花费工时的，二者之间的得失如何权衡？开发团队会出于自我保护的目的而留下文档记录。但是这种做法还会形成别的浪费。比如：咬文嚼字。

　　那么功能性需求应该是怎么记录的呢？故事卡，编号。

　　更有甚者，全员停机杀毒...

　　管理不到位的问题，可以通过改善管理方式进行规避。