认证Scrum Master培训笔记（二）

       第二天培训之前，黄老师发给每个小组一套卡片，里面是一些Scrum的概念判断，快速进行辨别，分成三种情况（正确、错误、不确定）摆放，统计结果。

       介绍了一个实操，BDD（Behavior Driver Development）与ATDD（Acceptance Test Driver Development），讲述了某企业的双十一全链路压力测试。

 

分享了三个观点：

1. 质量是不可以妥协的
2. 质量是团队负责制，测试也不只是测试人员的工作，开发人员也要做测试的工作
3. 测试不再是开发后的一个阶段

 

接下来，介绍3个工件，Product Backlog, Sprint Backlog, Increment。

 

Product Backlog

       重点强调了PB的内容由PO来制定，PB在迭代计划之前就应该被评估。PB粒度可粗可细，但是优先级高的，需要尽快实现的，需要细化明晰，方便团队进行refinement。

 

老师介绍了一个实操，用户故事的一般写法，从客户的角度来对业务需求进行描述。

 

老师接下来介绍了DoR（definition of Ready），通过大家的讨论，明细了一些需求准备好的标准。

随后还介绍了DoD（definition of done），通过该内容的讲解和讨论，明细了产品做完的标准，更加明晰了客户故事测试与开发单元测试的联系，以及测试在Scrum中的变化。

 

老师反复强调，作为一个有廉耻心的团队，质量是不可以妥协的。

 

接下来，介绍了Sprint Backlog的知识。

 

老师强调SBI是开发团队的资产，可以增加，更改，和删除。比如可以增加一些技术债的SBI。

 

老师给每个小组准备了现场的看板，Product Backlog, Sprint Backlog( to do)，Sprint Backlog( doing)，Sprint Backlog( Done)。

老师介绍了一款看板工具Leangoo（Scrum中文网开发）。

 

下面是介绍Increment，强调了2点：

1. 一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和
2. 新的增量必须可用并且达到了 Scrum 团队“完成”的定义的标准

 

产生燃尽图，建议以PB的Story Points来进行统计，而不是用工时。可以统计功能交付率，最好不要统计迭代失效率（容易产生打击团队积极性的效果）。

 

    老师还分享了一个众筹项目（USB电池）由创意到生产出产品，以及后续不断改进的过程。

 

    紧接着，介绍五大事件。

     Sprint

 

代周期1-4周，越成熟的团队迭代周期越短，但强调迭代周期最好不要临时更改（比如二周改成一周，或者有的迭代延长2天时间），以便产生稳定的团队产出率。

   

团队成员拖PB时，完成一个PBI后才能认领下一个PBI。为了不要形成小瀑布，建议结对进行PB认领，开发也参与测试。

Sprint Planning

前半程主要是弄清楚做什么，了解需求，承诺能做多少PB，后半程主要是弄清楚怎么做，分解SB，评估工作量（团队成熟后，也可以不用评估）。

 

Daily Scrum

 

尽量站着开会，建议加一个问题，每个人觉得这个Sprint 是否能完成计划的目标。

强调管理层在会上不要发言。

 

Sprint Review Meeting

 

1. 在 Sprint 快结束时举行
2. Scrum 团队和利益相关者协同讨论在这次 Sprint 中所完成的工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作
3. 演示的可工作软件，不是PPT

 

Sprint Retrospective Meeting

 

 

1. 在 Sprint 快结束时举行
2. Scrum团队成员一起回顾这个Sprint, 不要管理层参与
3. 可以有一些度量的数据，促进改进，要有行动
4. 从三个方面入手：

Product Backlog Refinement

 

1. 由PO驱动
2. 在Sprint期间持续进行
3. 这个Sprint期间Refinement下一个Sprint的PBI
4. 分解或合并PB
5. 评估PB的Points

 

 Values

   

1. 勇气
2. 开放
3. 专注
4. 承诺
5. 尊重

 

 

最后大家一起来回顾了3355，做成一张可视化的图像。

 

中餐……

 

黄老师又一次发判断卡片，根据培训内容，重新排放在（正确、错误、不确定），然后老师对有异议的卡片进行了讲解。

 

Estimation & Estimation

 

老师拿出了一个玻璃水杯，让大家评估里面的水大概是多少，大家的答案从30ml到120ml。然后在拿出一个玻璃水杯，里面转了少许水，让大家重新评估，第一个水杯是第二个水杯的几倍，这次大家的答案从1.2倍到1.8倍。

然后去比较这两次的误差，发现，相对值估算更准确。

 

实操练习：

利用乐高玩具，评估几种动物的拼装工作量。

 

第一轮：

先凭借直观感受评估，评估故事点。

 

第二轮：

先确定一个参照物，然后再评估其他动物的工作量。

 

老师介绍了一种评估方法：

Item	体量	需求复杂度	技术难度	权重=体量*需求*技术	Story Points
1	2	2	1	4	1（参照物）
2	3	3	4	36	9
3	2	3	2	12	3
4	2	3	5	30	8

 

接着介绍了T-Shirt Size Estimation

 

通过团队进行Scrum实践，持续不断改进，产生稳定的Velocity

通过统计多个Sprint历史数据，计算出团队产出率

 

 

利用PB估算和产出率，得出Release Planning

 

最后做了一个敏捷项目的练习，每个小组想一个创意，做一个手机APP。

通过几个Sprint的演练，最终每组去演示功能，PO说明商业前景及盈利模式，其他小组模拟成投资人表决给那个小组进行投资。

 

先确定三个角色，PO，Scrum Master，以及开发团队。

 

第一个Sprint，大家都比较匆忙，技能也生疏，规划不清晰，没有对工序进行并行，没有掌握好节奏，分工及结对都没有组织，比较混乱，也没有产生可以工作的产品。

站会大家都觉得完不成Sprint目标。

通过短暂的回顾会，及时调整和改进流程，工序并行，按照优先序。

 

第二个Sprint，大家沉稳了一些，根据我们的生成效率，重新进行了规划，最终有了一些可以演示的成果。

通过短暂的回顾会，有的小组提出了结对开发，效率大大提升，进一步确认了完成的标准。

 

第三个Sprint，大家基本达成了Sprint的目标

 

发布最终产品，团队成员演示了可以工作的成果，PO也上台阐明了系统价值和盈利模式。

大家作为投资人在下面也给团队提成了问题，给了一些建议，最终投出了自己手上的资金，通过统计总资金数，第一小组的生态农家项目获得了冠军。

模拟项目完成后，老师有分享了一些干货。

 

管理3.0的演变过程，分享了一些管理上的实践，推荐了几本书《驱动力》，《代码整洁之道》，《Managing for Happiness》。

自此，培训圆满结束。

特别感谢Scrum中文网提供的图片，黄方老师提供的PPT。