关于需求管理的胡思乱想---R3PR

1.啥是R3PR？

Requirement：需要做什么

Plan：计划怎么做

Resources：指派谁去做。当然资源还包括其他的，但谁让咱只是管编码的呢，在我手里，只有人是资源

Process：实际怎么做

Result：结果怎么样

2.包含哪些信息？

举个例子，编一个计算器程序。

Requirement：

ID	需求名称	描述	与其他需求关系	属性	状态
1	输入界面	让用户输入表达式	2，4，5	优先级=高，重要性=强，…	新建
2	算法实现	根据表达式计算结果	2，4	优先级=高，重要性=强，…	评审
3	输出界面	显示结果	5	优先级=较高，重要性=较强，…	新建
4	性能1	又快又准	2	优先级=高，重要性=强，…	完成
5	性能2	操作方便	1，3	优先级=高，重要性=强，…	新建

思考：

需求为什么要状态？

因为需求不是静态的，需求应该是在开发过程可以增加、删除、变更的。比如在初始设计时，是没有与bug相关的需求的，但是到开发阶段，就有与bug相关的需求了。因为需求是动态的，所以需求的状态是应该记录的

需求间有哪些关系？我们需要区分这些关系的种类吗？

需求间可以有你所能想象的各种关系。通过关系可以把需求组成一张网，然后从一个需求出发，找出它的关系网中的其他需求。这对分析和管理需求是重要的。但是关系的种类也许不必要区分。打个比方，在许多社区网站上都有一个“加关注”功能，社区网站的管理者或数据分析者可以利用用户之间的关注关系描绘出一张用户的关系网。但是好像没有谁给关注再分个类，标明关注强度或关注理由等信息。这些信息没有用吗？按理说也有用，但是为什么不做呢？我想应该是性价比。要求用户在加关注时填写过多信息会降低用户体验，同时给社区管理带来的增值不够明显。同理，需求之间表示存在关联应该就足够了，更多的信息并不能极大提高管理效率，但是增加了管理成本（填写这些信息并保证他们的正确性和完整性所付出的努力都是成本）。

需求为什么需要属性？

属性把需求看做了一个集合，利用属性就可以从这个集合中提取出一个子集。当需求很多的时候，属性提供了一个过滤或聚焦的工具，让管理者可以快速找到感兴趣的需求集合。那一个需求需要多少属性才够？谁也说不准。所以最好需求的属性是能够自定义的，当需要什么样的分类时就添加什么样的属性

 

Plan：

ID	任务名称	子任务	前置任务	描述	工时估计
1	实现输入界面				2
1.1		表达式输入框		用户可以输入一个表达式	1
1.2		计算命令按钮		用户启动计算过程	1
2	实现算法				6
2.1		表达式解析		解析用户输入的表达式	3
2.2		表达式计算	2.1	计算解析后的表达式	3
3	实现输出			返回计算结果	1
4	检验性能1				3
4.1		检验是否快			2
4.2		检验是否好			1
5	检验性能2	检验操作是否方便			2

Resources：

ID	资源名	分配的任务
1	张三	1，3
2	李四	2
3	王五	4，5

思考：

计划中的任务和需求有什么区别？

计划中的任务讲的是要做什么，需求讲的也是要做什么，他们的区别在哪里？最大的区别在任务之间有明确的先后关系，而需求之间没有。正是因为任务有先后关系，才能在此基础上，排出时间进度。而任务的工时，任务分配给谁等等，不过是为了让排出的时间进度更准确。

需求与任务之间应该是什么关系？

理论上是多对多关系。即一个需求可能需要多个任务去实现，一个任务可能为多个需求服务。但在实际操作时，也许可以用一对多描述。想象一下你是怎么提出任务的：拿着需求列表，指着一个需求说，我希望这个需求用这几个任务去完成，然后手指下滑，指着下一个需求，继续说，我希望这个需求用这几个任务去完成…，最终，得到了一张任务列表。那么，如果一个任务能够为多个需求服务，怎么办呢？首先，需求之间任务重叠的概率是很低的，因为如果需求间有太多的重合任务，说明你的需求分析有问题，没有把应该分离的需求分离开。其次，真的有两个需求A和B之间有重叠的部分，完全可以把重叠的部分提出来，形成一个新需求C，A和B的任务各自完成不重叠的部分，而把重叠的部分委托给C。比如日志服务就是一个范例。这样做有什么好处呢？首先，思维模式是顺畅的，因为我们通常是根据需求去确定任务，而不是根据任务去反推他应该为哪个需求服务。其次，产生的任务是高质量的，因为你既没有为需求A和B提出重复的任务，又解耦了A和B之间的关联，提出了一个通用性更强的需求C。

 

Process：

ID	为什么干	谁干的	啥时干的
1	完成[任务1.1]的界面部分	张三	01-02-03 10：35：25
2	完成[任务1.2]的界面部分	张三	01-02-03 10：36：25
3	完成[任务2.1]的输入校验	李四	01-02-03 10：45：25
4	完成[任务1.1]	张三	01-02-03 10：55：25
5	[任务4.1]检测不合格	王五	01-02-03 12：35：25
6	完成[任务2.1]	李四	01-02-03 14：35：25
7	[任务4.2]检测不合格	王五	01-02-03 22：35：25
…

过程应该怎么管理？

过程是指任务的实现。过程的记录通常是借助版本控制系统。那么哪种版本控制系统是更好的呢？想象一下，你为了完成一个任务，需要编写3个文件，A文件写完你提交了，任务完成了吗？没有。应该3个文件都提交，才算齐活。因此，以任务单元提交为模型的版本控制系统才是合理的，而以文件单元提交为模型的版本控制系统会给管理带来很多不必要的工作量。

过程应该记录哪些信息？怎么记？

过程应该记录的信息不外乎3类：谁干的？啥时干的？为什么干？。因为过程是用版本控制系统记录的。版本控制系统一般都自动记录了who和when，剩下手工记录的只有why了。why一般都通过commit时的comment记录。那comment应该怎么记录why呢。我想首先应该记录的是与commit相关联的任务ID或需求ID，这样管理时就知道这次commit是针对哪个任务或需求了。至于其他信息，不过是对commit与任务/需求之间关联的更详细的解释，怎么写都行。那究竟应该记录任务ID还是需求ID呢？看你使用什么bug管理系统。普通的功能需求往往对应多个任务，将commit与任务ID对应更精准。而bug的处理通常是一个bug对应一个任务/需求，有的bug管理系统把bug算需求，有的呢则算任务，不管怎么算，在comment中记录任务id或需求id是必须的。否则就容易丢失“为什么干”的信息。

 

Result:

ID	描述	状态
1	性能1	bug
2	性能2	合格

思考：

结果应该怎么记录？

结果是通过测试过程获得的，结果的目的是验证需求是否得到满足。所以结果应该和需求发生关联。在结果的记录中，应该有对应需求的id，同时结果要表明需求是否已满足，因此结果应该改变或维持对应需求的状态。其次，一个不满足需求的结果应该产生新的需求或任务，即bug报告。在bug报告中除了尽量清楚的描述bug外，重要的是要把被测需求的id记录下来，这样别人才知道这个bug针对谁。