Worktile 首席架构师详解:如何让敏捷更好地落地?

Worktile
Worktile 2018-08-17 15:01 0 643

徐子岩: Worktile首席架构师,前微软高级项目经理、微软MVP,《实战Windows Azure》一书作者,十五年软件开发经历,包括企业级软件的架构设计、开发和测试等。项目管理及敏捷开发经验非常丰富。

d866e48a-5968-4ba4-8d48-1b90c5c06547.jpg

以下是部分演讲内容,主要围绕敏捷开发、Scrum以及我们是怎么做的展开。

敏捷开发

首先大家要明白的是,敏捷开发不是具体的指导性方法,它是一种观点和价值观,敏捷开发提供了一种思维方法,但真正的敏捷开发并不告诉大家怎么做。

敏捷开发的精髓是响应变化,不去控制变化,而以往的项目管理是要控制变化,以实现整个开发周期是可控的。敏捷开发产生以前,由于软件开发和传统行业天然的有着鸿沟,几乎用尽了以往所有的经验办法,都没法做到详实的很精确的控制。有人便提出了,既然不能控制变化,何不去响应这种变化,敏捷宣言也由此产生。

微信图片_20180816113525.png

敏捷宣言推崇合作、变化,并不推崇计划、谈判和条条框框的东西。

因为敏捷开发实际上只是个概念,而怎么落实这个概念呢,怎么转变成敏捷团队呢,就需要运用敏捷的各种方法论和实践。敏捷的方法论有很多,例如,源于丰田公司的精益软件开发,新兴测试方式-探索性测试,测试驱动开发等。我们今天重点要讲的是Scrum,也是敏捷很重要的一个方法论。

微信图片_20180816135744.png

什么是Scrum?

Scrum是敏捷软件开发的方法学,它包括了一系列实践和预定义角色的过程骨架 ,Scrum真正定义了要达成敏捷的流程和方法。简单来说,你想要成为Scrum团队,你都需要什么样的角色、做什么样的事、开什么样的会……只要按照Scrum的方法论去做,你就能变成Scrum团队,也就是敏捷团队。

总的来说,敏捷提供了一种思维,一种很美好的未来,而Scrum则让敏捷更好地落地。

微信图片_20180816135751.png

Scrum团队一般有三种角色: Product Owner、Scrum Master、 Development Team 。

标准的Scrum运行流程是,Product Owner基于Vision,创建多个Product Backblog,即为达成Vision所要完成的各种功能需求,然后Product Backblog会被拆分成一个个Sprint,真正的Scrum是在一个个Sprint周期之内,不断地完善产品。

微信图片_20180816135756.png

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完成后,会进入到Scrum Review,每个成员用Demo演示自己负责的Backblog,让Product Owner评估是否完成。

敏捷开发遵循了一个原则,所有最终完成的东西对客户都要是有意义的。 在Scrum里面,每个Sprint做完了的Backblog,都是能让用户完整使用的功能。对于开发人员来讲,用Demo的方式去展示成果展示,他会非常重视质量。

所有这些结束后,还会有一个 复盘会 ,整个团队沟通上个Sprint执行中的问题和改进点,这就是一个完整的Sprint的流程。

我们是怎么做的?

在Scrum流程中,总会遇到各式各样的问题,有些是团队的问题,有些是成员的问题,接下来我会讲我所在的团队是怎么执行Scrum的。

1、原则
对产品有用的就做 ,或对客户(用户) 有用的就做,其他的都不做。 这也是评估有些事情做与不做唯一的标准。

微信图片_20180816135759.png

2、角色
整个Scrum团队的角色划分,Product Owner一般是产品经理或产品总监,有的时候也可能是客户,很少是Dev Manager、公司高管。Scrum Master 一般是开发团队中一人兼职,也可能是公司成立的Scrum Master团队,具体的工作包括组织各类会议和把控会议高效进行,确保团队按照Scrum的标准在执行。然后是Dev Team ,不止是开发,也可能包括测试、运维、架构、设计等,所有最终给客户产出的人都是Dev Team的一员。

微信图片_20180816135803.png

这只是一个参考,敏捷的精髓是响应各类变化,发现不合适的时候也可以改掉。

我们团队在Worktile里面,对于各类角色,会有权限划分,比方说研发工程师的角色不能创建需求、产品经理的角色不能创建任务等等。当然,有的团队对权限划分非常细,有的团队会比较OPEN。而在Worktile7.0里面,是可以基于自己的团队风格、氛围去配置的。

微信图片_20180816135807.png

微信图片_20180816135812.png

3、周期
Scrum周期这块,内部发布的周期我们一般是两周,也建议团队刚开始敏捷的时候,可以用两周一个Sprint,再根据节假日调整成3周。在版本发布之前,可能有的团队需要一段时间集中测试(回归测试、压力测试等)。通过Release Sprint应对,做测试、改Bug等。

微信图片_20180816135815.png

下图为Worktile内部的Sprint,右侧的Product Backblog可直接拉到左侧的迭代需求里,未安排的BUG也可拉到当前迭代缺陷里,做Sprint规划。

微信图片_20180816135819.png

微信图片_20180816135822.png

4、规模-Effort
至于Scrum里说到的规模-Effort,即某个工作的复杂度。标准的Scrum里,在第一个Sprint中,估算一个功能点的工作量,多轮的Sprint后,团队会慢慢的达成一个共识。但是大部分团队可能无法按此执行。我们团队Effort的定义,这里不是一个指导意见,只是一个实践,是团队普通能力工程师1天的工作量 。Effort最大值是32,Work Item经过多个Sprint都无法完成,导致这些Sprint都是失败的,这会让Scrum很难继续推进。

微信图片_20180816135826.png

微信图片_20180816135830.png

5、Scrum会议

Scrum有哪些会议?

微信图片_20180816135835.png

微信图片_20180816135840.png

微信图片_20180816135846.png

微信图片_20180816135852.png

微信图片_20180816135856.png

会议遵循的一些规则:

微信图片_20180816135901.png

下图为Worktile内部每周的Scrum会议:

微信图片_20180816135907.png

总结一下,“ 敏捷其实是一个观点,不是我们去控制变化,而是我们去顺应变化。敏捷不会告诉我们怎么做,具体怎么做是Scrum要做的事情,包含持续的进行改进。同时,'敏捷'自己也要敏捷起来,觉得用得对的地方要持续去使用,觉得不对的地方需要调整,并执行一次让团队评估有没有效果。最后一点,永远只做有用的东西,对客户有用、对产品有用、对团队有用的东西!

Worktle 免费了

评 论