摘要: [在从word 拷贝到blog 中出现不少排版问题，特此致歉. 所有内容均属个人意见，没有任何担保或授权，以"现状"提供。 版权所有] 1        软件测试和VSTS 测试工具 本部分介绍各种测试类型，以及它们在VSTS 2005中的应用。   在学习讨论之前，阿彪问大家：我有一个闷在心里好久的问题 – bug到底翻译成什么最好？ 杂曰：     臭虫，缺陷，错误，地雷，应用程序异常，     就用bug好了，大家都理解！   小强！小强！   大家回头一看，阿毛红着脸说：我们宿舍里有不少小强，每晚自习回去都要打小强。。。 众大笑。 阿彪：我倒是不反对用“小强”。 阿超：好是好，VSTS也支持改工作项的名字。就怕我们以后招进来名字中有“强”的同学。 阿彪：我觉得我可以为“小强”花一颗银弹，我们以后就把“小强” 当作bug的同义词. 小飞：那我们怎么翻译“bug fix”?  翻译成“针对缺陷的修改”也太绕口了。 阿毛：我们是用拖鞋来打小强，所以不妨称之为“拖鞋”。 （大笑） 国栋：我反对把软件工程的术语生活化。。。     阿超：说到测试，大家肯定有不少了解，也保不准有一些误解，我们这个讨论就是要去伪存真，把大家的理解统一到一个水平上。大家知道的“测试方法”有多少？   杂曰：            Black box Test, White box Test            Code Coverage, Test Unit Test            Functional Test, Structural Test            System Test, Performance Test            Stress Test, Load Test            Acceptance Test, Regression Test            Ad hoc Test, Integration Test            Alpha/beta Test, Localization/Globalization Test            Security Test, Accessibility Test, Scenario Test,            Usability Test,Smoke Test   二柱：这么多！把我都忽悠得有点晕了。看来我国软件测试人才真是大有用武之地了。 小飞：这么多名词，是得学几年的，写程序的方法怎么没有这么多花头？   阿超：咱们还是一个一个来吧。 这么多名词只不过是从各个方面描述了软件测试，并不是说有这么多独立的测试方法，我们把它们分类处理就不难了。 1.1     从测试设计的方法分类 从测试设计的方法来看，我们知道有两类方法： Black box (黑箱) White box (白箱) 这是每个接触过软件测试的人都会给出的答案。但是这只是整个软件测试的入门。我们可以跳过去，直接讨论下面的内容。。。   问：我在网上看到有人争论黑箱测试和白箱测试哪一个是另一个的基础，还有那一个更难，那一个更有前途，等等。据说李村数码在搞“灰箱测试”，是不是更高级？能不能简单讲一讲？ 阿超：大家都有这些问题么？ 杂曰：[略去对此问题热烈的争论500 字] 阿超：听了大家的争论，看来我们的确得花不少时间统一认识.   第一个要注意的问题是，所谓黑箱/白箱，是软件测试设计的方法，不是软件测试的方法！注意“设计”二字。   黑箱：在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”, 从软件的行为，而不是内部结构出发来设计测试。 白箱：在设计测试的过程中，设计者可以“看到”软件系统的的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。“白箱”并不是一个精确的说法，因为把箱子涂成白色，同样也看不见箱子里的东西。有人建议用“玻璃箱”来表示。   在实际工作中，我们不应画地为牢，严格只用某一种方法来设计测试方法。在实际的测试中，当然是对系统了解的越多越好。所谓“灰箱”的提法，正是这一反映。有些人甚至希望我们全部忘记“箱子”和它们的颜色。   我们并不是要禁止懂得内部构造的人员来进行黑箱测试设计，只不过我们在设计时有意不考虑软件的内部结构。例如：在测试程序内部基本模块的时候（单元测试），我们通常是要求对程序结构非常了解的程序员来设计，这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基本模块的“行为”通常没有明确的定义。另一个例子是“可用性测试”，在设计此类测试的时候，我们没必要纠缠于程序的内部结构，而是着重于软件的界面和行为。但是软件可用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和 “白箱”没有简单的高低之分。   一旦测试用例写出来之后，我们大可以忘了它们是从那种颜色的箱子里出来的，用它就可以了。 1.2     功能测试 以下的测试术语都是主要测试软件的功能。在下表所列的测试中，测试的范围有小到大，测试者也由内到外 – 从程序开发人员（单元测试）到 测试人员，到一般用户（Alpha/Beta 测试）。   测试名称 测试内容 Unit Test 单元测试 – 在最低的功能/参数上验证程序的正确性 Functional Test 功能测试 – 验证模块的功能 Integration Test 集成测试 – 验证几个互相有依赖关系的模块的功能 Scenario Test 场景测试 – 验证几个模块是否能够完成一个用户场景 System Test 系统测试 – 对于整个系统功能的测试 Alpha/Beta Test 外部软件测试人员（Alpha/Beta 测试员）在实际用户环境中对软件进行全面的测试。                 1.3     非功能测试 一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“non-functional requirement”, 或者“quality of service requirement”- 服务质量需求。没有软件的功能，这些特性都无从表现出来，我们要在软件开发的适当阶段做这些测试。 比如： 测试名称 测试内容 Stress/load test 测试软件在负载情况下能否正常工作 Performance test 测试软件的效能 Accessibility test 测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能 Localization/Globalization Test 本地化/全球化测试 Compatibility......[阅读全文]

