敏捷开发到底是什么_敏捷开发的基本原则

为什么要敏捷？

在传统的互联网开发模块中，我们通常都是等到了一份完整的需求文档，需求原型，在需求明确清晰的情况下，我们在进行需求评审；然后进行API文档的设计，在进入没有任何需求变化、打扰的情况下进行编码工作，然后部署测试上线，通过；
这估计是开发人员最想看到的一种开发模块。

但是在实际的情况中，需求的多样性变化，客户的反馈，市场环境多元性的变化，让 传统的“瀑布式开发”、“迭代型”模式已经不在适合正常的运营模式。

例如，客户每次提出的东西一定是他们想要的？在需求沟通的过程中传递中，能保证信息的一致性吗？我们并不是客户本人，每个人的想法都是不一样的，大多数人是无法一次性真正满足客户的需求，因此我们需要一次次不断的测试，迅速推向市场，通过市场的验证与反馈，避免少走弯路。

什么是敏捷开发

“敏捷开发”是指 什么？？？ 我也问过自己，也不知道如何回答。针对这个问题，开始了下面的文章信息整理，然后找出自己的答案。

“敏捷” 通过文字简单理解为，快速，行动便捷。

根据百度百科的解释：“敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发”；

PMBOK 第六版 中描述 敏捷开发 指的是 适应型生命周期——属于敏捷型、迭代型或增量型。详细范围在迭代开始之前就得到了定义和批准。适应型生命周期也称为敏捷或变更驱动型生命周期。

根据百度文库与PMKBOK 中也描述到，敏捷开发 是以需求范围为核心，采用迭代模块的形式进行项目的开发。再次之前，会有1个明确的项目范围。 但是这种概念还是非常的模糊，无法定义敏捷的具体内容。
通过简单的描述得知 “敏捷开发” 一种流程，方法，框架或者是套路，按照一定的模块与方法来执行。
了解记得，目前国内适用于最多的 属于 Scrum （https://www.scrum.org/）

如何理解敏捷

在理解敏捷开模式开发之前，我们要了解常规的项目开发中会使用 “瀑布型生命周期”、“迭代型生命周期”、“增量型生命周期”的开发模式；
常见的开发 “瀑布型”与“迭代型” 居多，下面通过简单的几个生活案例来描述 这几个 开发生命周期的 区别有什么：

• 瀑布型（结束–开始的一种依赖模式，在明细明确的情况下，按照步骤一步一步的往下执行，将问题简单化）
• 敏捷型（拥抱变化，以客户为中心，不断的满足客户的需求， 保持一定的周期（冲刺周期）不变的情况更新）
• 迭代型 （顺序渐进，在需求不明确的情况下，完成整体的估算，顺着时间的变成对产品的完成，需求就更加明确）

敏捷和迭代是一个类型，只是简单的包含和被包含的关系吗？emmm，需要邀请专家大佬来解析一下，@敏捷专家

场景一：

餐厅点餐， 7名客户 去餐厅点餐，点餐数量12菜， 餐厅服务费将客户已经点好的菜单 提送给厨房，厨房根据产品的耗时长久来进行分工制作，那么在常见的餐厅上菜模式就会有种模式：

1. 等所有菜 全部完成，在一次性的全部 上菜给客户
2. 隔几分钟上菜一道菜

分析：

模式1： 大家可以理解成一种瀑布型，在客户点菜明确的情况下，厨房按步骤一步一步的往下执行任务，最后一次性将任务成功交付给客户，让客户的需求一次性满足

模式2： 以客户为中心，同时衡量每个菜品的耗时价值（做得越快，说明开发成本低，在这种价值下，快速交付给客户是价值最高的，比如说 凉菜，几乎不消耗厨师成本就可以交付），分阶段性的满足客户需求

在这个模块下我们继续分析得知 如果以客户的角度来说，这种情况下 模式1 肯定是不满足 实际场景需求的，因为耗时太长，客户的期望值会随着时间的边长会逐渐降低， 同时 如果 客户临时调整菜单，会将 模式1的时间比逾期耗时更久。

反过来在描述模式2，在模式2的情况下，保持一定的产品提交给客户，让客户一直保持期望，而且 如果客户在调整菜单时，也不会影响 后续未做产品的产品，因为实际并未开完。

可能部分场景不是很全部，但是相表达的通过简单的案例来区分出来，敏捷和瀑布的区别是什么， 瀑布是在一定模块下，按步骤一步一步执行，如果步骤又变化，会导致后续的流程也因此变化而变化，而敏捷不一样，敏捷是拥抱变化，以客户为中心的模式

场景二：依旧还是客户餐厅点菜，但是只有2人去餐厅点菜，点菜数量3道，但是店内客户很多，后厨工作已经在滞后中。

场景中描述了几个关键字信息： 1：当前客户需求不复制， 2： 对面客户多，研发工作量大
针对这种情况，那么后厨要采用什么样的方式才能进行快速的分工操作来完成任务呢？ 反过来 我们来看一下 “瀑布型”“敏捷性”的这种模式下，那一种更适合呢？

1：如果使用瀑布型，那么我们就一次性收集所有的需求 再次一次性按步骤一次完成，然后将产品一次性的交付给客户
2：如果使用敏捷性，那么就收到任务，将此此任务列入待办列表，然后根据客户点菜的顺序 按实际排序一步一步完成

