2.4 CMMI2级——需求管理(Requirements Management)

人是会死的,需求是会变的。相信大家都经历了很多需求变更的痛苦,项目被拖延,成本高涨,十有七八是需求管理没有做好导致的。有哪一些需求管理方面的常见问题呢,这里列举一下:

1.因为项目进度赶等原因,在很多需求还没有明确情况下,便开始开发的工作。

2.开始客户只能提出模糊的需求,客户喜欢先让你做个东西给他看,然后他才可能逐渐提出真正的需求,而需求调研人员,对此没有什么好的处理办法。

3.客户以种种原因不签需求,项目组在不签需求的情况下,便开始开发工作。

4.客户不承认之前提出来的需求,项目组又不能得失客户,项目成员苦不堪言。

5.需求经常变化,无法控制。

6.设计、代码与需求不对应,特别是需求变更时,不知道应该修改哪部分,也不知道会有哪些影响。

......

 

这方面的问题可真是“罄竹难书”了,需求管理这个PA提供了能解决以上大部分问题的最佳实践。

 

RM(Requirements Management)只有一个Specific Goals:Manage Requirements

Requirements are managed and inconsistencies with project plans and work products are identified.

 

中文大意是:

管理需求并且识别出需求与项目计划、工作产品不一致的地方。

这句话有两层意思:

1.需求要被管理,被管理的意思又有两层:一是需求要被确认,二是要控制需求变更

2.需求要用来指导下游的工作产品,如:计划、设计、测试等

 

下面简单介绍一下这个Specific Goals下的5个Specific Practice:

 

第一个SP是:理解需求。

开发者应该理解客户的需求,如果这点做不到,后面的工作是没有意义的。所以,那种在没有理解需求的情况下,就仓促开发的做法是不合适的。

当然,如果想通过做原型来获取需求不在此列,另外,大家也千万不要误解,在没有完全理解需求前一定不能开展开发工作,如果部分需求已经掌握,有部分需求还没有掌握,那也是可以先开展已掌握部分需求的设计、编码工作的,这时需要考虑没有确定部分的需求对这些工作可能带来的影响。

这个SP的英文原文是:Develop an understanding with the requirements providers on the meaning of the requirements.

 

第二个SP是:确认需求,就是要和客户签署需求。

我想大家都非常理解这点的重要性,但大家可能会说,说得容易,客户就是不签,咋办?客户不签需求,主要是两方面的原因:

1)客户不确定需求。

2)客户担心签了需求后,他就不好变了。

对于原因一,解决办法就是大家需要把SP1理解需求做好,如何把需求理解做好,更详细的内容可以参考3级的需求开发(RD),这里先不详细解说。

对于原因二,要消除客户的顾虑,首先签署需求不是单方面的约束,其实也是对开发方的约束,就是说我们要承诺做出这样的一个东西,如果做不出来,客户可以追究我们的责任,另外一个方面,要跟客户说清楚,需求是可以变的,现在签署只是标志着当前的一个工作里程碑,当前签订的需求,是我们后续工作的一个基准。

大家可能又会问如果只能确定一部分需求,客户还是不愿意签,咋办?那就先签确定部分的需求呗!

这个SP的英文原文是:Obtain commitment to the requirements from the project participants.

 

第三个SP是:管理需求变更。

需求不是不可以变,只不过需要管理。客户今天说改这,明天改那,后天又不算数,咋办?怎样才算管理需求变更呢?

1.要充分理解客户提出来的需求变更,深究其原因,不能客户一说变就变,超过一半的客户变更要求,其实都是不合理的,或者是有其它更好的替代办法的。

2.客户提出来的变更要求,要书面记录,并让客户确认,和客户讨论需求变更过程来往的邮件要保存好,和客户面谈、聊电话后,要发邮件总结当此会谈达成的要点共识,总之就是要有书面记录。

3.客户提出来的需求变更,要分析所有的影响,包括增加多少的工作量,需要修改或者增加哪些设计文档代码等,可能会引发什么风险等。所有这些要列出清单,反馈给客户,让客户确认。

4.如果需求变更导致项目成本和进度变化太大,超出可承受范围,则需要高层领导出面,和客户协商调整费用。

这个SP的英文原文是:Manage changes to the requirements as they evolve during the project.

 

第四个SP是:维护需求的双向跟踪。

需求是用来指导后续工作的,所以需求与计划、设计、编码、测试等后续工作都需要维护好对应的关系,这个工作与第三个SP是关系密切的,如果这个关系没有维护好,那么SP1.3也不可能做好。

这样是不是双向跟踪就能做好呢?不是,双向跟踪的意思不是由A能找到B,由B又能找到A就叫双向跟踪。双向跟踪是只纵向和横向跟踪,前面提到的只是纵向跟踪,纵向跟踪的意思是上下游工作产品之间的跟踪关系。而横向跟踪指的是需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等。其中一个需求变化了,有可能影响另外一些需求,其中一个设计变了也可能影响另外一些设计。

所以,这个双向跟踪网络,将会是一个很强的网络,任何一点发生变化,能找出全部受牵连的地方。

这个SP的英文原文是:Maintain bidirectional traceability among the requirements and the project plans and work products.

 

第五个SP是:识别出需求与下游工作产品不一致的地方。

这里有两层意思:

1.需求变更时,利用双向跟踪表找出需要修改的地方,并用跟踪表来发现不一致的地方并调整。

2.编写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品的时候,要注意要与需求保持一致。

这个SP的英文原文是:Identify inconsistencies between the project plans and work products and the requirements.

 

 

请看下一文……

 

 

作者:张传波

创新工场创业课堂(敏捷课程)讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》作者

www.umlonline.org创办人

 

posted on 2013-10-10 13:16  张传波(Fireball)  阅读(634)  评论(0编辑  收藏  举报