微软发布官方TFS,进行敏捷

作者: 化工塑胶  发布:2019-11-26

转自:

根据Forrester Research今年第二季度的一份研究报告,在超过1000名专业开发人员中,采用敏捷模式进行软件开发的已经有10.9%采用了Scrum模式,在所 有的敏捷开发模式中名列首位,而在所有的软件项目管理模式中,敏捷模式更是被35%的开发人员所采用。当然,研究报告为我们呈现的仅仅是一个统计学的观 点,到底你的开发团队应该采用什么样的开发模式,这还是要根据各自不同的开发环境,人员构成,公司架构以及文化背景来决定。

 

图片 1

最近在看Brian Harry的博客,发现微软刚刚发布了TFS 2010上面使用的Scrum v1.0 beta版的模板,虽然还是beta版本,但是已经是非常scrum化的模板。 

图1:Forrester 关于敏捷模式的调查报告

Visual Studio 2010 是微软在2010年4月发布的全新一代的集成开发环境,配合同时发布的Team Foundation Server 2010(TFS——团队服务器) ,为开发团队提供了全面的应用程序生命周期管理(ALM)工具和平台。在2010这个版本中,对于敏捷,或者说Scrum模式的支持是前所未有的。虽然微 软的Visual Studio Team System从2005年开始发布的时候就提供了敏捷流程模板(也就是MSF Agile)模板,但是2008版之前的这个敏捷流程模板都是基于MSF(微软解决方案框架)的;这个框架是微软针对自己的研发团队的最佳实践进行抽取总 结出来的,与广大敏捷开发社区里面所流行的很多敏捷方法并不是很契合,造成了开发团队在实施的时候有很多不适用的地方。因此,微软在开发2010版本的过 程中,大量的听取了敏捷开发社区中的声音,在自己的MSF Agile 5.0的模板中进行很多针对敏捷,更确切的说是Scrum开发模式的改进,使得2010版本中所集成的MSF Agile 5.0的模板非常适合我们来进行Scrum模式的开发组织。当然,微软的产品为了追求通用性,在MSF Agile 5.0的模板中并没有完全采用Scrum模式通行的名称和流程;同时,微软在两周前又发布了一个纯粹的Scrum流程模板以供那些希望完全使用Scrum 模式的开发团队使用,当然这个模板现在仍然是Beta版。

趁晚上的时间吧这个模板安装在我的测试TFS服务器上,简单测试了一下:

我个人认为,开发团队采用哪一个模板并不是最重要的,重要的是我们需要在开发过程中不断地改进过程,并对这个模板进行定制,以便适合我们自己的开发流程。这也是为什么TFS所提供的是一个模板,因为它的目的就是希望我们在这个模板的基础上不断的改进,最终找到适合

#1 – 安装很便捷

按照包里包括了模板文件和SharePoint门户的wsp部属包:

 

图片 2

 

使用模板管理器可以很方面的把模板部署到服务器上:

 

图片 3Stack Rank 

 

自己开发团队的流程。其实这也很符合Scrum模式的理念;简单一点来说,Scrum模式是一种针对复杂项目的流程组织方式的框架, 其目标是为了让我们开发出更高质量的软件产品。围绕的这个目标,Scrum模式为我们提供一个团队模型,一系列工具和一个简单的流程。在这样一个框架之 下,Scrum模式要求我们不断地改进流程以达到适合团队的最佳状态,这种对改进的要求也是Scrum模式区别于其他开发流程的重要特点之一。

#2 – 流程模板指南现在指向Scrum.org

我使用这个新模版创建了一个项目,发现流程模版指南里显示的scrum.org;我个人觉得如果指向Scrum Guide可能会更好一点 ().  

 

图片 4 

 

为什么Scrum模式适合软件开发?

