ScrumWorks,让Scrum更敏捷
 

2010-07-19 作者:王立杰 来源:ITPUB

 

曲折的选择之路

在开始实施Scrum之前,除了需要对所有涉及到的人进行培训之外,另外一项重要工作就是选择一个适合自己的Scrum工具。很多关于敏捷的论文或教科书都提到了白板和Excel电子表格。但白板与Excel电子表格明显不能满足一个注重过程资产的软件项目的要求。白板虽然适合每天的跟踪汇报,但是对Product Backlog支持明显不够,也没办法保留历史纪录。Excel虽然有很多现成的模板可以用,但当是团队成员比较多时,同时修改一个共享Excel文件,会相互冲突,不好同步。

我们最初使用的是一个叫ScrumWiki的免费/开源工具。因为之前大家一直把Wiki当作知识共享工具,每个人都很熟悉Wiki的机制与语法,采用采用wiki这种共享创作模式的Scrum小工具,可以让大家随意编辑,更新任务状态,非常适合我们当时的分布式开发。但随着Product Backlog变得越来越大,变化越来越频繁的时候,ScrumWiki明显不能满足我们的需求。特别需要指出的是,作为免费开源的软件,因为已经没有人支持和维护,系统存在一些Bug只能靠自己修正,花在维护和添加新功能到这个免费工具上的时间越来越多,已经是"买椟还珠",大家决定放弃这个工具。

几经周折,最终选定了ScrumWorks Basic作为我们实施Scrum的工具。为什么选择ScrumWorks Basic, 而不是其它如XPlanner、Version One、Mingle、Rally等工具呢?首先,这是一个商业化产品,一直有人持续开发与维护,大家不想重蹈ScrumWiki无人维护的覆辙;其次,有免费使用版,且无时间限制,如果需要,我们可以随时无缝切换到商业版ScrumWorks Pro;第三,根据当时的一个调查,业界使用率排名第三位,说明有足够的用户基础。第四,这个工具是专门为Scrum量身定做的,简洁直接,不像Version One、Mingle等工具因为需要考虑其它敏捷软件开发模式,而搞得过于庞大复杂。第五,从功能上讲,个人认为这个是对Scrum各个方面支持最好的商业产品。

一年下来,事实证明我们当初对ScrumWorks Basic的选择是非常正确的,它不仅容易安装、使用方便,还让我们的Scrum实践更加敏捷。

CS/BS两种访问模式,轻松满足Scrum项目管理需要

ScrumWorks Basic既提供了简单的web客户端,还提供了强大的java客户端,可以满足不同的使用需要。

桌面客户端需要在访问的机器上安装Java运行环境,允许用户操作所有的Scrum数据,譬如添加、修改、删除、移动Backlog条目,从Excel中导入或导出数据到Execl,后台数据备份,阻碍(Impediment)管理等。


通过ScrumWorks Basic创建或者打开一个产品后,通过桌面客户端登陆,即可以看到如上所示窗口。右侧是Product Backlog,可以通过"Releases"方式为Product Item组织分类,这点对于我们做了10多年的产品非常重要,因为产品Backlog需要分成多个发布版本来管理。左侧是以时间排序的Sprint列表以及对应的Sprint Backlog,可以根据需要,随时隐藏其中一侧。由于采用了"相对优先级"的概念,通过拖曳的方式就可以非常简单的设定优先级先后顺序(优先级高的在上面,低的在下面)。从"Product Backlog"到"Sprint Backlog"的过渡非常简单,只需要选定一组最高优先级的Backlog 条目,直接拖过去或拖回来即可,大大提高了我们开Sprint计划会议的效率。

左上角的分栏可以告诉我们正在工作在哪个产品上,因为我们一个团队就要负责三个产品,这点对多个产品的支持对我们也非常重要。

Web客户端(如下图所示)提供了一个轻量级的基于浏览器的访问方式,可以从任何一台装有Web浏览器的设备上访问。它提供了一个非常个性化的总结性的Web页面,不仅有Sprint 的Burndown Chart,还单独区分"用户自己的任务"、"全部任务"及"所有阻塞(Impediments)", 方便单个用户更新任务状态、剩余工作量,添加备注,查看阻碍(Impediment)等。

简单高效的Sprint管理

ScrumWorks Basic提供了一个单独的Sprint管理接口,让我们的每个Sprint都变得有条不紊。

每次新开一个Sprint时,会有一个单独的对话框,只需要输入起止时间、Sprint名称、Sprint目标,以及选择对应的Scrum 团队即可。在Scrum开发模式下,为每个Sprint起一个名字,不但可以增加团队软件开发的乐趣,提高大家的参与程度,还可以记录下Scrum Team当时的心情,这点非常重要,而ScrumWorks Basic正好提供了这个接口。列举我们的几个Sprint名称,创意来自于《加里森敢死队》:

· Sprint1--兵不厌诈(the Big Con)

