探索持续规划
持续规划是 DevOps 八个功能中的一个。
了解持续规划的必要性
让我们来看一个由政府机构在 2000 年至 2005 年之间开发的软件应用程序的案例研究。 该项目在 2005 年 1 月被正式放弃时离最终目标还相去甚远，最终演变成一场彻底的失败。 这次失败不仅浪费了至少 1 亿美元，该机构及其项目领导人还遭到了来自多方的指责。
2006 年又启动了第二个项目，结果同样一败涂地。 两次项目都在前期进行了大量设计，都采用了瀑布式开发方法，并策划了经典的具有轰动效果的营销宣传。 但最终在耗费了数亿美元后他们什么也没交付。
为什么项目会失败？
- 大量的前期设计 - 200 人的团队花费了六个月的时间来确定需求。
- 重要目标发生转变 - 项目进行到一半的时候发生了一场灾难，导致了大规模更改 - 换了一个 300 人的团队工作了六个月，结果确定了长达 600 页的需求。
- 浪费了大量时间并返工，导致错过了最后期限，同时团队精疲力竭 - 编写和重写了 70 万行代码。
2010 年 12 月，在同一地点成立了 Scrum 工作室。 工作人员从项目最初的 400 人减少到 40 人。 设计从 600 页需求转变为 670 个用户情景。 团队每隔两周就发布一次代码并演示一次新功能。 经过几轮冲刺，就已经可以按粗略的时间范围进行预测和逐量规划业务更改。 到 2011 年 12 月，代码已全部完成。
但为什么很难进行详细的规划呢？
艾伦·图灵在第二次世界大战期间研发了一台机器，破解了被称为“恩尼格玛密码机”的加密设备。
图灵需要持续破译新的密码来挽救更多生命。 图灵没有因为看似无尽的复杂性而放弃，他知道，只要从细节突破和破解，就能获得巨大成效：
“我们的目光有限，但可以看到许多要做的事。”
宏大的软件项目总是很复杂。 但不要让复杂性难倒你。 而是要在已明晰的细节和方面着手突破：即短期目标。
借助目标与关键成果法 (OKR)，沿着明确的方向、有重点地、敏捷地、持续有效地进行规划
在给出持续规划的定义之前，我们需要引入一个重要的概念和框架，帮助你沿着明确的方向、有重点地、敏捷地、持续有效地进行规划。
目标与关键成果 (OKR) 是一个目标设定框架，旨在将领导者设定的战略目标与执行团队的日常活动联系起来。
重要
OKR 有助于确定可能的最佳结果，并明确什么是真正的成功。
OKR 一般每季度制定一次，以便突出重点，提高灵活性。
“目标”是方向，“关键结果”必须是可衡量的。 最终你能够审视结果并毫无疑义地得出结论：我是做到了还是没做到？ 是？ 否？ 简单。 无法判断。
OKR 向下落实到组织中的所有团队并统一实施，以实现一致性和透明度。
什么是 OKR？
OKR 有三个重要方面：
它们构成了用于定义明确目标的“框架”，使组织各层级的目标和方向更加明确。
可衡量的关键结果进一步增强了这三个方面。 关键结果是用于衡量成功的结果。
它们推动了“结果”思维文化的形成，实现了从“输出”思维模式到“结果”思维模式的清晰转变。
OKR 示例
下面是一个 OKR 示例：
目标：在 1970 年结束前将一名宇航员送上月球。
关键结果：
- 在 1965 年之前制造出 4 万磅以下的宇宙飞船。
- 1967 年完成宇航员的登月训练。
- 成功将飞船降落在月球上。
- 安全地将宇航员带回地球。
这个 OKR 示例确定了在 1970 年结束前将宇航员送上月球这一目标或目的。
注意
目标应易于理解、应设定清晰的方向，并能提供动力。
在此示例中，关键结果是对目标进度进行的一系列度量的标准，用于确定目标成功与否。
注意
关键结果必须是可衡量的，并能够确定如何实现目标。
OKR 的主要优点
OKR 有五个主要优点：
- 重点：所有目标都应指向同一个方向。 每个目标的关键结果不应超过五个。
- 一致性：管理者和参与者应将自己的日常活动与组织的整体愿景联系在一起。 这种联系在术语上称为一致性，其价值怎么强调都不过分。
- 承诺：应对计划和资源进行调整，以确保达成所有确定的承诺。
- 跟踪：从输出向结果转变的 OKR 是为什么按目标进行管理在顶级公司中如此受欢迎的原因。 在每个 OKR 确立时，就应相应创建相关指标进行跟踪。
- 延伸：OKR 由于其内在特性，能促使组织进一步努力，争取实现比目标更好的结果。
比较持续和静态规划
“持续规划”需要规划人员、架构师和敏捷团队持续不断地将整个企业范围内的计划进行整合。
在持续规划中，通过基于 scrum 的规划方法和新兴设计，团队能够将计划细化到执行层面。
重要的是要有一个高级别的计划，它既能适应变化，同时也有明确的愿景和目的来作为指导。
用于权衡瀑布式开发与敏捷开发方法的“铁三角”阐释了持续计划和静态计划之间的比较。
在“静态”方法中，计划范围是固定的。 由你确定项目将花费的时间和成本。
在使用持续规划原则的“敏捷”方法中，为满足业务目标，时间是固定的。 唯一可以商讨的是范围。
铁三角通常显示时间、资源和功能。 Gartner 在这个描绘中加入了质量，因为持续时间和成本是相关的，而质量经常被忽略。
但是，两种方法的成功率如何呢？
敏捷式项目获得成功的一个原因是，小批量发布为获取信息提供了更多机会。
需要注意以下四点：
- 业务需求不断变化且往往是突然发生。
- 敏捷开发提供的规划机制可以跟上业务变化。
- 高绩效团队也可能快速走上错误的方向。
- 获取知识可降低风险。
瀑布式和敏捷式均可能面临困难。 敏捷开发的成功率只高出了 30%。
浏览持续规划的六个原则
浏览持续规划的六个原则：
- 重视简易性
- 敏捷软件开发声明
- 设计思维
- 迭代和增量开发
- 精益化管理
- 估计准确度
持续规划原则 #1：重视简易性
持续规划的第一个原则是重视简易性。
“如果不能用简单的语言来解释它，就说明你没有很好地理解它。”
- 阿尔伯特 爱因斯坦
持续规划原则 #2：敏捷软件开发声明
持续规划的第二个原则是敏捷软件开发的声明。
声明与软件交付相关。 它与软件开发相关，与项目管理或设计无关。 它是持续规划和 DevOps 的核心。
我们正在通过实践和帮助他人实践此原则来发现更好的软件开发方式。 通过这项工作，我们开始重视以下方面：
- 个体和交互胜过过程和工具
- 有效用的软件胜过全面的文档
- 客户协作胜过合同协商
- 响应变化胜过遵循计划
持续规划原则 #3：设计思维
持续规划的第三个原则是设计思维。
设计思维采用以人为本的创新方法。 它关注可行性、可用性和合意性的交集，目的是确立边界和减少浪费。
持续规划原则 #4：迭代和增量开发
持续规划的第四个原则是迭代和增量开发。
有些人担心自己不知道最后会得到什么。 迭代开发解决了这个问题，它在迭代反馈循环中将需求和优先性的确定交到利益干系人的手中。 每次迭代对其用户而言都是完整的、可用的且有用的。 它添加了更多的功能，如果可能的话，会首先添加最重要的功能。
持续规划原则 #5：精益化管理
持续规划的第五个原则是精益化管理。
价值会从最终客户的角度来定义。 在此过程中将标识价值流，并将未向客户交付价值的步骤标识为浪费并删除。
该过程将反复循环，通过不断改进，臻至完美。
持续规划原则 #6：估算准确性
持续规划的第六个原则是估算的准确性。
“估算”是对某件事情所需时间、成本或能交付多少功能的分析性预测。 它具有两个属性：准确度和精度，二者完全不相关。 这些估算由工程团队负责管理。
“目标”是对业务需求的陈述：希望某个目标耗时多长时间、希望花费多少钱，或者希望能交付多少功能。 这些目标由业务团队负责管理。
“承诺”是在限定日期交付目标功能和质量的承诺。 承诺由各方共同负责。
重要
持续规划的目标是保持估算、目标和承诺之间的一致性。 否则，我们将无法满足来自组织内部和外部的期望。
说明 OKR 和 Scrum 之间的关系
现在，你已经理解采用 OKR 的原因及涵义，以及持续规划的相关知识，下面说明这两者之间的联系。
使用 OKR 之类的技术来构建工作会减少不确定性，至少在短期内是这样。 因为 OKR 是以串联的方式来定义的，这会开始改变管理者呈现自身管理风格的方式。
OKR 这样的技术是逐渐摆脱专制管理风格的一种快速有效的方法。
