阅读作业之The New Methodology——洪虹

　　当前，传统的软件工程方法越来越难以适应迅速变化的需求。近年来出现了一类新的轻量级的软件开发方法，它们被统称为敏捷型软件开发方法。在所有敏捷开发方法中，XP 是最引人注目的。　　

　　早期的时候，多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix〕。设计过程充斥着短期的、即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。

　　软件行业中最初的一场运动是要改变这种情况，而引入了“正规方法” （methodology〕的概念。这些（正规）方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践 － 因此我把它们称为工程方法（engineering methodologies）（另一个广泛使用的词汇是计划驱动方法（plan-driven methodologies））。

　　工程方法已存在了很长时间了，但是没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。而敏捷型方法（agile methodologies）的发展是对这些工程方法的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。敏捷型与工程型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，它们更象是“面向源码”（code-oriented〕。事实上，它们认为最根本的文档应该是源码。敏捷软件开发是从20 世纪90 年代开始逐渐引起广泛关注的一些新型软件开发方法，它是一种应对快速变化的需求的软件开发能力。它强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重作为软件开发中人的作用。极限编程（Extreme Programming, XP）作为敏捷开发方法的一种，它是一种全新的、生机勃勃的软件开发方式。XP 的出众之处在于兼顾了质量的两个方面（满足客户期望的同时，降低缺陷的数量），颠覆了复杂性不断增加的循环。

　　在所有敏捷开发方法中，XP（Extreme Programming）是最引人注目的，它适用于需求快速变动背景下的中小规模的开发团队。XP 起源SmallTalk 圈子，一般认为归功于Kent Beck, Ron Jeffries 和Ward Cunningham。90 年代初，一系列的项目的实践让他们认为，软件的开发应该是灵活适应的，应以人为中心思想。极限编程弱化针对未来需求的设计，非常注重当前的简化。因此，极限编程适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求，极限编程在平衡短期和长期利益之间做了巧妙的选择。极限编程在很多方面都和我们传统意义上的软件工程不同。它在理念、管理和项目计划方法等方面也和传统的软件开发过程不同。极限编程的这些特点和方法在软件工程和其他管理活动中都有借鉴意义，能解决软件开发中的一些问题。

a. 需求把握不充分
　　这是软件开发中经常会遇到的问题。极限编程方法从整体团体的开发小型的系统等方面解决了这些问题。
b. 难以确定项目计划
　　目前，软件开发过程中的两个主要问题是:确定在每个时间段内应完成哪些任务，以及确定下一步应该做些什么，重点是把握项目开发路线。针对这种情况，极限编程使用了发布计划的方法。这种开发方法，使得开发人员和客户都能对前一阶段的开发成果进行评估和反馈，更好地把握后面工期的任务安排。同时，多个迭代周期也使工期的估计越来越精确。
c. 缺乏沟通和反馈
　　在软件项目开发中，经常会出现项目中的一些重要信息没有进行充分和有效沟通的现象。极限编程方法尤为强调面对面的沟通，通过现场客户、站立会议、结对编程等方式来保证沟通的有效。
d. 分工和地位的不合理
　　极限编程方法尊重人性，强调效率。软件开发是一种脑力的投入，如果不能保证开发人员自愿而有激情地投入工作，软件产品的质量就不能保证。事实证明，一个愿意投入的开发人员和一个不愿意投入的开发人员效率相差3 倍以上，对组织的贡献更是在10 倍以上。极限编程方法的出发点是相互信任，给开发人员提供他们所需的环境和支持，并且信任他们能够很好地完成工作。一旦做到了这一点，就能够充分地调动程序员的积极性，提高他们的创新能力，将使这个团队具有很强的竞争力。

　　我们在UI设计的过程中，其实或多或少都涉及到了敏捷性开发的规则，比如每天一次的DAILY SCRUM充分保证了组员之间的沟通交流，这对于工程的展开的确有很大的帮助。