什么是敏捷开发

一、概念

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

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

二、优势

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

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

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

三、敏捷开发与瀑布开发对比

1、敏捷开发

客人到餐馆来点菜（新项目）不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）后厨开始准备（项目启动）配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）客人吃完，很满意（基本满足了全部的要求）

2、瀑布模型开发

客人到餐馆来点菜（新项目）不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）后厨开始准备（项目启动）根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）再过了二十分钟，十个菜都一起上来了（项目最终一次交付）客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）于是，后厨只给客户加了盐，加了辣客人吃完，不是很满意，下次不来了（没有满足需求）

3、图像对比

瀑布模型开发

敏捷开发

四、实施方案

1、 迭代计划

每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程

迭代计划会议内容：

1）澄清需求、对"完成标准"达成一致

2）工作量估计、根据团队能力确定本轮迭代将会内容

3）细化、分配迭代任务和初始工作计划

关键点：

1）充分参与：项目负责人确保产品和开发人员,测试及UI美术充分参考讨论，达成理解一致

2）产品负责人承诺在短迭代周期不增加需求（2-4周）

2、 每日晨会

每日工作前，团队成员的例行沟通机制，由开发负责人组织，Team成员全体站立参加聚焦主题：

1）我昨天为本项目做了什么

2）我计划今天为本项目做什么

3）我需要什么帮助以便更高效的工作

每日会议好处：

1）增加团队凝聚力，产生积极的工作氛围

2）及时暴露风险和问题

3）促进团队内成员的沟通和协调

关键要点：准时开始，高效会议，问题跟踪

3、 看板

将项目状态（进度、质量等）可以通过看板实时展示，让团队所有成员直观地获取当前项目进展信息

关键点：

1）物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到

2）内容精简易懂：信息展示一目了然，切实对团队有帮助

3）实时刷新：延迟的信息拖延问题暴露，降低运作效率

4、迭代验收 (ShowCase)

如果开发完成，并向项目负责人、产品负责人SHOW CASE以后，开发人员把故事卡移植到等待测试

关键点：

1）展示真实的产品

2）收集反馈

5、迭代回顾会议

在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步

关键点：

1）会议气氛：全员参加，头脑风暴发现问题，共同分析根因

2）关注重点：小组共同讨论优先级，将精力放在最需要的地方

3）会议结论要跟踪闭环：可以放入下个迭代版本中

五、敏捷使用管理工具

看板管理工具,常见的有神兵(Wizard),禅道, Jira等

六、敏捷开发总结回顾

1.参与敏捷开发的项目人员尽可能不被其他工作打扰。当项目中有一员频繁被调动处理项目之外事情，容易造成任务阻塞，会降低整体团队积极性。

2.项目人员，善于沟通，及时反馈，减少中间需求的增加。

3.要求技术人员水平较高，在快速版本迭代的同时，也要注重项目架构设计，应对后续需求变更。

4.产品负责人要及时对开发完成验收，确保开发完成任务符合版本需求目标。

5.项目开发人员要有主动积极性，对自己代码不断完善，及重构，避免重复开发，做到资源复用。

七、总结

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