VSTS 工作件管理，工作件的构成，msf-agile 中工作件的类型和状态转换

VSTS 工作件管理，工作件的构成，msf-agile 中工作件的类型和状态转换
概要：
VSTS 工作件管理，工作件的构成，msf-agile 中工作件的类型和状态转换。
1       工作件
1.1      什么是工作件
一个软件产品从构想到完成，要做的事情千头万绪，从什么地方入手呢？开门见山，我们就要碰到VSTS 最重要的概念：
工作件 = 所有要做的事情
VSTS用工作件来描述软件工程中的要做的各种各样的事情。这些事情，不管是计划内的或者计划外，都被存放在一个工作件数据库里以便分派，跟踪，统计。这个数据库当中的每个记录都称之为一个工作件。工作件有各种各样的类型，工作件类型是可以由用户自行定义。 在定义工作件类型的过程中，用户可以定义以下的内容：
工作件的字段
工作件字段的规则
工作件的状态转换规则
工作件的表现形式
在进一步了解工作件的细节之前，让我们看看工作件长什么样：
＜工作件图例＞
1.2      工作件的字段
所有工作件都由字段组成，一部分字段是系统预定义的，称为核心字段（core fields），所有类型的工作件都必须包括这些字段，另一部分是系统扩展的字段，用户可以直接使用他们，也可以把这些字段排除在自定义的工作件类型之外。最后，用户可以定义自己的字段。在VSTS BETA2 中，有以下的核心字段.
《列出核心字段》
1.2.1    工作件字段属性
字段的属性，一个字段有下列的属性：
字段名 -  字段的名字，可以被修改（本地化），如“Title” 可以在中文环境中成为“标题”。字段名的命名规则是：
字段引用名 – 字段的永久名字，不能被修改，如“title”的引用名是System.Title, 无论其名字如何修改，“title” “标题” 的引用名永远是“System.Title”，所有的应用程序都可以直接引用，而无需担心名字过时。这就是“引用名”的来历。
字段号（Id）- 字段的标号，是一个整数。为什么不能用标号来永久标示字段呢？因为字段的标号在不同的namespace 中会变化，例如，团队A 自建了工作件类型 WIT1, 其中有自定义的字段“汇率”，引用名 CompanyA.Development.ExchangeRate, 在发布WIT1时， “汇率” 的标号是6000。 当团队A 要把它的WIT1 引入到另一个 namespace 中的时候，标号6000 可能已经被别的字段所占据。这是，只有引用名 CompanyA.Development.ExchangeRate 是可以保持不变的。
字段类型 – 字段的类型，主要有以下几种
Int
Float
String
DateTime
1.2.2    工作件字段的方法（method）
工作件字段的方法有如下几种，在开发篇中有详细的说明。
1.3      工作件字段的规则
在工作件类型定义中，用户可以定义针对工作字段的规则，如
在任何情况下，System.Title 不能为空字符串。 如果System.State 是“解决”，则“解决人”（Resolved By）和“解决时间”必须有正确的值。
1.4      工作件的状态转换规则
在一个正常运行的系统中，工作件的状态不断地变化，那么一个系统如何定义状态转换的规则呢？
1.5      工作件的表现形式
在用户浏览和编辑工作件的过程中，我们需要把工作件的各种字段都规范地表示出来。Vsts 中msf敏捷开发模式提供了这样的工作件表单：
《表单示例》
在具体应用过程中，用户也可以根据情况自定义表单，自定义表单通过修改工作件的类型定义来实现。
1.6      工作件的链接
不同的工作件之间会有各种各样的联系，工作件和vsts系统中的各个对象（artifact）也有各种各样的联系，把这些关系表现出来的是链接。链接有下面的几种方式：
关联链接：描述工作件之间的关系, 例如，工作件234 和工作件 97 是关联的。
例如：
《图例》
超级链接：相当于万维网中的超级链接，所有VSTS系统之外的网页，文件，以及其他对象都可以用超级链接来表示。
例如：
《图例》
外部链接：描述工作件和vsts 系统中各个对象的关系，如工作件123 有一个外部链接指到源代码控制系统的一个改变集合（change set）56。
再如，工作件256 有一个外部链接指到源代码控制系统的一个文件（file）\\root\path1\path2\file3.cs。
例如：
《图例》
链接有一个重要的属性是“注释”（comment）,  你可以用注释来说明链接的内容，例如：
《图例》
1.7      工作件的附件
工作件的附件和电子邮件的附加类似。用户可以加入，删除，打开，保存附件
例如：
《图例》
附件和超级链接的区别：超级链接也可以指向一个文件，但是所指向的文件并没有加入系统中，以后文件可能被修改，甚至删除，文件的路径可能不能访问，等。附件就没有这些问题，当然附件会占用服务器的空间，用户可定义规则来限制附件的大小。
1.8      在msf敏捷开发模式中，工作件有以下的类型：
(下列说明都可以从msf-agile process guidance 中得到)
1.8.1    任务
任务太好理解了 – 要派人去干活.  对于团队中的每一个角色, 他/她的任务也有不同.  例如, 分派给程序员的任务一般是实现场景和服务质量需求； 测试人员的任务一般是编写和运行测试案例.  我们也可以用任务来说明软件开发过程中的其他任务。
任务和缺陷的区别 – 有些团队喜欢只用缺陷类型来表示所有要做的事情和所有程序产生的缺陷，但是为了项目管理和交流的方便，我们建议用任务来表示预期要做的事，用缺陷来表示意外的结果。例如 – 阿超在签入代码后，他知道有些地方自己没有完全测试，他可以给自己分派几个任务去完成这些测试。
再如 -
写单元测试 – 这是任务，因为是可预见的，可事先安排的。
测试在不同语言操作系统下的正确功能 – 这是任务，理由同上。
在上一个任务执行过程中，如果测试人员发现在某一语言的OS下功能不正确 – 这是缺陷，因为这是理应不发生的事情。
那么，假设上面发现的缺陷（号码 4097）被分派给阿超，那么阿超能不能新建一个任务 –
任务 5003 – 修改缺陷4097
这是不对的，应付意外发生的缺陷就应该在用原来的缺陷工作件去跟踪。
任务的状态转换
新建
要做某件事情一个新建的任务，一般在msf敏捷开发模式中会有三种任务：开发 任务，测试任务，其他任务。
新建的任务一经保存，它的状态就变成“活跃”。
当任务的所有者完成了任务，或者出现下列的原因之一，它的状态就变成“关闭”。
活跃到关闭的原因
完成
做完了.
推迟
如果在当前的迭代（里程碑）中不能实现,  例如没有足够的时间，或者有另外的问题出现，使任务得不到解决。在这种情况下，要将“迭代”字段设置成正确的值.
无效
原来制定的任务不再符合实际情况.
取消
和任务相关的功能已经被砍掉了.
关闭
如果任务都已完成，
关闭到活跃的原因
重新激活
由于种种原因，原来关闭的任务又必须完成了。
1.8.2        场景
场景是工作件的一类，它记录了用户和系统互动的一个过程。当一个典型用户试图运用系统去做某件事的时候，场景纪录下用户为了达到目的所做的每一步骤.  一系列有序的步骤称为路径，有成功的路径，也有不成功的路径。对于一个实际的系统来说，有成百上千的场景，因此要决定哪些场景是值得写的。
为什么要写场景？
场景如何转化成设计？
他和别的工作件类型是如何互动的？
新建场景
新建的场景状态是活跃的.
活跃状态
场景开始的时候是处于活跃状态。 场景通常由了解用户需求的分析员来写，分析员在撰写场景的时候，要提供尽可能详细的细节内容。场景完成后，分析员把场景交付给开发组长，开发组长组织其他的开发人员实现这一场景.
由活跃到解决状态
完成
当开发团队完成了实现场景的一系列功能.
分裂
当需要把一个大的场景拆分成几个小的场景时，创建新的场景，并和原有的场景保持链接关系.
推迟
现在做不了。
取消
如果场景再也不需要实现时，设为取消.
解决状态
当实现了场景后，开发组长把此场景的状态设为“解决”，交付给相应的测试人员.
由解决到关闭状态
完成
通过测试.
分裂
测试人员同意此决定.
推迟
同上.
取消
同上.
由解决到活跃状态
测试失败
当测试失败时。同时，测试人员必须对每一个失败的测试新建一个缺陷。
关闭
如果通过了所有的测试，测试人员可以把一个场景的状态设为关闭。场景也可以变成关闭状态由于推迟，取消，或分裂.
由关闭到活跃状态
重新激活
如果出于某种原因，需要重新设计或测试场景时。
1.8.3    缺陷
一个缺陷就是软件产品中的问题，也叫bug，臭虫.  新建一个“缺陷”的工作件的目的是要准确地描述问题所在。有两方面的信息必须提供：
重现步骤：就像重建犯罪现场一样，要一步一步准确地描述怎么能让别人也看到问题。
描述：描述问题的严重性和对影响。
新建
活跃状态
当用户新建一个缺陷的时候，缺陷自动处于“活跃”状态，这意味着问题还没有解决。
在报告一个缺陷之前，测试人员最好先检索一下同样或类似的问题是否已经被发现了。如果发现的缺陷和已知的缺陷是一模一样，那就不用做任何事情；如果是类似，那就在原有的缺陷报告中说明新的情况.
<举例>
问题：如果大家都报告同样的缺陷，如何处理？
《只保留一个信息最全的，其他解决为“重复”，而且要在团队中避免大量一模一样的缺陷报告》
新建缺陷的原因
构建失败
构建失败， 缺陷中会列出构建的原因和指向构建日志文件的链接.
新建
新发现的问题。
由活跃到解决
一个缺陷在开发人员处理过后，或者会诊决定后，会成为“解决”状态。
原因
已修正
当新的代码已经签入到源程序库中. 在工作件中要把链接指向签入的修改集。
设计要求
产品就是这样设计的，系统和程序的表现是符合设计预期的。
推迟
如果在当前迭代（里程碑）中不能修正缺陷，只能推迟到以后的迭代去解决。
重复
如果有别的缺陷已经描述了同样的问题，这个缺陷就成为“重复缺陷”。应该在工作件中加一个指向另一个缺陷的链接。
过时
如果缺陷描述的问题在产品中再也不存在了。 例如如果相关的功能已经从不存在，则有关这个功能的缺陷可称为过时的。
无法重现
如果别人（开发者）不能重现所描述的问题。
由解决到关闭
原因
已修正
当缺陷已经被验证被修复.
设计要求
有关人员都同意所谓的问题是符合设计要求的.
推迟
如果测试人员同意推迟修复缺陷。
重复
测试人员同意另一个（更早发现的）缺陷描述了同一个问题。
过时
如果测试人员同意缺陷描述的场景或功能已经适用于产品了。
无法重现
如果测试人员不能重现问题，也不能提供更详细的步骤或其它信息来帮助重现问题。
由解决到活跃
原因
异议
对所做的决定有不同意见，不能接受目前的决定。测试人员可以提供详细并且有针对性的材料来表明立场，帮助同事达成正确的决定。
错误的解决方案
如果开发人员提供的新的代码是不正确的。同时详细说明为什么解决方案是错误的。
缺陷未解决
缺陷依然存在,  同时说明错误出现的构建版本。
关闭
关闭状态意味着所有有关这个缺陷的活动都告一段落。处于此状态的缺陷可能会被激活。
由关闭到活跃
原因
倒退
如果一个回归测试发现原来解决的问题又出现了, 这时就应该重新激活缺陷，把原因字段设为“倒退”.
1.8.4    服务质量需求
在一个软件产品中，有一些需求不能表达为功能，而是描述了软件产品要达到什么样的服务质量。如产品的效能，产品在负载状态下是否还能提供服务，可用性，压力，易用性，可服务性，可维护性等。（performance, load, availability, stress, accessibility, serviceability, and maintainability）. 这些需求通常表现为影响软件系统怎样运行的约束条件，我们称之为服务质量需求。
《专题描述这些服务质量需求》
新建
活跃状态
原因
新建
新建时都处于活跃状态.
活跃状态
服务质量需求在新建的时候是处于活跃状态。服务质量需求通常由了解用户需求的分析员来写，分析员在撰写服务质量需求的时候，要提供尽可能详细的细节内容。服务质量需求完成后，分析员把服务质量需求交付给开发组长，开发组长组织其他的开发人员实现这一服务质量需求.
正因为服务质量需求描述的不是一般的功能需求（如“网站管理员可以删除用户”），而是软件系统在特定环境中的运行状态和质量，开发团队要花时间了解用户的需求，制订测试计划和测试标准，建立和维护测试的环境。
由活跃到解决
原因
完成
开发人员把需求都实现了(至少认为实现了)。开发组长把需求交给测试人员.
推迟
在当前迭代中不能实现此需求。可能的原因有：没时间; 或其它的特殊事件阻碍了工作的进展。
分裂
当需要把一个大的需求拆分成几个小的需求时，创建新的需求，并和原有的需求保持链接关系。
取消
当需求再也不需要实现时。在这种情况下，要把出口标准设为“否”，因为不需要通过出口标准的考核。
解决状态
当实现了服务质量需求后，开发组长把此需求的状态设为“解决”，交付给相应的测试人员.
解决到关闭
完成
当产品通过了测试时，对于有些服务质量需求（如效能，负载测试），测试需要对每一个版本都进行测量以保证质量，并尽早发现问题。
推迟
测试人员同意推迟.
分裂
测试人员同意分裂此需求的决定。
取消
测试人员同意取消的决定。
由解决到活跃
测试失败
当测试失败时。同时，测试人员必须对每一个失败的测试新建一个缺陷。
关闭
如果所有测试通过了，或者测试人员对于解决的状态没有异议，则此服务质量需求就成为“关闭”。
由关闭到活跃
倒退
如果在测试中，原来通过的测试案例失败了，要重新激活此需求。
重新激活
原来被推迟的需求所在的迭代开始了，（躲得过初一，躲不过十五）。
1.8.5    风险
软件项目管理的很重要部分就是发现和管理项目与生俱来的种种风险. 所谓风险就是影响项目成功的任何可能发生的事件或情况. 当这些我们需要拿出实际的行动时，我们可以把风险分解成任务去平息或缓和这些风险, 例如，为了应付一个技术上的风险，我们可以创建任务做一个原形去实验一下. 团队应该鼓励大家及早发现风险，创造一个氛围，让那些喊“狼来了”的人不至于受到怀疑和猜忌。对风险保持积极的态度的团队往往能够更早，更成功地预见和管理风险.
[开心在一旁自言自语 – 这样讲下去，我们都有睡着的风险！]
新建“风险”工作件
新建的风险工作件处于“活跃”状态。风险应包括对于可能发生的事件及后果的描述和分析.  任何人都可以创建风险，但是风险交给谁？ 交给跟踪风险的人（简称“跟风”的人），通常是分析师，或管理人员。
活跃状态
原因
新建
初始状态.
活跃状态
活跃到关闭
原因
缓和
当团队可以采取一些措施来缓和或减轻风险带来的冲击。
不活跃
风险发生的可能性降到很低，可认为风险不会发生。
转移
风险转移到项目之外。风险并没有消除，只是转移到别的项目或团队中。
接受
当没法避免，减轻风险的时候。团队只好接受风险的挑战。
避免
由于种种原因，风险没有发生，这时 k work item can be closed as avoided.
关闭
关闭到活跃
重新激活
风险又出现了.
2005年3月6日 9:05
增加评论
标题: *
姓名: *
Url:
校验码请输入校验码！
评论:  *
Remember Me?
Powered by:

Copyright © 关心
_xyz