瀑布模型：
简单说就是先定好需求和相关文档，然后构建框架，然后写代码，然后测试，最后发布个产品
一旦文档需求确定，开发人员就按文档开发，直到产品开发完后，才会拿出来给客户。不过这种方式基本不适应现今快速发展的市场现状了。
弊端：
1.接力棒的协作模式带来信息差：瀑布模式下，业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理，再从产品经理传递给研发团队。信息每经过一次传递都有损失，研发团队不了解需求背后真正的业务诉求，业务方不了解技术方案背后的权衡。
2.难以响应变化：瀑布模式下，所有的需求分析和设计工作在开发前完成，并假设需求不会改变，研发过程只需遵循最初的项目计划和范围。事实上，对需求的发掘和理解，应该是一个持续的过程，需要不断地反馈。”
敏捷开发：
敏捷(Agile)作为一种开发流程， 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征
Scrum：
目的：
- 适应变化。Scrum 的一个基本假设，就是外部需求模糊而难以理解。Scrum 对此的理念是：让客户直接看到半成品，他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的：比如每个 Sprint 结束时由 Product Owner 为客户进行展示，又比如任务细化一般不超过一个 Sprint。理解了这一点，才会理解为什么 Scrum 似乎总在变化，因为需求总在变化。
- 快速迭代。Scrum 的另一个基本假设，是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本，而竞争对手半年就能发布，那么几年之内，我们就会被对手甩得远远的。Scrum 对此的理念是：发布即 Milestone（里程碑），宁可每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点，才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。
- 我们作出的决定中， 50% 都是错误的。早早失败，早早学习。因为发布周期缩短，团队没有能力保证作出的每一个决定都正确，很多开销都必须花在试错上；快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队，因为一个人的离职或病假都可能对单一功能的进度造成影响，不利于短期频繁发布。
Scrum 对此的解答是：不要试图不犯错误，而是保证小的错误能被尽快发现从而不会酿成大错
流程：
1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ，这是由 PO（Product Owner） 负责的
2.ST（Scrum Team） 会根据 PB 列表，进行工作量的预估和安排
3.有了 PB 列表，我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog
4.Sprint Backlog 是由 ST 去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）
5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）
6.做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员
7.当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）
8.最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中
极限编程：简称XP
思想：交流、简单、响应和勇气：加强交流；从简单做起；寻求反馈；勇于实事求是
敏捷开发的特点：
1）敏捷开发中更加强调沟通，沟通频率可能比以前更高，沟通时间可能会比以前更长，占用更多的个人工作时间，反而可能因此导致实际开发时间起过原来开发出某个功能的时间；
2）敏捷开发是从用户视图出发,可能会要求工程师成为所谓“全栈工程师”，使开发人员反而感觉工作量增加了，短时间内会表现出开发效率的下降，而且要求所有开发人员对需求的理解能力也要求更高了，所以很多人会感觉敏捷开发对人员的要求更高，其实是因为对人员要求的改变导致现有开发人员能力木桶效应现象发生。
3）快速的迭代使重构工作量增加，会感觉功能不断被修改导致了很多浪费。这种感觉如果不能正确认识，不仅会误以为影响了工作效率，而且会使程序员很受伤，因为他们认为是在不停地返工。
4）信息的透明性要求较多的数据收集，敏捷成熟度越高，收集的信息就越多，收集这些数据会占用一定的精力，如果不能够正确的理解这些数据的价值，会让程序员感觉浪费了很多时间在做无用功，反而降低了开发效率。
敏捷开发的流程：
需求评审：
（1）首先，一个story被PM提出时，需写好用户故事卡片和详细描述；
（2）接着，PM会找RD、QA的leader进行讲解，并交review，review人提出问题及改进意见；
（3）然后，PM和负责具体开发RD、测试QA进行讲解和讨论，RD、QA提出问题、疑问，PM解答，并对详细描述进行修改。
（4）最后，所有参与者觉得没有问题后，PM辅助QA补充详细的验收标准，RD对其进行review，并作为自测和自动化case编写的参考。
（5）此外，在开发和测试的过程中，若发现新问题，PM随时响应，答疑解惑，修改设计的不足。
敏捷开发的思想：
1）拥抱变化：各种因素都会影响计划的执行，所以计划要短，及时调整才能响应一切变化导致的计划的不可行性，避免走弯路。
2）快速响应：市场环境的变化，越来越要求产品、服务的响应及时。比如按照传统方式，规划半年一个版本，一旦需要调整需求，后面所有的计划都得改变，会为项目管理带来极大的挑战，变化的成本奇高，多数情况下会因为多数人的反对而不了了之。响应变化胜过遵循计划
3）快速将功能推向市场变现：迅速占领市场更显得尤其重要，这是在向时间要效益。比如做个用户系统，按照程序员的想法，一次性把用户注册登录、修改密码、忘记密码、记住密码、登录验证码、注销等功能设计完，而如果按功能逐版本开发而不是一次开发完成，而是放在不同的版本里，可能需要更多天数，因为里面会有重构、修改界面等，但是应用可以在第3天就上线。争取了15天上市时间，有哪个系统因为没有验证码在上线后第3天就就被恶意注册？有几个用户会在6天后就忘记密码？有几个人会在9天后就修改密码？有几个人会因为登录频繁因为没有记住密码功能而不在使用？，讲到这里，那位朋友想起他们在上一个版本中的一个功能，如果这个功能按照敏捷的方式开发，可以早3个月推向市场，每个月有上千万的收（上线后的效果统计数据），这才是敏捷真正的价值所在。
4）做最值得做的事：什么事最值得做，什么事就优先级最高，也就是ROI最高，ROI是评价需求优先级的唯一指标。其实ROI是一个综合指标，非常复杂的综合指标，它与开发工作量、市场需求迫切程度、技术关联性、市场价值等因素有关，需要全方位评估。
敏捷开发的误区：
1）敏捷开发不是用来管理开发人员的，不是用来提高开发人员的工作效率的，而是企业全面提升团队绩效的方法
2）瀑布开发模型是以文档为驱动的，把需求文档写出来后，根据文档进行开发的，而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
3）在敏捷开发中每次迭代都被成为一个sprint，中文意为“冲刺”，可见其速度与效率
4）尽管对敏捷开发的变通运用，可以带来巨大的效益，但现实情况是，多数变通能力需要经历学习曲线的规律。当人们和组织在学习的过程中，在经历阶跃变化前，交付能力可能还会下降，当经历这个转变后，才开始获得交付能力的提升。
5）当敏捷开发被大爆炸式地应用于大型项目、方案或整个组织时，存在一个显著的风险，即一个敏捷开发模式的好处可能不会被意识或理解。组织及其员工常常会继续着他们一直在做的事情，却自认为已经使用了一个“敏捷”方法。转变能力是一个长期的学习和改变的过程。企业在发展，同时执行业务最好的方式也在不断转变。因此，执行一个大爆炸式的“敏捷”转型后，想当然地认为进一步的改进不再必要，是一个错误认识。
6）没有MRD，如何管理好需求？使用story模式来管理需求，将庞大的MRD划分为一个个可独立交付的story（通常每个story能在1~5天内完成，包括设计、开发、测试），需求清晰明了可节省大量的需求评审时间。
7）项目一开始，XP 就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。从这里可以看出通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。
8）敏捷是万能的么? 我上学的时候老师教我们 “形式化的软件开发方法 (Formal Method)”, “里程碑式的开发 (Plan-driven development)”, 它们都被淘汰了? 答: 不是, 和任何武功和战术一样, 敏捷有它最适用的范围, 我借着酒劲, 画一个表:
| 客观因素\最适用方式 | 敏捷 (Agile) | 计划驱动 (Plan-driven) | 形式化的开发方法 (Formal Method) |
| 产品可靠性要求 | 不高, 容忍经常出错 | 必须有较高可靠性 | 有极高的可靠性和质量要求 |
| 需求变化 | 经常变化 | 不经常变化 | 固定的需求，需求可以建模 |
| 团队人员数量 | 不多 | 较多 | 不多 |
| 人员经验 | 有资深程序员带队 | 以中层技术人员为主 | 资深专家 |
| 公司文化 | 鼓励变化, 行业充满变数 | 崇尚秩序, 按时交付 | 精益求精 |
| 实际的例子 | 写一个微博网站; | 开发下一版本的办公软件; 给商业用户开发软件 | 开发底层正则表达式解析模块; 科学计算; 复杂系统的核心组件 |
| 用错方式的后果 | 用敏捷的方法开发登月火箭控制程序, 前N 批宇航员都挂了。 | 用敏捷方法, 商业用户未必受得了两周一次更新的频率。 | 敏捷方法的大部分招数都和这类用户无关, 用户关心的是: 把可靠性提高到 99.99%, 不要让微小的错误把系统搞崩溃! |
专有名词：
PB： Product Backlog , 即按优先顺序排列的一个产品需求列表，只能有一个产品backlog
po：Product Owner产品负责人
Sprint Backlog ：有了 PB 列表，我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog
sprint backlog和Product Backlog的关系：
每个矩形都表示一个故事，按重要性排序。最
重要的故事在列表顶部。矩形尺寸表示故事大小（也就是以故事点
估算的时间长短）。
sprint：每次迭代都被成为一个sprint，中文意为“冲刺”
story:翻译是故事，本意是产品的功能，backlog中包含了许多story，故事中包含了如下字段
1、id
2、name，也即功能名
3、重要性，越高越重要
4、初始估算，该故事所需工作量，单位是故事点，3个人需要4天时间，就是12故事点
5、如何做演示，测试规范
6、注解
例如：
注意点：
1、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品
2、Scrum 对此的理念是：发布即 Milestone（里程碑），宁可每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点，才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。
3、sprint计划会议：
内容：
（1）制定Sprint目标
（2）团队成员名单
（3）Sprint backlog（Sprint中包括的故事列表）
（4）确定sprint 演示日期
如何做：
创建索引卡，放到墙上，这种用户体验比计算机和投影仪好得多。
每个故事下面有多个任务，任务只会存在于故事下面，而不会存在于product sprint中
4、们已经完成了 sprint 计划会议，应该创建 sprint backlog 了。它应该在 sprint 计划会议之后，第一次每日例会之前完成，这样规划：没做的，正在做的，已经做的，和燃尽图
经过每日scrum后变成这样：
最后变成这样：
对于燃尽图：
5、每日例会，时间15分钟，每个人都会一边描述昨天已经做的事情和今天要做的事情，一边移动任务板上对应的即时贴，如果他讲的是一个未经计划的条目，那他就新写一张即时贴贴到板上。如果他更新了时间估算，那就在即时贴上写上新的时间，把旧的划掉。
如果有人不知道今天干什么，解决方法
（1）请人添加更多的即时贴上去。接下来我就会对觉得自己没事可干的人说，“我们已经过了一遍任务板，你们现在对今天要做的事情有想法了么？”。希望他们有点儿概念了。
（2）如果他们还不知道该干什么，我会考虑他们是不是可以去跟其他人结对编程。
（3）从任务板右下角的“Next”区域中拿出一两个故事，放到左边的“not checked out”列中。接下来重新进行每日例会。告诉产品负责人一声，你已经把一些条目加进了 sprint
6、对于大部分的团队sprint长度为三周，一个sprint包含10个故事左右
7、对于故事的任务量估算需要每个成员都参与，每个故事的估算，需要每人给出一个故事点，如果两人故事点相差太大，要讨论为什么，直到把所有工作估算完
8、Sprint 演示（有人也叫它 sprint 回顾）是 Scrum 中很重要的一环，且所有的 sprint 都结束于演示
9、Scrum 注重的是管理和组织实践，而XP 关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题，可以互为补充，相得益彰
10、测试驱动开发（TDD）：测试驱动开发意味着你要先写一个自动测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续
11、把测试人员放到 Scrum 团队来提高质量。如果团队在做 TDD，从第一天开始，大家都会花时间来编写测试代码，此时测试人员应该跟编写测试代码的开发人员一起结对编程。
12、多项目一起进行，那么两个项目的sprint应该是同步的
同步进行的 sprint 有如下优点：
可以利用 sprint 之间的时间来重新组织团队！如果各个sprint 重叠的话，要想重新组织团队，就必须打断至少一个团队的 sprint 进程。
所有团队都可以在一个 sprint 中向同一个目标努力，他们可以有更好的协作。
更小的管理压力，即更少的 sprint 计划会议、sprint 演示和发布
13、团队构建：
参考资料：
1、https://blog.csdn.net/nocky/article/details/51236848
2、https://blog.csdn.net/xinxing__8185/article/details/46708439
3、https://blog.csdn.net/baynkbtg/article/details/52402727
4、https://blog.csdn.net/liyangbing315/article/details/5387129
5、https://blog.csdn.net/ostrichmyself/article/details/5375223
6、http://www.cnblogs.com/xinz/archive/2011/04/27/2031118.html
7、https://blog.csdn.net/b0Q8cpra539haFS7/article/details/79245096
8、https://www.zhihu.com/question/19638322
9、scrum and xp chinese version.pdf