「这是我参与2022首次更文挑战的第1天，活动详情查看：2022首次更文挑战」。
本着用最直白的话说明白你所见的、或所听的软件开发组织方式！
在工作过程中，你可能有过这些经历或正在进行着：
场景一：
- 每天早上要站着开个简短的早会。
- 有个小黑板（白板）上面贴满了各种卡片。
- 项目软件每两三周上个版本，上一部分功能。
- 没多少文档，基本上代码先行。
- 互相审阅代码，可能是两两一对。
- 有时间精力就重构，不局限于自己开发的代码。
- 需求老是变来变去。 ……
场景二：
-
基本没那么多会议，早上来了正常上班。
-
开发前有很多文档评审，也就是先出文档再开发（全部文档和计划）。
-
需求变动也有，但一般是在开发过程中需求理解差异点导致，或者需求分析人员遗漏。
-
按需求分析文档，系统设计文档，其他各种详细文档拆分工时，按计划排期。
-
对于引入一些开源技术等，需要安全评估。 ……
可能在一个项目开发过程中，只出现了场景一的列项，或只出现了场景二的列项，更甚的情况下场景一二夹杂的都出现了！
现在，来想一下我们经常说的计划驱动、敏捷开发、瀑布模型、XP编程等等…
没错，上面的列项有些其实就是这些软件开发组织方式的一些表现形式。我们经常说现在都是敏捷开发了，其他都被淘汰了，这样说是有问题的，没有淘汰这一说，只能说是有些软件类别和需求场景用敏捷开发或XP效益更高，但是有些软件只能通过计划驱动来开发。比如基本上大多数的工业软件就需要计划驱动（瀑布模型）来开发，大多数的类似商城或者应用类的软件就是敏捷开发或者XP来完成的。
瀑布模型就是按计算驱动的实际，XP就是敏捷开发的一种，也有其他的属于敏捷开发（比如敏捷开发本身）的软件开发方式。
XP就是极限编程，与极限这个词没有很大的直接关系，主要是表现形式上，场景一就是归属于敏捷开发，其中大部分是XP的表现形式。
像是计划驱动和敏捷开发都是软件工程在不同场景不同阶段下演变出来的开发方式，没有谁能完全取代谁，敏捷开发方式更适合于开发需求可以预计的会发生变动或者需求不明确，需要快速的出一个版本的这种场景。而计划驱动可以预计的是需求基本不会发生多大变动，最多可能是需求理解偏差导致的变动，并且整个软件开发过程有很多的流程，文档要求较高等。
也不是说一个项目就会完全采用敏捷开发或者计划驱动，要看项目多大，如果是一个大的体系结构，由很多项目集成而成的集成系统，那在总体的大的场景下一般会用计划驱动，部分子系统开发过程中一般会使用敏捷开发。 也不是说用了敏捷开发就一定会完全的包含敏捷开发的特征，可能只包含部分，有些还可能会在敏捷开发完成的差不多了，回过头来补充开发文档等。总之，现在的软件工程并不是说这两个场景完全哩清，而是会演变成不同的施行过程，每家公司会结合自己的发展情况和实际情况等，有自己的软件开发管理过程，有时候你可能会觉得两边都沾点，那可能这样做确实是公司慢慢实践出来的，所以也不好评价了！
搞清楚这个，对我们的项目管理或者开发管理是很有用的，最起码有了一定的理论指导，闷头码代码确实爽，但是这些也是比较重要的东西————感而慨之！
