1、scrum的流程
2、scrum的目的
Scrum 是用于开发、交付和持续支持复杂产品的一个框架。
Scrum 的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。
3、scrum的理论
scrum 基于经验过程控制理论，Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险。
透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。
承诺、勇气、专注、开放和尊重是scrum过程的五大核心价值观。
4、scrum的三个核心角色
PO：产品负责人，负责管理产品待办列表的唯一负责人
Scrum Master：他/她是一位服务型领导，帮助每个人理解 Scrum 理论、实践、规则和价值。服务于PO，团队。
scrum团队：跨职能，自组织，由3~9人组成，在每个 Sprint 交付潜在可发布特性并且“完成”的产品增量。
5、Scrum的四个会议
Sprint 计划会议：对齐sprint的目标，确定完成的内容。
每日 Scrum 站会：通过三个核心问题，检视目标和进度。
Sprint 评审会议：检视交付件，获取反馈和促进合作
Sprint 回顾会议：检视人，关系，过程，工具的情况，并列出改进计划。
6、scrum的几个核心工件
产品待办列表（监控进度动作）： 理解为总需求列表 。
Sprint 待办列表（监控进度动作）：当前迭代的任务列表。
过程关注点： 完成的定义，信息的透明。
7、敏捷过程出现的问题
1、公司环境
①需求的输入不遵从scrum规则，变更频繁，过于享受scrum短暂交付就能看到成果的“快感”。导致出现临时方案堆砌，从而埋下祸根。
②管理层应该尊重客观事实，合理利用人力，sprint结合996，老板很爽，员工在苟延残喘。
2、scrum团队
①要有基本的scrum理论基础，以交付为目的，对齐目标。
②个人能力的提升需要达到一定的水准，否则频频跳票会让整个项目都很痛苦。
③跨组，跨团队的沟通合作，软实力要跟的上，本身的技术能力不能成为优秀的唯一标准。
3、核心岗位和关键角色
① 核心岗位要明确自己的职责，认知不清晰会很麻烦。
② 核心岗位身兼多职，导致既是球员又是裁判，诉求不一致，导致执行动作四不像。
8、感悟
敏捷过程实际类似于将团队化整为零，构建"特种兵战斗小组"的思路，走的是精兵战略。积小胜为大胜，从由量变引起质变。
频繁的交付如果不能产生作用，执行结果没有做到卓有成效或者被外界认可，那么持续获取成功优势会变成持续打击团队的劣势。（吐槽下团队持续集成和自动化工具的建设，成功将Scrum实践为中华田园人肉敏捷）
快速交付的场景下，团队的关键角色，scrum的组长，scrum master的素质要很高，因为没有充分的时间做完备的计划，虽然基于事后的 经验进行总结和持续改善，但是关键角色缺位或失职，团队很容易卡在天花板，甚至不进反退。因为在系统达不到要求的情况下，摩擦和冲突加剧了，那么资源的浪费就提升了。
绩效的评估。长期的项目总是有一个好的或者坏的结果，相对来讲绩效是比较好衡量的。 敏捷过程涉及目标的调整和校正，那么团队中各个角色产出结果的衡量就会变得复杂。如果绩效的激励出现了问题，会极大影响个人的主观能动性。
最后的思考，关于团队的效能衡量和持续改进。敏捷是短迭代的进行，很容易产生完整单元数据的积累，并且是基于经验主义持续改进。看起来很契合当前机器学习的思想。所以效能工具的研发是不是可以从工具层面来完善整个Scrum的过程，丰富scrum框架。
