《软件工程》第3章敏捷软件开发

    敏捷方法都具有以下共同的特性

    1.规格说明、设计和实现过程交织在一起；

    2.系统按照一系列增量进行开发；

    3.使用广泛的工具来支持开发过程。

§3.1敏捷方法

    敏捷方法已经在很多领域取得了成功，特别是以下两类系统的开发中。

    1.软件企业所开发的用于市场销售的中小规模产品；

    2.组织内的定制化系统开发，其中客户承诺可以参与开发过程，并且影响软件开发的外部利益者和法规不多。

§3.2敏捷开发技术

    极限编程（Extreme Programming, XP）对敏捷开发技术产生了极大的推动。

    以上表格展现出极限编程的特征。

    1.通过频繁的小的系统发布支持“增量交付”。

    2.通过在开发团队中持续地约见客户实现“客户参与”。

    3.通过结对编程、系统代码的共同拥有权，以及不包含超长工作时间的可持续的开发过程来支持“人而不是过程”。

    4.通过定期为客户提供系统发布、测试先行的开发、避免代码退化的重构、新功能的持续集成来“拥抱变化”。

    5.通过经常性的提高代码质量的重构、使用不包含不必要的系统未来变化预测的简单设计来实现“保持简洁”。

    3.2.1用户故事

    软件需求的持续变化使得人们需要积极应对这些变更，敏捷方法没有一个独立的需求工程活动，而是将需求工程与开发集成到一起。为了使之更容易，这些方法提出了“用户故事”的思想，即每个故事都是一个系统用户可能经历的使用场景。

    系统客户应当尽可能地与开发团队紧密工作，并且与其他团队成员一起讨论这些场景。他们一起开发出一种“故事卡片”的具体操作方案，其中每一个卡片都包含了系统的一个脚本。用户故事的最需要关注的问题是完整性，因为我们很难判断这些“故事卡片”组成起来可以覆盖所要开发的系统的全部重要需求。

    3.2.2测试先行的开发

    极限编程方法中测试的关键特性如下：

    1.测试先行的开发；

    2.基于场景的增量测试开发；

    3.用户参与测试开发和确认；

    4.使用自动化测试框架。

    在保证测试覆盖度的完备性方面还存在以下的这些问题：

    1.程序员更喜欢编程而不是测试，有时候他们会在编写测试时走捷径；

    2.有些测试很难增量地编写。

    3.2.4结对编程

    结对编程的好处包括以下这些方面：

    1.支持对于系统的共同所有权和共同责任的思想；

    2.扮演了非正式的评审过程的角色，因为每一行代码都至少由两个人看着；

    3.鼓励通过重构改进软件的结构。

§3.3敏捷项目管理

    与其他任何一个专业化的软件开发过程一样，敏捷开发必须处于有效的管理之中，以使团队所获得的时间和资源能够得到充分利用。为了应对这一问题，Scrum敏捷方法（Schwaber and Beedle 2001）被提出以提供一个组织敏捷项目的框架，从而至少在一定程度上提供项目进展状况的外部可见性。

    用户喜欢Scrum方法中以下几个方面：

    1.产品被分解为一组可管理、可理解、利益相关者可以对应上的条块。

    2.不稳定的需求不会影响进度。

    3.整个团队都对所有的一切保持可见，因此团队交流沟通和士气都得到了提升。

    4.客户可以按时看到增量的交付，并获得关于产品如何工作的反馈。他们不会在最后一刻当开发团队宣布软件无法按时交付时感到惊诧。

    5.客户和开发者之间建立了信任，建立了积极的文化，其中每个人都期望项目能成功。

