快速软件开发 学习笔记 之二

第3章 软件开发的基础性实践

人们经常劝导你要采用标准的软件工程实践，因为它们是“正确”的或者它们会提高产品的质量。但是，采用软件开发的基础性实践的原因不在于它们“正确”，而在于它们可以切实减少费用和缩短产品面市时间。软件开发的基础性实践分为管理实践、技术实践和质量保证实践。

3.1 管理的基础性实践

3.1.1 Planning（项目规划）

软件业界的最佳完成项目都具有这个鲜明特征：强有力的前期规划。软件项目的规划包括以下的内容：

 

表 3-1 规划软件项目

软件项目的规划活动	进一步参考
Estimation（项目估算）和scheduling（制定进度计划）	第7章和第8章
确定项目团队人数、所需技术技能、人员到位时间和具体人选	第11章
确定团队结构	第12章
确定项目采用的生命期模型	第6章
管理风险	第4章

3.1.2 Tracking（项目跟踪）

项目跟踪是一个基本的软件管理行为。你如果不跟踪一个项目，你就绝不会知道你做的项目规划是否被贯彻执行了。项目跟踪包括对项目的进度、成本和质量目标的检查，以提供项目状况的可视性，避免项目失控。

典型的管理层面跟踪手段包括：

l  task list

l  status meeting

l  status report

l  milestone review

l  budget report

l  management by walking around

典型的技术层面跟踪手段包括：

l  technical audit

l  technical review

l  milestone quality gate

l  issue tracking system

 

最佳实践：Issue Tracking System

给整个项目乃至整个公司选择一个issue tracking system。这个issue tracking system可以是商业软件系统（如ClearQuest），也可以是免费软件。只有在issue tracking system就绪之后，才开始启动你的项目。

3.1.2.1 Miniature Milestones（小型里程碑）

软件项目存在major milestones，它们是为项目设定总方向的长间隔里程碑。这种里程碑通常以“月”作为间隔。Major milestone对于设定方向很有帮助，但它们的间隔过长，以至于不能提供很好的项目控制。而miniature milestone则是一种进行项目跟踪和控制的精细方法，它能很好地提供项目状况的可视性。把major milestone和minor milestone组合会有很好的效果，major milestone提供项目的策略目标，而miniature milestone则提供实现每个目标的战术方法。

最佳实践：Miniature Milestone（小型里程碑）

1.       及早设立小型里程碑。先紧后松优于先松后紧。

2.       让开发人员建立他们自己的mini milestone。软件经理让员工定义他们自己的小型里程碑，也就是允许他们控制其工作细节。软件经理所要做的是要求员工告知其工作细节，这有助于员工全心投入工作，也避免了经理们的过度管理（macro-management）。

3.       确保mini milestone在1或2天内可到达。这也就要求单个mini milestone内的任务应该是明确的和细分的，而不是模糊的或笼统的。

4.       确保mini milestone的二义性。小型里程碑只有“done”和“not done”两种状态，而不存在“90% done”这类的说法。软件经理或Tech Lead应该细致地跟踪项目进展状况，要每天都同开发人员一道对照设定的mini milestone来评估项目进展情况。一定要确保当一个mini milestone被标记为“done”时，它是真正100%被完成了。

5.       把mini milestone用于短期规划，而非长期规划。

6.       如果发现经常不能按期到达mini milestone，则可以停下来，分析无法到达的原因（例如：开发人员需要培训、单个mini milestone内的任务过多、开发人员常受到杂务的干扰等）。找准原因之后，应该对原有的mini milestone规划进行调整，或者重新制定规划。

 

3.1.3 Measurement（度量）

使软件企业长期进步的一个关键是收集measurement data以分析软件质量和生产率。为了使开发更为高效，软件从业人员需要具有软件度量方面的基本知识，也需要理解与收集度量数据有关的问题，还需要理解某些度量数据以便用于分析项目的状况、质量和生产率。

最佳实践：度量

7.       以表3-1为基础，建立自己的度量数据表格。注意：收集过多的数据会让人淹没在不知其义的海量数据中。对于刚开始采用度量实践的软件团队和组织来说，可尝试最多收集12种不同的度量数据。即使是有丰富度量实践经验的组织，也最多收集24种度量数据。

