后两天的CSM训练。我们非常颠覆旧观念，有关的一些观点的简要培训记录：
约定大于监管：监督是管理水平。或旧有格局，该公约是一个团队与自己的法规。
工具：传统的管理工具和服务经理，还有许多人是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这是一个团队。没有部门之间的壁垒。
版权声明：本文博客原创文章，博客，未经同意，不得转载。