摘要: 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 上，不必额外去为了文档而再写一些东西。   《其他白话 MSF 文章》 // 这是我正在写的书的一段// 故事情节纯属虚构// 版权所有，不许转载...[阅读全文]

摘要: // 这是我正在写的书的一段：// 故事情节纯属虚构// 版权所有，不许转载// 背景： 阿超/国栋/小飞/大牛/丽丽/… 是移山公司一帮写软件的，正在琢磨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 风险 软件项目管理的很重要部分就是发现和管理项目与生俱来的种种风险. 所谓风险就是影响项目成功的任何可能发生的事件或情况. 当这些我们需要拿出实际的行动时，我们可以把风险分解成任务去平息或缓和这些风险,?例如，为了应付一个技术上的风险，我们可以创建任务做一个原形去实验一下. 团队应该鼓励大家及早发现风险，创造一个氛围，让那些喊“狼来了”的人不至于受到怀疑和猜忌。对风险保持积极的态度的团队往往能够更早，更成功地预见和管理风险.   [大牛在一旁自言自语 – 这样讲下去，我们都有睡着的风险！]   新建“风险”工作项 新建的风险工作项处于“活跃”状态。风险应包括对于可能发生的事件及后果的描述和分析. 任何人都可以创建风险，但是风险交给谁？ 交给跟踪风险的人（简称“跟风”的人），通常是分析师，或管理人员。   活跃状态 原因 新建 初始状态.   活跃状态   活跃到关闭 原因 缓和 当团队可以采取一些措施来缓和或减轻风险带来的冲击。 不活跃 风险发生的可能性降到很低，可认为风险不会发生。 转移 风险转移到项目之外。风险并没有消除，只是转移到别的项目或团队中。 接受 当没法避免，减轻风险的时候。团队只好接受风险的挑战。 避免 由于种种原因，风险没有发生.   关闭     关闭到活跃 重新激活 风险又出现了.     《其他白话 MSF 文章》...[阅读全文]

