最近决心培养阅读写作的习惯，每月定下目标写2篇分享，现在从工作相关的《Scrum精髓》阅读作为习惯开始的第一篇。
Scrum是一种用于开发创新产品和服务的敏捷方式，最早可以追溯到1986年，本田、佳能等公司通过可伸缩、基于团队的“蜂涌式”开发出世界一流的产品，形成了最早的Scrum概念：授权、自组织地管理。Scrum和看板都是敏捷开发方法，Scrum特别适合处理不可预测性大于可预测性的复杂域问题，而看板用于常常被打断的支持与维护工作。虽然Scrum主要用于开发软件产品，但其核心价值和原则也可以用来组织各类型的工作流程，上个月参加了个ASM敏捷大咖讲座，发现各行业的听众都有，像组织婚庆之类的也要敏捷管理。
Scrum团队一般由产品负责人、ScrumMaster和开发团队三种角色组成。产品负责人必须很好理解组织中利益干系人、客户和用户的需要及其优先级，另一方面需要和开发团队交流要构建的特性及其构建顺序，保证每一个PBI的接收标准已有明确说明，同时管理冲刺过程中的经济效益（比如多花一周进度延迟4%把一个新发现的特性添加到冲刺中可以增加50%的收入，应该怎么办？需要拿一周的时间和额外的成本换取收入的增加吗？）。ScrumMaster主要负责帮助每个人理解并乐于接受Scrum的价值观、原则和实践，保护开发团队免受外部干扰集中精力在每个冲刺交付业务价值，同时主动承担“清道夫”职责，扫清妨碍团队生产效率的一切障碍。ScrumMaster不提供问题的最终解决方案，而是引导团队自己解决问题。开发团队主要职责是执行冲刺，每日检视和调整，梳理产品列表，细化冲刺内容，自我组织完成价值交付。
在使用Scrum时，经常需要平衡预测性的事前工作与适应性的适时工作之间的关系。下面五个敏捷原则与此有关：
• 不到最后时刻，不轻易做决定
• 承认无法一开始就把事情做对
• 偏好适应性、探索式的方法
• 用经济合理的方法积极主动接受变化
• 在预测性的事前工作和适应性的适时工作之间做出平衡
在使用Scrum时，对工作进行组织，快速产生经验认知，下面三个敏捷原则与经验认知相关：
• 快速验证重要的假设
• 利用多个认知循环（例如每日例会是一个每日循环，冲刺评审是一个迭代级循环）并行的优势
• 妥善组织工作流程以获得快速反馈
估算与速率在敏捷规划过程中发挥重要作用。在一个冲刺内所有已完成PBI的大小之和即为该冲刺的团队速率。在估算PBI时，Scrum团队要使用几个重要的概念：
团队估算 -- Scrum可遵循一个简单的原则：大家一起估算，SM帮助指导和引导每个团队成员参与估算活动，最终产出每个PBI的大小。
估算不是承诺 -- 假如估算是承诺，每个人都会给出一个较大值，而估算应该是靠谱的，要确保估算不受外因而人工放大，陷入团队成员往上加和管理层往下减的抛球游戏。
准确与精确 -- 估算应该准确但不必过分精确
估算相对大小 -- 人类擅长相对比的估算，而不是绝对大小的估算，可以跟以往冲刺相同的功能点来对比估算
