在本文中，笔者将介绍Visual Studio 2010 Ultimate Beta2版本中的MSF for Agile Software Development V5.0的Scrum思想以及实施方法，通过对这些内容的阐述，让读者了解VSTS2010的敏捷之道，以便于.NET管理和开发人员能随心所欲的应用在自己的项目中，从而构建出高效的软件开发团队。
1.引言
道是天地万物演变的本体或本原，是存在之根本。一个行业或者一个事物既然现实地存在着，那么它的发展必然遵循着本身的自然规律。
谈起敏捷之道，令笔者不禁想起在《笑傲江湖》中描写令狐冲独孤九剑的精髓‘行云流水，任意所至。’这就是活学活用，实战中随手配合招式的变招。风清扬教令狐冲‘将这华山派的三四十招融会贯通，设想如何一气呵成，然后全部将它忘了，忘得干干净净，一招也不可留在心中。’其实是将华山剑法一招一式固有的套路动作拆开使它不存任何招数，再自由组合套路形成浑然一体的招式使出来。这都是活学活用，而这只是第一步。做到出手无招，才是真正踏入了高手的境界。真正的无招是没有主观的招式，根本并无招式，敌人如何来破你的招式?
软件开发的敏捷之道也是如此，当开发团队为了求得高质量、高效的完成软件产品的交互过程，无论项目管理者还是团队成员都需要全方面地学习，包括工具的熟练使用、学习UML、OOAD等技术和收集前人开发过程中的经验等等，从而使个人以及团队综合素质的大大增强，这就是为学的过程，最后把这些零碎无序的知识系统化后再全部统统‘忘掉’，达到出手无招、随心所欲，全是下意识自然而然的行动，无变之变，这就是敏捷之道，这可能就是做项目管理及开发的最高境界吧!
敏捷的含义就是速度的最大化。当你咖啡杯从你的手中悄然滑落的时候，你却下意识地接到了它，这种直线运动是最快的，其实里面蕴藏着一种意境和思想。这种下意识就是一种境界思维，它没有经过大脑，条件反射的方式以最短最快的速度取得了结果。
这种现象又让笔者又联想起了李小龙的“截拳道”，它的一个特点就是充分运用‘节约的经济线’(两点间的直线)的技击原理，所以它打击对方的机会和实用性最佳，而且最快，这种“下意识”的境界就是一种太极哲理，搏击之最高境界。万物皆有道，这都是从道的本体中演化出来的!
2.敏捷之简易
简单通常是一个好的设计具备特征，这些设计是经典的并且很难再改进的。 例如，Lego积木(参考图1所示)，经过许多年还保留着原来的样子，因为没有人能想出更简单的设计让人们将木块组合再拆开。人们无法再改进这些设计，因为它们不能够再简化，而将它们设计得更复杂也无法让它们更好用。
图1 Lego 积木
敏捷团队注重简易，这样做可以消除那些没必要的复杂。只需专注于开发当前所需要的功能和最简单的设计。如果能使用简单来帮助一个敏捷团队开发出马上就需要的软件，而不浪费人力和资源，这就是他们给那些投资的用户以最好和最直接利益的方法。
我们再从《易经》中的‘简易、变易、不易’的角度思考，可以把它看做是对易理的高度抽象→易理对宇宙的高度抽象→‘简易’指变与不变都是‘道’的体现，自然而然而非刻意求变，万事万物都只是按其本性生生不息而已。所以，简易之理是对大自然万事万物高度的抽象;‘变易’是指‘变化’，任何‘生生不息’都是处在不断的变化之中，没有停止过，宇宙中的万物没有一样东西是不变的;‘不易’是指万事万物的变化都有其不变的本性，同时又有当变则变、不当变则不变的含义。宇宙中万事万物虽然不断变化着，但是却有一项永远不变的‘东西’存在，就是能变出万事万物的那个‘东西’，是永恒存在的，中国传统哲学里称之为‘道’。”
2001年2月由17位世界轻量级方法学家提出了一份敏捷联盟宣言，这个宣言只是简单的四句话，但却是敏捷方法的精髓，也是对敏捷的高度抽象，这便是敏捷之道的最高境界：
个体与交互 胜过 过程与工具
可以工作的软件 胜过 面面俱到的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
3.Scrum敏捷过程模型
在Visual Studio 2010中，项目过程模板变化很大，微软把Scrum作为基本Agile开发模型(Scrum模型为基础参考导向)，如图2所示。TFS2010中集成了MSF for Agile Software Development v5.0，可操作性上又融合了敏捷等软件开发流程思想模型。
Scrum最初的含义是英式橄榄球争球队,是敏捷软件开发模型中的一种。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都明确的朝向目标推进。Scrum令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整，如果能够“随心所欲”应变，那么你就会体会到它的强大。
图2 Scrum for Agile
敏捷Scrum开发过程框架中，产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述，通常叫它故事(story)，有时候也叫做backlog条目。
例如，我们建立一个产品 BACKLOG(示例)，如表1所示。
表1 产品 BACKLOG(示例)
我们的故事包括这样一些字段：
ID：统一标识符，就是个自增长的数字而已，以防重命名故事以后找不到它们。
名称(Name)：简短的、描述性的故事名。它必须要含义明确，这样可以跟其他故事区分开。
重要性：(Importance)：产品负责人评出一个数值，指示这个故事有多重要。例如：
20或100。分数越高越重要。避免“优先级”这个说法，因为一般说来优先级1都表示“最高”优先级，如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢?优先级0?优先级-1?
初始估算(Initial estimate)：团队的初步估算，表示与其他故事相比，
完成该故事所需的工作量。最小的单位是故事点(story point)，一般大致相当于一个“理想的人天(man-day)”。
如何做演示(How to demo)：它大略描述了这个故事应该如何在sprint 演示上进行规范，本质就是一个简单的测试规范。
笔者借鉴过很多敏捷书籍和在实战的应用中尝试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去，这也就是一种最简化。
我们可以把backlog存放在TFS2010服务器上，或者共享在TFS2010的Excel或者Project(参考图3所示)文档里面，这是为了多个用户可以同时编辑它。
图3 在TFS2010中的Project Product Backlog模板
虽然正规意义上这个文档应该归产品负责人所有，但是我们并不想把其他用户排斥在外，开发人员常常要打开这个文档，弄清一些事情，或者修改估算值。
VSTS2010已经支持Scrum的Product Backlog的模板，并且可以进行Backlog的迭代，如下图4所示。
图4 Product Backlog模板
打开Product Backlog，建立User Story，如图5所示。
图5 建立User Story
编写相关Story条目内容，如图6所示。
图6 编辑Story条目
当编写完Story条目内容后，我们可以在Web端的Project Portal查看user story的内容与条目，如图7和图8所示。
图7 打开Web端的Project Portal
图8 Project Portal显示条目
在share point的Project Portal中，我们可以对该story进行编辑等操作。如图9所示。
图9 share point站点中编辑条目
我们可以对表1进行扩展，如表2所示。
表2 产品 BACKLOG扩展
Backlog组件 ID Important Estimate How To Demo Notes
组件用处 事件的编号 事件的重要性，用一个分数来表示。分数越高越重要(但重要的事件，内容不一定多) 初始的估算，也就是完成某个事件所需要的工作量。 事件的简单测试 用简洁的语句进行注解、说明等。
Backlog组件 Track Components Requestor BugTrack
组件用处 对产品的分类 产品由哪些部份组成 记录最先提出的需求，并在后续的开发过程中进行反馈。 Bug跟踪
注：有颜色的组件可以说是必需的!
在TFS2010中支持Reports的生成Excel报表，内容包括backlog、工作项等，如图10、11、12所示。
图10 创建报表Excel
图11 选择创建报表Excel生产类型
生成报表，如图11所示。
图12 生成Excel报表
在Scrum敏捷框架中，最强的就是快速应对客户需求的灵活变化。Scrum中有四个很标致性也很核心的词：backlog , sprint、迭代、反馈。结合VSTS2010的工具，可以快速进行story的变化，并且快速完成。例如，在产品 BACKLOG(参考表1)，在每个Spint中，实现特性How To Demo，通过VSTS2010的Architecture绘制SSO统一登录的UML顺序(如图13所示)，完成Spint Demo(可以是Spint中一部分)。
图13 绘制SSO统一登录的UML顺序
敏捷软件开发的核心是：使用项目行为的“轻量但足够”的规则以及使用以人为本的规则及面向沟通的规则。Scrum的Sprint计划会议非常关键，应该算是Scrum中最重要的活动(这当然是我的主观意见)。要是它执行的不好，整个sprint甚至都会被毁掉。
图14 TFS2010集成平台的开发项目的合作
举办Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。Sprint计划会议会产生一些实实在在的成果：
·sprint目标。
·团队成员名单(以及他们的投入程度，如果不是100%的话)。
·sprint backlog(即sprint中包括的故事列表)。
·确定好sprint演示日期。
·确定好时间地点，供举行每日scrum会议。
图15 Scrom敏捷过程管理
Scrom敏捷过程管理实施流程，如图15所示。将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.团队成员最后召开Sprint retrospective meeting，总结问题和经验。这样周而复始，按照同样的步骤进行下一次Sprint.
最终结果是，每个Sprint都产生出一个可见的、可用的交付产品，并向用户进行展示。一个增量可能是中期的，也可能是可交付的，但是它应该是独立的。 Sprint的目标是完成尽可能多的优质软件来确实质性进展，而不是用纸上里程碑(paper milestones)作为依据。
4.Scrum索引卡(白板文化)
在大多数sprint 计划会议上，大家都会讨论产品 backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分，等等都会在会议上完成。敏捷开发中提倡建立物理索引卡。要想收到好的效果，不妨创建一些索引卡，把它们放到墙上(或一张大桌子上)。
笔者在这里也有个扩展方法，可以制作电子版的索引卡，如图16所示。可以清晰、直观的显示燃尽图和索引卡等信息。
ScrumDashboard是微软站点中的一个开源项目，最新版本ScrumDashboard2.4.0.8，大家可以到http://scrumdashboard.codeplex.com/ 下载数据脚本以及源码。
图15 ScrumDashboard界面
5.总结
VSTS2010的增强的功能特点结合MSF for Agile Software Development V5.0中的Scrum敏捷过程框架，使从事在微软.NET技术相关工作方向的人们拥有了一把利剑。
写到此笔者不禁又想起了在《神雕侠侣》中杨过得到的独孤求败的三柄剑：
利剑、重剑、木剑;
如果我们把微软VSTS2010工具，看成是敏捷开发团队中，在不同阶段中所使用的‘剑’，随着你的功夫和意境提高，你手中的利器就显着不重要了，无剑的境界便是最高的追求。敏捷有时也为灵感所致，如果敏捷团队的人们能锻炼出这种境界，便是软件开发之最高境界，那就是敏捷之道了。所以，敏捷的开发团队也是讲究天人合一(团队敏捷意识合而为一)，敏捷也是哲学的。
除了工具和Scrum外，令人忽视的就是团队成员的素质能力和意识。我在《我也能做CTO程序员职业规划》书中也讲过，如果公司团队人员始终保持不被开除的水平，他就不能自动自发。天底下水是最自动自发地朝下流，但是你要让你的团队成员整体地自动往上走。例如，有目的、有计划，有要求的业绩，有期限，有质量的标准。做到这些才仅仅是外因。
内因就是驱动员工愿意干事情，要有内在驱动力。每个人敏感程度不同，给每个类型程序员的驱动力也不同。所有的员工自动自发的工作都是有内因的，(参见图16所示)，扫描你的团队成员属于哪种类型。例如，他是家庭感情型，你就可以在某个节日或者事件里到他家做客，体现领导对他的重视和认可。让家人觉得领导得好，家庭的力量对他施加自动自发的内因驱动力。如果程序员是‘危机风险型’，你就提供他创新的机会和平台，发挥他的最大内因驱动力等。当然，这都必须结合外因才会可度量、可操作、可监控和有目标方向。
我为it168籍稿，原文:http://tech.it168.com/a2009/1125/814/000000814906.shtml
