Visual Studio ALM下一版本中的敏捷项目管理

[原文发表地址] Agile Project Management in Visual Studio ALM V.Next

[原文发表时间] 14 Jun 2011 3:52 PM

我们最初开始设计Team Foundation Server时的一句箴言是：“你的流程，我们的流程或没有流程。”我们这句话的意思是TFS可以在开发流程自动化中扮演很重要的角色。很多团队已经建立了很好的流程，没有什么特别兴趣改变它。不管您的流程是什么，您都可以配置TFS来与其相适应。 很多团队没有建立好的流程，想要采用一些“最佳实践”并改进它们——TFS也能实现，现在我们有三个流程模板（敏捷、Scrum和CMMI）供你们采用。还有一些团队没有好的架构，对“P-word”深感怀疑。他们仅仅需要一些好的工具来帮助完成工作，TFS也能帮助他们实现那个需求。

与TFS的演化对应的， 软件开发流程的世界也成熟了许多。当今放在流程上的精力与围绕流程的讨论比十年前多了很多——还有一些成名的“后起之秀”。显然， 现在开发实践的敏捷家族已经牢固地建立起来了。在早期被极力吹捧的敏捷实践中，有些(比如结对编程)已经灰飞烟灭，有些(比如单元测试)则成为了桌面筹码，几乎获得了所有高效率团队的采纳。

我们在2005，2008，和2010版本中做了一些工作。比如2005中的单元测试、2008的连续整合、2010中的敏捷工作薄、Scrum模板等等。它们让团队通过使用TFS自动化各自的敏捷实践。但是，我们不赞成构建非常一致的体验，因为我们有点太坚持流程独立(请记住——你们的流程、我们的流程亦或没有流程)。

我们开始计划Visual Studio的下一个版本，很显然敏捷开发已经成为主流（我有调查数据显示35%的团队在使用“敏捷”）。新的流程层出不穷——Lean仍然后劲十足。 而且，事实上，我看到很多人都在试图将Lean和敏捷结合起来。随着定义良好的流程/实践集合的越来越多应用，我们决定是时候让TFS为这些实践提供更多的优化体验了。我们仍然坚持你的流程、我们的流程亦或没有流程，但是现在我们将为构建良好的实践优化提供工具支持。

我们选择专攻的领域之一是基于Scrum的工具开发。我的调查数据显示实践敏捷的团队中，84%的团队涉及到Scrum。这表明Scrum是被采用最多的实践。下面的表格显示敏捷团队所采用的方法：

具有讽刺意味的是，在讨论这个的同时，我们也决定为了提升我们自己的功能团队级别而采用Scrum。我们采用比微软实践更多来提高组织效率。这种事情非常偶然，因为它给了我们很好的机会来内部试用那些工具，保证我们在创建一些用户真正喜欢的东西。

很早之前我们决定将敏捷项目开发工具主要关注在基于站点的经验上。 基于浏览器的解决方案可以供团队所有人分享经验。同时，我们感觉将这些工具直接植入Visual Studio和Eclipse的开发环境也是非常重要的。

我们将基本Scrum项目管理周期细分成三个最高优先级的活动。

l Backlog 管理 – 收集列表用户诉求（需求）并将他们设定优先级。Backlog是Scrum中的中心理论之一。

l Sprint 计划 – 根据预计成本(诉求要点)和团队的容量(速度)选择一组在sprint中需要实施的用户。

l 每日站会 – 回顾最新完成的工作、遇到障碍的正在进行的工作和新开始的工作。

我们还考虑到一些别的事情（比如回顾等等），但是在与很多用户和Scrum专家讨论之后，断定以上列出的三个是新的工具能够帮助用户最多的关键地方，别的问题都能通过已有的工具解决。

我们希望针对以上的每个体验创建一个极其容易使用而且又低成本的解决方案——像我期望方式工作但是又不会挡我的路。 我们还认识到如果我们将这么依赖站点经验，就需要去做一些重要的准备工作。 我们希望更新全局外观和感觉——我们使用了Zune/Windows Phone的“Metro”风格。 我们还需要真正研究性能。在2010中，为了与用户之间的交互，站点访问严重依赖于服务器的往返通信。 我们想要有这样的体验：不但通过Java Script来保持大部分主要本地进程，而且还要使需要服务器往返通信的地方(比如保存工作项)保持异步。

随着我们自己开始使用Scrum并设计我们自己的Scrum解决方案，即将引入“团队”的概念的需求很快凸现出来。我们每个功能团队有自己的backlogs， sprints等等。我们需要一种方法来识别团队，易于选择它们，定义它们的属性，生成它们的报告等等。这样，在V.Next中，团队演化成了Web UI的核心元素之一。 您选择所属的项目和团队，然后UI上的大量数据就开始筛选，只向你显示和你相关的那些。

Product Backlog

在Scrum中，Product backlog是那种“唯一真相”。它是项目中所有工作的列表。 那些工作显示为用户诉求。您可以将用户诉求想象为需求。 有些团队将他们的用户诉求形容为“作为<某种类型用户>，我可以<做些事情>来<获得某些结果>”。用户诉求可以被归入“Epic”。这样就构成了需求的组织结构。Back log然后将这些用户诉求按照重要性从高到低排序——您应该将它们那么排列。 任何时候一旦有新的用户诉求出来，就被归入到backlog中。当然，您需要不时地审阅您的backlog，确保他们仍然是按照正确的顺序排列。

