今天是CSM培训的第二天，看得出大家经过一天的培训今天稍许有些疲惫。。。
1. 首先，吕老师回顾了一下昨天的讲课内容，并对大家提出的问题进行了一定的解答。有一个问题吕老师说在今天讲课之后会提到，就是SCRUM中并未提及绩效管理，采用scrum后绩效管理应该如何进行。
后来到课程的最后吕老师提到，有一本书曾经说过，考评并不能带来任何效益，但我们现实中却无法避免考评。他作为SCRUM团队的Mgr，他是这样做的：
a. 由于SCRUM团队应该是自管理，自问责，不区分角色的，所以团队整体的表现应该占50%
b. 30%来自团队成员，PO， SM的评价
c. 由于SCRUM强调 Generalizing Specialist ， 20%来自考察该成员除了自己主要的职能外，对团队其他成员的职能是还也掌握了相关基本水平。
2. PO 和 Product Backlog.
PO 应该主要考虑ROI，也就是两个主要的维度：价值和成本。在做版本计划时，对时间，成本，范围进行权衡。传统模式是先确定范围，然后根据范围确定时间和成本，但在SCRUM中，一般是先确定时间与成本，然后据此决定范围。
Product Backlog中每一项叫PBI（product backlog item)，而User Story/Use Case 只是PBI的描述形式。每一个PBI都应该估计他的价值与成本。根据价值排序。在product backlog中一般情况下自上而下为已经完成的，细粒度的，粗粒度的，下一版本的PBI。
好的Product Backlog应该满足：D(Detailed Appropriately)E(Emergent)E(Estimated)P(Prioritized)
PO应以 高价值低成本，高风险高价值的PBI优先。团队可以贡献和讨论PBI，但优先级最终应由PO决定，哪怕是错误的，可以让问题及早暴露。
PO 在做release 计划时，先和团队估算版本中的所有PBI的点数，然后根据版本时间，及以往的经验速率，可以得到期望的版本燃尽图。如果没有经验速率就先做两个sprint再得到实际速率。 Release plan 不是team对PO的commitment，也不能以实际版本燃尽图作绩效考核。
在发现实际版本燃尽图中完成速率与期望差太大时应及时调整。由于Release不是timebox，我们可以：
1) 延长版本时间
2) 减少PBI
3) 增加团队 （最好是在早期加入，后来发现多作可以撤走，但如果加入太晚反而成为累赘）
4) 改进办公条件，开发环境等，从而提高速率。
在Sprint中间，应预留相应的时间（2周的sprint, 大概半天)，进行product backlog梳理。主要是对近期将要做的项目进行需求分析，进一步分解，重排优先级，重估故事点。最好是放在一个sprint中间某周的开始和结束。这样不会干扰团队，PO也有时间进一点和客户沟通。
分解PBI时就根据以下原则：
1）按功能分解（instead of module) ，关键能否交付
2) 分解后的PBI工作量比较平均
3) 分解后的PBI优先级分明
打牌确定PBI的故事点数。
1)故事点数为Fibonacci数列，这是为了做故事点数越大，不同点数之间的差距越大，区别更明显
2)先择倒数第二小的PBI作为2
3)大家估计很不一致时，让最大最小者发言分析，再重出牌
4)大家估计差不多时取较大者。 （注意，task的估值一般取平均）
写User Story 时应遵循的原则：
1) Card : As ( XXX role ) , I'd like to (XXX function), the value is XXX
2) Conversation: PO & Team的对话， PO & Customer的对话
3) Confirmation ： 怎么算做完了（AC）
3. Scrum Master ---- Facilitator
不是管理者，不是决策者而是促进者。Facilitate 整个团队做好SCRUM，协助团队提高工作效率，增进合作。
多问团队，少做决定。
4. Scrum 团队
自管理，自问责，跨职能
5. 讲了一些工程实践，主要是ATDD和CI
6. Scrum Master的秘密～～～ 左手，顶脚，woof~
今天的时间有点紧，主要是由于中午上菜过慢浪费了半小时。无论怎样还是觉得收获颇丰，能认识挺多人，有机会走入SCRUM community，很值啊：）