敏捷开发中,对于当下/非当下的任务的优先排序以及中期目标的制定

 我希望对产品的发展方向有一个中期愿景。我发现三个月的维度很好。

 

在每个季度开始时,产品所有者应该定一个目标:“这是我们想要在三个月内需要完成的目标。”这个目标需要与团队和其他利益相关者共同完成的,但产品的最终愿景是由产品所有者决定。

 

产品所有者不需要过度投入到愿景这件事 - 愿景是可以被改变。但是,几个月后,如果没有实地利益,优先顺序很可能是由冲刺规划会议之前爆发的紧急事件决定的。没有长期愿景,紧急总是战胜战略。

 

为了在中期愿景的竞争性想法之间进行选择,我喜欢使用非常正式的方法 - 通过向其他人解释。我希望能够说,“我选择专注于这样而不是这个和那个”,然后展示一些分析,表明我是如何做出这个决定的。我在其他地方写过关于「相对权重」,「主题筛选」和「主题评分」的内容 - 我们在这个网站上有工具来执行这些分析。

 

但是,在每个sprint开始时,产品所有者需要制定较小的当下和非当下的决策,以便在下一个sprint中优先处理用户故事。我建议产品所有者考虑他们正在评估的产品积压项目的四个方面,而不是使用正式的,可解释的方法:

 

  • 这个功能有多么宝贵

  • 通过开发该功能将进行的学习

  • 功能的风险

  • 功能相对成本的任何变化

我这样做是首先对属性1上的候选产品代办项进行排序——这是产品人多年来优先考虑功能的方式。

 

但我不止于此。我使用第2到第4项来调整现在排序的积压。

 

在大多数情况下,我会根据这些额外因素的影响,将产品积压项目向上移动而不是向下移动。

 

第二个因素是指通过开发该功能将进行多少学习。学习可以采取多种形式 - 例如,团队可能会了解所使用的技术(“这个供应商的图书馆并不像我们被告知的那样容易”),或者产品所有者可能会了解用户对新技术的反应程度用户界面。如果开发特定产品积压项目所带来的学习意义重大,我会将该项目移到产品待办事项上,以便在即将到来的sprint.pro中开发。

 

至于第三个因素——风险,如果无法避免给定的风险,我更愿意尽早做出产品积压项目,以便我可以了解风险的影响。因此,我将把产品积压项目移到当前的sprint中。但是,如果有可能完全避免风险(可能完全没有执行此功能),我会将该产品积压项目移出当前的sprint。然后,我希望在每个后续冲刺中继续这样做,从而完全避免这种风险。

 

最后,如果它们现在完成,某些功能可能很便宜,如果它们被推迟,它们会很昂贵。

 

当我在产品积压中看到这样的项目时,我会将其移动到当前的sprint中,以避免延迟该功能的更高成本。

 

通过结合使用这四个因素,在选择冲刺项目时,采用正式方法建立中期大概三个月的愿景,您将能够成功地优先考虑当下和非当下的方式实现更大的目标。

其他