演示驱动开发

演示驱动开发（Demo-driven development）：将工作分解为用户故事，计划每周演示，并将会议重点放在目标而不是任务上，以推动有效的产品开发。

项目计划应重点关注里程碑和用户故事而不是任务：

• 用户故事代表了可论证的功能，可以在每周的冲刺中逐步开发，并在每周五向利益相关者进行演示。
• 团队的每周启动会议应集中讨论周五之前可以实际演示的内容，而不是审查任务。
• 技术和项目经理还可以从单独的每周会议中受益，以协作解决问题、挑战和批评计划。
• 定期演示和迭代规划有助于确保工作始终专注于为客户提供价值。

演示驱动开发是一种实践，您可以使用

1. 定期演示，
2. 标准的每周项目计划，以及
3. 基于价值的用户故事。

与其他方法相比，演示驱动开发的一些优点是：

• 你从客户的需求出发思考。这将团队与业务影响联系起来，产生更好的结果。
• 本周的目标更加明确，团队内部可以更好地集中注意力和协作。
• 团队成员感到更加满足。为什么？人们天生需要感受到进步，并将他们的工作与他们所提供的价值联系起来。他们喜欢解决问题并理解为什么它很重要。
• 演示驱动的开发提供了一种提高项目对话质量的结构。计划简单易行。用户故事处于一定的粒度级别，可以轻松控制范围。这会带来更加流畅和动态的项目——实际管理的项目，而不是自动运行的项目。

第 1 步：周五演示
第一件事就是介绍每周或每两周一次的演示
首先：

• 每周让每个团队演示他们的工作。
• 轮换进行演示的人员，让他们为团队演示工作。这有助于确保每个人的团队工作得到认可，并为工程师提供展示其工作的宝贵技能的练习。您还可以让每个人演示自己的工作或从事某项工作的人员的工作。
• 演示可以在会议中完成，也可以异步录制并发布在 Slack 的房间中。如果你异步进行，请复制我从 Bjorn Freeman-Benson 那里学到的东西：要求每个团队制作一个两分钟的视频。建议人们在 Slack 线程中提问，并使用 Slack 反应表情符号为成就欢呼。我喜欢告诉人们在 2 分钟的视频上花 10 分钟，以防止录制内容太大而浪费时间制作。

第 2 步：周五要演示什么？
在冲刺启动会议之前做好准备

• 工程经理和产品经理在冲刺启动会议之前会面，并决定接下来几周的目标。
• 你们两个想出了接下来几周的良好演示会是什么样子。您可能不确定什么是合理的，但请考虑一下您想要实现的目标，以及朝着什么方向迈进可能是一件好事。请记住，这并不是一成不变的。
• EM 和 PM 应准备一份本周需要解决的错误或可用性问题的列表。

• 在团队的每周启动会议上，产品经理给出了我们未来几周的工作背景，并提醒团队接下来的工作的价值和权衡。
• 你，工程经理说，“周五我们应该演示什么？”。根据您的团队的不同，您也许可以就此打住，让他们提出满足 PM 所讨论目标的项目。他们可能需要更多的指导。因此，您可以分享您认为团队在接下来的两周内可能会做的事情，并询问他们本周演示什么是合理的。
• 讨论的一部分应该是关于需要进行的其他工作。本周应解决哪些错误和可用性问题。
• 然而，讨论的主要焦点应该是讨论演示计划——什么是现实的，以及演示应该是什么样子。
• 团队将剩下的时间花在每周启动会议上讨论如何实现这一目标，并将高级演示目标分解为本周需要完成的技术工作。他们讨论如何协调工作，以及可能需要解决的任何决定或问题。合作！

第 3 步：将团队转移到里程碑而不是项目
基本思想是用里程碑代替项目。这改善了项目分解、排序和增量设计的偏差。

如果您是新经理，您可能会稍后再这样做，因为某些团队可能会抵制或不理解这一点。

