第三章 软件生存期模型

1 生存期模型选择

2 预测型模型

2.1 瀑布模型

需求：很明确
方案：很明确
类似项目： 短期项目

2.2 V模型

需求：很明确
方案：很明确
类似项目： 系统性强、安全等有严格要求

3 迭代模型（原型模型）

需求：不明确
方案：复杂性高
项目：变更频繁

4 增量模型

优点：

5 敏捷模型

敏捷方法是一种脑阔了各种框架和方法的涵盖性术语。敏捷模型既有迭代，也有增量。

敏捷模型也在不断地发展过程中，从经典的Scrum模型到XP极限编程发展到持续的交付，以至于到全程敏捷的Devops模型。

敏捷开发(Agile Development)是一种以人为 核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种 开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是 迭代式开发；

敏捷与传统模型（瀑布模型）的区别：

1.传统软件开发更倾向于不考虑项目后期需求的变化，在项目开始时预测用户的需求然后分析需求，制定相应的开发计划，再按照计划执行。而计划与实际间会存在一定的差距。

2.与之形成鲜明对比的的是敏捷软件开发过程，他是不断地进行反馈，动态调整需求，最终达成目标，这种自适应性的特征使得敏捷开发的产品更符合实际的需求。

5.1 Scrum模型

敏捷的工作模型：

项目需求来自于待开发的功能列表，初始需求可以很粗，但是要有优先级，每个迭代是按照优先级来进行，从中选择部分内容进行迭代。

每个迭代1-4周左右，迭代完成就提交一个可交付的运行成果，然后进行评审，反馈进行下一个迭代。

scrum里面的三个角色：

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产 品负责。
scrum master 负责召开各种会议，协调项目，为研发团队服务。 研发团队(开发人员，测试人员，ui设计人员...)则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

scrum里面的五个会议：

产品经理负责整理user story，形成左侧的product backlog。
发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出 这一期迭代要完成的story列表，sprint backlog。
迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有 明确的负责人，并完成工时的初估计。
每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成 果。期间大家的反馈记录下来，由po整理，形成新的story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改 进的效果。

5.2 极限编程模型（XP模型，extreme programming）

XP(eXtreme Programming)极限编程是由Kent Beck提出的一套针对业务需求和软件开发实践的规则。

XP由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联， 并通过行为贯穿于整个生命期。

四大价值观：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）

五大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作。

极限编程13个最佳实践是通过整体实践，开发团队实践，开发者实践三个层面来体现。

5.2.1 四个整体实践

1.完整团队（Whole Team）：团队当中包括客户，程序员，测试员，分析员还有一个上层的经理等等，那么每个角色是平等的。
2.计划博弈 ( Planning Game )：体现主要两个主要计划，发布计划和迭代计划。
3.小型发布 ( Small Release )：如果有可能，每天都要发布一个小版本。
4.现场客户( Customer Tests)：客户对每一个需求都定义了一些验收测试，通过运行验收测试，开发人员和客户可以知道开发出来的软件是否符合需求。

5.2.2 五个开发团队实践

1.集体所有（Collective Ownership）：团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。同时，XP强调代码是谁破坏的，就应该由谁来修复。
2.代码规范 ( Code Standards )：开发团队应该拥有一个编码标准。
3.平稳工作 ( Sustainable Pace )：加班最终会扼杀团队的积极性，最终导致项目失败，每周工作40小时是一种顺势行为，是一种规律。
4.系统隐喻 ( System Metaphor )：寻求共识，发明共享词汇，描述体系结构。隐喻是设计和沟通的辅助手段，使项目成员对于系统的实现方式达成共识。
5.持续集成 ( Continuous Integration )：开发人员坚持随时进行提交，系统每天一次集成。

5.2.3 四个开发者实践

1.简单设计 ( Simple Design )：用最简单的方法来实现小的需求，那么这些设计只要能满足当下的需求就可以了，而且所有的这些设计都将在后续的开发中被不断地重整和优化。
2.结对编程 ( Pair Programming )：系统的任何一个部分都肯定至少有2个人以上熟悉，好处是代码会被100%review，有效地降低代码缺陷率。
3.测试驱动开发 ( Test-driven Development)：极限编程将测试结合到开发过程中，每次结合代码都应该运行一遍所有的测试。
4.代码重构 ( Refactoring ) ：时刻对代码进行重构，一直保持其良好的结构与可扩展性。集体检查也是很重要的。

5.3 DevOps

DevOps是 Development 和 Operations 的合成词，其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢？需要我们的项目做到持续集成、持续交付、持续部署。

时下流行的DevOps工具有: Gradle、Git、Jenkins、Docker、Kubernetes、Ansible、Raygun等等

DevOps是一种方法论，是一组过程，方法与系统的统称，用于促进开发，技术运营和质量保障（QA）部门之间的沟通，协作与整合。

6 混合模型