敏捷宣言
- 个体以及互动胜过过程和工具
- 可用的软件胜过完整的文档
- 客户合作胜过合同谈判
- 应对变更胜过遵循计划
敏捷十二原则
- 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使得客户满意。
- 欣然面对需求变化，即使是在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件。相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也高的方式是面对面的交谈。
- 可工作的软件是进度的首要衡量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能共同维持其步调稳定延续。
- 坚持不懈的准求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何提高成效，并依此调整自身的行为表现。
三个角色
1. 产品负责人PO
- 负责管理产品待办事项列表PB的唯一责任人
- 改变PB的优先级都需要经过产品负责人
- 需求不明确，可以与PO和干系人澄清
- PO是某个业务专家，但一般不会由Scrum Master兼任
- PO决定接受或拒绝每次Sprint完成的增量
2. 开发团队
- 由组织创建并得到授权
- 自组织：自主进行任务的估算、自主决定任务的分配、自行决定任务具体怎么执行
- 跨职能：团队拥有创建产品的全部技能，T型人才一专多能，有利于协作、交叉培训和结对
- 去中心化：不认可任何头衔，不管承担什么工作，都叫开发人员，没有多个层级也不认可子团队
- 相对稳定：一般3~9人，比较稳定，建议全职
- 主动学习：愿意接受挑战，主动要求成长
- 一般不包括PO和Scrum Master，除非他们也参与执行Sprint待办事项中的工作
3. Scrum Master
-
服务型领导(仆人式领导)
-
服务于产品负责人：确保团队理解目标；找到有效管理PB的技巧；确保产品负责人了解如何安排PB；帮助理解并实践敏捷性
-
服务于团队：作为教练在自组织和跨职能方面给予指导；移除开发团队工作中的障碍；在Scrum还未完全采纳和理解的组织环境中，作为教练指导开发团队
-
服务于组织：作为教练指导组织采纳Scrum；帮助干系人理解并实施Scrum；引发提升团队生产率的改变；增强组织中Scrum应用的有效性
-
仆人式领导提供协作和支持，而不会去命令和控制
-
不会去分配任务，不会去下达指示
-
当PO、团队或者其他干系人不了解敏捷时要提供培训，服务于各方
-
当团队遇到障碍时，应该帮助团队扫清障碍
