软件开发生命周期中的沟通、发布与管理优化
1. 沟通链问题
小时候玩的“疯狂电话”游戏，一个人编造有大量细节的故事写下来，然后读给下一个人，依次传递，通常经过四个人后，故事就和最初的大相径庭，而且从第二个人开始故事就会有变化。在瀑布模型中，需求人员创造一个故事讲给开发人员，开发人员再创造一个新故事讲给QA人员，这必然会导致问题。
传统行业设计出错率低，因为他们制造的是有形物品，如汽车或核反应堆，容易检查，而且通常比软件项目简单。而软件问题可能需要数年才能发现。为缓解这个问题，软件行业使用统一建模语言（UML）创建简洁而复杂的图表，但也存在问题：
- 有些细节难以在图表中体现。
- 业务利益相关者不理解UML。
- 创建图表需要时间。
特别是业务利益相关者不理解UML，在捕获需求后，更改需求或在较低层面（开发、运营等）提出问题时，至少有一方不理解需求捕获所用的语言。而项目需求很少是静态不变的。
2. 修复bug的成本
由于存在沟通问题，软件开发过程中必然会出现bug。在瀑布模型中，修复bug的难度随着阶段推进而增加：
-需求阶段：修复bug很直接，只需更新图表或文档。
-验证阶段：如果QA工程师发现bug，需要更新文档、创建应用新版本并部署到QA环境。
-生产阶段：修复bug涉及更多步骤，还会带来很大压力，特别是影响公司收入时。
3. 发布新版本
以前在一家公司，生产部署步骤详细写在Word文档中，如“Copy