软件工程的核心痛点在于大量的不确定性以及产品必然的能效和成本诉求。一切管理讨论的基础诉求均来源于此，Scrum也不例外。
软件工程中的不确定性
当前的软件开发，既是一个工程化的过程，但又充满了大量的不确定性。这样的不确定性表现在需求的不确定性、人员稳定性的不确定性、技术风险的不确定性、人员能力的不确定性以及交付时间的不确定性等等。但统合起来看待，整体的问题更多的还是来源于“人”这个因素。目前的软件工程中，人所占用的比重还是很高的，尤其是相对复杂的部分，人员能力对于整体结果的影响是最为关键的因素。因此，如何把整个过程涉及的人员有效且高效的组织在一起，增加正向收益，降低和消灭负向收益，就是软件开发管理的核心要素了。
效能和成本
究其本质而言，Scrum方法很简单：无论你什么时候启动一个项目，为什么不经常检验一下自己正在做的事情，看看是否朝着正确的方向前进？结果是不是大家真正希望看到的？是否有什么办法能改善目前正在做的事情？如何才能做得更快更好？存在哪些潜在的障碍？—— Jeff Sutherland, Scrum创始人
我们之所以喜欢在软件工程上使用“敏捷开发”这个词，更多的是因为“敏捷”和“效率”是近义词，而效率的提升，则可以给我们带来更高的产出。Jeff Sutherland这段话很好的描述了Scrum给我们带来的收益。工程的方向是否正确，结果是否正确，能否改善，如何做得更好更快，如何排除潜在的问题。这也是我们希望Scrum给我们带来的，因为解决了这些问题，必然会给Scrum的使用者来带效率的提升。
但如果仅仅是效率的提升，显然又是不够的。因为最终衡量团队价值的并非效率，而是效能，效率并不等价于效能，只有效能的提升才是真正提升软件工程产出价值的必由途径。前面已经提到了如何提升“效”，那么“能”呢？
能即是单位时间内的有效产出。什么是有效产出？去掉无效工作以后的价值即为有效产出。无效工作就是不产生价值，或者产生的价值被覆盖，亦或是产生了负面价值的工作，因此无效工作本质是一种隐形的工作成本。
著名的丰田管理法的创始人大野耐一在他的书中描述的第一条训诫，即是：
首先，你就是成本，消除无用的浪费，否则没有提升
是的，我们除了提升效率，更重要的还有降低成本。当然，这里有一个前提条件，就是在正确的方向上努力降低成本。如果路线错误，则所有的努力都是白费。
Scrum和目标管理
目标管理就是在我们的工程中，必须确立明确的目标。这个目标必须是有价值的、可交付的产物，并且在设置的时间范围内，完成我们的目标，这就是团队输出后最大的价值所在，即价值输出。无论这个目标是短期的，中期的亦或是长期的，有了目标，团队才有前进的方向，团队的每个人才知道自己所在的位置。目标是一个团队的方向，也是每个人努力的方向，更是团队前进的路标和量尺。正因为目标的重要性，目标管理也是Scrum管理的第一要素。
我们在Scrum管理中，会将团队、个人的目标作为一个一个的任务项明确其中，并且随着迭代的进行，目标的状态会随着工作而发生变化，而随着目标的变化，团队和个人也能明确目标的完成情况，团队和个人在目标池中所在的位置，这所有的一切，给予了团队一个清晰的标尺，让混沌不再，让不可量化变得可以量化。
Scrum和风险、效率管理
相对于明确的目标管理，风险管理和效率管理有的时候不就那么一目了然了。因为在开发过程中，风险往往是不能全部预估到的，而效率也是往往最难于评判的。风险的难以预估表现在，我们往往只能判断我们认知的风险，而对于超过我们认知能力的风险，我们往往是难于预估的。而效率会包含开发效率、产品设计效率、测试效率、沟通效率等等，它的构成复杂度会更高一些，并且相互之间互相影响、互相制约，我们不能用一个简单维度来看待整体效率的高低，因为一个环节的低效可能会毁掉全流程的高效。Scrum能在风险和效率上给参与者带来什么呢？“透明”！透明的过程，让所有参与者对于整个工程过程都可以做到最大范围的信息同步，所有人都可以以很低的成本了解到当前的团队状态，并且可以很容易的在第一时间暴露问题，无论是过程中的风险，亦或是进程上的阻塞，简单的一个透明，就可以让信息的同步畅通无阻，更可以在站会上集思广益，用团队的力量来帮助个体解决问题。即使需要调整目标，目标也仍然不会被轻易丢弃，团队可以很容易将风险暴露到外部，争取其他资源来解决问题。
Scrum的价值提升
本质上讲，记录、过程和透明几乎涵盖了Scrum的全部内涵。但它能创造的价值却是可以超过目标管理、风险管理和效率管理的。因为信息本身就是价值的本源所在。
通过对于信息的拓展和深入挖掘，在软件工程的管理上，是可以很容易得到更多的价值的。例如团队绩效，工作量衡量，任务达成甘特图等等，但这些都是Scrum的外延。
但Scrum也不是万能的，真正依靠的还是团队的执行力。对于Scrum的良好运用可以有效提升团队的产出能力，团队中个人的存在感以及价值感，并且可以对于团队间的横向比较以及团队内部的纵向比较都会有坚实的信息支撑。
Scrum实践案例
我们可以以运维团队在Scrum上实践前后工作状态的变化了解Scrum到底能给一个团队带来什么。
| 项目 | 前工作状态 | 后工作状态 | 效率提升点 | 成本降低点 |
|---|---|---|---|---|
| 任务安排 | 口头传达 | 使用任务卡片 | 任务不会丢失 可以随时回顾 随时可调整 |
降低或消除了人员明确任务项的时间 |
| 工作量评估 | 没有评估 | 对卡片工作量进行集体评估 | 可以量化工作 | 工作任务的安排变得可以预估 明确降低人员闲置时间 员工对工作目标可以主动安排计划 |
| 任务状态 | 口头等方式确认 | 变化卡片状态 | 一目了然，降低管理成本 | 沟通成本大幅降低 |
| 早会内容 | 各团队、个人均不同 | 报告完成卡片和点数 报告待进行目标卡片 报告目标卡片风险 |
统一了对于目标的沟通模式 | 降低了沟通成本 |
| 风险管理 | 口头询问 个人主动报告 |
卡片不能顺利完成就必然会有风险报告 | 能够统一的模式确保风险暴露 | 流程上避免了风险被屏蔽 |
| 任务池管理 | 个人记录 | 看板backlog管理 | 从backlog无缝转移至看板中 无需跨系统和模式安排任务 |
降低了任务转移成本 |
| 人员工作价值评估 | 感官评估 | 任务量统计评估 | 量化评估工作价值 | 提供了有效评估参考维度 |
| 团队产出评估 | 感官评估 | 总工作量统计 | 量化评估工作 | 团队负载得到有效评估 不需要额外消耗做统计 |
| 任务交付 | 缺乏明确的约定 | 卡片中有明确约定 | 明确了任务目标 | 减少了返工 |
| 任务交付顺序 | 没有明确约定 | 根据卡片优先级 可以随时调整 |
员工明确知道如何调整优先级 对外对接工作可以明确进行回复交付能力 |
明确了整个工作流程 无论内外均可以根据情况调整自己的节点安排 |
| 团队信息同步 | 没有 | 通过卡片标准进行通信 对其他人工作有了明确认知 可以提供协助 |
形成了团队合力 | 提高了个体在个体问题的解决能力 |
从上面的对比我们可以看出，在实行了Scrum管理之后，整个运维团队在目标管理、风险管理、效率管理方面均实现了较大的提升，它明确了任务目标和状态，降低了大量的管理成本，提高了工作效率，并且还建立了能够暴露风险的固定流程，确保我们能够把所有的不确定性提前进行暴露，再用团队合力将不确定性转化为确定性。在此以外，在任务量评估、沟通效率、团队建设等方面也实现了较大的提升，也正因为此，Scrum管理才见证了运维团队效能的巨大提升。
Scrum框架定义
Scrum框架包括3个角色、3个工件、5个事件、5个价值：
3个角色
产品负责人（Product Owner）
Scrum Master
开发团队
3个工件
产品Backlog（Product Backlog）
SprintBacklog
产品增量（Increment）
5个事件
Sprint（Sprint本身是一个事件，包括了如下4个事件）
Sprint计划会议（Sprint Planning Meeting）
每日站会（Daily Scrum Meeting）
Sprint评审会议（Sprint Review Meeting）
Sprint回顾会议（Sprint Retrospective Meeting）
5个价值
承诺 – 愿意对目标做出承诺
专注– 把你的心思和能力都用到你承诺的工作上去
开放– Scrum 把项目中的一切开放给每个人看
尊重– 每个人都有他独特的背景和经验
勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
参考文献：
