关于敏捷开发

 Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种。

 

  Scrum的基本假设是：

    开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误。Scrum 将软件开发团队比拟成橄榄球队，

有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战， 确保每天、每个阶段

都朝向目标有明确的推进。

 

   Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。

    
    下图是Scrum模型和传统模型的对比：

    

 

1 Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。

--短迭代（渐进、迭代式的开发并始终维护可交付的产品，相对瀑布是的模型能够适应需求的变化，降低风险）与快速沟通（减少沟通成本，快速解决问题）

 

2 在每个迭代（sprint）开始前要开一个sprint planning meeting，将当前迭代周期的需求（blocking）划分成更小的模块，并确定各模块的优先级，并详细的讨论各个功能模块的详细设计并给出时间估算以小时计。

 

3 daily scrum meeting：每天15分钟的站立会议，主要交流3个方面，完成了什么，遇到什么困难，将要做什么--提高沟通效率，快速解决障碍

 

4 Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。

 

5 Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。

 

二）实施Scrum的过程简单介绍

    1) 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。

    2) 召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。

    3) 进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。

    4) 整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.

    5) 团队成员最后召开Sprint retrospective meeting，总结问题和经验。

    6) 这样周而复始，按照同样的步骤进行下一次Sprint.

    整个过程如下图所示
    

 

 

敏捷软件开发宣言：

• 个体和交互     胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作       胜过 合同谈判
• 响应变化       胜过 遵循计划

持续的交付有价值的产品

欢迎需求的变化

开发期间，业务人员与开发人员零障碍的沟通（泡在一起）

鼓励面对面的交流

不断的关注优秀的技术和好的设计

简单即是根本

每过一段时间，团队要在改进效率方面进行反省和总结并加以改进

 

当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。

• 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
• 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
• 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
• 粘滞性： 做正确的事情比做错误的事情要困难。
• 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
• 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
• 晦涩性： 很难阅读、理解。没有很好地表现出意图。

敏捷开发依靠适应变化来获得价值，在设计上不做总体固定的假设，始终关注可扩展性和可维护性，保持结构的简单，并使用单元测试作为支持。这保持了设计的灵活性和易理解性，团队依靠这种灵活性持续的改进设计，以保证每次迭代之后产品更加适应最新的需求。

 

敏捷开发保持软件的新鲜与面向对象的设计原则是分不开的

• 单一职责原则(SRP)
  就一个类而言，应该仅有一个引起它变化的原因。--从封装变化的角度来看类的设计
• 开放-封闭原则(OCP)
  软件实体应该是可以扩展的，但是不可修改。--程序的抽象层的修改时封闭的，对具体的实现层的扩展时开放的
• Liskov替换原则(LSP)
  子类型必须能够替换掉它们的基类型。
• 依赖倒置原则(DIP)
  抽象不应该依赖于细节。细节应该依赖于抽象。--最基本的原则了，以便利用多态实现开闭原则
• 接口隔离原则(ISP)
  不应该强迫客户依赖于它们不用的方法。--尽可能开放最少的接口给客户
• 重用发布等价原则(REP)
  重用的粒度就是发布的粒度。
• 共同封闭原则(CCP)
  包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
• 共同重用原则(CRP)
  一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
• 无环依赖原则(ADP)
  在包的依赖关系图中不允许存在环。
• 稳定依赖原则(SDP)
  朝着稳定的方向进行依赖。
• 稳定抽象原则(SAP)
  包的抽象程度应该和其稳定程度一致。

敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。