ScrumWorks,让Scrum更敏捷

曲折的选择之路

    在开始实施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)。