演示驱动发展

这是软件团队如何有效整理其项目的两部分博客文章的第二部分。第一个帖子列出了三种常见的反模式，用于管理团队的软件项目。

多年来，我已经复制并开发了一系列的实践，即我开始呼吁“演示驱动的发展”。我相信它激励了改善您的规划的正确事项，并考虑到混乱和产品开发的变化。

演示驱动的发展是您使用定期演示，标准的一周的项目计划和基于价值的用户故事的练习，以规划团队的工作。您可以使用这些来驱动会议，鼓励更积极调整和改进项目。

这种方法是有效的，因为您正在向后思考，并将团队重点关注每周要解决的问题。人们有一个先天的需要感受进步，并将工作与他们提供的价值联系起来。他们喜欢解决问题而不是检查任务。这种方法与人类如何找到满足感。

演示驱动的开发也有效，因为它引入了鼓励对话的结构。计划简单易玩。用户故事处于粒度级别，使其易于控制范围。这导致更多的流体和动态项目 - 实际管理的项目，而不是在自动驾驶仪上运行的项目。

那么你如何实现演示驱动的发展？和这种做法有什么关系？

首先要做的是，如果你还没有这样做，就是每周或两周期介绍（我会在这篇文章中每周使用，但如果这对你有更多的意义，你可以替换为双周。您可以构建许多不同的方式，而是开始：

旋转做演示的人，并让他们演示团队的工作。这有助于确保每个人都被认可为团队的工作，并为工程师练习展示了他们工作的宝贵技能。

演示可以在会议中完成，或在懈怠的房间内进行异步录制和发布。如果你异步这样做，请复制我从Bjorn Freeman-Benson中学到的内容：让每个团队做一个两分钟的视频。向人们建议他们在松弛线程中提出的问题，并使用松弛反应表情符号为成就感受。

下一步，一旦你有演示到位，就是每周启动目标。工程经理和产品经理应该在Sprint启动会议之前举行会议，并清楚地了解下周或两者的目标是什么。

产品经理在接下来的几周内提供了一些上下文，并提醒团队在即将到来的工作中的价值和权衡。

EM和PM应编写该周需要解决的任何错误或可用性问题。他们应该清楚地了解他们在此期间要完成的内容。因此，他们简要展示了他们认为这一星期可能值得考虑的最重要的物品。但球队的主要关注点是通过演示计划谈论 - 什么是现实的，而演示应该是什么样的。

这是一个非常澄清的问题。迫使团队思考一周，他们努力的目标以及他们走向的具体结果。他们而不是一堆任务，他们正在努力走向某事，有意义和有价值的东西。

重要的是，这不是一个承诺，而是一个合理的猜测。在复杂的环境中要求确定是要求对冲，并可以反馈。产品开发是不确定的，只要他们努力了解为什么他们错过了他们，就必须安全地对抗他们的目标。否则，他们估计过于保守的，并采取防守，而不是学习更有效。

该团队在每周开球会议上花费了剩下的时间，谈论他们将如何实现这一目标，并将高级演示目标分解为当时需要发生的技术工作。他们通过如何协调他们的工作，以及他们可能需要解决的任何决定或问题。合作！

无论是同时，还是在您开始在星期五的关于如何演示的问题时稍微踢掉一周后，你会组织围绕更高级别的抽象：用户故事的工作。

这些用户故事代表您在特定周上可能会演示的东西。他们的大小应该是大约几天到一两天的工作。它们应该是跨性质的，尽可能地重点关注为客户提供有价值的东西，或者您从中学习的东西。它可以朝着更大的东西增加，但努力以某种方式有价值。

用户故事应该可以通过未在项目上的技术观察者可以理解，并肯定由产品经理肯定。例如，“通过制作与标签一致的图表颜色减少混淆”。如果您有一个特定的方法，可以这么说，但需要定义目标。例如，“通过基于已保存选择的图表颜色一致”减少图表中的混淆“。

团队往往喜欢创建与技术工作相对应的Todo项目。 Jim Shore教会了我有两个级别的崩溃：用户故事代表了团队以外的产品经理或技术人员的理由。然后在该用户故事下，您可以创建代表您需要执行该用户故事所需的技术工作的任务。

在您到达的一周之前，任务细分不需要发生。在谈论演示之前，这可能是开球会议中的活动。

理想情况下，开球会议然后成为工程经理，说：这是我们的下一个用户故事。我们认为我们本周可以演示什么？团队决定如果这是很多还是有点，如果他们有更多的带宽，你说，好吧，我们有下一个故事，我们认为我们是否可以向完成这项工作进展？该团队同意他们可以演示的内容，然后剩下的会议是在提供的物流和协调，包括创建任务分解并弄清楚谁会做些什么。

