工程\集成用户故事-如何利用客户价值进行编写？

Question

我在一家大型电信公司工作，我们的部门最近转向了“企业敏捷”的工作模式(这一切都非常令人兴奋！)我们在过去运行过特定的敏捷友好项目，但现在正在尝试使用敏捷原则来交付我们的整个计划。我们的大部分工作都是基于系统集成和配置的，很少有软件开发是在内部运行的。

我现在正在尝试提供我们生命周期计划的功能，并试图鼓励团队编写以客户价值为中心的故事，但是当功能需要大量的技术基础工作时，如何做到这一点，以交付非常锁定的用户功能？(第三方软件已经定义了用户可以和不可以做的事情)

例如，我们有一个通过新的报告解决方案交付现有客户报告的功能。不会提供任何新功能-至少作为初始版本的一部分。我们已经确定了一组将为用户构建的标准报告。这些是我们的客户价值案例。但要交付一个案例，我们需要部署和配置新的主机、新的业务对象数据库、新的数据收集点、新的数据聚合和提取层，并将当前客户数据导出到解决方案中，并验证\调整演示-然后才能构建和交付实际的报告。

新客户队列报告的交付是我们的史诗般的故事，我们应该如何捕获交付此报告所需的所有技术基础工作？主机的升级和数据库的构建可以作为用户故事编写，也可以仅作为技术任务编写。如果它是作为非估计任务编写的，我们将运行大约4-5次迭代，然后才能交付单个用户故事。即使试图提供最低限度的功能，本故事也适用于拥有大量数据量的大规模客户，并且需要大量的技术工作才能交付第一个价值故事/

我在这个优秀的网站上搜索过，无论是在网络上还是在像Mike Cohn这样的书中，建议似乎主要都是基于软件开发的。我喜欢在这方面得到一些答案，我可以将其应用于大型企业明智的工程项目。随着敏捷运动的成长和扩展，它的软开发根源，这对团队来说肯定是一个越来越大的问题？

Answer 1

我认为也许你的方法是错误的。一个大型的可交付成果将与敏捷哲学背道而驰--即你需要能够快速响应客户的需求变化。

例如，允许定义新报告的新技术的实现。如果客户已经签署了这份报告，那么不用说，这份报告应该提前交付，报告数量很少。

另一方面，如果客户没有签署这一点，那么在这一点上，您的敏捷交付可能是样本报告和证据，证明您可以在您自己的基础设施上交付客户想要的东西，直到您购买为止。

对我来说，敏捷意味着能够改变方向--我认为你的方法并不适合这一点，因为你的用户故事太专注于后来的可交付成果。