但是 实际场景中，如何我们使用敏捷性，那可能会出现一种， 客户A 点了3个菜，第一盘才上了之后，大家吃完了，然后第二盘菜和第三盘菜，可能会等很久，才会完成，那么这个时候，客户的期望值会和 《场景一》 中的保持一致吗？
如果使用瀑布型，将客户的产品一次性的交付，一次性满足客户的期望，是否会比 “敏捷型”更好？

感觉场景二描述的并不是特别好，存在许多BUG，因为场景一的情况也还会在场景二中出现， 但是我们需要考虑是，敏捷型一定是最好的吗？ 并不是，我们需要因材施教， 在产品不复杂，体量不高的情况下， 瀑布型或者迭代型 是不是一种更好的方式呢？

场景三： 我们需要 春节假期 坐车回老家（大于100公里）

依旧，我们先分析需求，
1： 目标非常明确， 回家，
2： 执行的方式： 回家的方式有很多，（1：做的士 2：坐火车 3：坐班车）
3： 规划路线，规划行程。

进行成本价值分析之后，得知，做火车肯定是最方便，相对省钱的，但是过程中是不复杂的。 做的士成本肯定是最高的，但是过程中是最简单的。坐班车虽然是最省钱，但是过程非常复杂，不稳定因素大，体验度也不佳。

常规来说，最省钱的肯定是我们的第一选择，此时就需要进行风险管理，对风险进行假设规划风险，指定应急方案

风险1：抢火车票， 春节假期的 火车站 是很难抢的，因此 最适合自己的时间段的车票 无疑是 高风险，高概率，因此 次风险最高。

应对计划：因此 我们需要制定风险应对措施，我们需要订当天其他时间段 自己能力收能接受的其他范围车次，让能上火车的概率 提升， 但是这种风险是需要投入应对成本，但是这种成本不高。（抢票时，提前退票手续费很低）

风险2：赶火车，票虽然到手，肯定我们需要在指定的时间内（里程碑计划），到达目的地，因为火车不会等我们（下个里程碑的开始时间），如果没有提前到，会导致整体的风险，导致目标无法完成的概率无限增加。

应对计划：我们需要在在某个指定的时间到到底火车站，无疑而言做地铁是最好的方式，地铁的故障率几乎未0%，准点率几乎为100%，因此去火车站的路线，肯定是以地铁为主，其他不需要考虑其他问题。 那么这个的风险在哪里呢？ 肯定是时间！！！
我们需要估量时间， 地铁的耗时是已知的，动车的发车时间是已知的，下地铁到候车厅的时间估算也是已知的，起床出门的耗时时间也是可以估算，那么根据这些已知量，我们需要估算起床的时间， 因此这一题的风险点是 “你起床的闹铃是否设置”

风险3：火车晚点，概率低，风险低，因此不过过多描述，因为那怕晚点了，最终车还是会到达

…方式2、方式3 的风险风险也是比较简单的， 都是低概率，低风险，因为最终不会影响目标执行情况，只是时间不会很长。可能有人会说，坐火车也不会影响最终目标的情况呀，题目已经说了，春季假期，火车票很难抢的客观因素， 也不能同时保留同日多天的车票，如果车票一直保留，这样对应成本太高，不适合 选择火车的方式（因为火车省钱）

完成了项目风险之后，我们来选择 用“敏捷型” 还是“瀑布型” 来执行的时候，就有区别了；
1：如果使用瀑布型，那就是按流程 一步一步去完成， 但是一但某个环境 出现 了问题，将严重影响结果，或者某一个需求发生了变化，也会影响

例如：1：火车票1个都没抢到， 2：起床起晚了。

2：如果使用 敏捷性，敏捷强调 拥抱变化（活着在当下），起床起晚了，就换行程方式，例如做大巴或者做的士，不考虑下一步的情况是什么样的。 只完成当下的工作，但是目标是不会发生变化的（为了春节回家）

场景3 描述的过于繁琐，增加了维护识别和管理风险模块的内容；但是我们可以看到，敏捷一定快吗？不一定，在这种情况下，敏捷肯定是慢于瀑布型的，因为一切是有计划在执行，而且变化的可能性也不会很大。

总结

敏捷？就是快吗？ 并不是，需要根据场景而言，什么样的项目使用什么样的模式，需要项目经理和团队一起来衡量，决策， 敏捷不一定适用于所有的项目，因此，我们就需要更加的了解“敏捷”，什么时候“敏捷”，怎么样“敏捷”

也是最近项目管理的过程中有所想对此也进行了一些简单的思考，内容和场景带有个人理解色彩，无法和专业的敏捷专家 项目管理 专家相提并论，本身自己也是1个学习者。关于“迭代”，“增量”，“瀑布”，“敏捷” 其他 网络上也有篇的文章，但是也可以学习了解，但是最主要的是，我们需要理解，以当前环境的方式来理解，概念并不能为我们带来更多的好处。 也想寻求 一个敏捷专家 帮我答疑解惑，针对敏捷我也有许多自己的问题。

今天的文章敏捷开发到底是什么_敏捷开发的基本原则分享到此就结束了，感谢您的阅读。