qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

如何有效实现软件的需求管理(6)

如何有效实现软件的需求管理(6)

 在我们公司,获取了一个需求以后,

  首先,相关人员会先在DevSpec建立一个条目,添加相应的一些属性信息,比如标题,内容描述,状态,对应文档,优先级,紧急程度,负责人,对应版本,对应浏览器,对应数据库等等。。。

  提交完了条目以后,由于这个条目设置了一个负责人,所以那个负责人登录系统就可以马上看到自己名下有这个条目,他就会马上去处理这个需求。(可能有些人没登录系统去看,我们也可以设置Email或者手机短信的自动提醒功能)

  这里提到的“负责人”,在不同的过程里,负责人都是不同的,比如“评审”阶段就有专门的评审负责人,普通人无法成为评审负责人,哪些人在哪些过程里能成为负责人是可以在流程中设置的。而上面提到的提交完条目后,一般情况第一个过程就是要审核刚获取的需求,负责人审核通过后就可以把这个需求从“审核”状态改到“需求分析”阶段了,当然负责人也会改变,“需求分析”过程的负责人就会马上知道自己有事情干了。

  就这样,经过一个一个的过程,经手了一个一个的负责人,这个需求就逐渐从一个只有一个思想,到有了轮廓,再设计出里面的框架,然后最后被实现。

  其实,大家都是这么来处理需求的,不同的是,我们通过一个工具来管理这个过程,而有些公司只是就人工来做一下。我们这么做,好处和坏处其实都有,正如之前有个客户问,你们这么做的话,是不是每一个需求的处理效率会降低?对,的确会降低,我们承认,因为这些都是严格的流程,而且是在一个系统中管理,肯定没有他们口头直接说一下快。但是,我们考虑的是我们是在卖产品,牺牲一部分的效率来确保产品的质量,我们觉得划得来,毕竟质量才是最重要。人家虽然速度快,但是问题也来得多,需求多的时候,这个忘做了,那个做错了,或者相互责任推来推去的事情多着了,最终导致产品质量出问题的事情比比皆是。但是我们用了系统以后,就避免了这些事情,实践也证明了我们这么做以后,产品质量是得到保证了的。

  当然,产品的质量也不是简简单单像我说上面说的“经过一个一个的过程,经手了一个一个的负责人”就能马上实现了,这里还会涉及到很多细节注意点了,待我一一道来。

我之前说过需求管理有几个严格的要求,流程化和审核机制大家其实已经看到了,其实在某种程度上,审核是流程化的一部分,因为审核过程本身就是需求处理过程中一个过程而已,我们只要在流程中设置了这种过程,安排负责人去负责就行了,当需求进入这个过程,就自然有人会去审核了。

  如果把上面两个要求看成是需求管理的基础的话,那其他几个严格的要求:欢迎变更、版本控制、可跟踪性,就可以看成是确保产品质量成功的关键点了。有了基础才有可能成功,有了关键点才能保证成功!

  欢迎变更:

  欢迎变更的重要性大家应该知道了,变更其实也就是需求经常变,从某种程度上也就意味着产品的质量下降,因为这个需求你不断变化,今天刚写好这段代码,明天要改成那样,后天又要大改,谁都知道有潜在风险,而且还有与之有关联的功能呢?你突然改了个接口参数,人家可能还不知道了。靠测试?测试人员也没法很好解决这个问题,因为今天刚测完这个功能,明天却大改了,但是那个测试人员虽然看到这个功能需要测试,但是他却可能认为昨天已经测好了,是不是忘记关闭了,所以就去测其他功能了。

  那怎么解决呢?也很简单,当有变更的时候,

  首先,尽量让相关的人知道,让开发知道,让测试知道,让需要我们接口的人知道,这样子大家就都会同步就完成自己要做的事情,不会出现需要做的人却不知道他要去做这个事的情况。在DevSpec中,我们可以采用变更自动通知功能来实现,因为在DevSpec中一个需求总是和它的开发任务和测试任务关联在一起的,所以当需求有了变更以后,只要发送一个通知,开发人员和测试人员就能马上看到变更,就能及时去做他们的工作了。

  第二点就是,尽量把影响的范围搞得清楚点,让开发知道哪些地方可能会影响到,做的时候小心点;让测试知道这个改动会造成哪些地方有潜在的Bug,需要重点测一下。在DevSpec中,我们会有专门的功能让设计人员和开发人员注明影响到的地方,需要重点测的地方,而且这个功能可以设置成强制,只要有变更,设计人员和开发人员就必须注明,甚至可以要求测试人员也注明测了哪些点,可以让设计与开发人员检查是否有遗漏。

  第三点就是,针对任何变更(特别对于瀑布模式那种公司),因为关系到了可能会影响质量、进度及成本,风险很大,所以对于变更的内容需要专门的评审流程,评审通过后才能开始开发。在DevSpec中,我们针对这种情况,就会经常启用变更管理视图,在这个视图中,会有特别的流程对变更做评审,在次期间,这个需求是没办法被任何人转到开发环节的,也避免了有些人不清楚情况,直接就把没审核的需求直接让开发去做了。(当然,我们现在很多产品已经是用敏捷开发的模式了,所以这个功能就用得比较少了)

  这样子做的话,我们还是能把质量掌握在自己的手中,也就是把公司的前途掌握在自己手中。

  (未完待续)

posted on 2011-12-09 16:28 顺其自然EVO 阅读(108) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2011年12月>
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