敏捷开发方法越来越多地用于传统软件开发领域外的所有不同业务领域（甚至是市场营销）！因此，我们必须思考，敏捷开发在事件管理领域是什么样子的？在 Atlassian，我们将敏捷开发定义为一种结构化的迭代式项目管理和产品开发方法。敏捷开发让您能够在不偏离轨道的情况下响应更改。
由于生产、事件和停机期间中的错误可以归类为“事态偏离轨道的时期”，因此我们认为，像敏捷开发这种旨在帮助团队保持在轨道上的方法可以在事件管理（具体来说就是事件通信）中占有一席之地。
将敏捷价值观应用于事件响应
尽管不乏可以帮助您的团队检测、警报、聚集和解决事件的工具，但光靠工具无法取代与利益相关者的清晰沟通。而且说实话：风险可能会很高。声誉、客户流失、损失控制所花费的时间，这只是其中几例。敏捷开发方法可以帮助尽可能降低这些风险。
你们中的许多人可能已经熟悉敏捷宣言的四个关键价值观：1) 个人与流程和工具之间的互动，2) 工作软件胜过综合文档，3) 客户协作而不是合同谈判，4) 应对变更胜过遵循计划。我们来更深入地研究每个方面，看看如何利用它们进行更敏捷的事件沟通。
事件沟通原则：以人为本的事件沟通
该原则基于敏捷价值观，包括个人与流程和工具的交互。流程和工具对于任何事件管理流程都很重要，但如果脱离尝试使用它们的人员和围绕它们形成的文化来看，则毫无意义。填补人员、流程和工具之间空白的粘合剂是什么？当然是沟通！
出现问题时，沟通至关重要，无论是生产中的小错误还是全面的系统故障。即使是最完整的事故规划也需要经常沟通，以达成解决方案并保持信任。
在事件发生期间，受影响的用户很可能会遇到令人沮丧（如果不是全面衰弱的话）的错误，需要尽快知道发生了什么。许多人已经发送电子邮件、发推文和/或提交有关该问题的工作单，因此，通过一条消息快速了解情况对每个人都有好处，该消息表明您知道出了点问题并正在考虑解决问题。在 Atlassian，我们使用 Statuspage 在停机期间与内部和外部利益相关者进行沟通，我们认为，在尝试以快速、可扩展的方式与用户沟通事件信息时，您也会很快发现其价值。实际上，Statuspage 已帮助用户将事件通信的速度提高了 50％。
但是，无论您使用哪种工具为客户提供 4-1-1，以人为本的沟通都会大有裨益。而问题背后还有真实存在的人，他们依赖您的服务，在出现问题时需要您来帮助他们保持正常运行。对于完美的世界来说，模板非常棒，但您需要能够制作清晰、简洁、善解人意和相关信息的人员，这样即使在最坏的时期也能建立客户信任。以 Dyn 为例。Dyn 曾遭遇过历史上最大的 DDoS 攻击之一，期间他们出现了大规模中断，但用户仍然感谢他们在服务中断的那段时间坦诚的表现：
正如 AWS 首席技术官 Werner Vogels 2017 年 2 月谈到 AWS S3 大规模中断时所说的那样：
“客户不喜欢听到建议说‘不要动’。这不是他们想要的，为此，您需要向他们提供非常好的信息，让他们了解正在发生的事情，如果有相关信息的话，不妨告诉他们服务预计何时会重新上线。”
事件沟通原则：无障碍页面创建和事件更新
对于这个原则，我们着眼于敏捷价值观，即工作软件优先于全面的文档。有关您产品的文档应该清晰易用，我们认为事件更新也应该如此！您的用户无需去费力揣度（或略过冗长的段落）即可了解出了什么问题以及何时可以修复。虽然您确实需要考虑事件更新，并确保您在沟通中保持善解人意和人性化，但您不应该让批准门槛或多次修订阻碍频繁、实事求是的更新。
再看一遍 Dyn 事件，您可以看到他们的团队在向用户传达更新时一点都没有浪费时间。在超过 11 小时的事件中，他们更新了 11 次状态页面（两次更新之间平均为 61 分钟）。通过状态页面，他们能够在一个地方就事件进行沟通，而不必花时间寻找邮件列表来发送电子邮件，或弄清楚如何在 Twitter 上将更新内容缩减至 140 个字符。换句话说，他们在传达信息的同时仍然主要专注于恢复服务。
开箱即用的状态沟通工具的美妙之处在于，您不必花费大量时间来启动和运行可靠的页面。创建状态页面只需不到 30 分钟，就像敏捷开发一样，您的状态页面可以而且应该是迭代的。考虑为您的客户提供一个工作页面，然后努力去改善。当您在流程中使用状态页面完成了几起事件之后，您可以进行调整以随时改进。
准备好创建自己的状态页面了吗？注册或登录 Statuspage >>
不要等到下一次事件才创建状态页面。现在就花几分钟时间，这样在停机期间，你才可能处于最佳位置。记住，不需要花很多时间设置页面来完成这项工作：
- 了解如何自定义您的状态页面
- 从出色的状态页面设计和自定义示例中汲取灵感
事件沟通原则：事件期间及以后的透明沟通
客户协作优先于合同谈判，这种敏捷价值观就是与客户合作，尽可能提供最佳的产品和体验。对我们来说，这意味着要建立适当的反馈渠道，以便客户可以表达疑虑并提醒您遇到的任何问题（使用 Jira Service Management、Twitter 等工具）。世界级公司明白，客户期望他们的反馈得到回应，并希望在改进您的产品和事件响应流程时参与其中。正如这些推文所示，具有同理心和细心解释对您的发展有益，并且客户直言需要这些：
这也意味着保持正常运行时间的透明度，以便用户在注册时确切地知道他们会得到什么。当您注册云服务时，您相信该服务是可靠的。这并不一定是实物合同，而是客户和服务提供商之间谈判达成的固有合同，即出现问题时，双方将展开合作，以确保问题得到迅速解决，从调查到解决，每个人都积极参与其中。这就涉及我们应对变化的最终价值...
事件沟通原则：敏捷开发回顾
即使是最好的计划...好吧，后面的事你也知道。回想敏捷价值观，应对变革而不是遵循计划，我们知道，即使是经过深思熟虑的计划，也不可避免地需要在事件发生期间和发生之后进行更改。敏捷开发就是能够轻松进行调整，并获得快速持续的反馈，从而改善您的产品和文化。
互联网视频和分析托管公司 Wistia 2013 年发生过一次意外事件，该事件使他们的统计基础设施陷入停顿，自此他们了解到保持敏捷的重要性。他们当时没有做好准备，最终收到了不满的客户发来的大量支持工作单。他们进行的第一个调整就是创建自己的状态页面，以帮助他们更轻松地应对这种情况。但是，通过创建自己的状态沟通工具，他们现在除了核心产品外还支持一种新产品。很明显，这是他们当时 20 人的团队负担不起的费用。第二个调整是放弃他们自主开发的解决方案并移至 Statuspage。
Wistia 的支持工程师 Jordan Munson 描述了这次迁移：“经过这几个月我们几乎没有特色但很有帮助的自主开发解决方案带来的轻微挫折后，我们觉得我们需要更多的东西，并且这些东西不需要太过费心。所以我们选择了 Statuspage。自从迁移到 Statuspage 以来，我们已经能够完成我们想要做的事情——快速、轻松地让客户了解我们申请的最新状态。而我们只经历了一次大规模中断并开发了新产品就实现了目标。快进几年到现代，我们的流程似乎更加顺畅。出现中断时，人们会直接从我们这里获得更新，他们知道在哪里获得更新，对我们状态页面的更新会直接推送到许多地方。”
Munson 的团队真正从 2013 年的中断中吸取了经验教训，实施了一种经过改进且可扩展的新事件沟通流程。这是对变化的最佳敏捷反应。
回顾也是这种敏捷价值观的关键部分。通过回顾，您的团队有机会退后一步，讨论在事件沟通中哪些方法行之有效，哪些效果不佳，最重要的是，您将采取哪些措施来防止同样的问题再次发生。在事件标记为“已解决”或者您认为自己的团队表现不错之后，还是要坚持回顾。在事件沟通方面，总是有改进的余地，并且总有机会与用户建立更融洽的关系和信任。
试试 Atlassian 团队行动手册中这个回顾措施，为您的团队提供一个安全的空间，让他们思考和讨论哪些方法行之有效（哪些不起作用！），以便您进行改进。
回顾我们的第一个敏捷宣言，回顾会肯定需要以人为本的沟通才能取得成功并产生持久的结果。下面看一下在回顾会中讨论您的事件解决方案如何进行时要考虑的一些语言。服务再次恢复后，您发送给用户的事后分析或事后审查 (PIR) 中也应包含其中一些语言。保持敏捷意味着不仅不断改进执行事件相关任务的方式，还意味着不断改进压力很大的情况下与队友的关系和履行角色的方式。
人类语言 | 产品语言 |
|---|---|
| 假设、希望和恐惧 | 任务、事务和操作 |
| 动机、误解和行为 | 冲刺、长篇故事、故事和发布 |
| 偏好、关系和尊重 | 里程碑、依赖关系和日期 |
| 角色和职责 | 会议、日历、电子邮件和文件 |
别忘了信任
我们经常讨论对敏捷开发的信任，这个用例也没什么不同。有效的事件沟通需要信任和授权。整个组织的团队都应该觉得自己拥有与用户就事件进行沟通所需的批准和知识。个人还应该能够相信，在事件响应期间，每个人都会履行分配的职责，并且在意外发生时会毫不犹豫地加入并接受流程的中断。信任您的团队能够就事件进行有效的沟通，让客户更快地获得通知，从而提高用户对您服务的信任度和忠诚度（67％ 的 Statuspage 客户表示 Statuspage 帮助提高了用户的信任！）真正的双赢。
