如何决定敏捷需求的优先级顺
决定需求的优先级顺序有两种方法：定性评估法和定量计算法。定性评估法是通过评估影响需求排序的几个要素，然后为需求排出先后顺序；定量计算法是为影响优先级顺序的每个要素赋予一个数值，然后用公式计算并排列出需求的先后顺序。1.定性评估法
决定需求的优先级顺序需要考虑以下几个要素。
[*]延期成本。对需求进行排序，延期成本是首要考虑的因素。当延期成本无法区分出先后顺序的时候（比如，团队经常会发现很多与其他需求价值相当的需求，在上线时间上团队对其也没有一定的预期），团队可以考虑下面的其他几个要素。
[*]实现成本。对于价值相同、时间要求相同的需求来说，团队通常会选择成本低、交付速度快的需求，因为越早完成，越早产生价值，并越早获得用户反馈，从而使团队逐渐提升对用户和市场的认知。
[*]风险和不确定性。风险和不确定性是一对“孪生兄弟”，但却是两个不同的因素：不确定性可能蕴藏着风险，不一定会带来风险；但风险却一定是带有不确定性的。如果需求具有不确定性（例如，在一定条件下，这个需求会引爆市场，但是这个条件何时到来还不知道），那么一般采取的方法是推迟决策，同时密切跟踪市场动向，注意避免过早或过晚做出决策。此外，团队还可以设计一个低成本的MVP，用其对特定用户群体做调研，来验证需求的市场风险，从而为是否进行产品开发提供反馈。
如果实现需求在技术上有风险（例如，需求会对已有代码模块的实现逻辑甚至架构带来重大冲击），那么尽管这个需求价值很高，团队往往也会推迟到将来再做，这是人们为了逃避风险所做的一个自然反应。但其实这样做是错误的，因为如果现在不做，实现逻辑的代码会继续堆积，以后再做这个需求时，团队付出的代价会更大。因此，对于带有这种风险的需求来说，如果团队决定必须做，就要早做，直面风险。一般应对这种技术风险会采用探针（Spike）的方式，即先做一个小的试验，将风险量化后，依据试验结果来决定是否做该需求。
[*]依赖。INVEST原则中的I（Independent）指的就是独立性，即拆分用户故事时要尽量避免其相互依赖。但是依赖是不可能完全避免的。如果最后还是发生了用户故事A依赖于用户故事B，那么最好将A和B错开一个迭代周期后再实现，至少错开一周。尤其是在相互依赖的用户故事由其他团队交付的情况下，由于进度不受团队自己控制，所以团队更需要将它们错开节奏，如图8-17所示。
图8-17相互依赖的用户故事要错开一个迭代周期
团队针对每个需求均进行了以上这些要素的分析后，就可以排出需求的优先级顺序。
2.定量计算法
规模化敏捷框架SAFe（ScaledAgileFramework）采用一种定量计算法来评估需求的优先级，即“加权最短作业优先法”（WeightedShortestJobFirst，简称WSJF）。其计算公式如下：
其中，“工作规模”大家比较熟悉，即需求的估算规模，可以用故事点、理想人天等估算得出。
公式中的“延期成本”包含如下三个因子。
（1）用户和商业价值，指的是需求对客户或商业的相对价值。比如：
[*]用户更喜欢哪一个需求；
[*]这些需求对这些盈收有什么影响；
[*]如果不做这个需求的话会产生什么潜在的负面影响。
（2）时间的关键性，指的是随着时间的推进，延期交付对用户的商业价值产生什么影响。比如：
[*]是否是固定交付日期类型的需求；
[*]用户是否会愿意等待，还是会选择其他产品；
[*]如果在某个时间窗口不上线的话，是否会让用户失望。
（3）减少风险或获取新的商业机会，指的是除了上面的第一个和第二个因子涉及的因素之外，这个需求还能为企业带来哪些价值。比如：
[*]是否会降低团队以后交付某些必要的特性的风险；
[*]是否会获得团队之前不知道的知识或信息；
[*]是否会给企业带来新的商业机会。
由此，WSJF公式可细化为：
那么具体该如何操作呢？我们可将所有特性和WSJF公式所涉及的因子列成一个表格，如表8-4所示。表8-4WSJF评估表
首先，针对这个表格里所对应的WSJF公式中的每个因子，采用故事点相对估算法对需求做出估算。比如，以工作规模最小的特性A为基准，将它的工作规模设为1，如果特性B的工作规模是特性A的3倍，那么特性B的工作规模就是3。
其次，按照故事点相对估算法为WSJF公式中的其他因子做同样的估算，即找到一个因子最小的特性，将其作为基准。然后通过其他特性与之相比较，得到估算数值。针对每一个特性，将WSJF的每个因子做相对估算后，依据WSJF的公式计算出每个特性的WSJF值，这样就得到了量化的需求优先级的排序。
最后，排列需求优先级顺序时要注意如下两点。
[*]优先级是相对的，不是绝对的。只有将两个需求放在一起，你才能判断出哪个要优先做。
[*]虽然WSJF公式看起来更科学，但是只能当作参考。需求的排序不是完全靠数学公式计算出来的，而是一个理性评估加艺术直觉的快速决策过程。团队的交付节奏越密集、交付速度越快，花在排序上的时间就可以越少。因为，即使优先级排得不合理，或者不确定，团队也可以马上在下一个版本中发布排名靠后面的需求。
问：是否应对整个Backlog进行排序？
答：不需要。团队需要做的是将排在Backlog顶部的当前版本的需求以及最近一两个迭代的需求排出唯一的先后顺序；而对于以后版本以及一两个迭代以后的需求，则不需要排出唯一的先后顺序。随着产品特性的持续发布，并通过用户的反馈，团队对需求的优先级认识会有变化。因此，过早排序也是一种浪费。
页:
[1]