第 4 步：将团队的工作转向使用用户故事
您的下一步是转向使用用户故事，而不是任务。
什么是用户故事？

• 用户故事代表您在特定一周可能演示的内容。例如，“用户可以为仪表板中的图表选择颜色”。“用户可以保存为图表选择的颜色”。
• 用户故事应该是产品经理或其他团队的工程师可以理解的内容。（这使产品经理有更多的权力通过移动用户故事来控制范围）。如果您有某种特定的方法，您可以这么说，但用户故事应该主要传达您为企业或客户提供的功能。
• 理想情况下，它们的大小应该是几天的工作量。
• 用户故事应该以团队为中心，而不是以个人为中心。一个常见的错误是创建可以由个人完成的用户故事。例如，一个糟糕的用户故事可能会将前端工作与后端工作分开。编写用户故事，使它们本质上是“跨职能的”——跨越技能界限。他们应该提及用户以及他们能够做什么：“用户能够看到他们在表格中列出的待售商品列表”。请注意，这意味着前端和后端工作。
• 用户故事可以是实现更大目标的增量，但如果可能的话，它们应该尝试让自己变得有价值。

第 5 步：创建项目计划或里程碑计划
准备好用户故事后，下一步就是改进您的规划。我喜欢这样做的方式是制定每周的时间表，其中只是每周几个用户故事的列表。您还应该列出本周可能发生的风险或有趣的事情，例如有人不在办公室，或者有人需要帮助团队中的新人入职。

只进行里程碑规划，而不是项目规划。如果您正在规划整个项目，您就会投入大量时间来对您可能永远无法完成的工作进行估算。

第 6 步：制定技术计划
技术计划不一定是技术规范。最重要的事情要浮出水面，这些事情可能会在未来影响你。我喜欢请人们简短地写下这些主题：

• 正在做出权衡，以及原因。
• 团队正在做的任何新的或非标准的事情。我将这些称为技术性赌注。在一个项目中押一两个赌注通常没什么问题，但如果同时采用很多新方法，那就是危险信号了。
• 对于引入的任何新模式，如果我们喜欢的话，是否需要将代码库的其余部分迁移到该模式？（这需要强有力的理由）
• 考虑为将来难以更改的内容添加一个部分，例如 API 或数据模型。
• 我们正在采取的任何已知的捷径都可能会在以后引起问题。

第7步：项目执行会议
然后，项目计划可以反馈到项目执行会议中。这些会议的目的是让项目经理（通常是工程经理）互相帮助，共同解决项目问题，并批评彼此的项目计划。并讨论项目的执行情况以及组织中可以改进哪些方面以使项目更好地运作。

对于这些会议来说，重要的是要成为讨论问题的安全场所，而不是人们摆姿势和炫耀的场所。亚历克斯·克罗曼（Alex Kroman）教会了我在开始这些会议时坦率地承认产品开发是困难且不可预测的价值。我们都知道我们应该期待挑战。我们都曾参与过可怕、混乱的项目。所以让我们互相帮助吧。

第 8 步：技术领导会议
您可以利用技术领导会议对技术计划提出类似类型的批评。您的技术领导者可以聚集在一起，分享有关他们所做的技术权衡的任何有趣的事情。

这些会议可能会产生非凡的影响力。项目失败的最常见原因之一是项目同时承担了太多雄心勃勃的赌注。工程组织面临的许多挑战都是由前几年做出的技术决策造成的。拥有一个可以制定技术标准的团队将防止痛苦的迁移项目蓬勃发展。创建一种讨论选择的长期影响的文化可以避免未来几年的许多痛苦。

总结
演示驱动开发侧重于创建产品功能演示来驱动开发过程。这种方法奖励表面文章工作，使其在演示时看起来更有意义、更有成效。
一些人认为：

• 只有当最终产品主要用于演示而不是供真正的客户使用时，这种方法才有效。
• 对于面向客户的产品，开发应该关注真正的用户需求，而不是仅仅通过演示来打动观众。