本文共 2384 字，大约阅读时间需要 7 分钟。
一、敏捷开发技术的几个特点和优势：
1．个体和交互胜过过程和工具
2．可以工作的软件胜过面面俱到的文档
3．客户合作胜过合同谈判
4．响应变化胜过遵循计划
二、敏捷开发技术的12个原则：
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2．即使到了开发的后期，也欢迎改变需求。
3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5．围绕被激励起来的个人来构建项目。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7．工作的软件是首要的进度度量标准。
8．敏捷过程提倡可持续的开发速度。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
10．简单使未完成的工作最大化。
11．最好的构架、需求和设计出自于自组织的团队。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
三、敏捷开发技术的适用范围
1.项目团队的人数不能太多
2.项目经常发生变更
3.高风险的项目实施
4.开发人员可以参与决策
根据以上三点，大体可以总结出：
优势：
敏捷确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。
劣势：
但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。
需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
敏捷开发：
就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
优点：
1、敏捷开发的高适应性，以人为本的特性。
2、更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
缺点：
传统瀑布开发优缺点：
优点：
1. 为项目提供了按阶段划分的检查点。
2. 当前一阶段完成后，您只需要去关注后续阶段.
3. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点：
1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。
Scrum开发流程中的三大角色
– 产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
– 流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
–开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
过程：
1、我们首先需要确定一个Product Backlog（产品需求列表），这个是由PO负责的（如图（一））；
2、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
3、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）（如图（二）和如图（三））；
5、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。
6、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。
7、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
转载地址：http://erpmi.baihongyu.com/