因为大家第一次采用Scrum, 对这个Agile流程都很期待,同时呢,对于怎么做,如何用,还很模糊

· Sprint2--越狱记(Breakout)

经过了第一个Sprint后,大家干劲十足,士气高涨,认为我们可以在第二个Sprint取得重大突破(breakout)

· Sprint3--虎口余生(Hours to doom day)

这个Sprint里面有很多技术难点需要破解,如果解决不了,那么后面的工作就无法进行,将是非常关键的一次攻坚战。

· Sprint4--大结局(The Big End)

这次计划会议,作为Scrum Master,自己因为有事没有参加,汗!但大家认为工作基本差不多可以做完了,起了个结局的名字。

每天开站立例会时,可以把如下图所示的Sprint明细窗口用投影仪直接投放到墙上。让大家可以看到Sprint目标、Burndown Chart、Sprint Backlog 条目的状态及剩余时间等,提高沟通的效率和紧迫感。

如果遇到阻碍(Impediments),可以通过如下接口及时添加并更新进展。

通过"主题"分类管理Backlog

ScrumWorks Basic提供的"主题"功能可以更方便的组织和管理product backlog条目。"主题"就象关键字或者标签,可以分别应用到每个Product Backlog条目,从而实现Product Backlog条目的分组管理,这种方式比"文件夹"更有效,因为同一个条目按照自己的需要,可以施加一个或多个主题。 这样就可以轻松的按照指定的"主题"对backlog进行过滤,迅速找到你关心的条目。这种管理方式,对一个庞大的Product Backlog是非常有效率的。

对主题的分类,没有任何限制。可以按照需求列表划分,也可以按照功能列表花粉,或者你想到的任何其它分类模式。

我们把主题用到需求变更管理上后,获得了非常好的效果。把每一个需求,定义成一个主题。当某项需求变更的时候,我们通过该主题进行过滤,可以迅速找到可能受到影响的Backlog条目,分析影响的大小,再对回归测试计划进行相应调整,可以保证产品功能的完整性不受干扰。

多种报表

Scrum象其它敏捷软件开发方法一样,依靠的是经验管理,ScrumWorks Basic提供的多种报表与衡量机制,为经验管理提供了超强的支持。

Product Burndown Chart--从更高的角度展示当前Product的完成状况。

Enhanced Product Burndown Chart--通过区分由于添加或者删除Backlog条目引起的变化,可以更准确地预测出产品可能的完成日期。

Dashboard Report--通过一种简洁的方式,将一个或多个产品的状态集成在一起,并以颜色分别标示是否延迟、是否正常,让高层管理团队对所有实施Scrum的项目进展状况一目了然。

Sprint Change Report--详细勾勒出Sprint中任务添加/删除/重新估算对整个产品backlog的影响。

其它亮点

ScrumWorks Basic除了提供多用户机制外,还提供了虚拟团队管理模式,一个用户可以加入不同的团队,这样可以让我们成功实现以下项目管理模式:

· 单个团队工作于单个项目

· 单个团队同时工作于单个产品的多个版本

· 单个团队工作与多个项目

· 多个团队工作于单个项目

· 多个团队工作与多个项目

此外,ScrumWorks Basic还提供了支持SOAP协议的API接口, 可以订制add-ons、报表,或跟其它应用程序集成。

缺失与遗憾

以上介绍都是基于ScrumWorks Basic这个免费版本的,同ScrumWorks Pro这个收费的商业版本相比,缺乏如下重要特性:

· 缺乏对Bugzilla和Jira的集成

ScrumWorks Pro与Bugzilla和Jira的集成,体现在它可以导入两者中的条目作为backlog条目,并且可以像对其他backlog条目一样,对这些条目进行操作。可以使用搜索来选择感兴趣的条目,并进行单独或多项导入操作。

· 没有带有主题过滤功能的burndown图表,及其他辅助了解项目状况和走势的功能

ScrumWorks Pro中,将backlog按照主题进行组织后(类似于web 2.0中使用标签),可以高亮或是过滤这些backlog,并且能够使用同样的主题针对burndown图进行过滤,这点对定量分析还是非常有用的。

· 不能添加附件

对于Backlog条目而言,如果能添加需求、设计等文档或其它文件,将是很有用的。

· 邮件自动通知

· 跨团队、跨产品、跨项目的"我的任务"视图

· Sprint日历订制,主动剔出周末或者其它假期的干扰,生成真正的Burndown Chart 如果不想忍受这些缺失与遗憾,而且资金充裕的情况下,可以选择ScrumWorks Pro。

更多敏捷实践总结,可以参考笔者的敏捷软件开发随笔(http://scrumxp.blogspot.com)。



由外而内看敏捷软件开发
架敏捷开发中史诗故事与用户
看板任务管理
面向全球化的有效敏捷交付
小型团队快速开发方法
DevOps,不是一个传说!
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行


某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...   
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号