软件行业至今已经有超过40年的历史,很多在软件工程中的管理方法都是在不断摸索中改进而来的。早期的软件行业由于规模有限,绝大多数属于作坊型, 几个人在一起靠着自己的聪明才智创造出软件产品;但是当团队规模不断扩大的时候,开发人员开始需要一种模型来组织越来越庞大的团队,满足越来越复杂的需 求。因为没有经验可循,软件开发团队将很多传统工业工程的方法借鉴到软件行业,因而出现像“瀑布式”的模型。“瀑布式”模型要求我们在实际的开发工作开始 之前进行很多非常细致的设计和计划,力图将不可控的开发过程细化成可以控制的颗粒,以达到对复杂项目的总体控制目的。但是“瀑布式”模型忽视了软件项目的 一个本质特点,那就是需求的不确定性;我们不可能像造汽车一样在上生产线之前把所有的零件都设计好,所有的流程都规定好,再进行装配;因为任何软件在实际 进行编码之前都没有人知道这些代码应该如何实现,而且每一个开发人员的水平不同,习惯不同,写出的代码也是不同的;再加上客户对于软件的需求也是在不断变 化的,一年之前的业务流程很可能在一年之后就产生的变化,如果还按照之前的需求进行开发,那么交付的时候肯定是无法满足要求的;更重要的事,在客户没有看 到或者实际操作软件产品之前,他们永远也不能明确地告诉你他们要的到底是什么。因为这种种原因,造成了软件开发不可能采用传统的工程方法进行组织,因为其 本身是一种需要依赖于开发人员智慧的探索性行为,也造成了我们的软件项目中有很大一部分是失败的。

Scrum模式的出现正是基于对于软件开发行为本质的认识,提供了一种松散的框架,让我们使用一种探索性的流程方法来组织本来就是探索性的开发过 程;从根本上满足了软件开发本身对于流程的需求。这种方法论实际上是基于爱德华?戴明所提出的戴明环的管理方法;戴明环理论提出:人类在进行任何复杂活动 时,获得成功的最有效过程要经过:Plan 计划– Do执行 – Check 检查– Act改进,四个子过程,并不停的迭代以便找到最佳的方法来解决问题。这个理论不是针对软件开发提出的,但是软件开发本身其实就是最典型的复杂活动。

图片 5

图2:Scrum的流程

这里我们再回头看看Scrum的流程,Scrum的流程主要包含以下内容:

  • (P) Release/Sprint Planning:发布/迭代计划
  • (C&P) Daily Scrum:每日回顾
  • (C&A) Sprint Review:迭代产品检查
  • (A) Sprint Retrospective :迭代流程检查

我们可以看到,Scrum模式的流程与戴明环仅仅相扣。有很多认为敏捷模式会弱化计划的作用,其实不然,敏捷模式更加强调计划,而且强调更加频繁的计划,比如:每日回顾这个流程就要求我们的团队每个成员每天早上用15分钟的时间来回答3个问题:

  1. 你昨天做了什么?
  2. 你今天计划做什么?
  3. 有什么问题阻碍你的开发进程?

其实这正是对于之前开发内容的检查,同时也是对后续开发内容的计划过程。

#3 – 工作项全部针对Scrum进行了优化

工作项已经被更新为完全Scrum化的类型,名称符合Scrum的常用标准:

  • Product Backlog Item(PBI产品需求列表项): 代替了User Story 

  • Impediment(障碍工作项): 代替了 Issues,这个工作项是Scrum Master用来记录阻碍团队正常开发的障碍的工作项,是Scrum Master的工作重点

  • Task (任务工作项)

  • Test Case (测试用例工作项)

  • Shared Steps (共享测试步骤工作项)

  • Bug (缺陷工作项)

  • Sprint(Scrum中的迭代): 这是全新的工作项,用来记录和迭代相关的内容,如:迭代开始/结束时间,审核会议记录等内容。

图片 6 

 

Product Backlog Work ItemPBI产品需求列表项 :

 

使用新的Scrum模板创建了一个PBI工作项,发现这不仅仅是User Story的工作项的改名那么简单: 

图片 7  

具体看一下PBI的内容: 

-       Backlog Priority (优先级): 代替了User Story中的Stack Rank和Story Points,PO可以使用这个值来对PBI进行优先级的标注,这是PO的主要工作内容之一;
-       Effort(工作量): 这代表了用来完成当前PBI所需要的工作量;
-       Business Value(商业价值): 用来衡量PBI对用户的价值的相对值;
-       Tasks(任务列表): 这里需要链接到所有实现当前PBI的任务工作项;
-      Test Cases(测试用例): 我们在定义Scrum项目的PBI的同时需要对如何对当前PBI进行测试进行定义,也就是UAT。这也是Scrum模式中的需求所不同之处,一边来说需求仅仅是对用户的要求进行描述,但是Scrum要求我们对用户如何测试这个需求也同时进行定义,以保证需求的有效性;
-       Acceptance Criteria(接受条件):这里应该对当前PBI的接受条件进行定义,应该等同于done criteria,但是一般来说,我们不会对每一个PBI采用不同的done criteria。 

PBI的状态转换: 

