今天这篇文章主要给大家讲解下 ScrumMaster

敏捷开发有四个价值观：1.个体和互动 高于 流程和工具   2.工作的软件 高于 详尽的文档   3.客户合作 高于 合同谈判   4.响应变化 高于 遵循计划

这四个价值观主要强调的就是 互动、交互、合作、响应。也就是说一定要及时的对当下的工作内容做出积极的回应才是最好的选择。

敏捷宣言：

最重要的目标   是通过及早和持续不断地交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。

团队定期地反思如何能提高成效，并依此调整自身的行为表现。

Scrum的3个角色：产品负责人，scrum master ， 开发团队

3个工件：产品工作积压，冲刺工作积压，产品增量

5个事件：冲刺，冲刺计划会议，每日站会，冲刺评审会议，冲刺回顾会议

5个价值：承诺（愿意为目标做出合理的承诺（这个特别重要，一定要注意修饰语 合理的。有些人不顾青红皂白，一拍脑袋就把本来30天的工期定为1天，没有团队成员愿意跟轻易许下这种承诺的人合作的））、专注（于你的承诺）、开放（公开透明）、尊重（每个人）、勇气（有勇气做出、履行承诺，接受别人的尊重）

自组织要比传统方法时间更短一些，也就是灵活根据当前的具体工作内容或者遇到的问题来管理更具有针对性和高效性；在同样的时间内，Scrum团队能交付出更多更有价值的产品增量。

po的特点（产品负责人，product owner的缩写，现在很多人都怕学得英语白费了，在哪里都搞英语，搞就搞吧还不好好说话，用缩写。这就使不同行业看起来有了更高的进入门槛，其实我说就是装x）：

一个人扮演这个角色、推动产品成功、向利益相关者代表项目、代表项目的利益相关者、与所有人合作、通常由客户或客户代表扮演、团队中的一员-在冲刺中全力以赴（说白了就是甲方的接头人，让你装逼，拉出去枪毙两年）。

po的使命：

创造产品愿景、定义产品的功能、根据市场价值优先考虑功能、负责ROI（投资回报 Return of Investment 又来缩写装逼，拉出去枪毙）、根据市场反馈调整功能/优先级、有权接受/拒绝工作结果、确保sprint正确输入。

Scrum Master的特点：向管理层代表团队，向团队代表管理层，无管理头衔（不能强制下达命令），不能代表团队做决定，授权“羊--狗”（又装x），指导团队而不是成为一名球员，变更代理人（装x），听而不是说，仆人领袖

Scrum Master的使命

帮助团队消除障碍，保护团队免受干扰和其他威胁，指导团队实践来达到不断改进提升，促进团队内部以及团队与产品负责人之间的互动，向团队、PO和其他人教授Scrum，在组织发展过程中担任变革代理人以便尽早、经常地交付，以及清除无用、多余的环节（团队中的拉后腿的人或者产品中的多余功能）

接下来介绍3个工件，Product Backlog, Sprint Backlog, Increment。

Product Backlog具有这些属性：描述、次序、估算、价值

推荐一款敏捷开发项目管理工具 Leangoo

Increment

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。

增量是在 Sprint 结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。

五大事件重点解释：

Sprint

在 Sprint 期间：

不能做出有害于 Sprint 目标的改变；不能降低质量的目标；以及随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会澄清和重新协商。

Sprint计划会议

Sprint 计划会议回答以下问题：

接下来的 Sprint 交付的增量中要包含什么内容？

要如何完成交付增量所需的工作？

每日站会（Daily Scrum Meeting）

昨天，我为帮助开发团队达成 Sprint 目标做了什么？

今天，我为帮助开发团队达成 Sprint 目标准备做什么？

是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

每个人觉得这个Sprint 是否能完成计划的目标。

强调管理层在会上不要发言。

Sprint评审会议（Sprint Review Meeting）

Sprint 评审会议在 Sprint 快结束时举行

Scrum 团队和干系人协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。

评审会议时间最长不超过 4 小时

Sprint回顾会议（Sprint Retrospective Meeting）

Sprint 回顾会议的目的在于：

检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；

 找出并加以排序做得好的和潜在需要改进的主要方面； 同时 制定改进 Scrum 团队工作方式的计划。

工作量以及工作权重评估方法：

利用公式计算可以明确知道一个需求需要的时间

比如 权重 = 体量*需求复杂度*技术难度

所需要的时间 = 权重 * 整体计划的工作时间/评估出来的总权重（可能会不合理）

所需要的时间 = 权重 * 每个单位权重分配的时间