《软件工作之美》材料地址： https://time.geekbang.org/column/article/84054
一 快速开发快速改
快速原型模型
快速原型模型，就是为了要解决客户的需求不明确和需求多变的问题…
原型模型因为能快速修改，所以能快速对用户的反馈和变更作出响应，，同时原型模型注重和客户的沟通，所以最终开发出来的软件能够真正反映用户的需求
但这种快速原型开发往往是以牺牲质量为代价的。
针对原型模型的这种快速、低质量的特点，通常有两种处理策略：抛弃策略和附加策略。
二 大瀑布拆小瀑布
瀑布模型的很多问题，根源都是周期太长。
拆小比较典型的主要是：增量模型 和 迭代模型。
1，增量模型——按模块分批次交付
适用于：需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付。
2，迭代模型——每次迭代都有一个可用的版本
迭代模型每次只设计和实现产品的一部分，然后逐步完成更多功能。每次设计和实现一个阶段叫做一个迭代。
每个迭代过程如下
增量模型是按照功能模块来拆分；而迭代模型则是按照时间来拆分，看单位时间内能完成多少功能。
迭代模型最难的部分，在于规划每次迭代的内容和要达到的目标。
迭代模型由于在初始迭代时，只清楚当前迭代的需求，而不知道后续需求，设计可能会考虑不周全。这样的话，迭代一多，系统会有不少冗余，一段时间后就需要对系统进行重构。
三 不同场景
场景一：外包项目，需要阶段验收
场景二：项目风险高，随时可能会中断
场景三：山寨一款软件产品，希望能快速上线发布
增量开发
场景四：客户都没想清楚想要什么，但是个大单子
统一软件开发过程（Rational Unified Process，RUP），适用于复杂和需求不明确的软件系统。
场景五：我的产品已经上线，但是需要持续更新维护
迭代模型是比较合适的。固定时间周期，在固定的周期内选择适合的需求开发任务和 Bug 修复任务去完成，按时发布。
* 严格来说，敏捷开发并不算是一种开发模型，更像是框架或指南。
四 总结
一个以确认需求为主要目的的项目，就可以不用花太多时间在代码质量上面，低成本、高效做出来才是最重要的；
一个高风险的项目，则可以采用螺旋模型，出现问题及时止损；
一个很长时间加班加点，却一直没法上线，导致士气低落的项目，可以改成增量模型，先上线一个小模块，让大家看到成绩提升士气，然后再迭代，逐步上线其他模块。
五 我的留言
对于增量或迭代开发，大型企业需要考虑这些不适应点：
(1)大型官僚机构的办事程序和敏捷过程不匹配
比如开发想敏捷，但财务采购等都不敏捷。代码敏捷了，基础环境不敏捷等
(2)伴随增量的添加，系统结构会逐渐退化。
特别是对于大型系统，其系统结构的建设，就需要提前制定计划，系统架构要尽量避免或减少修改次数，但在需求不是很清晰的情况下，系统架构肯定会随着需求的迭代而迭代。为了减少系统架构修改带来的大范围的系统变更，应该尽量采用稳定的可伸缩的可插拔的分层的充分解耦的系统架构。
(3)与开发方的合同问题，需要新形式的合同
旧形式的合同是固定合同，做多少事拿多少钱都在合同时谈好了，不适应工作量的变更。
老师回复: 的，要敏捷起来，组织架构、流程制度也必须要跟着调整，光喊口 做样子是没用的。
补充:
有关五（2）中架构问题,软件架构的挑战和设计原则
参考https://time.geekbang.org/column/article/7071
1,挑战：“不确定性”
优秀程序员和架构师之间还有一个明显的鸿沟需要跨越，这个鸿沟就是“不确定性”。
2,架构三原则 ：合适原则、简单原则、演化原则
（1）合适原则
合适原则宣言：“合适优于业界领先”。
（2）简单原则
简单原则宣言：“简单优于复杂”。
1. 结构的复杂性
组件越多，就越有可能其中某个组件出现故障
某个组件改动，会影响关联的所有组件
定位一个复杂系统中的问题总是比简单系统更加困难
2. 逻辑的复杂性
结论：《UNIX 编程艺术》总结的 KISS（Keep It Simple, Stupid!）原则适应于架构设计。
（3）演化原则
演化原则宣言：“演化优于一步到位”。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！