Scrum到底怎么玩儿?——BB-Talk #001回顾

前言
BB-Talk 是什么?
BB-Talk 是由Worktile 特别推出的线上分享活动,聚焦互联网时代更高效的工作流,横跨TMT、电商、律师、教育等各行业,覆盖研发、产品、设计、市场、运营、HR、行政等各职业。
每期邀请一位相关领域的大牛嘉宾,通过微信群内的语音、文字、图片等形式,分享干货、自在交流。
本文为6月14日BB-Talk 第一期嘉宾分享与互动提问的总结。

本期嘉宾

徐子岩,Worktile 首席科学家,软件架构师,连续5届微软MVP,著有《实战Windows Azure》。

内容概要

Scrum 是众多敏捷开发方法中的一种,它既是方法论,也包括了一系列预定义的角色、一系列的流程,以及一系列的实践经验。那么践行Scrum 到底是应该坚持以理论为准绳,还是从实际角度出发,有所舍弃和调整?一个可运行的 Scrum 流程的主要步骤是怎样的?在这个过程中,工具应该扮演什么角色?Worktile 怎样做到了让原本的Scrum 效率提升50%?这些,在徐子岩近一个小时的分享中都有着重提到,帮助大家快速地梳理出了Scrum 的关键性要素。

分享内容

我是Worktile 的徐子岩,Worktile 是为互联网时代的企业打造的协作办公平台,支持企业内部沟通、电话会议、任务管理、日程安排、企业网盘和办公应用,连接企业内外部一切服务。而作为一个效率平台,为用户带来便利是Worktile 最基本的属性,同时作为一个研发型的企业,我们在研发方面有深厚的积累和经验。近期,Worktile 从我们超过30万的使用企业中找到30支研发团队、与之深度沟通,重装打造了从 研发流程管理工作效率评估 的一站式研发解决方案 。其中就包含了我今天要与大家聊的关于“Scrum 到底怎么玩儿”。

####敏捷开发也有价值观?

对于敏捷开发来讲,有人说是流程、是方法论是工具,但对于我来讲它更是一种精神,它并没有局限在流程、方法、工具上。敏捷软件开发的目的就是解决需求中的变化和中的不可控因素。

当时提出敏捷开发的这个人或者这个群体,提出来的是敏捷开发的四个价值观:第一,个体的互动要高于流程和工具;第二,可工作的软件要高于详尽的文档;第三,客户的合作高于合同谈判;第四,响应变化高于遵循计划。这四点价值观是最能体现敏捷开发的核心的东西,其精髓就是拥抱变化,而不是控制变化。

敏捷开发方法有很多种,我们今天主要讲的就是其中的一种:Scrum。

了解Scrum 是什么很重要

首先我们说Scrum 是什么。它既是方法论,也包括了一系列预定义的角色、一系列的流程,以及一系列的实践经验,包括需要的文档。我提出的一个观点是,对于我有用的就做,对于产品、项目没有用的就不做,但是Scrum 实际上不是这样的。你想做到Scrum 有些东西是必须要做的。所以我也希望大家,在聊完Scrum 之后,能够自己批判性,灵活用它,而不是死板用它。

Scrum的主要角色

Scrum 主要定义了三个角色:Scrum Master,Product Owner,Development Team 。

Scrum Master 不是Project Manager, 他的主要的工作是要保证这个团队执行 Scrum 的顺畅。Product Owner 是真正对产品负责的人。如果我们是做产品研发的话,产品经理就是Product Owner。如果我们是做项目开发,客户就是Product Owner,这也体现了我们刚刚提到,我们并不是和客户去谈判,而是真正把客户放在我们的这种流程中,真正与他合作。第三种 Development Team 就是干活儿的。

所以 在Scrum 里面没有管理者的概念 。另外,Scrum 里面实际上所有的真正为最终产出的软件付出的,都叫Development Team。这个地方也体现了一个Scrum 的观点,就是它希望能够打造Cross-Functional Team,即在这个团队中的所有人可以做所有的事情,每个人都是Development Team。

Scrum的开发流程

Step1. 需要一个 Vision

真正Scrum 的流程是什么样子的?首先,我们需要有一个Vision ,就是我们所做的产品或者所做项目的愿景。这个需要所有Team Members,包括Product Owner 一起确定,然后大家朝着同样的目标前进。

Step2. 维护Backlog

Vision 出现后,Product Owner 会维护一个Scrum 中我们提到的第一个文档,即 Backlog。它可以理解成我们从产品当中,从各个角度收集的需求, Product Owner 要做的事情就是维护Product Backlog,并且将Backlog 一条一条的按照优先级排好顺序。Product Owner 是唯一有权利维护这个列表的人。

在Worktile 中,其实就免去了写文档的的这一步,可以直接将需求通过任务的方式收集,每个需求就是一条任务,Product Owner 可以给任务打标签来标示优先级。

Step3. 拆分Sprint