下面是我们的产品计划backlog的一个截图。我们仍然通过导航模型来工作, 但是让我来强调一些重要改进吧。在左上方，可以看到“DevDiv”。那是Aaron所用到的团队项目名称（在右上角看到他的名字了？）。然后是“Agile”——即Aaron所在团队的名称。下面是一列“hubs”或设置的背景下产品的领域。 您看到这里所选中的是“backlog” hub。 它允许您可以看到整个产品backlog或一个过去的，现在的，活将来的sprint， 您可以容易地直接在页面上添加新的用户诉求并拖拽那些条目来设置优先级。 如您所见，您还可以容易地将他们分成层次结构， 甚至还可以将一个条目拖拽到左边的Sprint上，并将迭代路径自动设置为该Sprint。

总而言之，它提供了一个非常调优的体验来管理backlog。简洁又非常快速地完成所有重要的backlog管理操作。

Spint计划

一旦有了backlog，就该计划sprint了。在左边的sprint上简单地点击一下，就会转到sprint计划视图。要计划sprint，您需要选择一组用户诉求然后将他们细分成任务。做这件事的时候，您需要在预计成本和容量间循环切换。不同的团队会用不同的方式，所以我们提供一些选项。 如果您想选择的话，可以就使用诉求要点来计划sprint，跳过任务分解。或者可以分解成任务（分解成小时或所选择的其他单位），将任务按照规律(开发，测试等等)分配出去，然后通过规律计划容量。或者您可以将任务分配给个人，然后根据人员来计划容量。在这个示例中，用户诉求被分解成任务，并分配给成员。右边显示每个人根据其容易所分配到的任务(红色表示分配过多，绿色表示适量)。用户诉求列表上面的容量栏显示相对容量的所有sprint承诺。

用户列表上的灰色条上，您可以看到“Backlog”和“Capacity”。在backlog hub里面有视图。容量视图允许您配置计算的容量(团队成员的可容量，干扰等等)。

最后，我想指出在“alm sprint 13”的右边您可以看到“April 27 – May 17”。这些是sprint/iteration的日期，是TFS V.Next中的另一项新的基本功能。我们现在有关于iteration的日期贯穿于产品的好几个地方(比如可以将报告设置为显示iteration，然后他们自动获取日期)。这是多年来一个很大的用户需求，我们现在将它添加到敏捷项目管理体验中了。

每日站会

一旦计划了sprint，就需要执行sprint。在Scrum中，管理sprint执行的主要工具是每日站会。 在每日站会中，团队成员聚集在一起一小段时间(比如15分钟)，回顾前一天的进展，计划当天的工作，并讨论阻碍当前进展的任何问题。 有些团队并不事先将工作分配给成员，而是将每日站会作为从sprint backlog中提取当前所需工作的契机。 每日站会可以选择的工具是“任务墙”。 它列出了sprint中所有的用户诉求，并显示用户诉求/任务的状态——比如，计划中、进行中、完成。在站会中。每个成员用几分钟的时间来发言并更新任务墙。在Scrum早期，任务墙主要表现为有很多便利贴的墙。随着越来越多的团队采用Scrum，特别是分散的团队，电子版的逐渐流行起来。

我们的新任务墙显示成下面这样，左边是一列用户诉求，和一系列代表工作状态的列（比如：计划中，进行中、完成）。表格中的卡片代表实践用户诉求的任务。您可以简单地看到任务的标题，分配的人以及任务的成本。任务墙通过简单地将任务从一栏拖到另一栏来更改。

在右上角，您可以看到一个显示sprint中的进展的burn down图。点击它，可以看到大的版本，包括趋势线等等。您还会注意到灰色栏选中了“诉求”。如果选择“Team members”，将显示根据人员而不是用户诉求选择的信息。

我们在过去几个月中一直在内部试用，我们很快发现一件事情：在站会中，“下一个人”不容易找到他们的任务(甚至是以队伍成员为中心的时候)。我们最近增添了一个新的筛选功能来真正让专注于自己的工作变得容易，这样您可以更新您的状态，然后很快移到下一个人身上。

在下面的视图中，您可以看到筛选出来了Jon Tsao的工作(请看趋势图的右下边)。当选中Jon的时候，所有他没有相关任务的用户诉求都被收起来。他有任务的用户诉求都被展开了。Jon所分配到的任务被标成深色，没有分配给他的任务被标成浅色。这样Jon可以非常简单地关注在他的工作上并做出更新。 进一步地，如果Jon更改任何该视图中筛选出来的任务(比如，他将一个任务从“proposed”中移到“in progress”)，任务就会被自动地分配给他(如果还没有被分配分配给他的话)。这更加加速了站会的速度。如果Jon需要从别人那里拿走一个任务或者从back log中拖走一项任务，他只要将任务拖到新的表格里，任务就会自动分配给他了——非常酷！

结尾思考

为使用Scrum的人们创建非常好的体验让我感觉非常好。这里我只是给您展示了一小部分功能但是我希望能够足够打开您的胃口。随着我们进入下个版本发布的计划阶段，我和我的团队谈论了很多关于关注于创建很优美的解决方案而不是仅仅关注提供是可以创建完成的解决方案的平台。我们的产品在两方面都做得很好，对此我非常自豪。