8.       在项目进行过程中，每到一个major milestone，更新度量数据表格中的相应数据。

9.       在项目结束之后，再次汇总数据。

10.   由原始数据获得一些组合数据，例如：

l  已修复的缺陷数 vs. 被发现的缺陷总数（有助于评价产品质量）

l  尚未修复的缺陷数 vs. 被发现的缺陷总数（有助于预测项目发布日期）

l  通过inspection发现的缺陷数目 vs. 通过execution testing发现的缺陷数目（有助于规划质量保证任务）

l  估算项目剩余天数 vs. 实际项目剩余天数（有助于跟踪和改进估算准确度）

l  按编程语言统计每人每月的平均代码行数（有助于估算和规划编码任务）

l  按编程语言统计每人每月的平均功能点数目（有助于估算和规划编码任务）

l  按缺陷严重程度、按子系统或按缺陷潜入时间来统计修复一个缺陷所用的平均时间（有助于规划纠正缺陷的任务）

l  生成一页文档的平均小时数（有助于规划文档任务）

11.   花较多的时间分析和整理得到的度量数据。可以采用下面任何一种方法：

12.   把收集的试题数据和分析结果反馈给开发人员和软件经理，并讨论试题数据表格是否需要增加或删减表项，以供下一个项目使用。

 

表 3-2 常用度量数据

成本和资源

l  按activity、按phase或按人员类型来统计的工作量

l  计算机资源

l  日历时间

变更与缺陷

l  按不同分类法（严重程度、子系统、潜入时间、出错原因，解决手段）统计的缺陷数目

l  缺陷检出方法（review、inspection、test，等等）

l  检出并修复每个缺陷所用的工作量

过程

l  process definition（design method、编程语言、review method，等等）

l  估算完成时间

l  milestone progress

l  随时间的代码增加量

l  随时间的代码修改量

l  随时间的需求变更量

产品

l  开发日期

l  总工作量

l  项目种类（内部业务软件、商用盒装软件、或系统软件）

l  项目中的函数数目或object数目

l  以代码行数或功能点数衡量的项目规模

l  文档的规模

l  编程语言

 

度量是有用的，但它也不能包治百病。应该记住度量存在的局限性：

l  收集的数据是有误差的。试题过程中会有很多误差，因此收集的数据并不准确。

l  警惕过分依赖度量数据的倾向。度量数据能够为我们提供软件项目的历史数据，对度量数据的分析也能够为我们提供一定的项目洞察力，但是，它只是起参考作用而不能被过分依赖。

3.2 技术的基础性实践

3.2.1 Requirements Management（需求管理）

需求管理是一个完整的过程，它包括：收集需求；把需求记录为文档、电邮、UI storyboard、executable prototype或其它形式；依据需求跟踪软件设计与编码；在项目进行过程中管理需求变更。

需求管理的成功取决于理解各种不同的实践，以便为特定的项目选择最合适的实践。下面是需求管理的基础性实践：

l  需求分析方法论（结构化分析，数据结构分析，面向对象分析）

l  系统建模实践（类图，数据流图，实体-关系图，数据-字典表示法，状态转移图）

l  沟通实践（Joint Application Development，user-interface prototyping，常规会谈实践）

l  需求管理与不同的生命期模式的关系

需求管理在两个方面对加快开发速度发挥着巨大的影响：

l  requirements gathering往往比其它软件开发任务完成得要从容些。如果能加快需求收集的速度但又不伤及质量，那么就能缩短总的开发时间。

l  从项目一开始就把需求弄清楚的成本，比起直到构建阶段或维护阶段再把需求弄清楚的成本，要少50到200倍。

3.2.2 软件设计

软件架构与设计的基础性实践包括：

l  总体设计风格（对象设计，结构化设计，数据结构设计）

l  基础性的设计概念（information hiding，modularity，abstraction，encapsulation，cohesion，coupling，hierarchy，inheritance，polymorphism，basic algorithm，basic data structure）

l  对典型性困难问题的标准解决方法（exception handling，internationalization和localization，portability，memory management，database design，performance，reuse）

l  针对应用领域的独有设计思考（财务应用，科学应用，嵌入式系统，实时系统，安全攸关的系统）

l  系统架构方案（subsystem organization，layering，subsystem communication styles，典型的系统架构）

l  设计工具的应用

