传统敏捷开发模型两大流派
传统敏捷开发模型中的两大流派，敏捷开发的高适应性，以人为本的特性。
更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
缺点：
由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。
敏捷开发scrum的实施
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。
Scrum开发流程中的三大角色
– 产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
什么是敏捷开发
敏捷开发（Agile Development）是一种迭代、增量的软件开发流程，强调快速的响应变化和持续的交付。敏捷开发通常采用迭代式开发，每个迭代的持续时间为1到4周，每个迭代完成后都有一个可交付的软件产品。敏捷开发的核心思想是通过不断的反馈和调整来改善软件开发流程和产品质量。
敏捷开发强调以下几个方面：
1. 个体和交互：注重团队成员之间的沟通和协作，以及与客户之间的沟通和反馈。
2. 可工作的软件：注重软件产品的实际功能和价值，以可工作的软件为目标。
3. 持续交付：强调在短时间内交付可用的软件产品，以满足客户的需求和反馈。
4. 变化响应能力：注重对于变化的快速响应和适应能力，以满足客户的需求和市场的变化。
5. 稳定的质量：注重软件产品的质量和稳定性，通过持续的自我检查和改进来提高产品质量。
敏捷开发通常采用一些敏捷方法论，例如极限编程（XP）、Scrum 等，通过这些方法论来帮助团队实现敏捷开发的目标。敏捷开发已经成为现代软件开发的主流方法之一，得到了越来越多的应用和推广。
瀑布式开发和敏捷开发的具体区别是什么
敏捷开发，首先把客户最关注的软件原型先做出来，交付或者上线，在实际场景中去修改弥补需求中的不足，快速修改，再次发布版本。再次上线或者交付。通过一些敏捷实践方式，细化story，可以提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确的项目、创新性的项目或者需要抢占市场的项目。
瀑布式开发，要求明确的需求，大家按照需求一步步做好规划，在项目运作过程中严格产出各种文档，按着流程一步步走下去。这种模式一般适用于需求比较明确、to B端项目
但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。
敏捷软件开发是如何被带跑偏的
首先什么是敏捷开发？
敏捷开发不仅仅是快速编程和迭代式需求变更。他有很多的实践。
比如沟通损耗尽可能低的小团队。
比如面向故事，测试驱动开发。
比如头脑风暴。
比如多人编程提高质量。
比如自解释的代码。
等等等等
在大学的时候，因为在某家还可以的公司实习，显得很狂妄，答辩的时候，我对答辩老师说，虽然传统上说敏捷并不适合大型项目，但是确实有些大型公司在使用并且成功了。
经过8年的工作，我想收回那句话。
敏捷并不适合所有团队，所有项目。
敏捷思想的真实核心不是工程管理，而是欲望。
其实这些实践中不难发现，都是在刺激编程人员创造力和成就感。这些方法都是基于"精英"程序员的做法，就是，那些以编程为乐趣，废寝忘食的人，对于这些人，别说996，忙到2-3点，睡两三个小时，继续工作的都乐此不疲。
现实情况是，这样的人，事实上很少，绝大部分程序员只是编程当成一个工作，老板把项目当成谋利工具，把敏捷当成减少成本的方式。在这样的团队里搞敏捷，味道已经不对了，资方抠，劳方精，是不可能真正完成上面的实践的。
不是说敏捷不好，只是合适的方法，需要合适的平台，很多地方把敏捷说的那么高效，那是因为大神的队友也都是大神，他们思维活跃，不受束缚，富有创造力，这也就不难理解为什么敏捷里会有增加成本的双人编程的情况了。在大部分公司里，用代码的规范替代了双人编程的思维发散与了解。用绩效来替代了迭代。用模块分工替代了头脑风暴。用测试团队替代了测试驱动。确实不太对味。
在国内，老板有老板的苦衷，员工有员工的想法，如果不是一群创业爱好者，尽可能还是走瀑布，走原型吧，没有付出的老板和没有责任心的员工不适合这种高度自由的方式。