软件开发模型系列四迭代开发 —— 先让东西跑起来再慢慢变好前面三种模型瀑布、V 模型、螺旋有一个共同假设项目有明确的起点和终点。但互联网时代来了——软件上线不是结束而是开始。迭代开发改变了这个基本假设。1、什么是迭代开发迭代开发Iterative Development的核心思想很简单不要试图一次做对所有事情。先做一个能跑的简陋版本然后通过一轮又一轮的反馈和改进逐步逼近最终目标。基于上一轮反馈基于上一轮反馈第 3 轮 · V2.0需求分析设计编码测试交付/反馈第 2 轮 · V1.1需求分析设计编码测试交付/反馈第 1 轮 · V1.0需求分析设计编码测试交付/反馈和瀑布模式的关键区别瀑布一次交付整个系统中间没有用户反馈 迭代每次交付一个可运行的版本不断根据反馈调整方向2、迭代开发的历史比你想象的早得多很多人以为迭代开发是 2000 年代敏捷运动之后才出现的新东西。但事实上迭代开发的实践比瀑布模型更早。时间事件1930sWalter Shewhart贝尔实验室提出统计过程控制和持续改进循环的概念后被 Deming 发展为 PDCA/PDSA 循环1950sW. Edwards Deming 将 Shewhart 的循环推广到日本工业界深刻影响了丰田生产系统1960sNASA 的水星计划Project Mercury使用迭代开发1971IBM 的 Harlan Mills 提出软件应该通过增量开发来成长1977-80IBM 团队用 17 轮迭代每轮约 8 周开发了航天飞机的主飞行控制软件1986 / 1995Frederick Brooks 在《没有银弹》1986中主张软件应增量式地生长grow, don’t build“1995 年在《人月神话》20 周年纪念版中更直接宣称瀑布模型是错的”1990sRational Unified ProcessRUP将迭代开发系统化、商业化历史的有趣之处迭代开发不是发明出来替代瀑布的它一直就存在。瀑布模型在 1970-1990 年代的大规模流行反而是一段历史上的弯路——很大程度上要归因于美国国防部 DOD-STD-2167 标准对 Royce 论文的误读。3、迭代 vs 增量一个重要区分这两个词经常被混用包括在很多教材中但它们指向的是两个不同的维度维度迭代Iterative增量Incremental关注点时间维度重复同一个过程产品维度叠加新的功能工作方式同一个功能反复打磨、改进每次增加一个完整的新功能块比喻画家画一幅肖像先画轮廓再逐步细化盖房子一间一间盖每间盖好就是成品核心问题“我们做对了吗”学习与修正“接下来交付什么”功能分解在实际项目中两者往往是结合的微信的发展 迭代的维度 → 聊天功能从文字→语音→视频不断打磨 增量的维度 → 先有聊天再加朋友圈再加支付再加小程序现代 Scrum 框架详见本系列第六篇实际上同时包含了这两个维度每个 Sprint 是一个迭代重复相同的仪式和周期而每个 Sprint 结束时交付的是一个增量可用的产品功能切片。4、迭代开发的核心优势4.1、风险前置而不是后置瀑布 迭代 需求 设计 编码 测试 V1: 需求→设计→编码→测试→反馈 ↓ 最大的风险在最后 V2: 需求→设计→编码→测试→反馈 才发现 ↓ V3: ... 最大的技术风险和需求理解风险在 V1 就被发现了4.2、用户可以尽早看到产品这带来的好处远超让用户开心用户可以在看到实际产品后给出更准确的反馈而不是对着需求文档凭空想象错误的产品方向在投入还不多的时候就会被纠正用户可以边用边学需求质量逐轮提高4.3、团队可以在过程中学习第一轮大家还在磨合代码质量一般 第二轮对业务更理解了架构可以调整 第三轮找到了最佳实践效率大幅提升瀑布模型的一次性开发剥夺了团队这种学习机会。5、迭代开发的挑战5.1、架构容易退化如果每一轮只关注这轮要交付的功能很容易出现第 1 轮快速上线架构随意 → 能跑第 2 轮加新功能打补丁 → 还能跑第 3 轮再加功能更多补丁 → 勉强能跑第 4 轮架构崩溃需要重写 → 跑不动了这就是技术债的积累。迭代开发需要比瀑布模型更强的架构自律——每次迭代都花时间重构和还技术债。5.2、对用户的时间和参与度要求更高迭代模式需要用户持续参与每个版本的反馈。如果用户组织太忙了下一版再看反馈循环就会断裂迭代开发的核心优势就丧失了。6、迭代开发 vs 瀑布模型一个具体对比假设开发一个电商 APP预计要 6 个月瀑布模式 月1-2需求分析产出 200 页 PRD 月3-4系统设计 月5编码 月6测试 上线 → 用户在第 6 个月才第一次看到 APP 迭代模式 月1-2第1轮注册登录 商品浏览→ 用户试用 月3-4第2轮搜索 购物车 下单→ 用户试用 月5第3轮支付 订单管理→ 用户试用 月6第4轮评价 推荐 优化→ 正式上线 → 用户在第一个月就能看到可运行的 APP如果用户在第 2 轮反馈搜索体验太差了我们需要全文搜索而不是简单的关键词匹配——在迭代模式下第 3 轮就可以调整。在瀑布模式下等你听到这个反馈所有代码都写完了。7、本篇要点速记迭代开发 分轮交付 持续反馈 逐步完善 历史比瀑布模型更久远NASA 1960s 就在用。 关键区分迭代反复打磨vs 增量逐块叠加 优点 → 风险前置、用户早参与、团队可学习 局限 → 架构退化、需要用户持续参与 一句话不要一次把东西做好要先把东西做出来再把它做好。8、迭代开发模型 vs 螺旋模型迭代模型关注的是产品如何成长螺旋模型关注的是风险如何降低。Iterative Development 的第一性原理没有人第一次就能把产品做好。产品质量不断逼近目标。迭代开发 Continuous Improvement持续改进螺旋模型第一性原理螺旋模型认为第一性原理真正的问题不是怎么开发而是我根本不知道这个项目有没有坑。每绕一圈风险越来越少。不是功能越来越多。而是未知越来越少。关键词Risk Reduction风险降低螺旋包含了迭代螺旋把风险分析放到了每一次迭代最前面。把最大的坑先踩出来。软件开发 │ ┌───────────┴───────────┐ │ │ Product Growth Risk Control 产品成长 风险控制 │ │ ▼ ▼ Iterative Development Spiral Model螺旋模型 风险驱动的迭代开发Risk-Driven Iterative Development两者看起来都在一轮一轮地做事但驱动力完全不同迭代开发以产品演进为中心螺旋模型以风险演进为中心。也正因为如此可以把螺旋模型理解为一种以风险管理为核心的迭代开发方法——它保留了迭代的形式但重新定义了每一轮迭代最优先要解决的问题。上一篇螺旋模型下一篇敏捷开发 —— 从按计划行事到拥抱变化
软件开发模型系列四迭代开发 —— 先让东西跑起来再慢慢变好前面三种模型瀑布、V 模型、螺旋有一个共同假设项目有明确的起点和终点。但互联网时代来了——软件上线不是结束而是开始。迭代开发改变了这个基本假设。1、什么是迭代开发迭代开发Iterative Development的核心思想很简单不要试图一次做对所有事情。先做一个能跑的简陋版本然后通过一轮又一轮的反馈和改进逐步逼近最终目标。基于上一轮反馈基于上一轮反馈第 3 轮 · V2.0需求分析设计编码测试交付/反馈第 2 轮 · V1.1需求分析设计编码测试交付/反馈第 1 轮 · V1.0需求分析设计编码测试交付/反馈和瀑布模式的关键区别瀑布一次交付整个系统中间没有用户反馈 迭代每次交付一个可运行的版本不断根据反馈调整方向2、迭代开发的历史比你想象的早得多很多人以为迭代开发是 2000 年代敏捷运动之后才出现的新东西。但事实上迭代开发的实践比瀑布模型更早。时间事件1930sWalter Shewhart贝尔实验室提出统计过程控制和持续改进循环的概念后被 Deming 发展为 PDCA/PDSA 循环1950sW. Edwards Deming 将 Shewhart 的循环推广到日本工业界深刻影响了丰田生产系统1960sNASA 的水星计划Project Mercury使用迭代开发1971IBM 的 Harlan Mills 提出软件应该通过增量开发来成长1977-80IBM 团队用 17 轮迭代每轮约 8 周开发了航天飞机的主飞行控制软件1986 / 1995Frederick Brooks 在《没有银弹》1986中主张软件应增量式地生长grow, don’t build“1995 年在《人月神话》20 周年纪念版中更直接宣称瀑布模型是错的”1990sRational Unified ProcessRUP将迭代开发系统化、商业化历史的有趣之处迭代开发不是发明出来替代瀑布的它一直就存在。瀑布模型在 1970-1990 年代的大规模流行反而是一段历史上的弯路——很大程度上要归因于美国国防部 DOD-STD-2167 标准对 Royce 论文的误读。3、迭代 vs 增量一个重要区分这两个词经常被混用包括在很多教材中但它们指向的是两个不同的维度维度迭代Iterative增量Incremental关注点时间维度重复同一个过程产品维度叠加新的功能工作方式同一个功能反复打磨、改进每次增加一个完整的新功能块比喻画家画一幅肖像先画轮廓再逐步细化盖房子一间一间盖每间盖好就是成品核心问题“我们做对了吗”学习与修正“接下来交付什么”功能分解在实际项目中两者往往是结合的微信的发展 迭代的维度 → 聊天功能从文字→语音→视频不断打磨 增量的维度 → 先有聊天再加朋友圈再加支付再加小程序现代 Scrum 框架详见本系列第六篇实际上同时包含了这两个维度每个 Sprint 是一个迭代重复相同的仪式和周期而每个 Sprint 结束时交付的是一个增量可用的产品功能切片。4、迭代开发的核心优势4.1、风险前置而不是后置瀑布 迭代 需求 设计 编码 测试 V1: 需求→设计→编码→测试→反馈 ↓ 最大的风险在最后 V2: 需求→设计→编码→测试→反馈 才发现 ↓ V3: ... 最大的技术风险和需求理解风险在 V1 就被发现了4.2、用户可以尽早看到产品这带来的好处远超让用户开心用户可以在看到实际产品后给出更准确的反馈而不是对着需求文档凭空想象错误的产品方向在投入还不多的时候就会被纠正用户可以边用边学需求质量逐轮提高4.3、团队可以在过程中学习第一轮大家还在磨合代码质量一般 第二轮对业务更理解了架构可以调整 第三轮找到了最佳实践效率大幅提升瀑布模型的一次性开发剥夺了团队这种学习机会。5、迭代开发的挑战5.1、架构容易退化如果每一轮只关注这轮要交付的功能很容易出现第 1 轮快速上线架构随意 → 能跑第 2 轮加新功能打补丁 → 还能跑第 3 轮再加功能更多补丁 → 勉强能跑第 4 轮架构崩溃需要重写 → 跑不动了这就是技术债的积累。迭代开发需要比瀑布模型更强的架构自律——每次迭代都花时间重构和还技术债。5.2、对用户的时间和参与度要求更高迭代模式需要用户持续参与每个版本的反馈。如果用户组织太忙了下一版再看反馈循环就会断裂迭代开发的核心优势就丧失了。6、迭代开发 vs 瀑布模型一个具体对比假设开发一个电商 APP预计要 6 个月瀑布模式 月1-2需求分析产出 200 页 PRD 月3-4系统设计 月5编码 月6测试 上线 → 用户在第 6 个月才第一次看到 APP 迭代模式 月1-2第1轮注册登录 商品浏览→ 用户试用 月3-4第2轮搜索 购物车 下单→ 用户试用 月5第3轮支付 订单管理→ 用户试用 月6第4轮评价 推荐 优化→ 正式上线 → 用户在第一个月就能看到可运行的 APP如果用户在第 2 轮反馈搜索体验太差了我们需要全文搜索而不是简单的关键词匹配——在迭代模式下第 3 轮就可以调整。在瀑布模式下等你听到这个反馈所有代码都写完了。7、本篇要点速记迭代开发 分轮交付 持续反馈 逐步完善 历史比瀑布模型更久远NASA 1960s 就在用。 关键区分迭代反复打磨vs 增量逐块叠加 优点 → 风险前置、用户早参与、团队可学习 局限 → 架构退化、需要用户持续参与 一句话不要一次把东西做好要先把东西做出来再把它做好。8、迭代开发模型 vs 螺旋模型迭代模型关注的是产品如何成长螺旋模型关注的是风险如何降低。Iterative Development 的第一性原理没有人第一次就能把产品做好。产品质量不断逼近目标。迭代开发 Continuous Improvement持续改进螺旋模型第一性原理螺旋模型认为第一性原理真正的问题不是怎么开发而是我根本不知道这个项目有没有坑。每绕一圈风险越来越少。不是功能越来越多。而是未知越来越少。关键词Risk Reduction风险降低螺旋包含了迭代螺旋把风险分析放到了每一次迭代最前面。把最大的坑先踩出来。软件开发 │ ┌───────────┴───────────┐ │ │ Product Growth Risk Control 产品成长 风险控制 │ │ ▼ ▼ Iterative Development Spiral Model螺旋模型 风险驱动的迭代开发Risk-Driven Iterative Development两者看起来都在一轮一轮地做事但驱动力完全不同迭代开发以产品演进为中心螺旋模型以风险演进为中心。也正因为如此可以把螺旋模型理解为一种以风险管理为核心的迭代开发方法——它保留了迭代的形式但重新定义了每一轮迭代最优先要解决的问题。上一篇螺旋模型下一篇敏捷开发 —— 从按计划行事到拥抱变化
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
