该帖子同步发自：(wcabt的博客  访问该博客)

　　【定义】确认管理是确保“你做了正确的事”。

　　【摘要】如果确认做得不到位，会在后续的过程中产生矛盾。例如：开发阶段，单元测试测试代码行覆盖率不达40%(根据实际规定)，集成测试，代码行覆盖率不达标30%(根据实际规定)，发布后，到了测试阶段，会有更多问题出现。会导致开发和测试之间的互相不信任。

　　为什么开发和测试之间总是反复

　　【案例】

　　最近某软件公司GIS项目组负责人小黎头痛不已，项目已经进展到系统测试阶段，软件开发人员提交给测试组的产品总是无法通过系统测试，甚至一天出现两三次产品内部的发布，软件开发和测试人员都被加班压得透不过气来。软件开发和测试人员之间的埋怨也越来越多，开发人员认为软件测试人员在挑他们的毛病。软件测试人员总是觉得产品质量实在太差，还没有怎么测试系统就不能使用，这样的产品就不应该发布。可是软件开发人员却认为他们做过了单元测试和集成测试，所以提交的产品质量是合格的。

　　项目负责人小黎觉得这个问题必须尽快解决，开发与测试之间的反复已经导致项目延期了一周的时间，以这样的情况发展下去还有可能恶化。更重要的一点是项目团队成员之间出现了矛盾，软件开发和测试人员之间已经越来越缺乏信任，这样下去将导致项目彻底崩溃。

　　【分析】

　　项目负责人小黎找到项目总监张经理，希望得到他的帮助。项目总监经过对项目组成员的访谈以及实际查看了项目的代码后，发现项目组发生的问题都是因为没有对工作产品进行确认而导致的。

　　本着“亲兄弟明算账”的原则，软件开发人员必须证明他们提交的工作产品已经符合了质量的要求，软件测试人员也要确认开发人员所讲的是否是真实的。公司已经规定了单元测试代码平均覆盖率至少为60%，集成测试用例代码平均覆盖率至少为45%，那么确认的准则已经存在，就应该按照此准则进行确认。

　　小黎按照张总的要求对项目组下达了对每次发布必须进行确认的任务，这下产品内部的发布戛然而止，原因是开发人员注意到他们的单元测试用例和系统测试用例很多都是重叠的，代码覆盖的比例达不到公司的要求，因此他们需要增加新的测试用例。在随后的日子中通过增加单元测试用例和集成测试用例又发现了很多产品质量的缺陷。

　　通过采取对工作产品进行确认后，产品只经过了两轮的反复就通过了系统测试，而且开发和测试人员之间的矛盾也大大降低了。

　　确认是对需求变更的约束

　　【案例】

　　某软件公司人力资源管理系统的项目经理小白非常开心，因为他的项目已经顺利通过验收。虽然项目过程中发生了一大一小两次需求的变更，但是项目的进度、成本并没有发生什么偏差。公司领导让小白对他的项目进行总结，并且将心得体会与其他项目组成员进行分享。小白在他的项目经验总结中就提到了一点：“需求的确认工作是对需求变更的约束”。

　　【分析】

　　小白在项目需求调研阶段就把《软件需求说明书》拿出来让客户进行了确认，客户通过对需求说明书的评审了解到他们所提出来的内容已经完全包含在《软件需求说明书》中，由于《软件需求说明书》的内容非常细致，因此客户对本次合作充满信心，所以很痛快地就进行了确认。但在设计和编码开发阶段分别发生了一次需求的变更，主要原因是客户方忽略了一些需要实现的功能而没有告诉项目组，但是客户又对《软件需求说明书》进行了确认。由于第一次变更的影响不大，小白决定免费为其进行修改，并且将变更后的《软件需求说明书》给客户进行再次确认，客户对小白的工作态度非常满意。

　　当在编码阶段发生再次需求变更时，小白将变更的影响告知了客户，并且提示客户方已经先后两次对需求进行了确认，希望可以对此次变更增加相应费用。客户方的代表也觉得自己有一定责任，所以就相应延长了项目的时间并增加了项目的费用，直到最后项目顺利交付。

　　因此小白在本次项目中最大的收获就是体会到软件确认管理给项目需求变更带来的好处。

　　小结

　　软件确认管理可以使软件研发“流水线”前、后环节中的操作人员增加彼此之间的信任感，而减少互相间推卸责任的理由。软件确认管理可以确保软件生命周期中的每个阶段都按部就班地开展工作，避免了外界或人为的因素而导致项目出现混乱，它是让项目“冷静”下来的重要手段。