软件开发基本原则（一）—— 策略和因素
前 言
前段时间一直在写技术方面的文章，现在想转转口味，从软件开发过程和项目管理的角度来谈论软件开发。本座也知道，从这两个角度来谈论软件开发对谈论者来说是非常冒险的一件事情，它不像技术，对就对错就错，有一个客观的评判标准，别人想喷你也得自己先好好研究等拿到了足够的论据才能喷，但开发过程和项目管理就不同了，别人仅凭一点点所谓的管理经验甚至是主观推断就能喷得你体无完肤，摇摇欲坠 ~ 因为没有什么所谓的事实标准与放之四海皆有效的软件开发过程和项目管理方法。保守估计，100个人中至少有150种想法。本座也深知其中的凶险，因此避重就轻，从基本原理谈起，宏观的角度阐述相关问题，尽量减少中弹的机会。欢迎大家畅所欲言 ^_*
注：本文大量图片和素材来自《Rapid Development》(Steve McConnell 1996)
1 概 述
时间 -- 成本 -- 质量（或特性）是评价软件项目成败的三个关键指标，这三个指标之间相互影响和制约，形成了所谓的“项目管理三角形”。要提高质量或增加特性意味着成本和时间的增加，或两者都增加；要在时间不变的前提下缩减开发成本或成本不变的前提下缩减时间则意味着质量的下降或特性的削减。
图 1-1 项目管理三角形
上述分析其实只是理论上的“理想平衡”状态。现实工作中往往出现的情形是：要么时间超过计划，要么成本超过预算，要么质量达不到要求，要么三个指标都达不到预期。
典型例子：
由于客户的压力需要尽量缩减开发时间，由于企业间的竞争和盈利压力需要尽量节约成本，因此需要一个人做两个人的工作，一个月做两个月的工作，同时压缩需求分析、设计、测试、评审和项目会议等活动。可想而知，即使软件的构建阶段能够按时完成，但做出的软件质量是难以保证的。更糟糕的还在后面：由于质量的低劣，构建阶段结束后对系统进行集成测试时，很多问题就会暴露出来：对某些需求的理解有误差，导致这部分功能要重新分析、设计、编码和测试；架构设计缺乏整体思维导致系统不同模块各自为政，产生大量重复的难以维护的代码；编码太仓促导致一大堆的Bug；沟通不畅顺导致模块接口不兼容……从而项目被带入了修改无限循环地带，即使勉强上线发布，修改还是一直持续，直至最后，没有人再敢接近这套代码，对这个项目谈虎色变。
软件开发项目有其自身规律和原则，只有遵守其原则并付诸相应的实践才可能使项目健康稳定地前进。本文讲述的是软件开发的基本原则，它是通用的，几乎适用于所有的软件开发项目。不同项目可以根据自身特点在原则的指导下定义相应的项目开发实践。
2 策略和因素
2.1 总体策略
要避免混乱低效的开发，就要求每个人能够放弃他们自己的一些坏习惯，通过采取以下四种策略实现快速开发：
1、 避免典型错误
2、 打好开发基础
3、 管理风险，避免灾难发生
4、 采用面向进度的实践
图 2.1-1 快速开发的四跟支柱
典型错误：是指一些经常被许多人使用的无效的开发实践，如：不现实的预期，缺乏计划，功能蔓延和银弹综合症等。将在第3章详细讲解。
开发基础：是指项目开发过程中管理、技术、质量保证等方面行为和活动，如：计划编制，需求管理和技术回顾等。将在第4章详细讲解。
风险管理：是指对有可能影响项目的风险进行评估和控制。将在第5章讨论进度计划相关的风险。
面向进度的实践有以下三类：
-
- 面向速度的实践：可以提升开发速度，帮助你更快的交付软件
- 面向进度风险的实践：可以降低计划风险，帮助你的项目平稳推进
- 面向可视化的实践：可以提高进程的可视化程度，帮助你掌握项目动态
图 2.1-2 面向进度的实践
图2.1-1所示的前三根柱子为可能的最佳进度提供了最重要的支撑，虽然可能不是最理想的，但却是最需要的。也就是说，即使不借助于面向进度的实践方法，也可能实现较优化的项目进度；但是，如果仅仅依赖面向进度的实践却不可以支撑可能的最佳进度计划。
图 2.1-3 仅仅依赖面向进度的实践不足以支撑最佳进度计划
2.2 软件开发的四维
每个软件项目都有四个重要的维：
- 人员：完成任务要么快，要么慢
- 过程：优化人员的工作效率，或者浪费人员的时间
- 产品：以自我完善的形式定义，或者阻碍人员达到最好效果的形式定义
- 技术：促进或者阻碍开发的实现
图 2.2-1 开发速度的四维
2.2.1 人员
研究数据：
人件极大地影响着生产效率，任何关注提高生产效率的组织首先必须有一套良好的人员激励、团队合作、员工选择及培训机制。
发挥人员最大潜能，缩短项目周期的方法：
1、 项目成员的选择
五个原则：
- 用更少更好的人
- 使任务与人员的技能和动机相匹配
- 帮助人员自我实现，而不是强制地把他推到他最有经验或最需要他的岗位上
- 人员选择应强调人员之间的互补与协调性
- 尽快排除或替换不称职的人员
2、 团队组织结构
人员的组织方式对人员的工作效率有很大影响，调整项目团队以使之与项目规模、产品特点以及进度目标相匹配。特定的软件项目也可以从适宜的专门组织中受益。
3、 人员激励
人员激励能激发人的动力，从而付出额外的努力工作；它适用于不同组织、不同项目和不同人员。人员激励是达成快速开发的最具潜力方法。
2.2.2 过程
研究数据：
Hughes Aircraft、Lockheed、Motorola、NASA、Raytheon和Xerox等组织通过对开发过程的改进将产品上市时间缩短了一半，降低成本、减少错误为原来的1/3~1/10。
过程是指软件开发生命周期中定义的一系列工作流程和活动的集合。可以概括为以下三类：
- 基本过程：包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程
- 支持过程：包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程
- 组织过程：包括基础设施过程、改进过程以及培训过程
忽略过程容易造成工作效率低下，工作目的交叉重复，产品质量难以保证等问题；另一方面，如果过程过于严格、过于官僚同样会挫伤人员的积极性，或者由于执行过程的成本过高而影响实际的工作效率。
组织可以对现有的过程进行裁剪和调整，制定出适合特定项目的过程；或者可以为项目从头开始定义过程。无论是裁剪过程或是定义过程，应该把关注点放在以下几个方面：
1、 避免返工
软件项目节省时间一个最直接的方式就是确定过程，避免重复工作。如果在项目最后阶段改变需求，就可能不得不重新设计、编码和测试；如果直到系统测试阶段才发现设计有问题，就可能不得不扔掉已经细化的设计和编码。
2、 质量保证
质量保证有两个目的：
- 确保交付的产品能够达到可接受的质量水平
- 在各阶段以最少的时间和成本代价查出错误
应尽早在错误发生的时候就查出来，错误在产品中停留的时间越长，清楚错误所花费的时间和成本就越多。质量保证是任何开发过程中必不可少的部分。
3、 开发基础
一系列的软件工程实践活动形成了开发基础，如：分析、设计、构建、集成和测试等。在过程中对开发基础加以关注，并定义良好的工作规范和任务集合能防止项目失控。
4、 风险管理
与进度相关的风险管理是开发过程必要的组成部分。风险管理虽然不能直接提高开发速度，但它是避免项目灾难的有效实践。
5、 资源目标
资源包括人力资源、环境资源和软硬件资源等。优化资源的调配有助于提高生产率。
6、 生命周期计划
生命周期计划是基本的管理计划，有助于确定软件项目要进行的活动集合和资源分配。每种周期模型都有其适用范围和缺点，为项目选择适当的生命周期模型能有效提高工作效率或降低项目风险。
图 2.2.2-1 纯瀑布模型
图 2.2.2-2 瀑布模型的另一种形式——鲑鱼生命期模型
图 2.2.2-3 编码修正模型（一种不规范的模型）
图 2.2.2-4 螺旋模型
图 2.2.2-5 生鱼片模型
图 2.2.2-6 包含子项目的瀑布模型
图 2.2.2-7 能够降低风险的瀑布模型（对需求分析和架构设计阶段采用螺旋模型）
图 2.2.2-8 渐进原型模型
图 2.2.2-9 阶段交付模型
图 2.2.2-10 面向进度模型
图 2.2.2-11 渐进交付模型
图 2.2.2-12 面向开发工具的设计模型
7、 面向客户开发
谁是客户？
对客户的理解取决于场合，可能是项目委托人，最终用户，市场人员或者老板。
现代软件开发非常关注客户的需求与期望，开发出合符产品规格的软件只是完成了一半工作，另一半是帮助客户配置出产品能够实现的功能，而实现这些功能所花费的时间通常远远多于确定纸面上的产品规格所需要的时间。
将自己站在客户的角度考虑问题是避免大量返工的最好方法。同时应该建立有效的客户沟通渠道，合理控制客户的期望值。
2.2.3 产品
在软件开发的四维中，最切实的维是产品维。对产品规模和产品特性的关注，意味着巨大的缩短计划进度的机会。削减了产品功能通常就可以缩短产品开发周期。
1、 产品规模
产品规模是对开发进度影响最大的一个因素。构建软件所需的工作量的增长比产品规模的增长要快得多，并且增长是不成比例的，所以产品规模的缩小将大大提高开发速度。将中等规模的软件削减一半通常可以使工作负荷削减2/3。
2、 产品特性
产品的一些非功能性需求或额外关注点会影响设计的复杂度和构建的工作量，如对性能、稳定性、可维护性和可扩展性等要求很高的产品比没有这些特性要求的产品需要更长的开发周期。
2.2.4 技术
从使用低效的工具转为使用高效的工具是提高开发速度的快捷方法。选择有效的工具并管理好由此带来的风险也是提高开发速度的方法。
敬请期待：软件开发基本原则（二）—— 典型错误
