敏捷开发快速入门（二）：传统开发VS敏捷开发

概述

• 瀑布式开发的基本流程是 需求 → 设计 → 开发 → 测试 ， 是一个更倾向于严格控制的管理模式 。 要求有明确的需求，大家按照需求一步步做好规划，每一阶段工作的完成是下一阶段工作开始的前提，每一阶段都要进行严格的评审，保证各阶段的工作做得足够好时才允许进入下一阶段。这种模式一般适用于需求比较明确、to B端的项目。
• 敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把 用户（客户 ）最关注的软件原型做出来，交付或上线，在实际场景中去 快速 修改弥补需求中的不足，再次发布版本。通过一些敏捷实践方式，细化Story，提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确、创新性或者需要抢占市场的项目。

传统开发模式面临的问题

问题	解释
交互周期长	3~6个月或是更长
进度延期久	计划往往追赶不上变化
按时低发布	技术债务多、bug率高
团队土气弱	长期的工作，看不到成果
软件质量差	赶工与加班，身心疲惫

敏捷开发模式优势

优势	诠释
快速交互	1~4周的迭代周期
品质优先	持续集成 、迭代全量
风险降低	短周期持续问题反馈，及时修正
适应变化	小步快走、产品需求方向调整
持续改善	多个检查点、迭代总结回顾
满意度高	一直与客户和产品沟通反馈修正

敏捷开发 - 快速交互，及时反馈

从高优先级需求开始迭代，尽早开始

• 尽早交付, 把可用的软件展示给客户
• 及时反馈，这是一个验证和试错的过程，及时的让客户矫正我们对产品的理解

敏捷开发中的反馈点

• 每日站会（Daliy Meeting）
• 迭代评审会（Sprint Review Meeting）
• 迭代回顾会（Sprint Retrospective Meeting）
• 及时反馈，这是一个验证和试错的过程，及时的让客户矫正我们对产品的理解

敏捷开发 - 价值驱动，优化排序

敏捷开发思维模式

• 敏捷开发的一个核心思维模式的转换便是： 从瀑布式开发所代表的“Fix Scope, Flex time”（固定范围，弹性时间）转向“Fix time, Flex Scope”——固定时间，弹性范围。 在市场变化和技术变化的背景之下，既然市场需求和产品定义所代表的“范围”无法实现固化，因而无法确定应该投入多少资源来完成，那不妨固定好已有资源的，以资源为约束，实现“范围”的最大化实现。因此从“计划驱动”转向为“价值驱动”。