1. 瀑布流开发模式介绍
一种曾经广泛流行的软件开发模式。
一种重视文档，强调顺序的软件开发流程，通常按照阶段依次顺序执行，自上而下、相互衔接的固定次序，如同瀑布流水逐级下落，所以被称为瀑布开发。
整个开发流程大致可分为三个阶段，分别是计划时期、开发时期、运行时期。
计划时期包含问题定义、可行性研究；开发时期包含需求分析、概要设计、详细设计、编码、测试；运行时期包含运行和维护。
瀑布模型适用于需求确定后变动小的项目
2. 敏捷开发模式介绍
当今广泛流行的软件开发模式。
强调快速迭代，尽早交付的开发流程。
敏捷开发模型，适用于当今各个需求变化迅速的项目。
敏捷宣言
2001年2月，在美国犹他州的一个滑雪场，由17个人组成的一个自称为无*组织的团体出现了。这是17位轻量级软件开发方法的创始人和专家，包括Kent Beck、Martin
Fowler、Robert C. Martin等等，共同发布了“The Manifesto for Agile Software
Development”（敏捷软件开发宣言）。
随着时间流逝，敏捷终于为软件行业，以及这个行业中的一些人所认识、理解和推崇。
四个核心价值观
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
12个原则
1.最重要的目标是通过及早和持续不断地交付有价值的软件使客户满意。
2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7.可工作的软件是进度的首要度量标准。
8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10.以简洁为本，它是极力减少不必要工作量的艺术。
11.最好的架构、需求和设计出自自组织团队。
12.团队定期地反思如何能提高成效，并依此调整自身的行为表现。
3.极限编程
简单介绍
极限编程（Extreme programming，缩写为XP）。
是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。
如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。
极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；
他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法
极限编程的12个核心实践
短交付周期
极限编程和Scrum一样采用迭代的交付方式，每个迭代1-3周时间。
在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。
计划游戏
XP的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该做些什么。
不断的回答这两个问题，就是直接服务于如何实施及调整开发过程；与此相比，希望一开始就精确定义整个开发过程要做什么事情以及每件事情要花多少时间，则事倍功半。
针对这两个问题，XP中有两个主要的相应过程：
软件发布计划（ReleasePlanning）。
客户阐述需求，开发人员估算开发成本和风险。客户根据开发成本、风险和每个需求的重要性，制订一个大致的项目计划。
最初的项目计划没有必要（也没有可能）非常准确，因为每个需求的开发成本、风险及其重要性都不是一成不变的。而且，这个计划会在实施过程中被不断地调整以趋精确。
周期开发计划（IterationPlanning）。
整个开发过程中，应该有很多阶段计划（比如每三个星期一个计划）。
经过每个开发周期，用户都应该能得到一个已经实现了一些功能的系统。而且，每经过一个周期，客户就会再提出确定下一个周期要完成的需求。
在每个开发周期中，开发人员会把需求分解成一个个很小的任务，然后估计每个任务的开发成本和风险。
这些估算是基于实际开发经验的，项目做得多了，估算自然更加准确和精确；在同一个项目中，每经过一个开发周期，下一次的估算都会有更过的经验、参照和依据，从而更加准确。
可持续的节奏
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
编码规范
XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。
因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现代码集体所有的重要前提之一。
测试驱动开发
测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。
测试驱动开发的基本过程：
① 快速新增一个测试
② 运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过
③ 做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法
④ 运行所有的测试，并且全部通过
⑤ 重构代码，以消除重复设计，优化设计结构
简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号
简单设计
XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必须通过测试。
这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。
结对编程
结对编程是指代码由两个人坐在一台电脑前一起完成。
一个程序员控制电脑并且主要考虑编码细节。另外一个人主要关注整体结构，不断的对第一个程序员写的代码进行评审。
结对不是固定的：我们甚至建议程序员尽量交叉结对。
这样，每个人都可以知道其它人的工作，每个人都对整个系统熟悉，结对程序设计加强了团队内的沟通。这与代码集体所有制是息息相关的。
代码集体所有
代码集体所有意味着每个人都对所有的代码负责；这一点，反过来又意味着每个人都可以更改代码的任意部分。
结队程序设计对这一实践贡献良多：借由在不同的结队中工作，所有的程序员都能看到完全的代码。集体所有制的一个主要优势是提升了开发程序的速度，因为一旦代码中出现错误，任何程序员都能修正它。
在给予每个开发人员修改代码的权限的情况下，可能存在程序员引入错误的风险，他／她们知道自己在做什么，却无法预见某些依赖关系。
完善的单元测试可以解决这个问题：如果未被预见的依赖产生了错误，那么当单元测试运行时，它必定会失败。
重构
XP强调简单的设计，但简单的设计并不是没有设计的流水账式的程序，也不是没有结构、缺乏重用性的程序设计。
开发人员虽然对每个USERSTORY都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫设计的重构。
重构主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。
但XP强调，把重构做到极致，应该随时随地、尽可能地进行重构，只要有可能，程序员都不应该心疼以前写的程序，而要毫不留情地改进程序。
当然，每次改动后，程序员都应该运行测试程序，保证新系统仍然符合预定的要求。
系统隐喻
为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。
比如，对于一个搜索引擎，它的系统隐喻可能就是“一大群蜘蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。”
持续集成
集成软件的过程不是新问题，如果项目开发的规模比较小，比如一个人的项目，如果它对外部系统的依赖很小，那么软件集成不是问题，但是随着软件项目复杂度的增加（即使增加一个人），就会对集成和确保软件组件能够在一起工作提出了更多的要求-要早集成，常集成。
早集成，频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。
持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。
每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
现场客户
在极限编程中，“客户”指的是真正使用该产品的人。极限编程认为客户应该时刻在现场解决问题。
例如：在团队开发一个财务管理系统时，开发小组内应包含一位财务管理人员。客户负责编写故事和验收测试，现场客户可以使团队和客户有更频繁的交流和讨论。
极限编程的5个原则
1. 快速反馈
当反馈能做到及时、迅速，将发挥极大的作用。
一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。
与传统开发方法不同，极限编程开发与客户的发生接触是不断反复出现的。客户能够清楚地洞察开发中系统的状况就能够在整个开发过程中及时给出反馈意见，并且在需要的时候能够掌控系统的开发方向。
单元测试同样对贯彻反馈原则起到作用。
在编写代码的过程中，应需求变更而做出修改的系统将出现怎样的反应，正是通过单元测试来给出直接反馈的。
2. 假设简单
假设简单认为任何问题都可以”极度简单”地解决。
传统的系统开发方法要考虑未来的变化，要考虑代码的可重用性。极限编程拒绝这样做。
3. 增量变化
极限编程的提倡者总是说：罗马不是一天建成的。一次就想进行一个大的改造是不可能的。
极限编程采用增量变化的原则。比如说，可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式，使得整个开发进度以及正在开发的系统对于用户来说变得更为可控。
4. 拥抱变化
可以肯定地是，不确定因素总是存在的。“拥抱变化”这一原则就是强调不要对变化采取反抗的态度，而应该拥抱它们。
比如，在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员，必须拥抱这些变化，并且拟定计划使得下一个阶段的产品能够满足新的需求。
5. 高质量的工作
极限编程的提倡者认为范围、时间、成本和质量这个四个软件开发的变量，只有质量不可妥协的。
4.scrum开发框架
scrum简单介绍
Scrum是一种典型的敏捷开发方式，开发核心是迭代式增量开发。
三大支柱
scrum理论基于经验主义，可以视为经验过程。
透明和检视和适应是经验过程控制的三大支柱，支撑起每scrum过程的实施
透明
scrum过程中的关键环节对于那些对产出负责的人必须是显而易见的。
要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。
例如
• 所有参与者谈及过程时都必须使用统一的术语。
• 负责完成工作和检视结果增量的人必须对“完成”的定义，有一致的理解。
检视
Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint目标的进展，以便发现不必要的差异。
检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉地执行时，效果最佳。
适应
如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。
调整工作必须尽快执行如此才能最小化进一步的偏离。
scrum团队
Scrum 团队由一名产品负责人、开发团队和一名scrum master组成，scrum团队是自组织团队
自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的人来指导。自组织团队是跨职能团队，拥有完成工作所需的全部技能，不需要依赖团队之外的人。
产品负责人
对整个产品负责的人，确定产品订单中需求的优先级，督促团队优先开发最具价值的功能，确保最具价值的开发需求始终安排在最近的迭代中完成。
Scrum Master
Scrum Master维护Scrum流程，确保团队与产品负责人对Sprint的目标一致，对Scrum的成功负责
召开会议
消除障碍
保护团队
沟通协调
变革发起人。
开发团队
开发团队包含了各类专业人员的自组织团队,负责在每个 Sprint 的结尾交付可发布的“完成”产品增量。
3种工件
产品待办列表
Product Backlog，可以理解为排好优先级（商业价值）的需求
Sprint待办列表
Sprint Backlog，可以理解为一次迭代的需求
增量
Increment 一次迭代中，实际完成的需求。
5种事件
Sprint
scrum的核心，包含其他事件。（可以看做一个迭代）
Sprint计划会议 （Sprint Planning）
计划一次sprint中要做的工作的会议（过需求）
每日Scrum站会 （Daily Scrum）
站会，很短，十五分钟左右，一般每天早上开。开发团队各成员介绍说明三件事情
1.昨天干了什么。
2.今天预计要干什么。
3.有没有遇到什么困难，阻碍工作进度。
Sprint评审会议（Sprint Review）
Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办列表
Sprint回顾会议 （Sprint Retrospective）
Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。
5种价值观
承诺 Commitment
愿意对目标做出承诺
勇气 Courage
有勇气做出承诺，履行承诺
专注 Focus
把心思和能力都用到承诺的工作上去
开放 Openness
Scrum 把项目中的一切可开放给每个人看
尊重 Respect
每个人都有他独特的背景和经验，团队成员相互尊重。
5.DevOps
什么是DevOps
DevOps （Development和Operations的组合词），理念就是希望能打破软件开发过程中种种角色之间的屏障，让研发（Development）和运维（Operations）一体化，让团队从业务需求出发，向着同一个目标前进的软件研发理念。
软件开发最高效的组织形式是“One Man Work”，只有一个人干活，写个小项目，从需求到开发，从测试到部署全部独立完成，非常高效。
但随着业务的增长，项目开始逐渐变得庞大，变成团队，出现了分工，出现了产品经理、项目经理、开发、数据、测试、运维等等角色。这些角色间存在天然的工作目标上的矛盾。
从字面意思上说 DevOps 是指“开发运维一体化”，即通过工具辅助开发完成运维的部分工作，减少成本。
但 DevOps 其实是一种软件研发管理的思想，DevOps追求的是一种没有隔阂的理想的研发协作的状态，涉及到的角色包括软件开发中的所有角色，如开发、测试、产品、项目管理、运维。
所以我们认为，为了帮助研发团队在保持质量的前提下提高交付效率的方法和方法论都隶属于 DevOps 的范畴。
DevOps的五个核心要素
文化
建立一体化的全功能团队，打破开发（Dev）与技术运营（Ops）隔阂
自动化
自动化一切可以自动化的。靠平台和工具，如ci/cd支撑
精益
以精益的方式小步快跑，持续改善
度量
建立有效的监控与度量手段快速获得反馈，推动产品和团队的持续改善
分享
不同职能角色、甚至不同产品之间分享经验