标签：需求 迭代 项目 开发 敏捷 客人

什么是敏捷开发

0、先来一张导图

 

 

1、概念

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷最大的特色是迭代式开发。

2、优势

 

 

1、敏捷开发属于增量式开发，对于需求范围不明确，需求变更较多的项目而言，可以很大程度上响应及拥抱变化。

2、对于互联网产品而言，市场风向转变很快，需要一种及时快速的交付形式，而敏捷开发则能更好地适用于此。

3、敏捷开发可最大程度体现80/20法则的价值，通过增量迭代，每次都优先交付那能产生80%价值效益的20%功能。能最大化单位成本收益。

3、误区

 

4、特点

 

5、核心原则

 

 

6、捷开发与瀑布模型开发

 

瀑布模型开发

    

 

敏捷开发

 

某博主po的一个很有趣的“敏捷和瀑布”对比例子，给大家作为阅读参考：

 

 

6.1、敏捷开发

• 客人到餐馆来点菜（新项目）

• 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）

• 根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）

• 后厨开始准备（项目启动）

• 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）

• 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）

• 上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）

• 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）

• 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）

• 客人吃完，很满意（基本满足了全部的要求）

 

6.2、瀑布模型开发

• 客人到餐馆来点菜（新项目）

• 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）

• 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）

• 后厨开始准备（项目启动）

• 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）

• 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）

• 再过了二十分钟，十个菜都一起上来了（项目最终一次交付）

• 客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）

• 这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）

• 于是，后厨只给客户加了盐，加了辣

• 客人吃完，不是很满意，下次不来了（没有满足需求）

 

7、总结

但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用

最后借用民国时候的一句话：少研究一些主义，多关注一些实际问题

标签：需求,迭代,项目,开发,敏捷,客人
来源： https://www.cnblogs.com/jentary/p/11506762.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。