随着微软Visual Studio 2010 Ultimate Beta2版本的发布,除了它提供协同一致的ALM(应用程序生命周期)管理工具外,MSF for Agile Software Development过程框架从4.2升级到5.0,并且是以Scrum模型为基础导向扩展,并且结合了VSTS2010工具的众多特性,从而成为微软.NET相关技术人员手中不可多得的利器。 在本文中,笔者将介绍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 演示上进行规范,本质就是一个简单的测试规范。 笔者借鉴过很多敏捷书籍和在实战的应用中尝试过很多字段,但最后发现,只有上面提到的六个字段我们会一直使用下去,这也就是一种最简化。 ![]() 图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所示),扫描你的团队成员属于哪种类型。例如,他是家庭感情型,你就可以在某个节日或者事件里到他家做客,体现领导对他的重视和认可。让家人觉得领导得好,家庭的力量对他施加自动自发的内因驱动力。如果程序员是‘危机风险型’,你就提供他创新的机会和平台,发挥他的最大内因驱动力等。当然,这都必须结合外因才会可度量、可操作、可监控和有目标方向。 |