【笔记】敏捷开发

  敏捷软件工程是哲学理念和一系列开发指南的综合。这种哲学理念推崇：让客户满意且尽早的增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。开发的指导方针强调超越分析和设计（尽管并不排斥这类活动）的发布，以及开发人员和客户之间主动和持续的沟通。
  敏捷开发可以带来多方面的好处，但它并不适用于所有的项目、所有的产品、所有的人和所有的情况。它并不完全对立与传统软件工程实践，也不能作为超越一切的哲学理念而用于所有软件工作。

一、什么是敏捷

  敏捷不仅仅是有效地响应变更，它还包含着对本章开头的宣言中提及哲学观念的信奉。它鼓励能够使沟通（团队成员之间、技术和商务人员之间、软件工程师和经理之间）更便利的团队结构和协作态度。它强调和运行软件的快速交付而不那么看重中间产品；它将客户作为开发团队的一部分开展工作，以消除持续、普遍存在于多数软件项目中的“区分我们和他们”的态度；它意识到在不确定的世界里计划是有局限性的，项目计划必须是可以灵活调整的。

二、敏捷及变更成本

  软件开发的传统方法中（有几十年的开发经验作支持），变更成本随着计划的进展成非线性增长。而敏捷的拥护者认为，一个设计良好的敏捷过程“拉平”了变更曲线，似的软件开发团队在没有超常规的时间和费用影响的情况下， 在软件项目后期能够适应各种变更。


三、什么是敏捷过程

  任何敏捷软件过程的特征都是以某种方式提出若干关键假设，这些假设可适用于大多数软件项目。

1. 提前预测哪些需求是稳定的以及哪些需求会变更是非常困难的。同样，预测项目进行中客户优先级的变更也很困难。
2. 对很多软件来说，设计和构建是交错进行的。也就是两种活动应当顺序开展以保证构建实施来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。
3. 分析、设计、构建和测试并不像我们所设想的那么容易预测。

  这三个假设提出了一个重要的问题：如何剪力能解决不可预测性的过程？答案就在于过程的可适应性。故敏捷过程必须具有可适应性。

  应当使用增量式开发策略，必须在很短的时间间隔内教辅软件增量（可执行原型或部分实现的可运行系统）来适应（不可预测的）变更的步伐。这种迭代方法允许客户：周期性地评价软件增量，向软件项目组提出必要的反馈，影响为适应反馈而对过程进行的适应性修改。

• 敏捷原则

  敏捷联盟定义了12条原则：

1. 我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
2. 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
3. 经常交付可运行的软件，交付的间隔可以从几个星期到几个月， 交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
7. 可运行软件是进度的首要度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够长期保持稳定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——使不必做的工作最大化的艺术——是必要的。
11. 最好的架构、需求和设计出自自组织团队。
12. 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

  并不是每一个敏捷过程模型都同等使用这12项原则，一些模型可以选择忽略（或至少淡化）一项或多项原则的重要性。然而， 上述原则定义了一种敏捷精神，这种精神贯穿与本文中的每一个过程模型。

四、极限编程

  极限编程（XP）是敏捷软件开发中使用的最广泛的一种方法。

