周六下午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是一个很好的管理框架,是敏捷中相对简单也应用最广,但要用好不容易,需要持续反思改进。