我们如何开始以两倍的速度发布功能（案例研究）

当企业依赖您的应用程序进行日常工作时，您必须足够敏捷以快速满足他们的需求。 如果你不这样做，其他人肯定会。 在无情的 SaaS 世界中，延迟一个关键功能（或匆忙编写一段充满错误的代码）将意味着失去客户。 一个可靠的敏捷工作流程可以让一切变得不同。

我们是Active Collab背后的团队，这是一个项目管理应用程序，具有不断增长的功能集和庞大的用户群。 这意味着即使是最小的功能变化也会影响到大量的人。

关于 SmashingMag 的进一步阅读：

• 如何在不伤害忠实用户的情况下推出新功能
• 网站启动清单 – 上线前的 15 项基本检查
• 以用户为中心的移动设备网页设计方法
• 如何启动任何东西
  

因此，开发过程需要平稳运行并达到标准，将延迟减少到最低限度。 在任何更改到达最终用户之前，它都会经历五个关键阶段：反馈、设计、开发、质量保证和部署。 在本文中，我将分享我们从八年多的业务中学到的（艰难的）每个阶段的经验。

叫醒电话

在详细介绍之前，让我们先看看这一切是如何发生的。 经过多年在没有足够审查的情况下添加功能，我们的应用程序遭受了功能膨胀的困扰。 多年来，我们添加了如此多的功能，以至于新用户被 UI 的复杂性吓倒了（再也不会回来了）。 我们知道我们必须从头开始重建，即使这意味着从头开始重写每一个功能。

然后是延误。 新版本的功能总是落后于计划。 例如，初级开发人员应该开发与 QuickBooks 的集成。 我们没有准确预测所需的复杂性、技能或知识。 再加上，他是唯一一个被分配到这个任务的人，没有人可以快速跳出来帮助他。 结果，原本应该为期两周的工作最终只需要五个。 那是一些危险信号。

显然是时候改用更敏捷的方法了。 我们从各种敏捷（而不是那么敏捷）方法中汲取了我们喜欢的东西，将其与经验相结合，并提出了我们自己的版本，从那时起它一直在提供很好的结果。

让我们仔细看看一个功能在提供给最终用户之前必须经过的路径。

从建议到特色

在我们的工作流程中，一个新功能在它到达开发团队之前就已经开始形成，它通常是由用户反馈产生的。 这不是巧合——我们过去常常发布不需要的功能，通常只是因为一个用户特别吵，或者我们只是认为拥有一些东西会很棒。 我们现在不是想象用户可能需要什么功能，而是根据实际需求做出决策。

如果您从事精益制造，您会说我们的客户通过比其他人更频繁地请求某些功能来“拉动”某些功能。 我们的支持和销售团队是这个过程的重要组成部分，因为他们经常与分享他们的需求和想法的用户保持联系。

根据反馈，我们的团队更新了一个如下所示的表单：

当我们没有所需的所有信息时，我们将直接与客户联系。 这通常是通过对精心挑选的样本进行有针对性的调查来完成的。 重点是我们倾听。 我们不会丢失任何反馈。 它总是得到承认和记录。

下一步是分析。 我们每个月都会统计分数，看看哪个功能获得了最多的选票。 此外，通过适当的分类，我们可以更广泛地了解我们软件的哪些部分需要工作。 例如，如果日历收到很多投诉，我们将考虑修改整个部分，而不是引入获得最多票数的功能（例如日历导出）。

然而，即使结果出来了，引入一项功能的决定也不是最终的。 在它进入我们的待办事项列表之前，我们总是会进行彻底的完整性检查：

• 这个功能会给用户带来什么好处？
• 它符合我们的产品理念吗？
• 它会增加不必要的复杂性吗？
• 它是否与现有的界面和功能很好地融合在一起？
• 我们是否有资源在合理的时间范围内交付它？

当一个功能通过检查表并且产品所有者批准它时，就该去绘图板了。

为用户设计

经验告诉我们，添加新功能并不仅仅意味着将其粘贴在 UI 之上——您必须将其与现有设计融为一体，并考虑到用户。 如果你不这样做，你很快就会得到一个如此复杂的应用程序，以至于只有少数勇敢的人才能通过试用的前五分钟（是的，我们一直在那里）。 美学对于良好的第一印象也很重要，但我们主要关心的是易用性。 需要以用户感觉自然的方式添加功能。

我们通过询问，用户期望这个选项在哪里？

对于现有用户来说，重要的是新设计遵循他们熟悉的模式并且不会破坏他们的工作流程。 此外，还有我们都（无意识地）习惯的行业标准和惯例。 永远不要期望您的用户完全改变他们的习惯。 如果界面不直观，他们更有可能在别处寻找。