我觉得这里的状态改进很好,因为它更好的体现了scrum模式的工作流程。首先PBI处于New的状态,然后由PO/干系人审核,变为Approved状态;在迭代计划会议上,PO会把PBI的内容交付给团队,团队需要给与PO承诺他们将按要求完成需求,这是转换为Committed;最终当团队完成了这个需求的时候,转变为Done的状态。(我个人一直认为微软的流程模板的精华在于其状态转换,很好的对状态转换进行定义意味着我们可以对团队的工作流程进行更好的控制;以往的MSF Agile模板因为过于追求通用型,对状态转换的定义往往无法满足开发团队要求,这个Scrum模板为我们提供了一个非常的例子)。   

图片 8

状态包括:

-       New
-       Approved/Removed
-       Committed
-       Done    

 

Sprint 迭代工作项:

这是Scrum流程模板中的全新工作项,也是以往的Agile模板所缺失的重要工作项类型。其内容包括迭代的开始/结束时间,迭代的目标定义和迭代的审核会议(Restrospective)的记录模板。 审核会议(Retrospective Meeting)是Scrum的精华内容:Scrum鼓励团队针对实际情况对工作流程,团队组织,任务分配等等进行不断的优化,以便可以找到适合团队的工作方式;审核会议是Scrum为团队提供的反思开发流程的机会,对这些内容进行定义可以为我们改进流程提供非常好的事实基础。

图片 9

 

Task 任务工作项:

 

Scrum中的任务不关心任务上的实际工作时间,因此我们没有在这个任务工作项上看到Completed Work数据域,而仅仅保留了剩余工作量Remaining Work数据域。这当然是Scrum模式的特点之一,但是对于依赖于工作小时来收取开发费用的咨询类软件公司来说,实际工作时间是非常有意义的数据。

另外值得我们注意的是任务工作项的状态有:To do, In Progress和Done,3个状态。这是一个非常棒的改动,就像我之前说过的,状态的转换代表了开发团队的工作方式。对于我来说,非常关心我的团队每天正在那些内容上工作,所以这个In Progress的状态就非常重要了。

图片 10 

 

Bug 缺陷工作项:

 

缺陷工作项同样有比较大的改进,特别需要注意的是Backlog Priority这个数据域;很多人都对如何处理Bug工作项有疑问,Bug到底应该等同于任务还是等同于PBI,这里Scrum模板为我们很好的解答了这个问题:Bug工作项应该是等同于PBI的产品需求。因为实际上Bug也是一种需求,是一种解决缺陷的需求,普通的PBI则是一种添加更多商业价值的需求(注意是商业价值而不是功能,因为scrum中的需求是业务导向的,而不是功能导向的)。

 

图片 11 

测试用例和共享测试步骤工作项:

这本来就不是scrum的内容,而是MSF Agile中的内容,在这里得到了保留。 

Scrum模式需要怎样的工具来实现?

对于使用什么样的工具来实现Scrum模式,现在也有很多不同的观点。其实有很多人认为白板和即时贴就是最好的工具,其实对于小型团队来说这的确是 最有效而且最经济的方法。但是如果考虑到软件公司的管理需求(工作量统计等),远程团队,开发工具集成,代码质量控制,发布后期支持等等;我们还是需要一 个高度集成的平台和一整套工具来支持我们的开发团队。

图片 12

图3:白板和即时贴

Visual Studio 2010所提供的集成开发环境可以满足我们以上的一系列需求,帮助我们的开发团队更好组织开发,帮助我们的管理层更好地掌控开发过程,帮助软件公司开发出更高质量的产品。

Scrum模式对于工具的要求,主要集中在以下一个方面:

  1. 团队组织:满足PO (产品经理),Scrum Master (流程经理)和开发团队管理,以不同的权限访问团队项目并对不同角色提供个性化的信息支持的能力。
  2. 产品需求记录和跟踪:对于Product Backlog Item (PBI 产品需求列表)的添加,编辑,优先级排序以及交付开发团队以后进行跟踪的能力。
  3. 流程管理:满足Sprint Planning, Daily Scrum, Sprint Review和Sprint Retrospective这些流程中对于信息共享,信息转移和跟踪的能力。
  4. 产品质量:在整个开发过程中,配合Scrum模式达到产出高质量代码和产品的能力。

下面我们就看看Visual Studio 2010系统在这4个方面如何满足Scrum模式的需求,并协助我们开发出高质量的产品。

#4 - 工作项查询也作了优化,很方便

