【IT168 技术文章】

    曲折的选择之路

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