白话MSF 连载 2
// 故事情节纯属虚构
// 版权所有，不许转载，但是欢迎评论
// 背景： 阿超/国栋/小飞/大牛/丽丽/… 是移山公司一帮写软件的，正在琢磨VSTS 2005 和 MSF...
//
// 这是我正在写的书的一段 - 到此告一段落，欲知后事如何，且听下回分解。
posted on 2006-01-24 08:04:00 by xinz 评论(0) 阅读(4216)
白话MSF (7) 工作项
// 这是我正在写的书的一段：
// 故事情节纯属虚构
// 版权所有，不许转载
// 背景： 阿超/国栋/小飞/大牛/丽丽/… 是移山公司一帮写软件的，正在琢磨VSTS 2005 和 MSF...
//
MSF的工作项
[由国栋主讲] 工作项有以下的类型：
1.1 任务
任务太好理解了 – 要派人去干活. 对于团队中的每一个角色, 他/她的任务也有不同. 例如, 分派给程序员的任务一般是实现场景和服务质量需求； 测试人员的任务一般是编写和运行测试案例. ?我们也可以用任务来说明软件开发过程中的其他任务。
任务和缺陷的区别 – 有些团队喜欢只用缺陷类型来区分所有要做的事情和所有程序产生的缺陷，但是为了项目管理和交流的方便，我们建议用任务来表示预期要做的事，用缺陷来表示意外的结果。例如 – 阿超在签入代码后，他知道有些地方自己没有完全测试，他可以给自己分派几个任务去完成这些测试。
再如 -
写单元测试 – 这是任务，因为是可预见的，可事先安排的。
写单元测试 – 这是任务，因为是可预见的，可事先安排的。
测试在不同语言操作系统下的正确功能 – 这是任务，理由同上。
在上一个任务执行过程中，如果测试人员发现在某一语言的OS下功能不正确 – 这是缺陷，因为这是理应不发生的事情。
那么，假设上面发现的缺陷（号码 4097）被分派给阿超，那么阿超能不能新建一个任务 –
任务 5003 – 修改缺陷4097
这是不对的，应付意外发生的缺陷就应该在用原来的缺陷工作项去跟踪。
任务的状态转换
新建
要做某件事情一个新建的任务，一般在 MSF敏捷开发模式中会有三种任务：开发 任务，测试任务，其他任务。
新建的任务一经保存，它的状态就变成“活跃”。
当任务的所有者完成了任务，或者出现下列的原因之一，它的状态就变成“关闭”。
活跃到关闭的原因
|
完成 |
做完了. |
|
推迟 |
如果在当前的迭代（里程碑）中不能实现,? 例如没有足够的时间，或者有另外的问题出现，使任务得不到解决。在这种情况下，要将“迭代”字段设置成正确的值. |
|
无效 |
原来制定的任务不再符合实际情况. |
|
取消 |
和任务相关的功能已经被砍掉了. |
关闭
如果任务都已完成，
关闭到活跃的原因
|
重新激活 |
由于种种原因，原来关闭的任务又必须完成了。 |
1.2 场景
场景是工作项的一类，它记录了用户和系统互动的一个过程。当一个典型用户试图运用系统去做某件事的时候，场景纪录下用户为了达到目的所做的每一步骤.? 一系列有序的步骤称为路径，有成功的路径，也有不成功的路径。对于一个实际的系统来说，有成百上千的场景，因此要决定哪些场景是值得写的。
为什么要写场景？
场景如何转化成设计？
他和别的工作项类型是如何互动的？
场景如何转化成设计？
他和别的工作项类型是如何互动的？
|
新建场景 |
新建的场景状态是活跃的. |
活跃状态
场景开始的时候是处于活跃状态。 场景通常由了解用户需求的分析员来写，分析员在撰写场景的时候，要提供尽可能详细的细节内容。场景完成后，分析员把场景交付给开发组长，开发组长组织其他的开发人员实现这一场景.?
由活跃到解决状态
|
完成 |
当开发团队完成了实现场景的一系列功能. |
|
分裂 |
当需要把一个大的场景拆分成几个小的场景时，创建新的场景，并和原有的场景保持链接关系. |
|
推迟 |
?现在做不了。 |
|
取消 |
?如果场景再也不需要实现时，设为取消. |
解决状态
当实现了场景后，开发组长把此场景的状态设为“解决”，交付给相应的测试人员.
由解决到关闭状态
|
完成 |
通过测试. |
|
分裂 |
测试人员同意此决定. |
|
推迟 |
?同上. |
|
取消 |
?同上. |
由解决到活跃状态
|
测试失败 |
当测试失败时。同时，测试人员必须对每一个失败的测试新建一个缺陷。 |
关闭
如果通过了所有的测试，测试人员可以把一个场景的状态设为关闭。场景也可以变成关闭状态由于推迟，取消，或分裂.
由关闭到活跃状态
|
重新激活 |
如果出于某种原因，需要重新设计或测试场景时。 |
1.3 缺陷
一个缺陷就是软件产品中的问题，也叫bug，臭虫.? 新建一个“缺陷”的工作项的目的是要准确地描述问题所在。有两方面的信息必须提供：
重现步骤：就像重建犯罪现场一样，要一步一步准确地描述怎么能让别人也看到问题。
描述：描述问题的严重性和对影响。
新建
活跃状态
当用户新建一个缺陷的时候，缺陷自动处于“活跃”状态，这意味着问题还没有解决。
在报告一个缺陷之前，测试人员最好先检索一下同样或类似的问题是否已经被发现了。如果发现的缺陷和已知的缺陷是一模一样，那就不用做任何事情；如果是类似，那就在原有的缺陷报告中说明新的情况.
<举例>
问题：如果大家都报告同样的缺陷，如何处理？
《只保留一个信息最全的，其他解决为“重复”，而且要在团队中避免大量一模一样的缺陷报告》
新建缺陷的原因
|
构建失败 |
构建失败， 缺陷中会列出构建的原因和指向构建日志文件的链接. |
|
新建 |
新发现的问题。 |
由活跃到解决
一个缺陷在开发人员处理过后，或者会诊决定后，会成为“解决”状态。
原因
|
已修正 |
当新的代码已经签入到源程序库中. 在工作项中要把链接指向签入的修改集。 |
|
设计要求 |
产品就是这样设计的，系统和程序的表现是符合设计预期的。 |
|
推迟 |
如果在当前迭代（里程碑）中不能修正缺陷，只能推迟到以后的迭代去解决。 |
|
重复 |
如果有别的缺陷已经描述了同样的问题，这个缺陷就成为“重复缺陷”。应该在工作项中加一个指向另一个缺陷的链接。 |
|
过时 |
如果缺陷描述的问题在产品中再也不存在了。 例如如果相关的功能已经从不存在，则有关这个功能的缺陷可称为过时的。 |
|
无法重现 |
如果别人（开发者）不能重现所描述的问题。 |
由解决到关闭
原因
|
已修正 |
当缺陷已经被验证被修复. |
|
设计要求 |
有关人员都同意所谓的问题是符合设计要求的. |
|
推迟 |
如果测试人员同意推迟修复缺陷。 |
|
重复 |
测试人员同意另一个（更早发现的）缺陷描述了同一个问题。 |
|
过时 |
如果测试人员同意缺陷描述的场景或功能已经适用于产品了。 |
|
无法重现 |
如果测试人员不能重现问题，也不能提供更详细的步骤或其它信息来帮助重现问题。 |
由解决到活跃
原因
|
异议 |
对所做的决定有不同意见，不能接受目前的决定。测试人员可以提供详细并且有针对性的材料来表明立场，帮助同事达成正确的决定。 |
|
错误的解决方案 |
如果开发人员提供的新的代码是不正确的。同时详细说明为什么解决方案是错误的。 |
|
缺陷未解决 |
缺陷依然存在,? 同时说明错误出现的构建版本。 |
关闭
关闭状态意味着所有有关这个缺陷的活动都告一段落。处于此状态的缺陷可能会被激活。
由关闭到活跃
原因
|
倒退 |
如果一个回归测试发现原来解决的问题又出现了, 这时就应该重新激活缺陷，把原因字段设为“倒退”. |
1.4 服务质量需求
在一个软件产品中，有一些需求不能表达为功能，而是描述了软件产品要达到什么样的服务质量。如产品的效能，产品在负载状态下是否还能提供服务，可用性，压力，易用性，可服务性，可维护性等。（performance, load, availability, stress, accessibility, serviceability, and maintainability）. 这些需求通常表现为影响软件系统怎样运行的约束条件，我们称之为服务质量需求。
《专题描述这些服务质量需求》
新建
活跃状态
原因
|
新建 |
新建时都处于活跃状态. |
活跃状态
服务质量需求在新建的时候是处于活跃状态。服务质量需求通常由了解用户需求的分析员来写，分析员在撰写服务质量需求的时候，要提供尽可能详细的细节内容。服务质量需求完成后，分析员把服务质量需求交付给开发组长，开发组长组织其他的开发人员实现这一服务质量需求.?
正因为服务质量需求描述的不是一般的功能需求（如“网站管理员可以删除用户”），而是软件系统在特定环境中的运行状态和质量，开发团队要花时间了解用户的需求，制订测试计划和测试标准，建立和维护测试的环境。
由活跃到解决
原因
|
完成 |
开发人员把需求都实现了(至少认为实现了)。开发组长把需求交给测试人员. |
|
推迟 |
在当前迭代中不能实现此需求。可能的原因有：没时间; 或其它的特殊事件阻碍了工作的进展。 |
|
分裂 |
当需要把一个大的需求拆分成几个小的需求时，创建新的需求，并和原有的需求保持链接关系。 |
|
取消 |
当需求再也不需要实现时。在这种情况下，要把出口标准设为“否”，因为不需要通过出口标准的考核。 |
解决状态
当实现了服务质量需求后，开发组长把此需求的状态设为“解决”，交付给相应的测试人员.
解决到关闭
|
完成 |
当产品通过了测试时，对于有些服务质量需求（如效能，负载测试），测试需要对每一个版本都进行测量以保证质量，并尽早发现问题。 |
|
推迟 |
测试人员同意推迟. |
|
分裂 |
测试人员同意分裂此需求的决定。 |
|
取消 |
测试人员同意取消的决定。 |
由解决到活跃
|
测试失败 |
?当测试失败时。同时，测试人员必须对每一个失败的测试新建一个缺陷。 |
关闭
如果所有测试通过了，或者测试人员对于解决的状态没有异议，则此服务质量需求就成为“关闭”。
由关闭到活跃
|
倒退 |
如果在测试中，原来通过的测试案例失败了，要重新激活此需求。 |
|
重新激活 |
原来被推迟的需求所在的迭代开始了，（躲得过初一，躲不过十五）。 |
1.5 风险
软件项目管理的很重要部分就是发现和管理项目与生俱来的种种风险. 所谓风险就是影响项目成功的任何可能发生的事件或情况. 当这些我们需要拿出实际的行动时，我们可以把风险分解成任务去平息或缓和这些风险,?例如，为了应付一个技术上的风险，我们可以创建任务做一个原形去实验一下. 团队应该鼓励大家及早发现风险，创造一个氛围，让那些喊“狼来了”的人不至于受到怀疑和猜忌。对风险保持积极的态度的团队往往能够更早，更成功地预见和管理风险.
[大牛在一旁自言自语 – 这样讲下去，我们都有睡着的风险！]
新建“风险”工作项
新建的风险工作项处于“活跃”状态。风险应包括对于可能发生的事件及后果的描述和分析. 任何人都可以创建风险，但是风险交给谁？ 交给跟踪风险的人（简称“跟风”的人），通常是分析师，或管理人员。
活跃状态
原因
|
新建 |
初始状态. |
活跃状态
活跃到关闭
原因
|
缓和 |
当团队可以采取一些措施来缓和或减轻风险带来的冲击。 |
|
不活跃 |
风险发生的可能性降到很低，可认为风险不会发生。 |
|
转移 |
风险转移到项目之外。风险并没有消除，只是转移到别的项目或团队中。 |
|
接受 |
当没法避免，减轻风险的时候。团队只好接受风险的挑战。 |
|
避免 |
由于种种原因，风险没有发生. |
关闭
关闭到活跃
|
重新激活 |
风险又出现了. |
posted on 2006-01-24 07:52:00 by xinz 评论(0) 阅读(2601)
白话MSF (6) MSF 模型 及 MSF Agile
MSF 团队模型定义了小组同级成员的一些角色和职责，如下图：
MSF 团队模型的建立是基于这样一种前提，即任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。如果任何一个角色无法实现其目标，这都会将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同作出。相关的目标和角色见下面的表格。
表 1：MSF 团队模型和关键质量目标
|
关键质量目标 |
MSF 小组角色 |
出口条件 |
|
按约束条件内交付产品 |
程序管理 |
我们的项目是在时间/资源的条件内交付的么？ |
|
按产品规格说明交付产品 |
开发 |
我们是否按照功能说明完成了各项功能？ |
|
保证所有问题都得到处理 |
测试 |
我们发现了所有的问题，而且都有处理方案？ |
|
产品部署和后续管理 |
发布管理 |
客户是否能快速方便地部署产品和进行后续管理？ |
|
让产品更好用 |
用户体验 |
产品是否适应用户的使用习惯？易学易用？ |
|
让客户满意 |
产品管理 |
客户是否（在总体上）满意我们的项目？ |
说白了，一个项目要到达的目标很多，MSF 团队模型 把这些目标让不同的角色去实现。在一个项目结束的时候，每个角色都问自己这样的问题 – 我是否达到了我的质量目标？
最后比如 – 测试团队（角色：测试）要保证“我发现的所有问题都得到解决”，那么测试团队就会做以下的两件事：
1．发现产品的问题
2．保证这些问题都得到处理
要注意的是，保证这些问题都得到“处理”和得到“解决”是不一样的，有些问题目前不能得到完美的解决，但是可以有让用户满意的处理方案，项目团队不能回避这些问题。
问：我们发现了问题，但是我们目前的“处理”不能让用户满意，怎么办？
答：测试团队就要和别的角色（如: 产品管理/程序管理/开发）一起研究用户需求，在可能的方案中选出一个：
1． 按照目前的状态交付，向用户说明（如：在某个操作系统/浏览器版本下，某个功能不能正常工作）
2． 推迟交付时间，让团队有足够的时间来解决问题。
3． 修改产品的约束条件（如要求客户的操作系统/浏览器必须是某一个版本以上，或者增加一个附加条件，产品发布后半年会出新的插件解决问题）。
在讨论处理方案的时候，每个角色从自己的质量目标出发，对自己的质量目标负责。
问：那有冲突怎么办？
答：那就吵呗 （众笑）。各个角色的利益是有一定的冲突的，MSF 没有掩饰这一点。MSF 团队模型的核心是，成功的技术项目必须符合各种利益相关人完全不同的，且常常对立的质量观点。
问：这么说在团队中有矛盾是正常的了？
答：对！例如，用户代表觉得新增加一个功能很酷，因为新功能“让产品更好用”，但是程序管理角色觉得会影响“按约束条件内交付产品”的目标，测试会觉得“保证所有问题都得到处理”的目标受到威胁，用大白话说，就是“我没有时间测试你的新功能，因此不能加这个功能！”。这就要各方在整个项目的共同利益之下，协商解决。
问：我原来认为测试人员说“我没有时间测试你的新功能，因此不能加这个功能！”是态度问题，会被开发人员鄙视的。
答：这是对产品质量负责的态度，你要代表你角色的利益，如果你有充分的授权和信任，你就要直言不讳。
除了项目的各个角色之外，MSF 团队模型还可以推广到包括操作、业务和用户等外部因素。在对立中寻找共同利益，在冲突中达到平衡。MSF 团队模型推动了不同利益代表在追求共同利益过程中的融合。
MSF 过程模型
每个项目都要经过一个生命周期，下面是 MSF 过程模型生命周期的一个简图。
MSF 过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划的优势与螺旋模型中增量迭代的长处结合了起来。
MSF 过程模型的基本元素是阶段和里程碑。所谓“阶段”，就是在这一段时间里团队集中精力做某一类事情，每个阶段的结束都代表了项目的进展和团队工作重心的变化。比如在“开发阶段”结束后，团队就不再允许设计/实现新的功能，除非有充分理由的“变更请求”。
问：我觉得这样也太理想化了，一个十多人的团队，不可能在某月某日同时完成某一阶段，然后第二天进入下一阶段。
答：对，各个阶段之间会有缓冲区，团队中各个功能组的进度是各有区别的，不必强求一律。
团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现。
此外，里程碑标志着每个阶段的结束，团队在此时应该引导成员转移工作的重心，并鼓励队员以新的视角来看待下一阶段的目标。在上一个阶段产生的各种交付内容，将成为下一阶段的起始点。
MSF敏捷开发模式
在Visual Studio 2005中，MSF演化为以下两个分支：
- MSF 敏捷开发模式
- MSF CMMI 开发模式
我的感觉是，MSF敏捷开发模式吸收了近几年来在软件业界流行的各种“敏捷”开发模式的优点，认识到目前大部分软件是以网络应用相联系，强调和用户更紧密地交流，快速叠代，避免不必要的过程。
在继承MSF3.0 基本原则的基础上，MSF 敏捷开发模式和以前有什么不同？有以下几点：
-
更强调与用户的交流
项目的商业价值要由用户说了算，那些“我觉得用户会喜欢”的东西要及早和用户交流。因为“我觉得”和“用户觉得”是两码事。
小飞：我说一句可能不太中听的话，我觉得有时用户好像很，嗯，很蠢。和他们交流有时好像对牛弹琴。
二柱：那就派大牛去弹好了。。。
大牛：有这么几种情况：
用户也不懂他想要什么
有些用户只有一个模糊的需求，他们说：我们企业要上ERP！你给我整出来。这种情况下，我们得和用户一起做需求分析。
用户想要的和商业价值无关
比如有些用户说，我想让每个按钮都是半透明的，还要有三维效果，就像一些网络聊天软件一样酷！这些要求和他的企业管理项目的价值没有直接联系。也许这个用户代表是一头牛，而不是用户代表，我们要找管牛的人。
用户想要的我们还不懂
这种情况下，我们是牛，用户是对我们弹琴。
-
重视防患于未然
防止缺陷的发生成为团队质量控制的首要任务，所有的角色都对防止缺陷的发生，和确保缺陷被修复负责。
有一些团队把开发和测试有意无意地对立起来，好像二者是矛盾的，一个典型的例子是，有时开发人员不想给测试人员足够的信息，好像不想“帮”测试人员找到缺陷；测试人员一旦找到缺陷，会有一些得意的表示 – “看，你写的代码那么臭，我又发现了N 个bug”。
一个大公司内部作过统计，在一个中大规模的团队中，一个“缺陷”从发生到被改正，中间经过了10个人，平均花费的时间是60 分钟。 有时我们吹嘘 “我改正了 N多的bug”， 也许要自省一下为什么会出现这么多。 最好的事情，是可能的缺陷在设计阶段之前就讨论过，并且在代码中已经避免了，因此在“缺陷跟踪系统”中，并且没有出现很多缺陷记录在案。但是软件的质量仍然很高。
-
重视在实战条件下的质量
保持随时可以发布的高质量
如果用户说：时间到了，网站要上马，我们应该很快地交给用户一个可用的版本，也许有不少功能没有加入，但是版本中包括的功能都可用。
这就要求我们必须保证项目的质量是“随时可用”
重视产品的安装和发布 – 产品要尽早能够达到随时安装，发布。我们以前的项目中，安装和发布都是最后阶段才作，这就导致下列问题 -
1．在开发过程中，测试团队很难安装产品，阻碍了测试团队的进展。很多情况下，测试人员不得不从多个源头拷贝不同的文件到测试环境中，才能测试
2．很多关于安装的缺陷得不到重视 – 用户拿到一个Beta 版，意见最大的就是 - 安装不上！或者好不容易装好了，却卸载不了，不得不重新安装系统。
二柱：好像这个VSTS 早期的版本就有这个问题，真是具有讽刺意义呀。
鼓励团队在实战条件下使用产品，就是“吃自己的狗食”，或者叫“自作自受”。大栓说：所谓“dogfooding”，也不难理解，比如我们小学食堂的伙食都很差 – 可以和“狗食”媲美。 （众人大笑），但是食堂职工无动于衷，因为食堂的领导和职工都是吃自己的小灶。如果食堂的领导实行“dogfood”，身体力行，和食堂员工一起吃给学生做的大锅饭，大锅菜。我想这个问题应该很快得到解决。
小飞：我们要做的项目，怎么dogfood?
大栓: 那我们就自己注册成为用户和商户，然后在系统上作一些交易吧。
阿超：这就要求我们的安装程序能够随时安装最新的版本，同时对于我们服务器端的数据迁移提出了很实际的要求。
实战条件下的质量的另一方面是 - 进行经常性的迭代（小的里程碑），使用户能够及时看到产品，给予评价。
问：这不就是快速原型法？
答：这不完全等同于快速原型法，用户看到的功能应该是能够马上使用的，而不只是一个原型。
-
精简过程，直奔主题
我们一帮人在吭哧吭哧干活是为了什么? 主题是什么？是为了解决用户的问题。用户给项目投资了成千上万，不是为了看到一堆过时的文档。
同样，在团队成员之间的交流要简明，不必为了交接而搞出许多文档。另外一个重要的因素是 – 如果团队在整个软件生命周期都使用团队协作服务器（TFS），那么很多活动，决定，文档都自然地记录在TFS 上，不必额外去为了文档而再写一些东西。
// 这是我正在写的书的一段
// 故事情节纯属虚构
// 版权所有，不许转载
posted on 2006-01-24 07:36:00 by xinz 评论(6) 阅读(4189)
白话MSF (5)
1.1.7 投资质量
对质量的重视，导致对质量的投资，导致对人，过程，和工具的投资。
[问：为什么叫投资？干脆叫“质量第一”，或者“全面质量管理”不就完了么？]
答：之所以叫“投资”，是很有道理的。听我慢慢道来：
1．投资要讲效率。软件开发过程大部分时间花在 了解/设计/变更/再了解/再设计的过程中。我们要重视质量，但是我们并不是要不惜一切代价达到最高的质量标准，（下面有人倒吸了一口凉气），因为想提高人/过程/工具的质量是要花成本的！我们不是为提高质量而提高质量。我们要讲投资的效率。比如 - 在作快速原形的过程中，有些部分可以做的粗糙一点。
2．投资要讲时机，比如说对于某项技术的培训，最好的做法是在快要需要的时候进行培训。太超前或滞后都不灵。
3．投资是长期的。和投资股票/不动产一样，正真的投资是长线的收益；人的成长，团队的成熟都需要时间，不可能短期内立竿见影。那些“短平快”的东西，叫投机，不叫投资。
所以，MSF 没有提“质量第一”，或者“全面质量管理”，我希望移山公司不是质量第一，而是解决用户的问题第一。我也不希望移山公司是“全面质量管理”，因为“全面”之后，会出现“大道废，有仁义”的现象，大家都讲“全面质量管理”，往往意味着我们的质量管理没有抓到点子上。而且有些庸人往往会以“要达到高质量”为由，阻碍正常的工作进程。
大牛：对，现在社会上到处讲诚信。。。 [在此略去大家对社会现象的讨论5000 字]
《歌曲 - 正如对爱的追求，对高质量的追求也是有代价的 <Link> 》
1.1.8 学习所有的经验
古今中外，人们对经验的学习还是比较重视的，我们经常听到“忘记过去的人注定会重复过去的错误”等等类似的谚语。咱们中国的老祖宗也没少唠叨，哪位能提供一些成语典故？
“数典忘祖”
“好了伤疤忘了痛”
“一朝被蛇咬，十年怕井绳”。。。
停！“一朝被蛇咬，十年怕井绳”并不是“学习所有的经验”，而恰恰是没有学习，不敢分析蛇和井绳的区别。
那为什么在软件开发中我们往往没有吸取前人的经验教训？
“没时间”
“每一个项目都有自己的特色，不宜生搬硬套”
“项目的经验都在各人的脑子里”
“项目结束后，大家都散伙了，没人组织总结，或者写总结的人有偏心”
“有时总结变成互相指责，搞得不欢而散。。。”
这一原则有两个部分：
- 把经验总结出来
- 分享经验
为什么要坚持总结和分享？
- 让团队成员从别人的成果和失败的例子中学到东西
- 帮助新项目重复以往成功的做法
- 培育团队总结的习惯和“批评与自我批评”的文化
MSF 在每一个里程碑结束时都要做一个“里程碑回顾”而不必等到整个项目结束，这样做的好处是大家都对最近的成败都记忆犹新，能提供比较准确和全面的反馈；如果发现错误，可以马上研究解决办法，在下一个里程碑中验证。另外，一些好的做法可以及时得到总结和推广。
在项目结束时，MSF 推荐请团队以外的专家来主持召开“事后诸葛亮”会，这样的专家会比较系统地总结团队的成功经验和失败教训，同时也客观的评价团队的一些特性和团队的开发过程管理，这样能促使团队成员以客观，向前看，解决问题的心态来参加“事后诸葛亮”会，避免主观臆断或相互指责。
《歌曲：?》
posted on 2006-01-13 05:09:00 by xinz 评论(1) 阅读(2488)
白话MSF (4)
1.1.5 重视商业价值
我们都是搞技术的，但是我们同时也是一个商业实体，我们的项目都应该是出于商业目的，如果没有商业的需求，再酷的技术也没有用。
[大牛： 我们村的技术在这一带是有口皆碑的，王屋河水流经之处，人们都知道王屋村的年轻人是.net的好手，这是我们的品牌呀。]
一个沉溺于技术而忽略商业价值的团队，就像盲人骑烈马，跑起来很拉风，但最终不免人仰马翻。
[小飞： 那答答的马蹄，是个美丽的错误，他不是归人，他只是过客，因为他不知道他的情人在楼上等他。]
《歌曲：? 还不明显么？》
回首望去，很多“高科技”的公司就是过客。怎么样衡量一个项目的成功？并不是最酷的技术，而是商业的成功。
一个项目的商业价值只有在它被成功地发布并运行时才能体现出来，所以，MSF 过程模式包括了开发和发布阶段。
问：我经常听说“激情”才是最重要的，大拿们当初都是激情万丈，代码如泉涌。。。
答：激情可以被激发出来，也可以消失，或移情别恋；而且激情因人而异。当项目遇到困难的时候，当项目看不到尽头的时候，有人就会问世间激情为何物，能叫我每天加班？一个团队项目如果没有经得起考验的商业价值，没有明确的远景，是很难坚持下去的。
“Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain.”
(Joel Spolsky, http://www.joelonsoftware.com/articles/Micro-ISV.html )
类似地，如果我们没有搞清楚我们的项目会解决什么问题，为谁解决了问题，为什么它会解决问题，以及怎么拿到客户的报酬，那我们的项目还不能开始。
问：但是正如你所说的，我们都是搞技术的，那么怎么样能保证我们“重视商业价值”？
答：在MSF 团队模型中，“用户体验”这个角色代表了用户的利益，保证产品能真正易于使用；“产品管理”这个角色代表了客户的利益，保证了我们的产品能为顾客提供商业价值。作技术的，要尊重这两个角色，因为他们代表的是我们的衣食父母。
小飞：我们的激情会变，但是大牛才是变得最快的，他隔三岔五跑来说：客户有点新想法，我们要做一些小改动。。。
大牛：那怪不得我，是咱们的“衣食父母”提出来的。
阿超：这就扯到下一个原则 -
1.1.6 保持敏捷，预期变化
软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一时刻很明确，然后保持不会变。要注意，我们是预期变化，不是期望变化。
除开外部原因，团队内部也在变化，我们对技术的掌握每天都在提高，原来认为不可能的事可能变得容易，原来觉得没问题的小细节成了大问题。这些都要求我们保持敏捷的身段。
大牛：最近业界有人总结，项目需求的生存期是18个月，就是说如果一个项目的需求是18个月前确定的，而产品还没有做出来，那几乎就可以不做了，因为需求肯定已经不存在了。
阿超：大家有没有注意到微软的一些成功的项目之间也是间隔18/24个月。
小飞：那为什么SQL Server 要五年后才更新？
阿超清了清嗓子，哪位能分析一下？
我们可以想象一下：在2000 年的时候，某个产品说我们一定要支持win2000 和win9x 平台，因此产品组做了不少技术攻关，保证代码同时可以在两个平台上运行，代码复杂度也上去了，测试组也大力气要“保证所有问题都得到处理”，两年过去了，2002年，大家终于实现了预期目标。然而产品并没有发布，winXP/win2003 正是时髦的时候，大家开始讨论是否有必要保持win2000/9x 的一致性，因为增加了开放和测试的难度；到了2004 年，当时的决定看起来像一个笑话，我们还没有发布，管理层开始讨论是否砍掉win9x 的测试预算。2005年，产品终于发布了，这时谁还关心win9x 和 win2000 呢？当初的投资有回报么？
[问：既然总会变，那么似乎没有必要在每一步骤都保持高质量？]
答：你的潜台词是因为变了之后，以前做的事就没有意义了。但是高质量在任何时候都是有益的，低质量的工作，会误导客户和团队，也许会导致错误的变化。达到高质量是有代价的，关键是要给客户提供及时，准确的信息，根据客户的反馈进行修改。质量是重要的，但是如果你的功能不能满足客户不断变化的需求（注意是‘不断变化的需求’） 那么再高的质量也没有用处。软件的质量在敏捷的开发流程中是处于什么样的地位？请看下一节。
<歌曲：?>
posted on 2006-01-13 05:02:00 by xinz 评论(2) 阅读(2369)
白话MSF (3)
1.1.3 充分授权和信任
这一点的关键是这个词：
Empower:
|
1. |
give authority to somebody: to give somebody power or authority |
|
2. |
Inspire somebody with confidence: to give somebody a sense of confidence or self-esteem |
在一个高效的团队中，所有的成员应该能得到充分的授权，他们有权力在自己的职权范围内按照他们自己的承诺完成任务，同时，他们也充分信任其他同事也能实现各自的承诺。类似地，团队的顾客（包括内部和外部的顾客）也能够认为团队能兑现承诺，并进行相应的规划。
[问：这样做好像很危险哪！]
[阿超：那应该怎么办？采用“命令”的方式?!]
充分授权的管理方式是 MSF 的核心观念之一 。MSF 团队模型就是建立在以下两个的原则上：
平等协作 – 成员之间，团队之间是平等协作的关系
充分授权与团队和成员。
这就是为什么MSF团队模型是网状，而不是层次结构。
这样做有什么好处？
1．被授权的人会承担起自己对项目的责任，同时也期望同事们也同样对项目负责。
2．MSF 提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，这意味着真正作这件事的人按照自己的估计去完成任务。这样做的结果是啥？人人都会支持项目的计划和时间表，因为这个时间表是每个人自下而上订出来的！
[问：听上去很美，但是我作为一个组长，给我的组员充分授权，到头来发现事情都没做完，咋办？我只好不断的问：你做到哪里了，还差多少？]
[答：这要靠工具的支持，在VSTS 系统中，由于所有工作的进展都记录在案，任何延迟都会被及时发现，这样组长（或其他层次的领导）就不用把精力花在“问”，而在“帮助解决”，在最关键的时候提供指导和帮助。领导在项目工程中的角色是“支持成员完成任务”，而不是“控制成员，迫使他们完成任务”。]
充分授权在MSF 团队模型的另一个含义是，信任，鼓励团队成员成长，每人都可以在某一时段，某一领域当领导。比如二柱是程序安全性的专家，他就可以带领其他成员对项目进行安全性检查。如果测试工程师阿毛刚刚学习了如何做压力测试，他可以带领其他测试人员对产品进行全面的压力测试。
[国栋： 能不能推而广之，如果企业的各级领导秉持充分授权的信念，让员工觉得被充分授权，而对工作产生热情，积极，进而能够充分发挥自我潜力，企业整体即能够产生良性循环。]
[大牛：这一原则还对企业传统招人，用人的方式有冲击，我觉得这是MSF 最难在中国公司实行的一部分，“授权”，“放权”的管理理念和很多公司的企业文化不相符。]
[二柱：我早就说过MSF 在中国不灵的啦。 另外，充分授权之后，领导是不是显得有点没用了呢？]
小飞：如果团队很厉害，领导就会升上去喽！
阿超：这个我也不知道，如果我能证明我的人马很厉害，甚至显得我都没有什么必要，那我倒是可以做一些更无足轻重的事了。。。
小飞：比如说总裁什么的。
《歌曲：》
1.1.4 各司其职，对项目共同负责
每个角色有自己的职责（见表），如果出了问题，这个角色就要负责任。
表 1：MSF 团队模型和关键质量目标
|
关键质量目标 |
MSF 小组角色 |
出口条件 |
|
按约束条件内交付产品 |
程序管理 |
我们的项目是在时间/资源的条件内交付的么？ |
|
按产品规格说明交付产品 |
开发 |
我们是否按照功能说明完成了各项功能？ |
|
保证所有问题都得到处理 |
测试 |
我们发现了所有的问题，而且都有处理方案？ |
|
产品部署和后续管理 |
发布管理 |
客户是否能快速方便地部署产品和进行后续管理？ |
|
让产品更好用 |
用户体验 |
产品是否适应用户的使用习惯？易学易用？ |
|
让客户满意 |
产品管理 |
客户是否（在总体上）满意我们的项目？ |
比如说，如果产品发布后，客户在部署和管理上出现了很多问题，那负责“产品部署和后续管理”的角色 -发布管理- 就要站出来对此负责。
与此同时，各个角色合起来，对项目整体最终的成功负责，为什么？因为每个角色在其职责范围内的失败都会导致整个项目的失败。而且各个角色的工作都是互相渗透，互相依赖的。这种互相依赖的方式也鼓励团队成员在自己本职之外为其他领域作贡献。例如：测试人员可以帮助“用户体验”角色更好地设计用户界面，因为如果用户界面很差，再好的功能也不能发挥应有的作用。
在项目进展的过程中，对于每一项任务，每个人都要明确以下几点
Who: 谁负责
What: 做什么，具体的执行方案，
When: 什么时候开始，什么时候结束，
Why: 为什么是这样安排（和项目的远景是否吻合？），在什么情况下可以变更？
和“开放的沟通”原则相呼应，这样的安排能让所有人都明确自己的职责，同时有“大局观”- 知道别人在做什么，为什么，以及整个项目的目标。
《歌曲：》
posted on 2006-01-13 04:58:00 by xinz 评论(3) 阅读(2736)
白话MSF (2)
1.2.2为共同的远景而工作
阿超：大家是怎么理解的？
[这就是所谓同心同德。兄弟同心，其利断金。我们当然是同心的啦，大家都是哥们，都为了移山公司的兴旺才来的]
好，但是这里面提到一个“共同的远景”，这是什么玩意？
[就是我们移山公司以后要发！]
发是肯定的，大家注意这个“共同的远景”是指产品的远景。我们做一个产品，不管是应用软件，行业软件，还是通用软件，我们要明确我们项目的目标是什么。
1．这个目标必须是明确的，没有二义性；
2．这个目标不是当前就能达到，必须是通过努力才能达到的；
3．这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。每天你来上班，如果发现你做的事情和项目的远景没有帮助，你应该跟老板提出来。
[我们有些项目好像没法订出来这样的目标耶，或者老板也不清楚我们到底要干什么]
那么很显然这些项目的带头人没有及格，这些项目最后没有达到预期的目标，也就不奇怪了，因为我们连预期的目标是什么都没有搞清楚。
[阿超 – 能举例说明么?]
比如我们村里曾经有个体育新闻网站，当时它的远景号称是
“移山体育网提供即时，准确的体育新闻，它提供论坛，体育用品购物网络，使得体育爱好者能享受一个公平，健康，安全的交流环境”
刚开始做得不错，我也经常光顾访问，但是后来好像新闻和论坛的质量都下降了，购物网页没有下文，几次改版之后，占据头条的经常是关于体育明星的小道消息，和他们传说中的女友的传说中的三围尺寸，还有李村中上层人士争喝某种饮料的消息等等。我一直想问谁是主编？
大牛举起手，说：刚开始，我每天做的事还是和我们最初的远景相吻合，人气也不错，后来我们觉得什么能吸引眼球就上什么，慢慢搞成了四不像，名声也搞坏了。我们的内部远景已经改为 -
“移山体育网要吸引眼球和广告，直到找到买家为止”
[大栓：大牛，你们啥时候改的远景？我怎么不知道？]
[大牛：这个要问阿昌…]
阿超 – 这样的远景也不见得错，但是不要忘了我们讲的是“共同的远景”，团队的领导人要让全体成员都同意项目的远景，并为之奋斗。如果一部分人还为远景1.0 而奋斗，但是另一半人却在为远景2.0 努力，那是要出乱子的。
另外，如果没有“共同的远景”，即使团队发布了产品，不同的成员对项目是否成功，以后如何发展，也会有不同的看法，因为他们心里的远景是不一样的。
[问：远景是由领导决定，还是自下而上形成的？]
[答：一般是由“有远见的人”提出，然后公开讨论，在讨论的过程中，可以消除误解，凝聚共识。这是一个项目的关键，是项目第一阶段要达到的主要目标]
[二柱：这是不是俗话说的“统一思想”，或者另一个俗话说的“洗脑”？]
[答：可以这样看，但是我们下面要说另一个基本原则，需要你的大脑有原创精神]
《洗脑归洗脑，我要用这首歌曲表达洗脑后的心情。。。》
posted on 2006-01-12 07:51:00 by xinz 评论(0) 阅读(2844)
白话MSF 连载
// 这是我正在写的书的一段：
// 故事情节纯属虚构
// 版权所有，不许转载，但是欢迎评论
// 背景： 阿超/国栋/小飞/大牛/丽丽/… 是移山公司一帮写软件的，正在琢磨VSTS 2005 和 MSF...
//
[国栋：超总，听说你要讲MSF，我就先预习了一下，但是MSF 的名词太多了，我真是头大，能不能解释一下这两句：“MSF 的一个基础原理是 学习所有的经验。这一原理在 MSF 过程模型 里的关键里程碑上得到了充分的应用，在过程模型里 愿意学习 这一关键概念成功应用这一原理所需要的。愿意学习这一概念通过 后里程碑回顾的经过检验的做法在项目里得到体现。在大型的和复杂的项目里，Microsoft 建议 是利用客观的外部服务商来确保有一个无过错的环境，并把学习最大化。”]
[阿超：你从哪里找到的绕口令？]
[国栋：MSDN 中文官方网站呀。]
果然，阿超在网上找到了文章和这一段，
http://www.microsoft.com/china/technet/itsolutions/techguide/msf/msfovrvw.mspx
他和国栋一起读了两遍，想找出各个句子的主语，谓语，和宾语，最后叹了一口气说：本来MSF挺简单明了的，这样一搞，反而很神秘晦涩。国栋，你不用预习了，我会搞一个“白话MSF”，你一听就懂。
隔壁的小飞探过头来：国栋，听到你还预习，我差点晕倒。
阿超：你说应该怎么学习呢？
小飞：好不容易出了学校，我现在对‘学’好像兴趣不大，什么东西过耳就忘。
国栋：好像流行歌曲的歌词你记得很牢嘛。
小飞：如果是载歌载舞，那倒印象深刻。可惜呀，MSF 。。。能不能在KTV学MSF? 都是3个字的英语缩写，应该是兼容的吧。
阿超：也许不妨一试，MSF 的每个基本原则，领会其精神之后，可以用一首流行歌曲代表，怎么样？
白话MSF(1) 推动开放的沟通
白话MSF(2) 为共同的前景而工作
白话MSF(3) 充分授权和信任 | 各司其职，对项目共同负责
白话MSF(4) 重视商业价值 | 保持灵巧，预期变化
白话MSF(5) 投资质量 | 学习所有的经验
posted on 2006-01-12 06:18:00 by xinz 评论(14) 阅读(8153)
白话MSF (1)
[阿超/国栋/小飞/大牛/丽丽/… 是一帮写软件的，在琢磨VSTS/MSF]
[国栋：超总，听说你要讲MSF，我就先预习了一下，但是MSF 的名词太多了，我真是头大，能不能解释一下这两句：
“MSF 的一个基础原理是 学习所有的经验。这一原理在 MSF 过程模型 里的关键里程碑上得到了充分的应用，在过程模型里 愿意学习 这一关键概念成功应用这一原理所需要的。 愿意学习这一概念通过 后里程碑回顾的经过检验的做法在项目里得到体现。在大型的和复杂的项目里，Microsoft 建议 是利用客观的外部服务商来确保有一个无过错的环境，并把学习最大化。”]
[阿超：你从哪里找到的绕口令？]
[国栋：MSDN 中文官方网站呀。]
果然，阿超在网上找到了文章和这一段，
他和国栋一起读了两遍，想找出各个句子的主语，谓语，和宾语，最后叹了一口气说：本来MSF挺简单明了的，这样一搞，反而很神秘晦涩。国栋，你不用预习了，我会搞一个“白话MSF”，你一听就懂。
身后的二柱说：是不是有意翻译得这么烂，让我等不得其门而入，以延缓我国IT大业的发展，呵呵？
隔壁的小飞探过头来：国栋，听到你还预习，我差点晕倒。
阿超：你说应该怎么学习呢？
小飞：好不容易出了学校，我现在对‘学’好像兴趣不大，什么东西过耳就忘。
国栋：好像流行歌曲的歌词你记得很牢嘛。
小飞：如果是载歌载舞，那倒印象深刻。可惜呀，MSF 。。。能不能在KTV学MSF? 都是3个字的英语缩写，应该是兼容的吧。
阿超：也许不妨一试，MSF 的每个基本原则，都可以用一首流行歌曲代表，怎么样？
白话MSF
1.1 简介
MSF 就是微软推荐的做软件的方法。
1.1 简介
MSF 就是微软推荐的做软件的方法。
简史：
1994年，基于微软产品开发的经验和教训以及微软微软咨询服务的业务经验，微软推出了Microsoft? 解决方案框架 Microsoft Solution Framework (MSF)。当时的MSF只是这些经验教训的松散集合。在以后的几年中，MSF 进一步吸收了微软各个部门和微软的合作伙伴在实际项目中的经验，在2002年，随着Visual Studio.Net 的发布，微软发布了一系列关于MSF 3.0的白皮书，针对MSF 3.0 的大规模培训也在中国开始。
2006年，MSF 4.0 随着Visual Studio Team Foundation 2005 发布。它增加了不少敏捷开发的内容，并且明确刻画了团队典型的流程和在新的团队协作软件包VSTS 中的应用。
[国栋：哪一年出的2.0呢?]
[阿超：我们关心么?]
[丽丽：国栋是怕到时考试会考到这一题吧]
我们可以不用管MSF 演化的细节，要记住所有模式都不是一成不变的，关键是要掌握变化的原因。
1.2 基本原则
MSF 的核心有八个基本原则：
MSF 的核心有八个基本原则：
推动开放的沟通
为共同的前景而工作
充分授权和信任
各司其职，对项目共同负责
重视商业价值
保持敏捷，预期变化
质量投资
学习所有的经验
1.2.1 推动开放的沟通
用大白话说，就是所有信息都保留，并公开，讨论要包括所有方面，决定要公开，并通知所有人。当然，牵涉到技术保密，安全性等信息要有必要的保护措施。
问：我们以前都是“老板让你知道，你就会知道，别多问，看起来比较好控制吧？”
答：以前大家两三个哥们一起鼓捣软件，大家都知根知底，好像没有意识到“沟通”的重要性，但是随着项目复杂度和团队规模的增加，没有开放的沟通是万万不行的。
问：如果有一些事情，我个人也没拿准是不是要通知某一方面的人员，怎么办？
答：在这种情况下，宁愿过分沟通。另外，在TFS中，所有和项目有关的信息都会保存起来。
例如：
所有工作件及其历史，
所有源代码的修改记录
一个经常问的问题是：在TFS中，我为什么不能删除工作项？
答案很简单 – MSF 的第一原则：所有的信息都保留，并公开。
大牛：有人犯了一些比较愚蠢的错误，TFS把它们都记录下来了，从个人角度，有人会说“我知道我做错了，已经改正，那最好把原来的记录删除了吧”，这样做，不是有利于打造和谐的团队么？
阿超：记录留下来，可以做事后分析，给后来的同事，或者别的项目的同事学习。如果删除，那也就违反了第八条原理“学习所有的经验”。我们公司要建立“对事不对人”的文化，好像有一句古话，把人的错误比做日食。。。
国栋：子贡曰：“君子之过也，如日月之食焉：过也，人皆见之；更也，人皆仰之。” 还有，“人谁无过？过而能改，善莫大焉。”
我们以前关于项目的好多事，都装在几个头头的肚子里，最开放的，也不过是把一些问题列在EXCEL 文件中，但是也没有历史记录，看不到所有信息，那么项目进度以及项目中存在的各种问题就不能及时让所有人知道，这样MSF中其他的原则也就不能实行了。没有开放的信息，也就谈不上“授权”，或“建立清晰的责任和共同的职责”，“保持灵巧，预测变化”。这也是为什么“推动开放的沟通”是第一个基本原则。
MSF 团队模型和MSF过程模型也是建立在“开放的沟通”原则上。
小飞： 我有歌一首，献给“开放的沟通”。
<歌曲：<猜>>
posted on 2006-01-12 06:05:00 by xinz 评论(8) 阅读(5648)
天下小酒馆换代人
今天，微软亚洲研究院参加了在中国大饭店举办的“Windows 创新日”活动。从新年前就开始和同事们忙着这件事，今天终于交差了。也不是什么大事，就是：
一个介绍微软研究院的演讲 （link）
组织了八个体现研究院近期研究成果的 demo, 这些demo 明天还能看到。 我听到有人评论其中一个demo 是他此行最大的收获。
这次活动所有的演讲都被叫做“课程”，我个人觉得最有收获的方式还是“讨论”，但是会场上黑压压一片，聚光灯都照在台上，我只能依稀看到前排的几个人，（有两位还一直处于半睡眠状态），也没法进行讨论。课后在讨论区和几个听众聊了聊，很有收获，其中一位艾克斯特公司的孙先生还认出我叫“关心”。
展厅上有一块巨长的展板，上面列出了DOS/Windows 三十年发展的各个里程碑，各个产品的渊源关系，一目了然，不知道谁有相片或图表?
八个demo 中有一个是中文对联工具，我出的上联是
“中国大饭店创新日”
程序很快就给出了20 多个对仗工整的下联，其中一个是
“天下小酒馆换代人”
大家都乐了。
大饭店，小酒馆，操作系统，都到了换代的时候了。
posted on 2006-01-06 06:46:00 by xinz 评论(4) 阅读(4681)