码迷,mamicode.com
首页 > 其他好文 > 详细

Scrum到底怎么玩儿?

时间:2016-06-24 15:51:16      阅读:236      评论:0      收藏:0      [点我收藏+]

标签:

技术分享

前言
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

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,重新改模块。

Scrum到底怎么玩儿?

标签:

原文地址:http://blog.csdn.net/u013695026/article/details/51729095

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!