§3.4敏捷方法的伸缩

    敏捷方法的伸缩包括以下两个密切相关的方面。

   1.将这些方法规模化以处理大系统的开发，这些系统往往因为太大而无法由单个的小团队来完成。

   2.将这些方法的应用范围从专门的开发团队扩展到在一个有着多年软件开发经验的大企业内更加广泛地使用。

   3.4.1敏捷方法的实践问题

    对于由软件公司为外部客户开发的大型、长生命周期的系统，使用敏捷方法还存在着下面这些问题。

    1.敏捷开发的非正式性与大型企业中通常使用的基于法律的合同定义不相符。

    2.敏捷方法最适合于新的软件开发而不是软件维护。然而，大型企业软件成本大部分来自于对已有软件系统的维护。

    3.敏捷方法适用于小的、同处一地的团队，然而当前的很多软件开发都包含全球分布的开发团队。

    然而，当维护工作涉及一个必须按照新的业务需求进行变更的定制化系统时，敏捷方法对于软件维护是否适用并没有一个清晰的共识。可能会产生以下3类问题：

    1.缺少产品文档；

    2.保持客户参与；

    3.开发团队的延续性。

    3.4.2敏捷和计划驱动的方法

    大多数大型的“敏捷”软件开发项目都来自计划驱动的方法与敏捷方法的实践相结合。敏捷方法被开发以及在项目中不断细化，以便用于开发中小规模的业务系统和软件产品，其中软件开发者控制着系统的规格说明。所以，这些系统需要在系统工程过程中提前进行计划、设计和文档化。需要注意的问题有：

    1.所开发的系统有多大捷方法在系统能够由一个相对较小且处于同一地点、可以进行非正式交流的团队开发时最有效。

    2.所开发的系统是什么类型要在实现之前做很多分析的系统，通常需要一个相当详细的设计来进行这种分析。

    3.所期望的系统生命周期有多长生命周期的系统可能需要更多的设计文档化，从而将系统开发者最初的意图传达给支持团队。

    4.系统是否要接受外部监管/p>

    敏捷方法对开发团队在系统开发过程中进行协作和沟通施加了很多责任。可能需要一些计划来充分利用可用的人。

    1.开发团队中的设计者和程序员怎么样/p>

    2.开发团队是如何组织的/p>

    3.可用的支持系统开发的技术有哪些/p>

    然而，企业中的管理人员可能对敏捷方法中的缺少文档和非正式的决策等做法感到不适，其中关键性的问题如下：

    1.在开始实现之前有一个非常详细的规格说明和设计很重要吗/p>

    2.增量的交付策略，即你向客户或其他利益相关者交付软件并获得来自他们的快速反馈，这现实吗/p>

    3.是否存在可能影响系统开发的文化问题/p>

    3.4.3面向大型系统的敏捷方法

    敏捷方法必须发展变化以适用大规模软件开发。其中的根本原因是大规模软件系统的理解和管理比小规模系统系统或软件产品要复杂得和困难多：

    1.大型系统通常都是系统之系统，即独立的相互通信的系统集合，其中不同的独立团队分别开发每个系统。

    2.大型系统是棕地（brown field）系统，即包含一些现有的系统并且要与之交互。

    3.当通过集成多个系统创建一个新系统时，开发工作中很大一部分都关注子系统的配置而不是原始的代码开发。

    4.大型系统及其开发过程经常受到外部的规则和监管制约，这限制了系统的开发方式，并且要求产生特定类型的系统文档等。

    5.大型系统的采购和开发时间很长。

    6.大型系统通常有一组多种多样的利益相关者，他们的观点和目标各不相同。

    规模化的敏捷方法有一些共性：

    1.一个完全增量的需求工程方法是不可能的。

    2.没有哪个人能单独作为产品负责人或客户代表。

    3.不可能只关注系统的代码。

    4.必须设计和实施整个团队的沟通机制。

    5.当系统必须通过多个独立程序的集成来创建的时候，持续集成在实践中无法实现。

    Scrum方法已经通过调整来适应大范围的开发。多团队Scrum方法的关键特性如下：

    1.角色重复；

    2.产品架构师；

    3.发布同步；

    4.Scrum团队的每日站立会议。

    3.4.4面向整个组织的敏捷方法

    1.没有敏捷方法经验的项目经理可能担心接受新方法而带来的风险，因为他们不知道这些方法对他们的一些特定的项目造成什么样的影响。

    2.大型组织经常都制定了所有项目都要遵循的质量规程和标准，因为他们的官僚主义状况，这些很有可能会与敏捷方法不相适应。

    3.敏捷方法似乎在团队成员具有相对较高的技能水平时效果最好。

    4.敏捷方法可能会存在文化上的抵制，特别是那些长期使用传统系统工程过程的组织中。