170826 Scrum培训笔记

周六下午1：30-5：30听了廖靖斌（Eric Liao）老师关于Scrum以及如何用Leangoo做敏捷管理的培训，收获不错，整理笔记如下：

敏捷的三大要义

1. 价值驱动

项目最大的浪费是什么？ 最大的浪费不是沟通成本，不是花了很多时间讨论需求，不是项目进行的效率低，而是交付后80%的功能都无人使用。所以要价值驱动，要事第一，做对客户最有价值的功能。

黄金圈法则 - Start with why

Why, What, How三者， Why最重要。要从Why出发，产品的理念和目标是最吸引用户的。

[TED]Simon Sinek: How great leaders inspire action

价值驱动 vs. 计划驱动

计划驱动旨在完成任务，价值驱动旨在解决问题

2. 适应变化

需求是涌现式的，会突然的大量出现。

客户的需求会不断变化，很多时候客户起初也不是很明确自己的需要，所以变化在所难免。

所以如何主动适应变化呢，敏捷中有3个做法：

• 以sprint为单位，持续迭代。一个sprint（小时间盒子）一般建议1-2周。

• 迭代开发，持续集成。

  
  
  

  增量开发
  
  
  

  迭代开发
  
  

  老师的PPT里的梦娜丽莎第一幅图的时候手是在腮边的，更能说明问题。以增量开发的模式，只有在最后全部完成的时候，才得到客户反馈说手的位置错了，这就需要大量返工。而以迭代开发的模式，第一幅线框图就可以获得反馈，这时只要少量修改，而不会浪费之后上色之类的工作。

  关于持续集成的好处，可以看看这篇博客：大话持续集成

• 保持透明，持续改进。在迭代开发的基础上，要让每个小成果都透明，及时获取反馈，以便及时调整。

这里有一个案例：敏捷设计-主动设计而又是涌现式的设计

3. 自组织团队

自组织团队的特征：目标驱动，共享责任。

传统团队	自组织团队
指令驱动	目标驱动
契约模式	共享责任

在敏捷开发中，团队一般以5-9人为宜。Amazon有个量化标准是两个匹萨要够吃（这时参加培训的同学纷纷问几寸的pizza...) 。团队是自管理，包含跨团队成员。

关于Scrum的收获

公司试行scrum也有半年左右的时间了，我担任了两个产品小组的scrum master，听了这次的培训，发现我们还有很多可以改进的地方。

• Eric老师要估算需求（user story）的工作量，而非每个任务的工作量。只有完成了某个需求，交付了可工作的版本，才算完成了一个工作单位，才能体现在燃尽图上，完成某个需求里的一部分任务不算。
• 不建议在sprint开始就把任务包人到户，可以每天站会大家领取任务，这样可以避免分配不均的情况，可以促进团队成员共享责任。
• 站会的时候最好不要按人次汇报进度，按user story汇报进度更有团队合作感。（这个可以试一下。站会的氛围还有待改进。）
• Sprint的时间和团队成员应该相对稳定。Sprint的时间一般为一周或两周。时间单位和成员稳定，团队的每周完成的故事点数才对之后的项目有参考价值。
• Scrum master目标是培养好的团队，激励团队成员，帮助团队排除障碍，建立好的工作流程。

Scrum是一个很好的管理框架，是敏捷中相对简单也应用最广，但要用好不容易，需要持续反思改进。