随后我们会针对这个Scrum 把它拆分成一个个的Sprint ,就是开发周期。然后将 Backlog 里面的项目添加到Sprint 中去,成为Sprint Backlog。每一个Sprint 开始的时候,需要进行一个Sprint Plan。

Step4. 运行Sprint Plan

Sprint Plan 就是整个团队一起,通过Backlog 从优先级最高的这个item 开始挑,挑出Product
Owner 对Backlog 进行介绍。紧接着的是,大家将Backlog 拆分成单个的Task,每一个成员在每一天的工作当中领Task,完成Task。

由此可见,在完美的Scrum 里面,是没有任务指派一说的。每个成员会根据任务、完成度,去及时更新任务的状态。为了让大家了解整个项目的进度,Scrum会引入白板(在墙上或者在板子上钉好多的小纸条,让大家明确项目进度和任务完成情况)。

但是现在,因为我们有了Worktile,这个工作不用在白板上做,可以在Worktile 的看板视图上做,这个看板视图非常像真正的白板。通常情况下,在 Scrum 里的白板列表只有三列:TO DO、IN PROGRESS,以及 DOWN。这个在Worktile 里面就十分简单,你可以打标签、分配人、设置截止时间、在任务上进行评论,并且任务可以直接在列表间拖拽,从而推进流程的进展。并且这一切都是实时的,所有人都能看到。

Step5. Daily Scrum

在Scrum run 起来之后,还有一件事情是Daily Scrum 。在 Daily Scrum 中,每个成员只需三件事情:我今天做了什么,明天要做什么,有什么是我搞不定的。Daily Scrum 一般来说会控制在15分钟之内,而且所有的成员必须要站着开会。

在Worktile 里面,工作台就可以对自己的个人任务进行集中的汇总展示,可以清晰的看到自己最近完成的任务以及接下来需要完成的工作。

Step6. Sprint Rview

当Scrum 结束后,我们会产出一个产出物。这个产出物在Scrum 里面,可以是一个可以运行的软件,也可以是一个可展示的功能。之所以这么说是因为有一个Sprint Rview 的阶段,我们需要通过Demo 在Product Owner 以及其他的Stake Holders 面前,现场演示你做好的东西(而不是给大家讲你做了什么)。

Step7. Retrospective

在Sprint Review 结束之后就是Retrospective。我们整个团队的人都要坐下来聊一聊,我们的Sprint 做得好不好,有哪些地方需要修改。

工具的作用

上面是对Scrum 的流程做的概要介绍,我们可以审视其中的一些环节:Backlog  阶段需求的收集和优先级排序、Sprint Plan 阶段任务的拆分、领取和进度跟踪、Daily Scrum 的统计……这些环节其实都需要一些工具的辅助,甚至可以说,整个Scrum 流程都可以通过工具的辅助来更好的运行。

依据Worktile 本身看板管理的特性和任务驱动的方式,可以很好的将一些进度和概要信息展示出来:每个需求可以直接创建一个任务,任务标签可以标示优先级,看板上的列表直接就能展示进度和阶段,也能很好地实现整体进度和个人进度的统计。并且在服务器监控和代码共享等具体的研发问题上,Worktile 也通过接入对应的监控服务和代码托管平台(比如github),得以一站式的解决。通过对比以前的研发进度和使用Worktile 做研发管理之后的迭代速度来看,整体的研发效率提升50%是很容易做到的。

在和一些研发企业做过深入交流并总结我们自己使用Worktile 做研发管理的经验之后,我们整理出了一套使用Worktile 做研发管理的解决方案,涵盖了需求管理、敏捷开发、bug 管理、代码共享、部署运维、研发周报和效率评估。其中贯穿了敏捷的思想和Scrum 的一些精髓,并且根据研发过程中的实际情况,做了针对性的调整,对于希望梳理研发管理体系或者实施Scrum 的团队有着非常好的借鉴意义。

有需要的同学,可以点击了解>>

关于Scrum的个人心得

通过上面的介绍,可以看到通过Scrum 这种方式能够把一个真正大的软件,拆分成小段,每一个成员都对工作非常清楚,所有的数据都是经过大家充分讨论、达成共识的。而且每一个任务,都是成员通过优先级,自己去领的。在Cross-Functional 的工作团队中,每一个人的工作能力、技能都是一样的,任何人领任何的任务,都能达成一致的效果。

但是理想跟现实之间永远是存在差距的,今天我们讲的都是理论状态下的Scrum 的样子。真正执行起来之后,会出现各种各样的问题。你会发现有的时候这个东西是不可能实现的。那么就面临的是说你们这种团队,或者说我们的这种研发团队究竟是死板的去追着Scrum 的原则来做呢?还是说我们自己也敏捷一把,把Scrum 也敏捷掉。

敏捷实际上就是一种理念,然后基于这个理念提供了一些方法和实践,在我眼里它意味着持续改进。所谓持续改进就是在产品设计上的持续改进,包括那我们尽量快速的迭代。我们每一个 Scrum 的Sprint 都不会太长,保证我们的每一个Scrum 都能提供给客户一个可运行的版本,能够快速得到客户的反馈。同时在产品区改进中,架构设计也会持续的改进。我们的设计并不是上了之后就把所有的东西都想好,而是基于我们产品的不断改进,在架构上持续的改进。敏捷本来就是持续改进,改进敏捷的流程,并用敏捷开发的精神改变我们自己的开发流程。

