回顾软件行业的研发模式,可以发现大致有三个阶段:瀑布式开发、敏捷开发、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成功与否,公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习,从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。