开发模型的演化

开发模型其实是在时代洪流的发展中，不断总结和摸索的结果。

1.瀑布模型

这是一个经典的模型，也是你们用的最多的模型 将项目活动分解为线性顺序阶段，其中每个阶段取决于前一个阶段的可交付成果。

优点：

1. 由于其强调需求，需求分析，在软件生产周期早期花费的时间可以降低后期阶段的成本
2. 强调文档（例如需求文档和设计文档）以及源代码，在设计和记录不够彻底的方法中，如果团队成员在项目完成之前离开，知识就会丢失，并且项目可能难以从损失中恢复。如果存在完整的设计文档，新的团队成员甚至全新的团队应该能够通过阅读文档来熟悉自己

缺点：

1. 需求文档经常描述不清楚，或者遗漏。
2. 工作人员经常认为编码完了，工作就完了。 3.各种设计文档工作量很大，内容乏味，但编码完成后基本都对不上了。 4.客户在看到工作软件之前可能并不确切地知道他们的需求是什么，因此会改变他们的需求，从而导致重新设计、重新开发和重新测试，并增加成本 5.设计人员在设计新的软件产品或功能时可能没有意识到未来的困难，在这种情况下，最好修改设计而不是坚持不考虑任何新发现的约束、要求或问题的设计。

具体参考

https://en.wikipedia.org/wiki/Waterfall_model

原型模型

原形要解决的问题就是需求不准，避免需求经过长时间的开发，浪费了大量的金钱和人力，得到的软件还不是用户所期望的。

原形模型采用的方式是：开发团队在分析需求的时候，尽快开发出一个用户看得到的原形， 让用户尽早感受到效果 。其实原形模型更多的是一种沟通方式，只是有人不丢掉原形，在原形的基础上继续开发，才被定位为原形模型。不过原形的开发过程时间紧，任务重，结果非常粗糙，重用的成本一般很高，建议还是丢掉。

优点：

1. 减少时间和成本：原型设计可以提高提供给开发人员的需求和规范的质量
2. 改进和增加用户参与：原型设计需要用户参与，并允许他们查看原型并与之交互，从而使他们能够提供更好、更完整的反馈和规范

缺点

1. 分析不足：对有限原型的关注可能会分散开发人员正确分析整个项目的注意力

具体参考

https://en.wikipedia.org/wiki/Software_prototyping#Throwaway_prototyping

迭代模型

迭代模型的思路是分解需求。看似简单的分解操作，却得到了三个好处：

1. 当需求变小后，每个需求的开发过程就会变简单，每个阶段的工作也都可控了。每个迭代的需求都像瀑布模型一样有分析、设计、开发、测试，但是因为需求小，对文档的依赖减弱很多。
2. 开发人员可以将前一个迭代学到的东西用在下一个迭代，开发越来越顺畅。
3. 为开发不确定需求提供了可能。虽然整个需求没有完全想清楚，但是想清楚的部分可以先开发。

参考

https://en.wikipedia.org/wiki/Iterative_and_incremental_development

敏捷

敏捷核心关键词： 快速交付，持续重构；演进的需求和方案；自组织且跨功能的团队 。

用户的需求一般都只是一个大方向，具体的价值和实现方式都是不确定的，用户也在不断探索他们的业务。敏捷接纳了原型法的需求分析方法，还提出了 Inception 来分析更有价值的需求，通过 MVP 圈定最小开发范围，快速验证方案，这就是演进的需求和方案

自组织且跨功能的团队

在 Self-Organizing 组织方式下，每个人都致力于项目的目标，团队成员互相尊重，每个人都专注于工作，开放，团队成员有勇气站出来参与该项目。这里最关键的就是 每个人都致力于项目的目标 。如果只有 Project Manager 直接关注目标，其他人很难知道自己做的内容和目标之间有什么关系，就不能对这个目标做太多的努力。类似一个开发人员开发了一个定时任务需求，测试人员需要等待若干小时才能测试一次。如果开发人员提供一个手工触发的接口，测试人员的工作效率就会提升很多。所以看清楚全局的目标和问题能很大的提升生产力，敏捷的每日站会就在为这个而努力。

参考： https://www.infoq.cn/article/lpq3iig3skbv3oqmz3wv