软件测试-了解的软件行业的研发模式（瀑布&敏捷&DevOps）

---

瀑布式开发

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。

瀑布模型的特点（传统的开发方式）

• 强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期才可以看到软件的“模样”。
• 没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应。瀑布就意味着没有回头路。
• 管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。

瀑布模型优缺点

• 优点明显：
  • 阶段清晰。从计划到开发最后到上线运行，三个阶段非常清晰。
  • 时间顺序。每个阶段顺序必须是从上到下，严格按照时间先后进行。
  • 环环相扣。在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。
  • 黑盒模式。每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注。
• 缺点突出：
  • 需求隔离。由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
  • 变更代价大。既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。
  • 束缚创造性。由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。
  • 周期漫长。整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。
• 归纳总结
  　　- 根据以上分析，我们知道瀑布模式强调里程碑，重视文档，强调分工，避免变化，凡事喜欢规划和做计划，但是代价就是拖沓笨重，反应迟钝。

---

敏捷开发

什么是敏捷开发？

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

---

极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。
敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。
敏捷开发集成了新型开发模式的共同特点，它重点强调：

• 敏捷就是“快”。快才可以适应目前社会的快节奏，要快就要发挥个人的个性思维多一些个性思维的增多。
• 客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求。
• 强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。
• 设计周密是为了最终软件的质量，但不表明设计比实现更重要。
• 迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”。对迭代的强调是缩短了软件版本的周期。
• 小版本。快速功能的展现，看似简单，但对于复杂的客户需求合理地分割与总体上的统一，要很好地二者兼顾是不容易的。

为什么说是以人为核心？

瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；
敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

什么是迭代？

迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

Scrum开发流程中的三大角色

• 产品负责人（Product Owner）
  主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
• 流程管理员（Scrum Master）
  主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
• 开发团队（Scrum Team）
  主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

---

• 敏捷开发的4句宣言
  • 个体与交互 胜过 过程与工具
  • 可以工作的软件 胜过 面面俱到的文挡
  • 客户协作 胜过 合同谈判
  • 响应变化 胜过 遵循计划

---

• 敏捷开发企业级项目工作一体化：
  
  敏捷开发作者：Cat Qi
  出处：http://qixuejia.cnblogs.com/

---

DevOps

DevOps简介

DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。

DevOps的概念

DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps其实包含了三个部分：** 开发、测试和运维。**

DevOps好处是什么？

DevOps的一个巨大好处就是可以高效交付，这也正好是它的初衷。
DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感；
快速的部署其实可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且，DevOps小步快跑的形式带来的变化是比较小的，出现问题的偏差每次都不会太大，修复起来也会相对容易一些。

为什么DevOps会兴起？为什么会继续火下去？

• 条件成熟：技术配套发展
  DevOps的实现可以基于新兴的容器技术；也可以在自动化运维工具Puppet、SaltStack、Ansible之后的延伸；还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。
• 来自市场的外部需求：这世界变化太快
  IT行业已经越来越与市场的经济发展紧密挂钩，专家们认为IT将会有支持中心变成利润驱动中心。能否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得至关重要。
  DevOps 2016年度报告给出了一个运维成本的计算公式：
  停机费用成本 = 部署频率 * 版本迭代失败概率 * 平均修复时间 * 断电的金钱损失
• 来自团队的内在动力：工程师也需要
  对于开发者而言，最有力的工具就是自动化工具！工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；（You build it, you run it）

实现DevOps需要什么？

• 硬性要求：工具上的准备
  • 代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
  • 构建工具：Ant、Gradle、maven
  • 自动部署：Capistrano、CodeDeploy
  • 持续集成（CI）：Bamboo、Hudson、Jenkins
  • 配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
  • 容器：Docker、LXC、第三方厂商如AWS
  • 编排：Kubernetes、Core、Apache Mesos、DC/OS
  • 服务注册与发现：Zookeeper、etcd、Consul
  • 脚本语言：python、ruby、shell
  • 日志管理：ELK、Logentries
  • 系统监控：Datadog、Graphite、Icinga、Nagios
  • 性能监控：AppDynamics、New Relic、Splunk
  • 压力测试：JMeter、Blaze Meter、loader.io
  • 预警：PagerDuty、pingdom、厂商自带如AWS SNS
  • HTTP加速器：Varnish
  • 消息总线：ActiveMQ、SQS
  • 应用服务器：Tomcat、JBoss
  • Web服务器：Apache、Nginx、IIS
  • 数据库：MySQL、Oracle、PostgreSQL等关系型数据库；cassandra、mongoDB、redis等NoSQL数据库
  • 项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
• 软性需求：文化和人
  • DevOps成功与否，公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习，从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。

---