摘要:[这是应开心的要求写的命题作文]   大约是96年春天，我在Wayne State Univ. 正忙着写硕士论文。一天，收到了一封email 号称来自Richard Brodie，上书：   I'm the creator of Word. I found your resume… are you interested in a contract position at Microsoft?   他叫我写了一个程序(好像是排序)，email 给他，几天之后，又安排了微软的一个电话interview，不久他就把Detroit/Seattle 的来回机票寄给我了。在这之前，我倒是得到了一家New Jersey软件公司的Offer，还有Detroit 和 Chicago的公司也在联系中。根据以前在HP公司的经历，我对大公司不太感冒，但是又一想，免费的机票… Microsoft… 还是去看看吧。   闲话少说，清早从Detroit 经 Pittsburg 到了Seattle，由于时差的关系，到达时还是早上。Richard 接了我，从机场到微软的路上，他和我聊了我在国内做过的项目，听说我们在目标码上汉化了SCO Unix，吃了一惊，拍拍我的肩膀说，那你做这个工作是没问题的了。   进了微软17楼的门厅，觉得气派不小，一个叫Gary 的人把我领到他的办公室，屋里堆满了各种各样的玩具，一个大盒子上好像还有日语写的“棋盘”二字。寒暄之后，就直奔主题：     “在一个含有DBCS的字符串中，如何从当前的位置向字符串头退一个完整的字符”   各位别笑，当时的编辑器有不少不能处理这些问题，光标时不时会跑到一个汉字的中间去。我在黑板上边写算法，他在一旁提问，这个问题的关键是了解DBCS  leading byte 和 trailing byte 的区别，然后向字符串开始处搜索，写完之后，他好像挺满意。   [现在想不起来午饭是如何解决的了，一般情况下吃午饭时也要问一些程序的问题]   第二个见面的叫Daniel，看样子像中国人，他叫我做了几个指针的程序，大概是把单链表倒过来之类的。然后分析各种算法的优劣。这一关很顺利就过了。   第三个见面的叫Matt，他跟我谈了他们正在做一个叫outlook 的 email 程序，远东版（中日韩）进度很慢，需要做不少处理双字节的工作，以及各种和中日韩环境有关的问题。我问 – 你们为啥不用 Unicode,  我觉得Unicode 一出，就再也不用DBCS了。他有点尴尬地说，我们的程序是建立在一个叫MAPI 的平台上的，它还不支持 Unicode。正说着，门外一阵骚动，有人推门进来说“哥们快去...”。Matt 带着我来到一个大厅，一帮人围着看一个人在被剃光头，有人还在起哄。被剃者面带微笑，他叫Mike，是Outlook 的 dev manager，他和大家打赌，如果在某日之前bug 数量减少到一定数目，他就以光头回报。   看过剃头，我从冰箱拿了一听 Mountain Dew，和 Matt 回到他的办公室，Matt 叫我实现 itoa() 功能，或许是累了，或许是Mountain Dew里的咖啡因起了作用，我觉得用简单的循环方法太平常了，就想了一个用数学库函数作的，他说，这是我第一次看到这样的解法，你为啥不用简单的方法？你知道数学库函数有多慢么？   下午，Richard 送我到机场附近的饭店，路上他问，要不要在西雅图一带兜兜风？ 我说，我觉得我肯定会来上班的，以后有的是机会，这次就不用了。 吃晚饭时买了一份报纸，拿了几份房地产的广告，和中西部的价格比较了一下。在饭店时太太从Detroit 打来电话说微软有个Recruiter 在找你，我和她刚谈了两句，她听到我正在面试，就挂了电话。   一两天后，Richard 来email 说，前两个面试都挺好，第三个有些看法... 又过了几天，他说，你可以来上班了，我就推掉了其它公司的offer，来到了Redmond，成为Richard Brodie 公司的职员，在微软上班。 我当时的email 地址前有一个“v-”，表示vendor。 当时一个芝加哥的公司（CASE）听说我不想接受他们的offer，问- 为啥？我说 - 西雅图气候宜人... CASE说 - 我们加上N千元，这样芝加哥的冬天就比西雅图还好过了，如何？我想了想，还是直奔西雅图而去。   上班一年后，我成为了微软正式职工，没有面试。当时outlook 的GM 叫Brian，他经常采取一些非常规的办法劝说在那里实习的学生直接成为正式职工，好像Daniel 就退学了，直接转正。我问我的老板，不是说成为正式职工要5 个人面试么？他说，别浪费时间了，你的工作就是最好的面试。   后来： Richard – 据说是微软的第77个员工，Word 的作者，一度成为Word 项目的General Manager。......[阅读全文]

摘要:人多，随笔多，评论多，但是我前两天看到的一篇精彩的文章很快就被淹没，再也找不到了 （用brute force可以找到，但是太累）。这是不是博客堂成长的烦恼？ 我看了几个月的blog，发了两篇随笔，禁不住要“下车伊始就哇喇哇喇地发议论”, 不当之处，请多指教。 我理想中的博客堂： 1- 主页中对每一个新的随笔都最多显示三行，这样旧的内容不会很快被一些大块头的随笔淹没。2-  搜索能够搜到东西。3-  能有一个简单的列表显示最近所有人发的随笔/文章/相片。4-  除了评论，大家可以给每个随笔/文章/相片打分，为了简化管理，只有注册用户可以打分。5-  能有一个简单的列表显示优秀的随笔/文章/相片。 6-  评论中也有真知灼见，文章的作者可以推荐好的评论到主页上的“精彩评论”栏中。7- 定义一些通用的“分类”， 如 C#, .Net 技术, ASP.NET，这样所有人使用通用的分类，而不要自己建立互相不兼容的分类。8-  能够分类浏览 - 如我想看所有关于 asp.net 的文章/随笔，只需要一个按键即可。9-  随笔 和 文章 事实上是一回事，只不过因为随笔可以在主页上显示，大家都写随笔 （二者比例为 9:1），目前的随笔相当于 “公告 - announcement”，因为所有人都可以立即看到 - 事实上有人用随笔来发招工广告， 和活动通知等等。 对此我没有想好解决办法，初步想法是把 “随笔（post）”改成“公告”，大家应该专注于写文章， 如果有需要让大家立即知道的事，才发一个公告。 欢迎评论。  ...[阅读全文]

摘要:前几天看到有人用农民起义比喻IT技术的兴衰，想想起义的结果好像不止两种，可以细分出有五种之多：   推翻了统治阶级, 成为新的统治阶级； 接受统治阶级的招安，然后去打别的不替天行道的农民起义军； 一度占领京城，被胜利冲昏头脑，旋即被新的敌人赶跑；最后被消灭； 取得阶段性胜利后，偏安一隅，开始搞个人崇拜和内部的倾轧，最后被统治者消灭； 原来要反B复A， 后来变成扶B灭C，最后被C消灭，B也没能撑多久； 现在的问题是在国内外IT 行业中找到以上的农民起义军的例子。 DOS? 所有被“统治阶级”收购的小公司? Borland? Corel? SCO, Sun? 想听听大家的高见。。。...[阅读全文]