图1
图2
图3
图4
作者评论：
乍一看，SAFe需求模型（SAFe Requirement Model）看起来挺吓人的（确实有点吓人！）。它的目的是为了全面概述各级需求是如何一起工作的，而且由于SAFe是一个包含非常大解决方案的综合开发框架，所以这个概述会很庞大、很复杂。在这里我们应该记住的是：只看模型中与我们相关的部分。也就是说，如果你只用经典SAFe（Essential SAFe，译者注：经典SAFe是SAFe框架最基本的配置，它提供了成功使用SAFe所必需的最低限度的元素），你基本上可以忽略绿色Feature框左边的所有内容。
虽然SAFe需求模型对于建模或配置工具以支持SAFe的工作方式是非常有用的，但更好的做法是真正的思考一下是否可以简化你的配置。也就是说，问问自己是否真的需要史诗（Epic）和/或能力（Capability），以及是否可以通过适当的、垂直切片的功能甚至只是故事来增加同样的价值。在这里我们相信，从LeSS或Nexus等轻量级规模化框架中，许多公司可以通过其更简单的产品定义和工作拆分方法获得启发，同时仍然使用ART和PI Planning等核心SAFe实践。如果你能清晰地定义产品，为它分配一些真正的特性团队，并简化产品工作的投资方式，就没必要使用令人生畏的SAFe需求模型了。
完整大图
本文首发于微信号“小船哥说敏捷”。全文完，感谢您的耐心阅读！
网友评论