转」最佳方案：迭代式开发
前言
Fred Brooks 在 25 年前就曾写到：“不要指望一次成功，无论如何你都要这样。”
敏捷开发，小步快跑，持续迭代，不断改进，产品升级。
在用例需要之前，不要添加数据成员
在代码之前编写测试
过早的优化时万恶之源
不要过度强调代码的通用性
为了降低风险，应采用迭代方式递进开发。每次迭代完成都会发布一个可执行文件。
主题
为什么要以迭代方式开发
迭代式方法的优点
适应变更
降低风险
学习
提高复用性
提高质量
为什么要以迭代方式开发
初始设计就其关键需求而言很有可能是有缺陷的。到后期才发现设计缺陷会导致非常严重的费用超支，在某些情况下甚至会导致项目被取消。
任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。
在瀑布式生命周期中，只有到生命周期的后期才能确知周围是否存在风险。
在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。
迭代式方法的优点
迭代式方法一般要优于线性或瀑布式方法，其中的原因多种多样。
允许变更需求。需求总是会变化，这是事实。给项目带来麻烦的常常主要是需求变化和需求“蠕变”，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。正如 Fred Brooks 25 年前所写的：“不要指望一次成功，无论如何你都要这样”。
逐步集成元素- 集成并不只是简单的“一锤定音”。在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40% 的那段较长的、不确定的且棘手的时期，现在分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。
及早降低风险，因为风险一般只有在集成阶段才能发现或得到处理。展开初期迭代时，您会检查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。过去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。
有助于组织学习和提高。团队成员有机会在整个生命周期中边做边学，各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。如果是非迭代式开发，这些人在初期只能制定计划或培训技能，空等着开始他们的工作。培训需求或对进一步帮助的需求（有可能来自外部）也可在评估复审中尽早提出。
提高复用性，因为分部分设计或实施比起预先确定所有共性更容易确定公用部分。确定和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。
生成性能更强壮的产品，因为在多次迭代中您总是不断地纠正错误。在产品脱离先启阶段后的初期迭代中仍然可以发现缺陷。性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。
容许产品进行战术改变；例如同现有的同类产品竞争。可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。
迭代流程自身可在进行过程中得到改进和精炼。一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
有一个客户曾经说过：“使用瀑布式方法，一切看起来都很顺利，直到项目快结束时，有时甚至集成已过半才发现问题。此时所有的东西都变得支离破碎。而使用迭代式方法，问题的本来面目不可能隐藏得很久。”
项目经理常常抵制这种迭代式方法，视其为无穷无尽的“大肆删减”。在 Rational Unified Process 中, 这种交互式方法是很规范的；迭代在数量、持续时间和目标上都是按计划进行。参与者的任务和职责都已确定好。对进度进行的目标评测都将记录备查。从一次迭代到下一次迭代确实会存在返工现象，但返工也是严格按规定进行的。
适应变更
迭代便于您将变更需求考虑进来。需求总是会随着过程而变更。
需求变更一直是给项目制造难题的主要根源，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。Fred Brooks 在 25 年前就曾写到：“不要指望一次成功，无论如何你都要这样。”用户会随着项目进行改变他们的想法。人的本性就是如此。强迫用户去接受他们最初所设想的那种系统，这是完全错误的。他们改变想法是因为环境在发生变化，在此转变过程中，他们对环境和技术有了更多的了解，并且他们还看到了开发各环节之中所生成的中间产品。
迭代为管理层提供了一种用于对产品进行战术变更的方法，例如，同已有的产品进行竞争。
例如：可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。
在过程中允许技术变更。
如果某种技术变化了或成为标准，或是出现了新技术，那么项目可以加以利用。这种情况在平台变更或者底层基础设施变更时最为显而易见。
降低风险
多数风险在过去只能到集成阶段才被处理或发现，相对而言，迭代使您可以及早降低风险。
展开初期迭代时，您会检查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。过去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。
集成并不只是简单的“一锤定音” - 元素是被逐步集成的。
事实上，在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量 40% 的那段较长的、不确定的且棘手的时期，，现在分散到六至九个（很难精确计划的）集成部分中，每一部分要集成的元素都比过去少得多。
提高复用性
因为相对于必须预先确定复用性而言，分部分设计和实施时更容易确定公用部分，所以可以提高复用性。
确定和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。
要充分利用市售 (COTS) 产品这个便利条件。
通过数次迭代来选择和集成它们，并核实它们是否适合这个构架。
学习
开发人员有机会在整个生命周期中边做边学，各显其能。
测试员可早些开始测试，技术文档可早些开始编写，其他人也是如此，而不是空等很长时间，只能制定计划和训练技能。在早期迭代的评估复审中，可以发现是否需要进一步培训或外援。
迭代流程自身也可在进行过程中得到改进和精炼。
一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
提高质量
因为错误经过数次迭代已得到纠正，所以这样生成的构架将更强壮。
在早期迭代中，随着产品逐步成熟，可以及早地发现缺陷。可以及时发现并减少性能上的瓶颈，而不是在交付前夕才发现它们。
这样生成的是一个经过全面测试的产品。
关键功能因而有机会在数次迭代中经历多次测试。测试本身和所有测试软件将有时间来完善，而不只是依赖于项目几近尾声时的一次性测试。
如果本文对你有帮助，别忘记给我个3连 ，点赞，转发，评论，
咱们下期见。
转」最佳方案：迭代式开发相关推荐
- C++11（及现代C++风格）和快速迭代式开发
过去的一年我在微软亚洲研究院做输入法,我们的产品叫"英库拼音输入法" (下载Beta版),如果你用过"英库词典"(现已更名为必应词典),应该知道"英库 ...
- 瀑布式开发、迭代式开发、螺旋开发、敏捷开发四种开发模式的区别
1.瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型,瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析.设计.编码.集成.测试.维护的步骤顺序进行. 步骤成果作为衡量进度的 ...
- 迭代式开发使用方法总结
为什么我在这里主要讨论迭代式软件开发?本文在此抛开千篇一律的理论,拟就根据多年的实践,总结出一套比较务实.可操作性强的方法,以期望在有限的资源下确保软件质量得到较大保证.一家之见,纰漏之处还请大家多多 ...
- 一次迭代式开发的研究：一个迭代式项目计划
前面我们提到,当我们为软件分解工作项目,评估了工作量,确定了优先级.同时,整个项目的人员安排,也就是哪些人负责需求分析,哪些人负责设计,哪些人负责开发,哪些人负责测试,被确定下来,我们就可以制订我们的 ...
- 瀑布式开发和迭代式开发
瀑布式开发 我收到一个开发任务,然后按照从需求到设计.从设计到编码.从编码到测试.从测试到发布这个流程去做:每个步骤都力求做到最好:上一个流程的输出作为下一个流程的输入,比如产品出一个需求文档,这个文 ...
- Computer：项目管理之软件开发模式(瀑布式开发、快速原型开发、迭代式开发、螺旋式开发、敏捷式开发、DevOps开发)的简介、对比之详细攻略
Computer:项目管理之软件开发模式(瀑布式开发.快速原型开发.迭代式开发.螺旋式开发.敏捷式开发.DevOps开发)的简介.对比之详细攻略 导读:软件开发模型,用来描述和表示一个复杂的开发过程. ...
- 【迭代式开发】V1软件需求规格说明书——大数据开发实战项目（二）
文章目录 前言 1.引言 1.1目的 1.2项目背景 1.3缩写说明 1.4术语定义 1.5参考资料 1.6版本信息 2.任务概述 2.1系统定义 2.1.1项目背景 2.1.2项目要达到的目标 2. ...
- 【迭代式开发】v1架构设计文档——大数据开发实战项目（三）
文章目录 前言 一.背景 二.名词解释 三.设计目标 3.1 实现功能 3.2 性能指标 Ⅰ.数据精确度 Ⅱ.时间特性 Ⅲ.适应性 四.系统环境 4.1 相关软件和硬件 4.2 数据规模预估 五.系统 ...
- 开发模型的理解：瀑布模型/增量式/迭代/敏捷开发——笔记
首先,不管采用何种开发模型.软件开发都至少具有以下的周期,包括: 需求获取/分析(系统分析.软件分析) 设计 实现 测试 发布(运行) 维护 正在上传-重新上传取消 既然所有的开发模型都具有相同的开发 ...
最新文章
- @Conditional派生注解
- 深度优先搜索(dfs)，城堡问题
- JAVA常用基础知识点[继承,抽象,接口,静态,枚举,反射,泛型,多线程...]
- JDBC驱动程序的四种方式
- 前端学习（2763）：基本的数据绑定
- 《『若水新闻』客户端开发教程》——10.代码编写(2)
- 第八章 项目质量管理
- wincc变量数据归档(案例)
- 解析一个PHP木马，PHP文件上传安全检测组件
- 执行SOA ——SOA实践指南
- 南充中等计算机专业学校排名,南充计算机/电脑学校哪里好|南充外国语中等专业学校计算机应用|顺庆计算机学校怎么样|南充中专学校...
- gdal切火星偏移的瓦片
- Python3.6-Flask：制作一个语音对话问答机器人系统（网页版）
- UVA1335 Beijing Guards
- 关于指针为什么是4个字节大小
- c51语言中数据的存储类型,C51-数据存储类型
- 科普文章-另一个视角解读计算机编码(修订版)【一个吊丝的个人理解】
- 股市投资实战的核心问题
- 普中科技单片机HC6800-EM3 V3.0资料下载
- Android建立网络连接，利用JSON数据获取百度图片搜索结果及GSON的简单使用