Scrum Training 第一天回顾

今天参加了吕毅老师的Scrum Master 培训的课程。吕老师是国内第一个Scrum Certified Trainer， 果然有大家风范，讲课相当生动，presentation skill 相当 sophisticated。虽然自己实践SCRUM已三年左右，期间也从事过SCRUM Master的工作但依然觉得受益颇深。现就讲课内容作一回顾：

 

1. 先对两天的课程作了大致的Agenda介绍

 

2. 就大家对SCRUM的熟练程度进行了一个自我管理的排队，熟悉的排前面，然后交叉分组，保证每组都有对SCRUM不同熟悉程度的队员。

 

3. 小组成员自我介绍，并提出对SCRUM的最大疑问

    我个人提出的疑问是，作为Scrum Master但权利有限，如何控制sprint中被强行加入的task ?

    后来在听课过程中得到了答案，scrum 不仅仅是R&D部门的事，而是整个公司的事，一个无法决定自己workload的teaｍ是无法适用scrum的。而作为PO应该承诺不干预sprint的内容，最多在极少数情况下异常中止sprint.

   作为PO，关心的粒度应该比较组：

            PBI（product backlog item ) instead of task

            Sprint instead of day

            Team instead of person

   因此可以带多个团队。

 

4. 介绍SCRUM的历史与敏捷宣言。其中四个价值观：

      a. 个体和交互 胜过 过程和工具

      b. 可以工作的软件 胜过 面面俱到的文档

      c. 客户全作 胜过 合同谈判

      d. 响应变化 胜过 遵循计划

 

   对于第二点我有些自己的体会。曾经听培训过SCRUM的同事回来跟老板changllenge不该写文档，因为SCRUM培训老师如是说。 当时就觉得不应该这样，但一直没找到“理论依据”反驳，现在想来应该是他误解了Agile的价值观，workable software是比文档重要，但不是说文档不需要。况且只是比面面俱到的文档重要，当然这里“面面俱到”翻得有些争议，原文是“comprehensive document"。

 

5. 以老板指挥员工走路和员工自己走路（在指定区域内一伙人一起走）看哪种方法在规定时间内走的步数多的游戏强调了在有约束条件下的自我管理的有效性。

 

6. 以野鹅南徒举例讲解了经验型(也就是inspect & adapt)的流程对复杂项目比较适用。并讲述了，检查，透明性与适应是SCRUM的三大支柱。

 

7. 讲述了美国FATBURGER将死松鼠肉做的汉堡卖给只出得起1.6美元的顾客的案例，试图说明我们不应该为顾客去决定风险。其实就是为了说明我们的项目需要有足够的透明性。

 

8. 讲述了SCRUM的整个work flow和role. PO --> Product Backlog --> Sprint Planning --> Sprint Backlog --> Sprint --> Daily Scrum --> Scrum review and retrospective meeting.  然后让大家列举出原来项目经理的职责，以用在SCRUM中应该由哪个role承担。从而将SCRUM中的三个role的职责阐明了。 PO focus在release上，以ROI为导向，要考虑版本的时间，收益，成本。

 

9. 提供一个具有一定风险性的案例，让大家扮演不同的竞标公司，而吕老师扮演招标公司老板。结果大家不约而同地为了夺得这个票，从而隐瞒了风险。讽刺的是大家的作法与FATBURGER卖汉堡的案例如出一徹。以此进一步说明透明性的重要性。

 

10. 以遗留代码的产生，及其维护代价说明其危害性。从而引出什么才是"done"的概念。

 

    就这点来说个人还是蛮有体会的，很少有公司定义的”done"能真正包含软件部署前所要做的所有事的。

 

    作为SM应该始终保证"done"不被破坏。

 

11. 详细讲解了sprint  plan , sprint backlog, daily scrum, scrum review & retrospective meeting。

 

     Sprint的长短视项目/产品需要适应变化的程度决定，一般互联网公司应该在2周左右。

     Sprint Plan --  需求层面 (what & why )  --> PO 定义 Acceptance Criteria

                         先分散，再合并。每组分别对不同的PBI写出：Question, Assumption, Scope以及AC,再合并。

                       --  设计层面（how & how much) --> team

 

       Done X AC --> 工作量。

 

      2周的sprint --> 1天的 task。调整更快捷。任务不要在planning时分配而是在每天分配。

 

       Burning down chart & task board.  期间可以根据进度调整PBI的出入。

 

      Daily SCRUM: Done ? To do ? Problem ? 

      Scrum Master组织daily scrum 应避免任何人成为中心。强调team自管理。

      SM小技巧: 1. 避免与汇报者眼神交流  2.围着task board开会  3. 录音，寻求feedback看哪些内容对大家有用

 

 

      Review Meeting :

      1. 总结。 根据 done 的定义来看，哪些完成哪些没完成。

      2. Demo 对比AC， 并要求PO或客户给feedback。如果请不到客户可以请公司内部最接近客户的同事参加

      3. 调整 release , 画release burning down chart.

 

       Retrospective Meeting :

      0. 看上次提到的问题有没有改进，如果没有，反思为什么。

      1. Set the Stage --> 开场白，说明会议的目的，流程，时间

      2. Gather date --> 时间线，大家按时间轴写出重要事件或有问题的事件。 心情曲线，大家画出自己心情在sprint中随时间的变化。 从而找出整个team的主要问题

      3. Generate insight -->分析问题的原因

      4. Decide what to do

 

课上大家问题很多，吕老师不厌其烦地讲解，导致课程时间不够用了，回家后看了看讲义，发现有很多内容都来不及讲。但不管怎么说吕老师还是非常nice的一个人。