1.极限编程过程

  XP使用面向对象方法作为推荐的开发范型，它包含了策划、设计、编码和测试4个框架活动的规则和实践。

  策划。策划活动开始与倾听，这是一个需求收集活动，该活动要使XP团队技术成员理解软件的商业背景，充分感受要求的输出和主要特性及主要功能。倾听产生一些列“故事”（又称为用户故事）描述将要开发的软件所需要的输出、特性以及功能。每个故事由客户书写并置于一张索引卡上，客户根据对应特征或功能的综合业务价值标明故事的权值（即优先级）。XP团队成员评估每一个故事，并给出以开发周数为度量单位的成本。如果某个故事的成本超过了3个开发周，则将请客户把该故事进一步细分，重新赋予权值并计算成本。重要的是应注意到新故事可以在任何时刻书写。
  客户和XP团队共同决定如何将故事分组，并置于XP团队将要开发的下一个发行版本（软件增量）中。一旦认可对想一个发布版本的基本承诺（就包括的故事、 交付日期和其他项目事项），XP团队将以下述三种方式之一对有待开发的故事进行排序：（1）所有选定故事将尽快实现；（2）具有最高价值的故事将移到项目进度表的前面并首先实现；（3）高风险故事将首先实现。
  项目速度是第一个发行版本中是i西安的客户故事个数。项目速度将用于：（1）帮助估计后续发行版本的发布日期和进度安排；（2）确定是否对整个开发项目中的所有故事有过分承诺。一旦发生过分承诺，则调整软件发行版本内容或者改变最终交付日期。
  在开发过程中，客户可以增加故事、改变故事的权值、分解或者去掉故事。接下来由XP团队重新考虑所有剩余的发行版本并相应修改计划。

  **设计。**XP设计严格遵循KIS原则，即使用简单的设计，而不是复杂的表述。设计为故事提供恰好可实现的指导，而不鼓励额外功能性设计。
  XP鼓励使用CRC卡作为在面向对象环境中考虑软件的有效机制。CRC（类-职责-协作者）卡确定和组织与当前软件增量相关的面向对象的类。CRC卡也是作为XP过程一部分的唯一设计工作产品。
  如果在某个故事设计中碰到困难，XP推荐立即建立这部分设计的可执行原型。实现并评估设计原型被称为spike解决方案。其目的是在真正实现开始时就降低风险，对可能存在设计问题的故事确认其最初的估计。
  XP鼓励鼓励的重构既是构建技术又是设计技术。

  重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。这是一种净化代码（并修改或简化内部设计）以尽可能减少引入错误的严格方法。实质上，重构就是在编码完成之后改进代码设计。

  重构的目的是控制那些“可以根本改进设计”的小的设计变更所要进行的修改。重构所需的工作量随着应用软件规模的增长而急剧增长。
  XP的中心观念是设计可以在编码开始前后同时进行，重构意味着设计随着系统的构建而连续进行。实际上，构建活动本身将给XP团队提供关于如何改进设计的指导。

  **编码。**XP推荐在故事开发和初步设计完成后，团队不是直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试，一旦建立起单元测试，开发者就更能够集中精力于必须实现的内容以通过单元测试。不需要加任何额外的东西（KIS，保持简洁）。一旦编码完成，就可以立即完成单元测试，从而向开发者提供及时反馈。

  编码活动中的关键概念是结对编程。XP建议两个人面对同一台计算机共同为一个故事开发代码。这一方案提供了实时解决问题和实时质量保证的机制，同时也使得开发者能集中精力于手头的问题。
  当结对的两人完成其工作后，他们所开发代码将于其他人的工作集成起来。

  测试。所建立的单元测试应当使用一个自动实施的框架，这种方式支持每当代码修改之后即时的回归测试策略。
  一旦将个人的单元测试组织到一个“通用测试集”，便每天都可以进行系统的集成和单元测试。这可以为XP团队提供连续的进展指，也可在一旦发生问题的时候及早提出预警。

  每几个小时修改一些小问题，要比仅仅在最后截止期之前修正大问题要节省时间。 ——Wells

  XP验收测试也称为客户测试，由客户规定技术条件， 并且着眼于客户可见的、可评审的系统级的特性和功能，验收测试根据本次软件发布中所实现的该用户故事而确定。

2.工业极限编程

  工业极限编程（IXP）：IXP是XP的一种有机进化，它由XP的最低限要求、y以客户为中心和测试驱动精神组成。IXP与原来的XP主要差别在于其管理具有更大的包容性，它扩大了用户角色，升级了技术实践。

  准备评估。 IXP团队确定该项目社区的所有成员（例如利益相关者、开发者、管理者）是否都准备就绪，是否建立了合适的环境，以及是否理解所涉及的技术水平。
  项目社区。 IXP团队确定人员及其所具有的技能是否合适，是否针对该项目已进行了阶段性培训。该“社区”包括技术专家和其他利益相关者。
  项目特许。 IXP团队通过对项目本身进行评估来确定对于项目的合适的商业调整是否存在，以及是否可以进一步深化组织机构的整体目标和目的。
  测试驱动管理。 IXP团队建立一系列可测量的“目标”以评估迄今为止的进展情况，然后定义一些机制来确定是否已经实现了这些目标。
  *回顾。**IXP团队在一个软件增量交付之后要实施特定的技术评审。这种评审称为回顾*，评审通过软件增量或者全部软件的发布过程复查“问题、事件以及经验教训”。
  持续学习。鼓励XP团队的成员去学习新的方法和技术，从而获得高质量的软件产品。

五、其他敏捷过程模型

  四种常见的敏捷方法：Scrum、DSSD、敏捷建模（AM）以及敏捷统一过程（AUP）。

1.Scrum

  Scrum原则与敏捷宣言是一致的，应用Scrum原则指导过程中的开发活动，过程由“需求、分析、设计、演化和交付”等框架性活动组成。每一个框架活动中，发生于一个过程模式中的工作任务称为一个冲刺。冲刺中进行的工作（每一个框架活动中冲刺的数目根据产品复杂度和规模大小而有所不同）适用于当前的问题，由Scrum团队规定并常常进行实时修改。
  Scrum强调使用一组“软件过程模式”，这些过程模式被证实在时间紧张的需求变更的业务关键的项目中是有效的。每一个过程模式定义一系列开发活动。

  待定项——一个能为用户提供商业价值的项目需求或特性的优先级列表。待定项中可以随时加入新项。产品经理根据需要评估待定项并修改优先级。
  冲刺——由一些工作单元组成，这些工作单元是达到待定项中定义的需求所必需的，并且必须能在预定的时间段内完成。冲刺过程中不允许有变更。因此，冲刺给开发团队的工作提供了短期但稳定的环境。
  Scrum例会——Scrum团队每天召开的短会，会上所有成员都要回答三个问题：

