约定大于监管：监管是管理层面的，还是旧有的模式，而约定是团队自己的法规。
工具：传统的管理工具是服务于管理者的，更多的是PM在使用，而敏捷中的工具是服务于个体的，比如白板，便签等。
会议与过程：
需求预定义过程：发生在sprint会议前，更确切的说，这不是一个会议，而是一个过程，参与者是PO与team, 通常好的作法是在这个迭代的时候，PO先定义下一个迭代的PB，然后找team确定，如果team接受，那么team和PO一起写AC(test case)，这些case通常是验收用例，所以这也可以说是验收测试驱动，写完测试，team还要估算PB的point。PO与team确认是否所有的case可接受，如果没有问题，那么这个过程就结束了。这个过程团队通常会花10%-15%配合PO.
在这个过程的产出物PBI一定要符合DEEP原则：
D: 恰当的详尽程度，需求是渐渐明细的
E: 可估算，并完成估算
E: Emergent
P: 优先级排序
AC的格式：
give:给定什么条件
when:做什么动作
result:得到什么结果
sprint会议：这个会议实际上是团队的会议，前半段理解需求，PO必需参加，后半段分析解决方案，PO可选参加。SM不是必需的
在这个会议上通常不需要估算task的大小，这个没有太大的必要，在计划会议上也不需要领任务，这个发生在计划会议后。
在计划会议上还要识别出RID（风险,issue和依赖）
每日站会：这个也是team自己的会议，SM不是必需的，可以参加，但是SM通常不需要发言，除非SM也是开发人员。三个问题：今天完成了什么？明天要完成什么？有什么问题？
评审会议：要求质量达标:自动化测试完成，有测试报告;功能可用：演示所有功能。
回顾会议：唯一一个属于SM的会议，SM要把上一个迭代的问题拿出来讨论，同时鼓励所有人提示建议，目标是持续改进。
SM的职责：
维护透明性：即是要暴露所有的问题，还不能让问题被隐藏起来。
面对的是内部管理层，背后是team，SM不是PO与team的中间人。
帮助显露问题，SM主要是看听记，他是教练、牧羊犬，帮助过程改进。
有问题时，SM需要跳出来与管理层沟通，但最好是用数据说话，要做一个活着的SM.
SM不是一个必需的角色
PO的职责：
PO面对的是stakeholds，背后是team. PO和SM共同撑起保护伞来保护team.
PO是唯一一个有正式授权的角色。
Team:
团队有权砍掉SB，如果发现这个sprint无法完成现有的SB，团队可以选择砍掉一部分SB,并通知PO.
PB是PO的资产，SB是team的资产
Bug属于team，bug只进SB，不进入PB
PB都是有价值的需求，PO不管质量，team负责质量
任何人都不能迫使团队交付他们不愿意交付的产出。
一个项目的前三迭代失败是很正常的，因为在这些迭代里面有很多前期工作要做，比如基础框架，技术选型。
测试是开发的一部分，测试应该融入开发，测试开发的比例通常是6:1。传统的测试人员可以通过三个方向转型：
1. 资深测试可以转测试专家
2. 普通测试可以转自动化测试，与开发一起工作。
最好是不要有专门的测试部门，保证一个scrum team就是一个团队。不要有部门间的壁垒。