使用键盘快捷键。 您可以创建自己的一组快捷方式并期望用户学习它们（他们可能不会）。 或者您可以添加人们已经使用的那些。 例如，我们的许多用户已经使用 Slack，因此我们添加了一个他们已经熟悉的快捷方式（ Command + K用于快速跳转也适用于Active Collab ）。

当用户流程到位后，我们的 UX 设计师会在 Sketch 中模拟设计。 我们很少在早期使用 HTML。 经过深思熟虑的 Sketch 可视化为我们提供了足够的灵活性，以至于我们在开始编码时无需进行任何回溯。 最初的设计通常最终匹配最终产品的 80%。 其余部分在此过程中添加和调整。

设计过程的另一个重要步骤是复制。 我们的撰稿人对每一个字都非常关注。 我们甚至有自己的风格指南，听起来平易近人，并且尽可能容易理解。 例如，说“安全证书”而不是“SSL 证书”，用通俗的话来说就是普通用户可能不熟悉的东西。

完成所有这些后，该功能将分配给开发团队。 该团队由一名项目经理、一名首席开发人员和一些后端和前端开发人员组成，具体取决于工作量。 项目经理确保一切按计划顺利进行，而首席开发人员则负责技术方面的工作。 他们还协调和指导初级开发人员。

是时候开始了

我们的启动会议不是无聊的激励性聚会。 它们是开发团队（由初级和高级开发人员组成）与项目经理和产品负责人会面的机会。

我们不会允许空洞的独白，而是专注于将每个人的话变成可操作的任务。 一整天，三个重要的会议发生：

• 产品负责人向团队展示给定的功能、其背后的想法、初始设计和预期结果。
• 然后，团队有自己的会议，讨论行动计划、潜在问题和测试时间表。
• 最终会议由所有相关人员参加，计划最终形成。 在本次会议结束时，团队会给出演示的估计和最终截止日期。

一天的三个会议听起来可能很多，但这就是我们确保及早解决问题的方式。 在这个阶段填补空白可以为我们的开发人员节省大量时间、错误开始和回溯。 会议还鼓励团队合作，让每个人都感到他们的贡献受到欢迎。

会议结束后，团队将获得所有必要的信息：

1. 什么？ 这是该功能的范围，包括需要完成的所有内容，以及潜在的障碍和瓶颈。 我们试图预测尽可能多的场景和边缘情况。 预测所有这些并不容易。 他们经常在我们走的时候出现。
2. 为什么？ 产品负责人估计一个功能的商业价值，并解释为什么值得付出努力。 这样，团队就可以清楚地了解对客户和产品的好处。 这里的主要动机是每个人都应该了解他们的工作为何重要以及它如何为整个公司做出贡献。
3. 如何？ 通过概述完成一项功能所需的步骤，我们确保我们的开发人员永远不会失去他们的指南针。 我们还通过添加复杂性标签来设定现实的期望。 我们选择了 T 恤尺寸 - S 可以在几个小时内解决，而 XXL 需要数周或更长时间才能完成。
4. 谁？ 团队负责人负责按时完成功能或任务，并负责向产品负责人更新进度。 其他团队成员被分配到他们自己的子任务集，因此非常清楚谁对什么负责。 尽可能保持透明有助于我们了解是否有人在苦苦挣扎或造成延误。
5. 什么时候？ 考虑到所有因素，预计到期日。 如果一项任务被延迟，我们会分析原因并在下次使用该经验。 这样，错过的最后期限就变成了学习的机会，而不是压力的来源。

开球日可能会很忙碌，但也非常富有成效。 每个人都提出想法和评论。 一项任务从一个空白的列表转变为一个评论、编辑和更新的中心。 到一天结束时，开发团队对未来的工作有了清晰的认识，并有了坚实的基础。

在开始工作之前，我们会检查此清单：

• 功能解释，
• 概述完成的步骤，
• 产品所有者分配的商业价值，
• 团队分配的复杂性，
• 已识别功能和错误依赖项，
• 确定的性能标准（如果需要），
• 已安排演示，
• 由团队负责人设定的开始和结束日期。

这是任务移动到“进行中”列的时刻。

现在是编码时间！

团队合作展示

我们的开发人员从不单独工作——这始终是团队的努力，也是迄今为止发布新功能的最有效方式。 在引入团队之前，（初级）开发人员会遇到一个问题，并且可能会在圈子里转来转去好几天（没有人意识到这一点）。 或者，如果他们不是独行侠类型，他们会经常分散同事和经理的注意力。

另一方面，在团队中，我们将具有不同技能和经验水平的人混合在一起。 这意味着每个人都被分配了一组适合他们水平的任务。 此外，老年人还可以从学习如何管理和指导初级队友中受益——而后辈则可以寻求帮助。 因为这是一个团队的努力，每个人都在朝着同一个目标努力，所以问题不会被视为分心，团队可以更有效地解决任何问题。 团队成为一个自组织实体，将工作分成阶段（或冲刺）并在演示期间展示他们的工作。

