7.7 移山开发方法——比TFS敏捷更精简
几个软件学院的学生来请教阿超，同学们自豪地说，我们要用全套TFS敏捷开发模式开发项目！
真的？阿超不敢相信。
同学： 对！我们要用全5个工作项类型 – 任务、缺陷、场景、风险、服务质量需求、
阿超： 你们有多少实战项目的经验？哦，都没有。这么说这是你们第一个真正的实用项目，我建议你们先忘记这么多工作项类型，把时间花在写代码上好了。
同学： 可是老师要我们上敏捷开发模式呀?
阿超： 当敏捷模式变成强迫，那还能敏捷到哪儿去呢？如果你们非用不可，我建议你们只用其中两个工作项类型：
- 任务
- 缺陷
同学： 超总，我觉得其他的工作项类型也很好用耶，比如场景，风险——没有风险管理，我们咋能上CMM等级呢？
同学： 还有“QoS——服务质量需求”，难道你不重视程序的效能和可扩展性？
阿超： 看来你们读书都不错，那些类型都很好，但是不直接使用这些类型并不表示我们不重视，特别是风险。因为在一个全新的团队中不加辨别地使用所有工作项类型也是一种风险。它增加了VSTS的系统复杂性，从而增加用户（就是你和我）学习和使用的难度，浪费时间。有可能使项目的进展受到影响！至于“服务质量需求”，我们很重视程序的效能和可扩展性，但是不必拘泥于非要用某一特定的类型不可。
对于小规模的项目，我的原则是“直奔主题，精简过程”，我们的主题是啥？让用户买我们的产品，只要用户满意我们的产品，他们会关心我们内部开发模式用的是哪几个工作项类型么？
我个人认为项目开发过程中有两件不同类型的事：
（1）事先预计到的要做的事。这就是任务，把要做的事情组合起来实现用户某一个特定的需求，这就是场景，也可以用任务来表达。
（2）事先没有预计到，但是为了项目成功而不得不做的事。这就是缺陷。
软件开发的过程就是做完这些“计划要做的事”和“没计划，但是不得不做的事”，做好就行了。等你们做了三五个项目，写了一万行以上的程序，再来看场景、风险、服务质量需求也不迟。
同学：您说得在理，但是老师让我们用全套敏捷模式，我们怎么办？
阿超：你们可以回去告诉老师说这是最新的“移山精简开发模式”，填补了国内外空白，很好用。
把同学们打发走了以后，阿超转念一想，为什么不呢？“移山精简开发模式”，说不定对小型团队来说是一个很好的模式。
举例说明：例如我们要设计一个网上拍卖的网站，商业用户（简称商户）可以开商店，卖东西；一般的用户可以浏览，购物。
商户可以用我们的系统进行登录。这是场景，也可以叫任务，我们要以此为基础，驱动开发和测试工作：
我们计划要在网络用户界面实现商户登录管理，这是任务。
我们计划要在中间逻辑层实现商户登录管理，这是任务。
我们计划要在数据层实现商户登录管理，这是任务。
我们计划要测试商户登录，这是任务。
我们计划要系统能支持100个以上的商户同时访问，这是任务，同时也是“服务质量需求”。
在某些情况下，商户登录失败，这是缺陷。我们事先没有预计到会出这样的问题。
在标准配置情况下，20个以上的商户同时登录时，系统的响应时间很慢，这是缺陷。我们事先没有预计到会出现这样的问题。
系统在上传某种图像文件时出错，这是缺陷。
对于一个不太复杂的系统来说，每次里程碑（迭代）中要实现的场景应该两个手掰指头能数得过来。而且场景是相对稳定的，不会突然间有大的变化。对于一线的开发和测试人员来说，每天打交道更多的是任务和缺陷。过多的类型会增加管理和交流的成本，一个开发者每天很简单地浏览“我的任务”和“我的缺陷”这两个检索，就能知道今天该做什么。同时开发和测试的交流也主要通过“缺陷”这一类型来完成。管理人员在跟踪进度、报告进度的时候也很简明。在这种情况下，“场景”只是起到一个综合与归类的作用，使管理人员和客户知道哪些功能能够使用了，哪些还差得远。因此，“场景”可以等同于“任务”。因为这是我们预计到要做的事情。
如果加上“服务质量需求”，那么团队中每个人需要接触的工作项类型就有4种，如果测试人员发现“服务质量需求”的某些部分不符合要求，需要重新激活“服务质量需求”，并创建一个新的“缺陷”，并且通报所有相关人员，对于一个小规模、人员相当集中的团队，真的有这个必要么？
对于一个新建的团队，保持一个精简的过程和管理方法是很重要的。只要任务、缺陷这两个类型足以解决问题，就不必考虑更多的工作项类型，而是集中精力把项目开发好。
在软件工程发展的过程中，各个专家在不同时期总结了软件工程的原则，下面是1983 年Barry Boehm在总结了多个项目（各个项目总共耗时约175000人月，主要是国防、航空、航天相关）之后提出的软件工程原则，请把它和MSF、Agile的原则相比，看看有什么异同?
表7-2 Barry Boehm总结的软件工程原则
| Principles | 中文翻译和解释 |
| 1. Manage using a phased life-cycle plan. | 使用分阶段的计划来管理流程，强调需求分析和抵制随意地改变项目计划。 |
| 2. Perform continuous validation. | 持续地检查认证，争取在早期发现问题。 |
| 3. Maintain disciplined product control. | 坚持规范的产品控制– 验证过的程序或文档只有通过规范的流程才能修改。 |
| 4. Use modern programming practices. | 使用现代的编程方法和工具 |
| 5. Maintain clear accountability for results. | 确保团队成员能分阶段，分模块地产生可以测试，可以复审的结果，并对结果负责。 |
| 6. Use better and fewer people. | 用少而精的人员，减少交流成本，提高效率。 |
| 7. Maintain a commitment to improve the process. | 持续地收集数据，和反馈，争取通过多个迭代实现流程的改进和整体软件质量的提高。 |
小飞： 能否有一个打折扣的MSF？让一个团队一下子接受MSF的“9项基本原则”似乎并非易事，那么我们可以打折扣地贯彻MSF吗？如果可以，应该如何实施呢？
阿超： 这些原则都是相互依赖、相互促进的。如果只实施了50%的原则，也许只有10%的作用。但是不必为此烦恼，只要开始改变，经常总结，就是好事。
小飞： 越是充分授权和信任，很多人在团队中越不自觉，结果写的代码都是敷衍了事（大学里面的团队很多都是这样），需要用什么激励机制来促进吗，还是说只能依靠团队成员的个人自觉？
阿超： 那我们要问一下这个项目的商业价值是什么？如果这个项目没有任何商业价值，我想你也不好意思照搬商业软件的做法。但是也许这个项目对个人而言很有价值（提高个人技术的价值），那些有心锻炼自己的同学，能够自我驱动，值得你去“授权”和“信任”。
小飞： 我体会最深的是——“如果你问一个技术人员，技术人员往往略带不屑地告诉你——把“工具 | 选项”打开，在某个“高级选项”下，改某个参数即可”这一段。移山公司的一些技术人员，特别是开发人员，甚至还带有一些轻蔑的眼神。参照这一新闻（北京禁止售货员用轻蔑审视的眼光扫视顾客），我大胆地提一个建议——“移山公司禁止开发人员用轻蔑审视的眼光扫视测试人员”！
大牛： 我同意，而且要扩展到“禁止开发人员用轻蔑审视的眼光扫视非开发人员”！
果冻： 西方管理学大师戴明曾经说：“Eliminate numerical goals, numerical quotasand management by objectives. Substitute (that with) leadership”，意思就是说（在团队中）要消除以数字定义的目标、份额，以及以类目标为基础的管理原则。我们要用领导能力取而代之。
这和“数量化的管理”级别的要求有没有冲突？二柱：软件工程讲的净是一些奇妙玄幻的概念，拗口的专业名词加上纷繁复杂的流程，其实做软件完全没那么难，主要靠的还是程序员自身的修养和完成工作的素质。
你怎么看二柱的观点？
论文信息：Seven Basic Principles of Software Engineering, Barry W. Boehm, 链接：