在很多经历过程改进的团队,如通过CMM/CMMI评级的团队都用某种方式费了不小的力气实现了需求跟踪这个关键的Practice,但往往评估师往往对会指出团队在需求管理/跟踪上还是有欠缺,还是可提高。
问题出在哪里呢?
需求跟踪无法有效的进行导致无法对整个开发活动进行准确掌控,总结下来,问题根源在需求信息关联关系的建立方式上。
常见的建立关联的方式有两种:一种“隐式关联”,即需求关联信息是隐含在各个文档中的,隐式地表明了需求之间的关系。
在对应的各个信息层次,项目团队用编号标识信息模块,如需求编号、系统功能点、子系统编号、测试用例编号等等;并在书写文档时,标识需求条目之间对应关系,如该系统功能点是对应满足哪个需求,或又如该测试用例是对应哪个系统功能点。
在项目的前期,开发人员在书写文档时会对需求模块进行标识,同时也标识对应关系。令人痛苦的是维护这样的信息标识和信息之间关联关系:虽然各人维护各自的文档容易,但调整后要向所有相关人员准确通知修改内容的工作耗时耗力,很多开发人员不愿做,或者是“忘了做”;利用需求的关联关系也不容易,关联关系的标识是在各个文档内部,需要在一系列文档中进行查找才能保证需求跟踪的完备性。更何况当需求的关联关系由于上文提及的原因不能及时更新、不能准确反映项目实际时,需要跟踪的意义更小。
现实很简单:即使流程的本意是好的,但实现方法上出了问题,造成开发人员不愿执行或“忘了执行”,这样的流程也是值得商榷的。