作为顾问，我们有幸在客户敏捷的旅途中为其提供帮助。 总是很有趣，因为每个客户都在各自独特的道路上以敏捷的采用取得了不同程度的成功和挑战。 他们中的大多数人还在某些项目中使用传统的项目交付方式。 而且，我必须承认，我喜欢这个！
作为“橡胶与道路相遇的地方”的顾问，我赞赏理论和应用敏捷概念之间的区别。 我喜欢为客户提供便利的应用解决方案的挑战。
我并不是要最小化我们对敏捷最佳实践的指导和培训的重要性–这确实很重要。 但归根结底，我们的客户欣赏应用敏捷性，这种敏捷性可以满足他们所处的位置并提升他们的旅程。
话虽如此，我从敏捷项目的开始就强烈地希望做到三件事，以为我们的客户提供最大的业务价值，而无论他们采用敏捷的程度如何。 我的博客总结了这些观点。
对于带有“空白纸...”的项目
促进产品发布计划和故事图。
在项目跑道上采用危险性方法并使团队处于同一页面上是效率低下且成本高昂的。 产品和故事图的可视化为利益相关者和敏捷团队提供了战略计划。
发布图应回答：主题/功能集是什么，发布日期何时？ 请记住，这将在当前版本中更详细，并且在后续版本中将通过逐步详细说明而变得更详细。
推动产品地图战略形成的关键因素是驱动最大的商业价值和降低风险，即选择早期学习的知识。 使未完成的事情最大化（功能的80/20规则）并很快获得用户反馈的简短发布是无价的–产品越快地进入最终用户手中，我们的客户就会获得更多的价值！ 在理想的情况下，产品愿景，计划和产品组合计划是产品结构支持的关键输入。
故事图描述了最终用户使用该软件执行的所有高级活动。 最终用户位于第一行，其高级活动位于第二行。 您可以讲述从左到右的时间顺序故事。
例如，管理员设置公司和用户，然后保险人提交他们的文件，然后分析师执行他们的分析。 这些活动被分解为较小的活动，并优先发布。
我喜欢故事地图，因为它们是植入产品积压并在整个项目中带来持续价值的完美方法。 该值通过以下方式实现：
- 促进对话
- 关注最终用户
- 描绘大局
- 易于交流，共享和检查是否缺少任何内容
- 识别并显示依赖关系
- 优先工作
- 显示团队针对每个版本的工作方向以及用户的结果
以多种方式切片以满足不同的结果，例如确定最小可行产品（MVP）； 产品发布； 或通过学习目标
对于尚未准备好开始其最有价值的业务功能的客户……。
鼓励他们继续这样做！
通过促进功能/功能相对价值的估算，然后用于确定发布计划和产品积压的优先次序，我们可以帮助客户最大化业务价值。
有一些有用的敏捷游戏，例如“购买功能”，可以帮助您确定业务价值。 故事图和产品积压不是由最大化业务价值驱动的，将产生次优化的结果，谁想要呢？
通过快速发布和发布高峰来利用业务价值，帮助获得用户反馈并以有时间限制的方式学习，从而帮助我们和我们的客户弄清楚需要什么。 对于想要提前提供大部分指导的客户来说，这确实很困难，但是从传统的项目管理中我们知道这根本行不通。
拥有一种系统的方式来通过峰值和风险调整的积压来应对未知数和风险，这有助于我们的客户发展敏捷的心态。 他们对歧义，快速学习/失败以及尽早管理风险变得更加自在-所有的好事！
如果不愿…
从一开始就鼓励所有利益相关者保持透明。
向主要利益相关者和可见信息传递者的Sprint演示是项目的关键反馈机制，指标和文化驱动力。 如果客户认为“我们还没有足够的开发能力来向我们的业务发起人和主要利益相关者进行演示”，那么发布计划可能没有使价值最大化或团队没有达到预期的期望。
无论如何，这应该是所有人都知道的。 不这样做就是健康敏捷文化的反面。 团队应欢迎整个过程中的反馈，以作为产品积压和发布计划的输入。 如果关键利益相关者通常不在反馈过程中，则无法最大化业务价值。
同样，可见信息辐射源应易于查看并在每次迭代后进行更新。 对于刚接触敏捷的客户而言，这一点尤为重要，因为他们会倾向于使用传统的项目指标。
我最喜欢的几个是释放燃尽图和按优先级排列的未解决缺陷趋势。
我喜欢发布燃尽图，因为除了显示已完成/剩余的工作之外，它还跟踪发布范围的变化。 如果资源和预算是固定的，它可以帮助证明所需的范围权衡。 并且当团队速度变得稳定时，它还可以通知发布计划。
我喜欢开放缺陷趋势图，因为它可以很好地直观提醒人们正在发生的技术债务积累。
包起来
这三个步骤将帮助我们和我们的客户最大化商业价值，并尽早建立一些良好的敏捷实践。
祝您下次旅途愉快！
翻译自: https://www.javacodegeeks.com/2016/07/three-considerations-agile-project.html