Architecture 工程\集成用户故事-如何写客户价值？

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

我正在尝试从我们的LealeCyle程序中提供特性，并试图鼓励团队编写以客户为中心的故事，但是当这个功能需要大量的技术基础工作时，如何提供一个非常锁定的用户功能片段？（第三方软件已经定义了用户可以做什么和不能做什么）

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

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

---

我在这个优秀的网站上搜索过，在网络上搜索过，在Mike Cohn和advise等书中搜索过，这些书似乎主要是基于软件开发的。我很想得到一些关于这个问题的答案，这些答案可以应用于大型企业级工程项目。随着敏捷运动的发展，它的软开发根基也在不断扩展，这对团队来说一定是一个越来越大的问题。

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

例如，允许定义新报告的新技术的实施。如果客户已经签署了这项协议，那么不用说，这项协议应该提前交付，只需提交少量的报告

另一方面，如果客户尚未就此签字，那么此时您的敏捷交付可能是样本报告和证据，证明您可以在自己的基础设施上交付客户想要的东西，直到您接受为止

---

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

这是程序员的一个伟大问题。stackexchange。comI投票将此问题作为离题来结束，因为它应该打开。感谢您的回复。这是一个生命周期项目，因此必须交付新的解决方案-1。为了支持新的媒体渠道，客户可能需要在其报告和2中集成。对旧解决方案的支持是生命的终结。我们的第一个版本是确保我们的客户在添加其他报告之前能够在新系统中交付他们的现有报告。在我们交付实际客户价值之前，要交付第一份报告需要大量的基础工作。这是我们面临的挑战。@user1550488-在这种情况下，我真的认为您需要您的第一个可交付成果成为本地的一些报表基础结构。一个大问题是，为什么需要复制现有技术。他们能够共存吗？