• 上次例会后做了什么？
• 遇到了什么困难？
• 下次例会前计划做什么？

  团队领导（也称为Scrum主持人）主持回忆并评价每个团队成员的表现。Scrum会议帮助团队尽早发现潜在的问题。同时，每日例会能够促进“知识社会化交流”以及自我组织团队的建设。
  演示——向客户交付软件增量，为客户演示所实现的功能并由客户对其进行评价。演示不需要包含计划内的所有功能，但那是规定该时间段内的可交付功能必须完成。

2.动态系统开发方法

  动态系统开发方法（DSDM）是一种敏捷软件开方法，该方法提供一种框架， 使其“通过在可控仙姑环境中使用增量原型开发模式以完全满足对事件有约时的系统的构建和维护”。
  DSDM使用迭代软件过程， 每一个迭代都遵循80%原则，即每个增量只完成能够保证顺利进入下一增量的工作，剩余的细节则可以在知道更多业务需求或者提出并同意变更之后完成。
  DSDM定义了一下3个不同迭代周期：

  功能模型迭代——为客户开发一系列可证明其功能的增量原型（注意：所有DSDM原型都倾向于逐渐演化为可交付的应用系统）。这一迭代周期的意图是在用户使用原型系统时引导出反馈信息以获取补充的需求。
  设计和构建迭代——在功能模型中，重新构建原型以确保每一个原型都以工程化方式实现，并能为最终用户提供可操作的业务价值。有些情况下， 功能模型迭代、设计和构建迭代可同步进行。
  实现——将最终软件增量（一个可操作的原型）置于运行环境中。应当注意：（1）增量不见得100%完成；（2）增量置于运行环境以后可能需要变更。在这两种情况，DSDM开发转向功能模型迭代活动继续进行。

3.敏捷建模

  AM是一种基于实践的方法学， 用于对基于软件的系统实施有效建模和文档编制。在软件开发项目中，AM是可以有效并以轻量级方式用于软件建模的标准、原则和实践。由于敏捷模型只是大致完善，而不要求完美，因此敏捷模型比传统的模型更有效。
  AM采纳了与敏捷宣言一致的全部标准。敏捷建模的指导思想认为，敏捷团队必须又做出决定的勇气，哪怕这些决定可能否决的当前的设计并导致重新构建。敏捷团队也必须保持奇拿需作风，应当意识到技术并不能解决所有问题，要虚心尊重并采纳业务专家或其他利益相关者的意见。

  有目的的模型。在构建模型之前，使用AM的开发者心中应当有明确的目标（如与客户沟通信息，或有助于更好的理解软件的某些方面），一旦确定模型的目标，则该用哪种类型的表达方式以及所需要的具体细节程度都是显而易见的。
  使用多个模型。 AM建议从需要的角度看，每一种模型应当表达系统的不同侧面，并且应使用能够为预期读者提供价值的那些模型。
  轻装上阵。只保留那些能提供长期有价值的模型，抛弃其余的模型。每次决定保留一个模型，你都要在以抽象方式使用信息的便利性和敏捷性方面做权衡（即团队内部、团队与利益相关者增强沟通）。
  内容重于表述形式。建模应当向预期的读者分享重要的信息。一个有用内容很少到哪语法完美的模型不如一个带有缺陷但能向读者提供有用内容的模型更有价值。
  理解模型及工具。理解每一个模型及其构建工具的优缺点。
  适应本地需要。建模方法应该适应敏捷团队的需要。

4.敏捷统一过程

  敏捷统一过程（AUP）采用了一个“在大型上连续”以及“在小型上迭代”的原理来构建基于计算机的系统。采用经典UP阶段性活动——起始、细化、构建和转换——AUP提供了一系列活动(例如软件工程活动的一个线性序列)，能够使团队为软件项目构想出一个全面的过程流。每个AUP迭代执行以下活动：

• 建模。建立对商业和问题域的UML表述。
• 实现。将模型翻译成源代码。
• 测试。像XP一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
• 部署。重点仍然是对软件增量的交付以及获取最终用户的反馈信息。
• 配置及项目管理。配置管理着眼于变更管理、风险管理以及对开发团队的任意产品的控制。项目管理追踪和空盒子开发团队的工作进展并协调团队活动。
• 环境管理环境管理协调过程基础设施，包括标准、工具以及适用于开发团队的支持技术。

5.敏捷过程工具集

  敏捷开发工具的目标是辅助敏捷开发的一个或多个方面，强调便利地快速构建可执行软件。敏婕工具集包括项目计划、用例和需求收集、快速设计、代码生成和测试的自动支持。代表性工具有OnTime、Ideogramic UML、Together Tool Set。

  自动软件工具应当被看作是对开发团队活动的小小的补充，而不是团队成功的关键。敏捷团队强调使用工具可以达到快速理解的目的。有些工具是社会性的，甚至开始于租赁阶段。有些工具是技术性的，可以帮助使用者团队模拟物理现状。很多工具是物理性的，允许人们在工作场所操作这些工具。