软件开发过程中的等待

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

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

(1)等待客户确认
(2)等待上司命令
(3)等待环境构筑
(4)等待前一个阶段的成果物
(5)等待Bug修改完毕
(6)等待测试结果
(7)等待UI设计图
(8)等待不知道什么——莫名其妙的等待

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

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

等待是怎么发生的呢？

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

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

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

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

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

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

在分析出问题的现象之后应该继续分析问题的实质。
之所以回归测试的过程需要等待的原因是流程本身设计有误。也就是说，测试需要等待的流程设计导致了等待的发生。

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

 

转载于:https://www.cnblogs.com/stephen-wang/archive/2012/11/08/2761657.html