Worktile 首席架构师详解:如何让Scrum更好地落地?
作者/徐子岩, Worktile & PingCode首席架构师,前微软高级项目经理、微软MVP,《实战Windows Azure》一书作者,十五年软件开发经历,包括企业级软件的架构设计、开发和测试等。
什么是敏捷开发?
首先大家要明白的是,敏捷开发不是具体的指导性方法, 它是一种观点和价值观 ,敏捷开发提供了一种思维方法,但真正的敏捷开发并不告诉大家怎么做。
敏捷开发的精髓是 响应变化,不去控制变化 ,而以往的项目管理是要控制变化,以实现整个开发周期是可控的。敏捷开发产生以前,由于软件开发和传统行业天然的有着鸿沟,几乎用尽了以往所有的经验办法,都没法做到详实的很精确的控制。有人便提出了,既然不能控制变化,何不去响应这种变化,敏捷宣言也由此产生。
敏捷宣言推崇合作、变化 ,并不推崇计划、谈判和条条框框的东西。
因为敏捷开发实际上只是个概念,而怎么落实这个概念呢,怎么转变成敏捷团队呢,就需要运用敏捷的各种方法论和实践。
敏捷的方法论有很多,例如,源于丰田公司的精益软件开发,新兴测试方式-探索性测试,测试驱动开发等。我们今天重点要讲的是Scrum,也是敏捷很重要的一个方法论。
什么是Scrum?
Scrum是敏捷软件开发的方法学,它包括了一系列实践和预定义角色的过程骨架 ,Scrum真正定义了要达成敏捷的流程和方法。
简单来说,你想要成为Scrum团队,你都需要什么样的角色、做什么样的事、开什么样的会……只要按照Scrum的方法论去做,你就能变成Scrum团队,也就是敏捷团队。
Scrum团队一般有三种角色: Product Owner、Scrum Master、 Development Team 。
标准的Scrum运行流程是,Product Owner基于Vision,创建多个Product Backblog,即为达成Vision所要完成的各种功能需求,然后Product Backblog会被拆分成一个个Sprint,真正的Scrum是在一个个Sprint周期之内,不断地完善产品。
Scrum开始的时候,会有一个 Sprint Planning 会议,Product Owner、Scrum Master和 Dev Team 会一起计划Sprint要做什么,Product Owner会基于Product Backblog的优先级,筛选出最应该做的Backblog,然后让成员给Backblog打分,并在达成共识后决定某个Backblog的规模。
打完分以后,Product Owner拿次一级的Backblog续打分,直到Scrum成员认为该Sprint周期只能做这些功能为止。并在Sprint Planing会议上,确定所有的Sprint内容。
接着就开始 Sprint周期 ,一般是1到4周,由团队成员去设计、编码、测试等。成员每天会执行Daily Scrum会议,说明三件事: 今天干了什么、明天要干什么、有什么困难 。
1到4周的Sprint完成后,会进入到 Sprint Review ,每个成员用Demo演示自己负责的Backblog,让Product Owner评估是否完成。
敏捷开发遵循了一个原则,所有最终完成的东西对客户都要是有意义的。 在Scrum里面,每个Sprint做完了的Backblog,都是能让用户完整使用的功能。对于开发人员来讲,用Demo的方式去展示成果展示,他会非常重视质量。
所有这些结束后,还会有一个 复盘会 ,整个团队沟通上个Sprint执行中的问题和改进点,这就是一个完整的Sprint的流程。
我们是怎么做的?
在Scrum流程中,总会遇到各式各样的问题,有些是团队的问题,有些是成员的问题,接下来我会讲我所在的团队是怎么执行Scrum的。
1、原则
对产品有用的就做 ,或对客户(用户) 有用的就做,其他的都不做。 这也是评估有些事情做与不做唯一的标准。
2、角色
整个Scrum团队的角色划分,Product Owner一般是产品经理或产品总监,有的时候也可能是客户,很少是Dev Manager、公司高管。
Scrum Master 一般是开发团队中一人兼职,也可能是公司成立的Scrum Master团队,具体的工作包括组织各类会议和把控会议高效进行,确保团队按照Scrum的标准在执行。
然后是Dev Team ,不止是开发,也可能包括测试、运维、架构、设计等,所有最终给客户产出的人都是Dev Team的一员。可参考文章:《scrum团队内部的角色与分工》
这只是一个参考, 敏捷的精髓是响应各类变化,发现不合适的时候也可以改掉 。
我们团队在Worktile里面,对于各类角色,会有 权限划分 ,比方说研发工程师的角色不能创建需求、产品经理的角色不能创建任务等等。
当然,有的团队对权限划分非常细,有的团队会比较OPEN。而在我们的研发管理工具PingCode里面,是可以基于自己的团队风格、氛围去配置的。
3、周期
Scrum周期这块,内部发布的周期我们一般是两周,也建议团队刚开始敏捷的时候,可以用两周一个Sprint,再根据节假日调整成3周。在版本发布之前,可能有的团队需要一段时间集中测试(回归测试、压力测试等)。通过Release Sprint应对,做测试、改Bug等。
下图为我们内部的Sprint,右侧的Product Backblog可直接拉到左侧的迭代需求里,未安排的BUG也可拉到当前迭代缺陷里,做Sprint规划。
关于如何更好地开Scrum会议,可以参考文章:《Worktile带你学敏捷:如何更好地执行Scrum会议?》
会议遵循的一些规则:
总结一下, 敏捷其实是一个观点,不是我们去控制变化,而是我们去顺应变化 。敏捷不会告诉我们怎么做,具体怎么做是Scrum要做的事情,包含持续的进行改进。
同时敏捷自己也要敏捷起来,觉得用得对的地方要持续去使用,觉得不对的地方需要调整,并执行一次让团队评估有没有效果。最后一点, 永远只做有用的东西,对客户有用、对产品有用、对团队有用的东西!