Scrum v1.0 Beta 模板包括了一个“当前迭代”的查询目录,里面包括了所有针对当前迭代的查询;非常方便使用并可以很容易的进行复制以便支持后续的迭代。

图片 13

-       Product backlog: 这里你可以看到PBI和Bug工作项类型被选定,他们都是产品需求列表的内容。

图片 14

-       Sprint Backlog 迭代需求列表: 除了PBI和Bug之外,还包括了相关的任务   

图片 15

-       Work in Progress 正在进行的工作: 这个查询太有用了,每天早上都已运行一下,就知道团队今天要干嘛了。  

图片 16

-       Open Impediments 未解决的障碍: 这会是Scrum Master用的最多的查询,看看团队现在有那些问题阻碍他们正常开发?

Visual Studio 2010上的Scrum团队组织

一个完整的Scrum开发团队主要由以下角色组成:

  1. Product Owner (PO 产品经理):我喜欢把PO翻译为产品经理,因为PO的工作职责就是向客户和干系人收集产品需求,进行排序并保证开发团队按照干系人对需求优先级的要求进行交付。
  2. Scrum Master (SM 流程经理):对于Scrum Master我一直没有更好的翻译,将其译成为流程经理是因为这一角色要保证团队按照Scrum的方式来组织开发,并协助团队和PO进行有效的沟通,解决 团队所遇到的问题。Scrum Master和项目经理的区别在于,他更加倾向于保证开发流程的完整性而不是倾向于满足客户/干系人的需求。
  3. 开发团队:开发团队在Scrum模式中是作为一个整体出现的,一般来说团队的大小控制在3-7个人的规模;团队作为一个整体向PO负责,而不是每个人对于自己的任务负责。

在Visual Studio 2010 系统中,使用TFS服务器基于角色的权限控制,我们可以很方便地定义出不同的权限范围。当然,最简单的方法是把Scrum团队的角色和TFS的默认角色之间进行映射。

图片 17

图4:TFS团队项目的默认角色

Scrum团队角色

TFS团队角色

 

Product Owner

Contributor

 

Scrum Master

Project Administrator

 

开发团队

Contributor

Builders

Project Administrator

根据团队不同人员的职责具体分配

项目干系人

Readers

如果客户愿意更直接的参与项目,可以允许他们直接访问TFS。

表1:Scrum团队和TFS团队角色映射

图片 18

Visual Studio 2010系统中对需求记录和跟踪的支持

Scrum模式中的需求主要是采用Product Backlog Item(PBI产品需求列表)和Sprint Backlog Item (SBI 迭代需求列表)来进行管理的,在Visual Studio 2010系统中,直接提供了针对这两个列表的工作项查询,并且还提供了Agile Workbook (敏捷工作簿)帮助我们更好对工作量和任务分配进行调控。

图片 19

图5:使用MSF Agile 5.0模板创建的TFS团队项目集成了对PBI和SBI的管理功能

图片 20

图6:Product Backlog 查询结果

上图中就是使用TFS内置的Product Backlog查询获取的产品需求列表,这个列表是PO使用的主要工具,我们可以注意到这个列表已经根据Stack Rank列进行了排序,这也反映了产品需求列表的特性:需要根据客户/干系人对需求项的优先级向团队交付任务;而PO的除了需要不断完善这个列表,还需要 不断和客户干系人进行沟通,一边确定这个优先级。

在Scrum模式中,对于优先级的定义决定于两个因素:需求的商业价值和紧迫程度;另外一个重要的指标就是Story Point,这个指标标志着当前需求项的相对大小,注意这里说的相对大小,很多人将这个值理解为人天或者人时,其实是不准确的,因为在PO准备产品需求列 表的过程中,仅凭PO的经验是很难准确的判断出以时间为度量的工作量的,但是相对的大小是比较容易判断的。

另外,从State和Iteration Path两个列的值我们可以看到,已经有一些需求在迭代1-2中已经解决。根据这些信息,PO可以很容易的对工作进度和剩余需求进行管理。

另外一个重要的查询就是Iteration Backlog查询:

图片 21

图7:Iteration Backlog查询结果