3.2.3 Construction（软件构建）

软件构建的基础性实践包括：

l  编码实践（变量和函数命名，代码布局，注释）

l  与数据相关的概念（scope，persistence，binding time）

l  特定数据类型使用方针（一般的数字，整数，浮点数，字符，字符串，布尔值，枚举，具名常量，数组，指针）

l  与控制相关的概念（组织直线型代码，使用判断式，控制循环，使用布尔表达式，控制复杂度，使用goto、return和递归函数等较少用的控制结构）

l  断言和其它以代码为中心的检错实践

l  把代码组织成函数、模块、类和文件的规则

l  单元测试和调试实践

l  集成策略（增量式集成，大爆炸式集成）

l  代码优化与实践

l  所使用的特定编程语言的细节

l  软件构建工具的使用（编程环境，对团队工作的支持，代码库，代码生成器）

 

最佳实践：Daily Build（每日生成）和Smoke Test（冒烟测试）

1.       每日生成和冒烟测试背后的思想很简单：每天都要对整个产品build和test一次。这意味着每天都要将每个文件编译、链接，并组成可执行程序，产品再通过一个相对简单的自动化测试，以检验其是否具有最基本的可用性。

2.       在daily build和smoke test就绪之前，不要开始任何construction任务。

3.       Daily build和Smoke test依赖于一些基础设施和前期准备，包括：

(1)     一台联网的专用build machine（可以是PC，也可以是服务器），用于生成产品和完成冒烟测试。

(2)     在build machine安装必要的支持软件，包括版本控制系统客户端，编译环境，自动化编译工具，邮件系统，自动化测试工具等。

(3)     对build machine及相关软件工具进行测试，确认build machine可以用于自动化的每日生成和冒烟测试与报告广播。

4.       从项目进入construction阶段的第一天起，就每天进行daily build和smoke test。过程如下：

(1)     build machine在每天晚上的10点，从版本控制系统中check out最新的项目源代码树，进行编译、链接，并把生成的程序和log文件放入与当天日期对应的路径下。一个好的daily build应该是成功地编译、链接所有的文件、库和组件，并且没有严重级别的编译告警和链接告警。

(2)     在build machine上对刚生成的程序运行自动化的冒烟测试，并把测试结果log文件放入与当天日期对应的路径下。程序应该通过冒烟测试中的所有测试才算成功。

(3)     build machine上的邮件系统向指定的干系人发送电邮，告知当天daily build和smoke test的结果。

(4)     干系人在第二天早上检查昨天的daily build和smoke test的结果。如果发现错误，应停下手头工作，立即进行改正。冒烟测试是execution testing中的第一道关口，所以必须被赋予最高优先级。

(5)     上述过程，每天进行，周而复始，直到项目交付。即使项目的进度压力大，也必须坚持本实践。

5.       冒烟测试随着产品代码的增加而增加。坚持为产品代码编写测试代码，看似花时间，但实际却是为项目真正地节约时间。

6.       Daily build失败或通不过smoke test应该是罕见的例外，而不应该是常态。如果频繁出现这种情况，那就应该好好思考一下为什么会这样了。

 

3.3 质量保证的基础性实践

大多数公司都认为：最好从一开始就远离错误。远离错误的关键就是从第一天起就注意运用质量保证的基础性实践。高的软件质量与短的开发时间是相辅相成的，下图给出了两者的关系。

由图可见：在95%附近的一些点很重要，因为能做到大约95%的被发现缺陷被修复的项目通常能实现最短的进度，最少的工作量和最高的用户满意度。

下面是一些质量保证的基础性实践：

l  Error-prone module。对易错模块（error-prone module）的质量保证是软件特别重要的一个方面。易错模块通常指错误率达到“10个缺陷/1000代码行”的模块。鉴别出易错模块，对其进行review以决定是否需要重新设计或重新实现。对于易错模块，推倒重来有时比东修西补更省时。

l  Testing。最常见的质量保证实践无疑是execution testing。两种基本的测试方法是单元测试和系统测试

l  Technical review。Technical review用于检查requirements、design、code、test cases或其它project artifact中存在的缺陷。Technical review是对execution testing的重要补充，是每个软件项目的关键组成部分。常见的technical review方式包括informal walkthrough、code reading和inspection。