经过两天的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必需参加,
约定大于监管:监管是管理层面的,还是旧有的模式,而约定是团队自己的法规。
工具:传统的管理工具是服务于管理者的,更多的是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必需参加,