0°

共读DAY009《软件需求最佳实践》09

2016-10-10《软件需求最佳实践》徐锋著

第9章 需求基线操作实务

小婧:我们今天进入到第三部分:需求管理。关于这个部分的内容虽然不多,但是实践起来难度很大。因为这里面情况非常复杂。本书也只是给大家一些建议和方法的指导,讲的不是特别深入。如果大家有相关的其他好书也请留言推荐呀!


1需求基线的理念与策略

A需求基线

《软件需求》一书中对需求基线(Baseline)的定义是:“团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合”;RUP中的基线定义是:“逐项列举的在应用程序的某个特定版本中提交的特征和需求的集合”。

从上面的定义中,我们可以看到两个最为重要的内容:一是“特定版本”,二是“一组需求集合”。

● 特定版本:说明在整个软件的开发过程中将出现多个不同的版本,这也意味着将采用分阶段或迭代开发模式。

● 一组需求集合:也就是需求的一个子集,可以理解为纳入基线的需求是将投入开发的需求,而其他的则是已提出但还没有接受或没有着手开发的需求。

小婧:我不清楚其他人是否知道“baseline”是什么,相信做过项目管理的人应该很清楚。所谓基线就是做一个快照,我们经过正式的review达成共识的一个版本。主要作用是为了后续进行变更时可以知道两个基线之间的变化到底是在哪里,属于管理的范畴。而简单理解即在下一个版本我们决定要交付的需求清单是什么,这就是一个初始的需求基线。


B基线的策略


何时划定基线的问题了。在这点上,有两种不同的观点:

● 划定基线必须在需求细节填充完成后:也就是划定基线时,相应的需求细节都要完整;这种方法在具体操作时有些困难。

● 划定基线可以在需求项标识出来时:也称为“早基线,晚冻结”。

小婧:做项目管理的人都知道,WBS的编制是滚动的渐进明细的。也就是说,让你做一个三年计划,每个月做什么,你肯定做不出来,最多只能定出每年做什么。但是在今年的计划中,你可以明确每个季度做什么,甚至每个月做什么,但是不能确定每个星期做什么。同样,在最近的两个月,你可以明确每个星期做什么。这就是渐进明细。对于眼前的事情,我们比较容易做计划,而太长远的计划我们无法进行很详细的计划。

这和基线策略有什么关系呢?

我们在划定基线的时候可以不用明确所有功能的原型和逻辑,而在确定基线后,以迭代的方式进行渐进明细。以敏捷为例,基线包括100个REQ的Backlog,而BA只需要分析明确前20个,确保前两个Sprint的正常进行,而在这两个Sprint进行的过程中再去明确接下来的20个。


2 基线划定的基础:优先级评价


在进行优先级评价之前,我们首先要将所有的需求项组织成一个树型结构(实际上就是WBS结构),然后按以下步骤进行优先级判断。

● 业务优先级判断:根据业务结构特点,对所有需求项划分等级。

● 技术依赖性、项目风险判断:从技术实现、项目风险两个角度调整优先级。

小婧:敏捷一直都强调,story的划分以及优先级是根据业务价值来定的。而在实际的工作中,我们很难做到story之间高内聚低耦合。主要原因是配套的重构执行起来比较难。

这里不禁要吐槽:没有重构配合的敏捷都是耍流氓,没有每日构建的敏捷都是假象。

以至于我们不论采用哪种研发模式,在定义需求优先级时需要全面考虑。就算有的需求优先级没那么高,但是因为高优先级的需求是基于它的,自然就带高了它的优先级。再说一次,在敏捷中这种情况应该极少存在,不是story拆分的问题就是懒得做重构。


3基线划定的要素:工作量估算


软件估算是随着工作任务的细化不断提高精确度的。

想更好地在需求阶段完成估算,就应该适当地根据实际的情况(包括项目特点、开发方法)考虑选择更容易找到的计数单元。

小婧:在国内的大部分产品和项目中,工作量估算的任务是丢给项目经理或者开发负责人的,但是我觉得可以采用敏捷的方式进行point评估工作量。这也是为什么有的需求优先级比另一个低但是会先做的原因。



4基线划定与管理


A划定基线


在划定基线时,我们首先根据优先级来进行筛选,优先级越高的就应该安排在较早的基线中。

B管理基线


在项目开发过程中有两个重要的变化因素,会对预先的计划产生破坏:

● 需求变更:在整个开发过程中,需求会发生变化;这些变化应该更新到“待处理需求”集(Backlog)中,并不直接影响基线。

● 迭代过程未完成:虽然从项目管理的角度,我们不希望每次迭代结束时还有遗留任务没有完成;但从需求管理的角度,这种现象又是不得不处理的。每次迭代总是有可能发生未完成某些任务的情况,这些将影响下一次迭代的基线。

可以采用的策略是:划定两次基线,一个基线投入开发迭代,另一个基线开始细化需求,从而实现流水线作业。而一次将各次的基线都划定出来是肯定做不到的。

小婧:按照理想的观点就是,每一次的需求变更都需要做影响分析,重新打基线,并且对比基线之间的差别。但是我觉得能把基线管理好是第一步,有很多项目根本就没基线,甚至连需求都没有统一进行管理。基线的管理理念在需求管理方面的作用还是比较薄弱的,主要是为了需求变更做准备。没有基线就无所谓的变更。



小婧是一名行走在产品路上的资深业务分析师(BA),如果想与我同行,就请关注我吧!

共读DAY009《软件需求最佳实践》09







「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论