展示并演讲

根据时间表，团队将为产品负责人进行演示。 演示的目的是展示一个功能在其当前状态下的表现如何，以及在哪些方面需要进一步完善。 这是一个现实检查，不允许找借口，“它只需要一些最后的润色”（需要一个月的润色）。 此外，如果事情开始出现问题，产品负责人会迅速做出反应。

每周会议

我们从所有开发人员参加的定期简短的每日会议开始。 每个开发人员都会简要描述他们正在做什么、他们的问题、他们的障碍以及他们是否需要帮助。 很快就很明显，这些会议需要更加集中并提供切实的成果。 因此，我们改为每周与各个团队开会一次。 这就是产品所有者和项目经理保持在循环中的方式，并且所有潜在的问题都在现场得到处理。

进行测试

代码已编写，演示已成功，一切似乎都很好地结束了……直到您发布该功能并看到应用程序崩溃。 这就是为什么我们制作的每个功能都经过质量保证(Q/A)。 总是。 我们的测试人员会仔细检查每一个可能的场景，检查所有选项并在不同的环境中运行测试。 一个功能很少会在第一时间通过 Q/A。

为了提高生产力，我们过去常常让开发人员在这个阶段开始使用新功能，但这只会导致很多延迟的、半成品的功能。 因此，现在开发团队在审查功能的同时忙于处理小型维护任务。 如果 Q/A 发现问题，开发人员会立即修复并重新提交。 重复该过程，直到该功能通过 Q/A 并继续进行代码审查。

这是高级开发人员确保代码是按照我们的标准编写的。 发布前的最后一步是编写文档——在发布一项没人知道如何使用的功能后，您不希望被支持电子邮件淹没。 我们的文案人员还会更新发行说明并撰写营销材料，例如电子邮件公告和博客文章。

这是我们对“完成”的定义：

• 编写的自动测试，
• Q/A 已完成，所有由此产生的任务都已完成，
• 代码审查完成，代码合并到master，
• 发布说明已更新，
• 识别的功能和错误依赖项。

该任务已进入最后阶段，称为“发布 Q”。

发布日

在选择发布新版本的日期时，我们立即决定避开周五和周一。 星期五不好，因为任何潜在的问题要到星期一才能解决； 另外，支持团队当时已经很忙了。 星期一不是最好的时间，因为任何重大更新都需要准备，而这必须在周末完成。 留出一天进行最后的修饰总是好的。 这将选择范围缩小到三天——我们选择了周二。 原因如下：

• 我们有星期一审查发布并在部署之前添加收尾工作。
• 如果有任何未翻译的短语（我们的网络应用程序支持七种语言），我们有足够的时间来完成翻译。
• 营销团队有足够的时间通过社交媒体发送新闻通讯和公告。
• 我们可以在本周剩余时间内快速有效地提供升级支持。
• 如果由于某种原因已经过了最后期限，我们还有周三或周四的时间来完成工作。

自由活动日

主要版本发布后的第二天是团队的空闲日。 这是他们学习新技能或做任何他们觉得有趣的工作相关的事情。 尽管每个人都渴望知道我们将在第二天启动哪个功能，但团队还没有讨论这个问题。 相反，他们会放松一下，可能会观看有关 Erlang 历史的演示文稿，或者阅读完关于为什么 PSR-7 和中间件对现代 PHP 开发很重要的文章，或者进行自己的回顾性讨论。 这是当之无愧的一天，可以为他们的电池充电并庆祝出色的工作。

捕虫日

除了开发主要的新功能外，总是需要在现有功能上完成工作。 无论是错误修复、设计更新还是功能上的小改动，团队都需要在合理的时间内处理好。

这就是为什么我们每月至少有一次寻找错误的日子。 这是所有开发人员停止从事主要项目并将注意力转向维护的时候。 事实证明，这种集中的努力取得了巨大的成功。 当每个人都在同一天单独处理错误并且可以互相帮助时，团队可以解决大量问题。

结果是什么？

从启动到开发、测试、代码审查、文档和最终发布，现在发布一个大功能平均需要大约三周时间。 一个具有同等复杂性的功能过去需要我们 45 天。 从我们的角度来看，这是生产力 100% 的提升。 我们使用相同的资源和人员完成了它，唯一的区别是改进了工作流程。

因此，如果我们对您有一个建议，那就是：培养一种消除对变化恐惧的公司文化，将使您的团队在工作上做得更好。 无论您将其称为 Scrum、看板还是精益都无关紧要，只要它有助于您的公司成长。 实验和创新是任何敏捷方法的核心。 不要害怕测试不同的解决方案、衡量结果并根据结果修改现有做法。 好的结果会随之而来。