Iteration Backlog 中包含了团队在某个迭代中需要完成的需求以及针对这些需求细化 出来的具体开发/架构/测试等任务。在Visual Studio 2010中,微软终于开始支持树形结构的工作项关联,从上图可以看出,每一个User Story的下面都挂接着相应Tasks,这些任务是在Sprint Planning Meeting中由团队成员自己根据PO对需求的阐述进行的细化,同时团队成员还需要根据经验对这些Tasks进行估算,给出基线估值(Original Estimate)。在开发过程中,团队成员在每天的Daily Scrum之前需要对前一天的任务更新状态(State),已完成工作量(Completed Work)和剩余工作量(Remaining Work)字段的内容;通过这些信息我们就可以使用TFS自带的燃尽图报表对进度进行查询和预测了。

实际上,纯粹的Scrum模式并不关心已完成工作量(Completed Work)也就是以完成工作量的值,但是对于使用人天/人时等信息来衡量团队工作量,甚至依赖这些数据想客户收取开发费用的咨询类公司来说,这些信息是非常重要的。

#5 - 报表还需要改进

当前的Scrum模板仅仅包含了Scrum中最常用的3个报表,还需要多多改进。根据Brian Harry的说法,他们会把Agile模板中的一些常用报表包含进来,特别是一些软件工程类的保镖,比如:构建报表。 

Release Burndown
Indicates how quickly the team is completing work and delivering Product Backlog Items. Its primary use is for planning when to schedule a release and to track the team's progress towards delivering on its goals.

图片 22

Sprint Burndown
Indicates the team's progress towards completing its work for a sprint.

图片 23

Velocity
Indicates the amount of effort the team is completing in each sprint.

图片 24

As I don’t have any data in the database yet, I just copied above screenshots from Brian’s blog.

Visual Studio 2010对Scrum流程中重要事件的支持

Scrum模式中的几个重要的会议包括:

  1. Sprint Planning Meeting
  2. Daily Scrum Meeting
  3. Sprint Review Meeting
  4. Sprint Retrospective Meeting

这一系列的会议是真正体现Scrum模式对于开发流程控制的核心内容,在Scrum模式中另外一个非常重要的概念是:时间箱(Time Box),它要求我们对于流程中的事件进行非常严格的时间控制。很多人在开始进行Scrum模式开发的时候的一个普遍问题是:一个迭代(Sprint)的 长度应该是多少?对于这个问题其实也没有标准答案,而必须根据团队的大小来进行判断。对于之前我所建议的3-7人大小的团队,我会建议采用2周的迭代长 度。原因在于1周太短,团队还无法完成真正有商业价值并可以进行交付的需求;而3周的时间则太长,需求的变化所造成的风险会变得比较大。

采用迭代式开发的时候其实长度是越短越好,我们总是尽可能的缩短迭代以便可以通过给客户的交付获得更有价值的反馈以便对后续的开发进行调整,因此这 个长度应该是团队刚刚可以完成可交付需求的最短时间。我们需要严格控制的是,迭代的长度应该是一个时间概念儿不是工作量的概念,也就是说如果2周的时间已 经耗尽但是团队还没有完成当前迭代中的所有需求,那么也必须结束迭代进行交付,而不能选择延长迭代来完成未尽需求。这样做的结果有两个:1)当前的迭代会 以失败告终;2)通过对已经完成需求的交付,我们可以获取客户的反馈。很明显,失败的迭代是我们不愿意看到的,但是客户对于已经完成需求的反馈比保持常胜 将军的名誉更加重要,因为后者是保证我们软件质量(符合需求)的重要手段。

当然,这里隐藏着另外一个很重要的问题,在团队无法完全完成需求的情况下如何还能提供可交付的成果,这就要依靠我们对于需求定义方式的变化和 Visual Studio 2010 中对持续集成和更加高效的测试支持来实现了。在需求定义上,我们需要采用业务导向的需求定义,保证每一个需求的完成都可以交付一定的商业价值。以往的需求 往往是功能导向的,但是功能导向的需求对于用户来说不一定具备商业价值,但是业务导向的需求则可以保证这一点,比如:我们可以这样定义一个User Story,作为市场经理,我希望对客户数据进行查询以便可以找到本市的客户并和他们进行联系。使用这样的需求定义意味着只要我们完成这一需求对客户就是 有价值的,因为它不是一个功能碎片,而是一个用户交互用例。如果在一个迭代中我们无法完成所有的需求,只要完成其中一个,那么都是可以向客户交付的。另 外,借助Visual Studio 2010对持续集成和测试的支持,我们可以采用每日构建的方式保证所有完成的代码都符合质量要求,也就避免了在迭代后期进行集中测试而拖延交付的可能性。

本文由88必发手机版发布于化工塑胶,转载请注明出处:微软发布官方TFS,进行敏捷

关键词: