瀑布模型
瀑布模型是典型的软/硬件开发模型，包括需求、设计、编码、测试、运行与维护几个阶段。产品流经“正向”开发是开发的基本步骤路径，“反向”的步骤流表示对前一个可提交产品的重复变更，由于所有开发活动的非确定性，因此是否需要重复变更，这仅在下一个阶段或更后的阶段才能认识到。这种“返工”不仅在以前阶段的某一地方需要，而且对当前正在进行的工作也同样需要。
主要特点：
- 每一阶段都以验证/确认话动作为结束，其目的是尽可能多地消除本阶段产品中存在的问题
- 在随后阶段里，尽可能对前面阶段的产品进行迭代
优点： - 容易理解、管理成本低。
瀑布模型的主要成果是通过文档从一个阶段传递到下一个阶段，各阶段间原则上不连续也不交迭，因此可以预先制定计划，来降低计划管理的成本 - 它提供有形的软件成果
文档产生并提供了贯穿生命期的进展过程的充分说明，允许基线和配置，早期接受控制。
软件配置项：
软件工程过程各项话动的产物(程序文档、数据)经评审或市批后都称为软件配置项（SCD），第一次交付的软件配置项构成基线(Base Line)配置项。软件开发中的主要配置项有：操作概念、需求规格说明、设计文档、源代码、目标代码、测试计划、测试用例、测试配置和测试结果、维护和开发工具、用户手册、维护手册、接口控制文档...
为了控制这些条目并避免过分制约早期开发活动，需要在合适的点上建立基线。
基线：
基线是经过正式评审和认可的组软件配置项(文档或其他软件产品)，此后它们将作为下一步开发工作的基础，只有通过正式的变更控制流程才能被更改。
基线的作用是把各阶段的工作划分得更加明确使本来连续的工作在这些点上断开，以便于验证和确认开发成果。因此，基线可为软件制品提供三种能力: - 再生能力：即能够“返回”到原先的某-时间重新制造软件系统的特定版本或再现曾经存在的开发环境。
- 可追踪能力：即将需求、项目计划、测试用例以及各种软件工件关联在一起。为了实现可追踪能力，不仅需要对系统中的各种工件进行基线化，而且要对项目管理工件进行基线化。
- 报告能力：即能够查询任一-基线中的内容以及对比不同基线的内容。基线的比较结果可以支持排错以及辅助生成新版发布说明。
这些能力助团队修复已发布产品中的缺陷，为规范开发流程，通过审核提供便利条件，最重要的是保设计实现需求、代码实现设计，并且使用正确版本的代码构建可执行的应用程序。
缺点： - 客户必须能够完整、正确和清晰地表达其需要。但在系统开发中经常发现用户与开发人员沟通存在巨大差异、用户提出含糊需求又被开发人员随意解释，以及用户需求会随着时间推移不断变化等问题
- 可能要花费更多的时间来建立一些用处不大的文档
- 在开始的两个或三个阶段中，很难评估真正的进度状态
- 在一个项目的早期阶段，过分强调了基线和里程碑处的文档
- 当接近项目结束时，出现了大量的集成和测试工作
- 直到项目结束之前，都不能演示系统的能力
适用范围：
- 一个项目有稳定的产品定义和很容易被理解的技术解决方案时
- 对一个定义得很好的版本进行维护，或移植到一个新的平台上时
- 开发一个容易理解但很复杂的项目时
- 质量需求高于成本需求和进度需求时
理念：
“用最普通的人，做不普通的事”。对于一个大系统，为了达到预期目标，需要做好周密的计划，在阶段、活动和任务的关键点加强评审和辅助性的管理，通过撰写大量的文档来尽量避免交流的歧义性和不确定性。为了保证最终提交物的高质量，在支持过程与辅助工作上花费大量资源，使整个过程显得过于笨重，因此被称为“重量级过程”。
敏捷开发【需求变更和迭代升级】
敏捷过程强调短期交付、客户的紧密参与，强调适应性面不是可预见性，强调为当前的需要而不考虑将来的简化设计。只将最必要的内容文档化，因此也被称为“轻量级过程”。敏捷不是方法论，也不是开发软件的具体方法，更不是开发框架或过程，而是一套价值观和原则。
核心理念：
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
a) 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
b) 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
c) 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
d) 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
e) 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
f) 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
g) 可工作的软件是进度的首要度量标准。
h) 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
i) 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
j) 以简洁为本，它是极力减少不必要工作量的艺术。
k) 最好的架构、需求和设计出自自组织团队。
l) 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
srcum
Scrum作为敏捷的落地方法之一，用不断迭代的框架方法来管理复杂产品的开发，成为当前最火的敏捷管理方法。项目成员会以1-2周的迭代周期（sprint）不断产出新版本软件，而在每次迭代完成后，项目成员和利益方再次碰头确认下次迭代的方向和目标。
Scrum有一套其独特且固定管理方式，从角色、工件和不同形式的会议三个维度出发，来保证执行过程更高效。例如在每次sprint开始前会确立整个过程：迭代规划、每日站会、迭代演示和回顾。并在sprint期间用可视化工件确认进度和收集客户反馈。
Scrum的三种角色：
产品经理：
负责规划产品，并将研发这种产品的愿景传达给团队。产品负责人需要整理产品需求清单（backlog），关注市场需求的变化来调整产品需求优先级，确认下次迭代需要交付的功能。与团队、客户、利益相关方持续保持沟通和反馈，保证每位项目成员了解项目意义和愿景。
Scrum Master：
Scrum Master帮助团队尽其所能地完成工作。例如：组织会议，处理遇到的障碍和挑战，与产品经理合作，在下次迭代前准备好backlog，确保团队遵循Scrum流程。Scrum Master对团队成员在做的事情没有权力，但对这一过程拥有权力——Scrum Master不能告诉某人该做什么，但可以提出新的sprint。
Scrum团队：
Scrum团队由五到七名成员组成。与传统的开发团队不同，成员们没有固定角色，比如会由测试人员来做研发。团队成员间相互帮助、共享成果，旨在完成全部的工作。Scrum团队需要做好整体规划，并为每次迭代划分合适的工作量。
Scrum会议：
整理产品需求清单（Product backlog）：产品经理和Scrum团队进行碰头，基于用户故事和需求反馈来确定产品需求的优先级。Backlog并不是代办事项列表，而是产品的所有功能列表。然后研发团队在每次迭代阶段去完成清单中一部分，最终完成整个项目。
确定迭代规划（Sprint planning）：在每次迭代开始之前，产品经理会在迭代规划会议上和团队讨论优先级高的功能需求。然后确认有哪些功能将会在下次迭代时完成，并将这些功能从产品需求清单中移至迭代任务清单（Sprint backlog）中。
梳理产品需求清单：结束迭代后，产品经理需要和团队碰头来确认下次迭代的任务清单。团队可以利用这个阶段剔除相关度低的用户故事，提出新的用户故事，再重新评估故事的优先级，或将用户故事分成更小的任务。这次梳理会议的目的是确保产品需求清单里的内容足够详细，并且和项目目标保持一致。
每日站会：每天花15分钟左右开一次站会，期间团队每个成员都会讨论当前的进度和出现的问题。这个过程有助于团队保持日常联系。
迭代演示：在每次迭代结束时，团队需要向产品经理报告已完成的工作，并做产品现场演示。迭代回顾：在每次迭代结束后，团队需要开例会总结使用Scrum进行研发带来的影响，并探讨在下次迭代中是否有能做的更好的地方。
Scrum常用工件：
- Scrum任务板：我们可以用Scrum任务板使Sprint任务清单形象化。任务板可以用不同的形式来呈现，比较传统的做法有索引卡，便利贴或白板。Scrum任务板通常分为三列：待办事项，正在进行中和已完成。团队需要在整个Sprint过程中不断更新。例如，如果某人想出新任务，他会写一张新卡并将其加入到合适的位置。
- 用户故事：用户故事是从客户角度对软件提出功能的描述。它包括用户类型细分，他们想要什么以及他们为什么需要它。它们遵循相似的结构：作为<用户类型>，我希望<执行某项任务>以便我能<实现某个目标>。团队根据这些用户故事进行研发来满足用户需求。
- 燃尽图（Burndown chart）：竖轴表示迭代任务清单，横轴表示剩余时间。剩下工作可以通过不同的点位或其他指标来表示。当事情不按照计划进行并且影响后续决策时，burndown chart可以在这时给团队提个醒。
看板
可视化流程框架
这种可视化框架能够清晰地向项目成员展示整个项目进度（要做什么／什么时候做／做多少）。我们会建议你当需要对系统进行小幅度改动的时候，可以采用看板方法来轻量化解决这个问题，因为看板本身并不需要额外去制定流程，我们可以在任何工作流上加看板。限制工作进度（WIP）
WIP将确定看板图上每列的最大、最小工作量。通过对WIP进行限制，我们能够根据自己的意愿来调整速度、灵活度，提升解决高优先级需求的效率。在这种情况下，开发中工作（WIP）代替库存，只有看板上空了以后才能加入新工作。软件开发项目的分列可能包括代办、准备阶段、研发、测试、审批和已完成。管理和改进流程
我们需要对看板图上的流程进行定期监控和总结改进，从而得到流畅高效的工作流，快速创造价值。制定明确的执行策略
为了防止在进行看板时发生协作变化，我们需要有明确的执行策略，每位成员都需要了解如何完成任务和“完成”的真正含义。持续改进
看板方法鼓励持续性的小幅度改进。一旦看板系统到位，该团队将能够识别、理解问题并提出改进建议。团队通过回顾总结工作流和测量周期时间来评估其有效性，提高产出质量。
参考资料说明：软件工程基础课程材料
转载于:https://www.jianshu.com/p/f201c18907fe