对比这段时间对此感觉“弱敏捷”的方式，在这篇文章之一介绍。在这些会议中，工程经理可能会提出20或30张门票的列表，并覆盖仍在飞行中的许多东西。他们通常会在几周之间移动一堆事情。他们团队花在会议上谈论这些任务，而不是他们试图完成的目标。任务感到有意义，他们只是觉得要做的清单。

以百万分之一达到敏捷格式，他们会花在谈论这些任务的所有时间，并确保每个人都了解他们，谁将做些什么。而不是谈论目标以及如何共同努力实现这一目标，而是专注于票务系统中的审核任务。

在Gantt-Aholic Taptoff会议上，通常重点是任务和与一切相关的点。我们完成了多少积分，即将到来的物品的估计值是什么，我们如何跟踪。重点在于时间表比目标更多。

相反，将会议集中在您要完成的目标上，并使用您的工具在对客户的影响程度上录制事物：用户故事。

在您有用户故事到位后，下一步是提高规划。我喜欢这样做的方式是乘周一个星期的时间表，这只是你认为那周的几件事的列表。您还应该列出那周可能会发生的风险或有趣的事情，就像有人离开办公室，或者有人需要帮助船上的新人。

这成为项目计划：一周逐个计划，帮助您计划，并通过项目的排序来思考。它应该经常更新（至少每周一次），并在会议期间使用。

项目计划应该是谈话的工具。它应该有助于暴露风险（将在时间及时完成依赖性吗？），您应该计划的事情（玛丽亚将在那周的呼叫中）和其他问题。它应该提示对话，“我们可以先完成这部分，所以我们可以先验证事情吗？”或“或”我们可以将这个项目分解一半，并在没有这种额外的东西jig的情况下将这部分交付给客户吗？“ “我们对未来几周的感受如何，可能出现问题？”

即使它可以在不完整的工作中演示进展，但团队应该努力保持他们的工作永远是可付的。项目计划应反映这一点 - 应该可以将范围拉出项目计划并提前提供事物。或者根据客户反馈拉动额外的范围。一个很好的项目计划保留了这种类型的可选性，并以逐步提供终止目标。这对按时提供物品令人难以置信的价值，并平衡客户反馈的需求。如果您没有使用这种类型的可选性管理您的项目，您的大多数项目将失败。

技术领先（或有时甚至更好地，团队中的其他工程师，通过技术领先的编辑和改进）写下了对项目这个阶段技术工作的任何有趣（如果您的项目是几个月的，请为里程碑做该项目）。他们应该召唤他们制作的任何技术赌注，或者任何需要未来移民工作的新手。并突出显示正在制作的权衡。如果正在制造技术捷径，则应暴露并合理。

技术计划还应成为对话和协调的工具。它应该有助于人们理解和对技术决策的方式的理由。他们应该分享他人以改善。

项目计划和技术计划的主题应该是：“使用周围的人来提高你的思考。”

这些计划之间存在相互作用。技术计划表面技术权衡和选择。项目计划序列工作并将其缩小为增量。

然后，项目计划可以进入项目执行会议。这些会议的目的是针对项目经理（通常是工程管理人员），以帮助互相解决问题 - 解决他们的项目，以及彼此的项目计划批评。并通过执行如何执行项目以及组织可以更好地改进的项目，以使项目更好。

对于这些会议来说，这是一个安全的地方，通过问题谈话，而不是人们姿势和炫耀的地方。 Alex Kroman教会了通过坦率的致谢来启动这些会议的价值，即产品开发很难，不可预测。我们都知道我们应该期待挑战。我们都是可怕，凌乱的项目的一部分。所以让我们互相帮助。

同样，您可以使用技术领导会议为技术计划提供类似的批评。您的技术领导者可以聚集在一起，分享有趣的任何有趣的技术权衡。

这些会议可能是非常有影响的。项目失败的最常见原因之一是在同一时间携带太多雄心勃勃的赌注的项目。而且工程组织的许多挑战是由往年制定的技术决策产生的。拥有一个可以设定技术标准的小组将防止渐渐的移民项目从盛开。并创造了讨论的文化，讨论的长期影响选择可以在未来几年中避免很多痛苦。

演示驱动发展在适当的粒度水平上组织了您的实践，以确保您的项目。它在工作中提供目标和含义，帮助使工作更加吸引，创造性和鼓舞人心。它会导致更好的创新，更愿意的焦点和更好的计划项目，以及替代方法。

通过逐步介绍演示驱动的发展背后的一套实践，您应该改善您的工程组织，以及贵公司的成功。让我知道它是如何为你的，我欢迎你对它的反馈或问题。

许多经验丰富的工程领导者对这篇文章的草案提供有用的反馈。谢谢你塞纳斯猎鹰，Bjorn Freeman-Benson和Kenichi Nakamura为众多结构和内容建议，使这篇文章更强大，更为集中。感谢Brent Miller，Davy Stevenson和Darin Swanson的改进！