最后,我个人理解的敏捷开发的精髓,就是我们永远只做对产品和项目有用的事情

Q&A

本期最佳提问人:@仕星 中医药大数据(BB-Talk 每期会挑选一位最佳提问人,并给予大礼包奖励!)

1.你们之前做到过Scrum 吗?@小悠

徐大神:开始做会很别扭,等做了四到五个Sprint 之后就会有一种节奏感和默契感。Scrum 对于团队来说重要的是找到节奏感,并且做的好的团队一定不会加班。
(小蜗语录:用了 Worktile 不加班哦)

2.不能演示的Task,如何 Review?@Nemo 前联想PM

徐大神:除了task 还有很多可Review 的东西,比如文档,一定要Review 成果性的东西。

3.产品老觉得我们不愿意做他们的需求,抵制情绪强烈,怎么破?@Rex.M AZT PM

徐大神:很好的例子,把产品拉进Team,因为不同的部门产品、测试、开发都有不同的事情和进度,都不愿意被打乱计划。而Scrum 里没有部门之分,大家都在一个 Develop Team 里面,更透明的方式就能够更好的沟通。
(小蜗语录:用Worktile 协作,更透明,无缝沟通)

4.如何让团队成员更主动去做事,如何在应用项目中推行敏捷开发?有时很艰难,格格不入。@王小🐱 中科软 程序员

徐大神:预设成员都是积极主动能做好工作,这是前提条件,其次要重视管理的艺术,对于成员的保护和激励。有的项目不适合做敏捷开发就不要勉强。可能有的项目更适合使用瀑布式流程,找到项目的对的方式去做也是敏捷的精髓之一。

5.如何让水平高低不同的团队整体提高协作水平,从而提高产品质量?@高杉 CBEC 产品运维

徐大神:确实一开始做的很痛苦,做了几个Sprint 就会好很多,大家看到这种开发模式的好处的时候,在不爽的地方对Sprint 改进,不断演进,让大家喜欢上这件事。让团队成员自己去领自己想要的任务,提倡成员去领感兴趣、想要做、想要挑战的那部分工作,同时让工作更透明化。

6.测试用例有专人负责写吗?@我在睡觉 openrec.tv

徐大神:在之前的项目中有个要求是不允许手动测试,只能自动化测试,有测试去写自动化测试代码。每个人都有分工和专长,在Scrum 里面也会有一定分工。

7.测试人员在敏捷团队中是什么样的角色?如何能更融入?@王晴 开目 开发

徐大神:尽量让测试人员也进入开发,进入自动化测试的范畴内,如果测试愿意,也可以Take 一部分开发的工作,这都是可以的。

8.目前团队还是以职能分工,所以不同部门之间的矛盾和分歧怎么解决?@Rex.M AZT PM

徐大神:推进敏捷开发需要的是管理层的支持,部门间有了分歧需要管理层切实去协调和协助,可以选择把重要的人加进Scrum Team 里,他感同身受的时候也会承受一部分压力,不同部门的 Leader 互相了解对方才能更好地配合。

9.Product item 拆成 Task 的力度如何控制?用Worktile 如何实现比较方便?@仕星 中医药大数据

徐大神:Task 尽量在一天内完成,一个 Product item 必须要在一个 Sprint 内完成,否则搞的太大就失去敏捷开发的意义了。

10.技术团队管理的问题,如何处理团队内任务负荷不均以及由此造成的矛盾和冲突?@凡

徐大神:在任务是被强制指派可能出现这种情况。如果是Scrum ,Cross functional ,至少做到一个模块两三个人都能 Take。而后者,如果有人没法做自己想做的东西可能出现,Scrum 提倡自己去Take 自己想要的任务,一般来说就不会有不满了。

11.任务由开发人员完成后是否需要其他人来审核任务完成度?@我在睡觉 openrec.tv

徐大神:在Scrum 里是没有的,启动之后,整个team组确定 DOD ,怎么判断一个任务算完成了,是整个 Dev Team确定的,做这个功能的人符合要求,就可以他认为完成了这部分工作。而最终能不能Release 出去还是在Sprint Review 时由Product Owner 看 Demo 来决定是不是可以Release,如果不可以,需要再新开一个Work item,重新改模块。

预告

W&Workshop No.6—企业效率革命之研发管理专场即将于本月底26号在北京举办,凭借Worktile 提供的优惠码可以免费报名参加。对Scrum 感兴趣或者想和徐大神面基的同学,一定不要错过>>

Worktile2018年已上线最新的7.0版本,完美匹配整个敏捷开发流程,详细内容可参考:

Worktile 敏捷开发解决方案
Worktile 首席架构师详解:如何让敏捷更好地落地?