在软件开发中，我们经常会遇到类似这样的问题
我们所理解的东西无法和用户想要的达成一致，所以用户提出的要求，经过项目经理、分析师，最后到程序员的就已经被篡改的面目全非，所以，经过程序员们日以继日的努力，终于做出来完全不是用户需要的程序了，于是我们不得不继续夜以继日的修改，终于在放弃了代码的质量、放弃了休息、加班加点的工作后，用户勉勉强强的接受了我们随时都可能奔溃的系统。
或者我们还会 遇到另一个问题：
第一次看到这个图的时候真是心酸，可是我们不是常常处于这种境况吗，只是我们写的是代码，而不是在挖坑，当销售部以牺牲各种签下了丧权辱国的条例之后，当产品经理大概了解了需要项目经理制定出看似争取的需求之后，就是程序员一个人在劳动的时候了，然后还要继续忍受感觉计划不合理向上反应的石沉大海，和测试部分的各种矛盾，和销售部门的各种嫌弃，就连每天加班让保安队长都建议颇多，但是干活的还是只有是自己。
但是，程序员都是高智商的，既然就问题，就肯定有解决的方法，下面我就介绍一种解决办法——敏捷开发（agile development）。
敏捷开发简介
敏捷开发（agiledevelopment）
是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷的组成
它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等
和其他开发对比
我们知道软件开发模型有很多，比如：
瀑布式
它首先是由Royce提出，该模式由于酷似瀑布闻名。在该模式中首先确定需求，然后拟定规格说明，在通过验证后方可进入计划阶段。因此，瀑布模式中至关重要的一点是只有当一个阶段的文档获得认可才可以进入下一个阶段。瀑布模式通过强制性规约来确保每个阶段都能很好的完成任务，但是实际上却往往难以办到。因为整个瀑布模式几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。虽然瀑布模式有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。
演化模式
它主要是针对事先不能完整定义需求的软件开发。它的方法是用户先给出待开发系统的核心需求，并且在核心需求实现后，再提出反馈以支持系统的最终设计和实现。也就是说：开发人员首先会根据用户的需求开发核心系统，然后提供给用户试用；用户试用后再提出增强系统能力的需求；最后开发人员再根据用户的反馈，实施迭代开发。实际上，这个模式可看作是重复执行的多个瀑布模式。演化模式要求开发人员把项目的产品需求分解为不同组，以便分批循环开发。但这种分组并不是随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。
螺旋模式：
它是瀑布模式与演化模式相结合，并加入两者所忽略的风险分析所建立的一种软件开发模式。螺旋模式基本的做法是在瀑布模式的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后，才开始计划下一阶段的开发工作。否则，项目就很可能被暂停。另外，如果有充足的把握判断遗留的风险已降低到一定的程度，项目管理人员还可作出决定让余下的开发工作采用另外的生命周期模式，如演化模式，瀑布模式或自定的混合模式。
过程开发模式：
它又叫混合模式或元模式，是指把几种不同模式组合成一种混合模式，它允许一个项目能沿着最有效的路径发展。因为上述的模式中都有自己独特的思想，现在的软件开发团队中很少说标准的采用那一种模式的，因为模式和实际应用还是有很大的区别的。实际上，许多软件开发团队都是在使用几种不同的开发方法组成他们自己的混合模式。
最后，我们来总结一下。螺旋模式是典型的迭代式生命周期模式，而RUP则是近代迭代式生命周期的代表。与螺旋模式相比，RUP将风险管理放在更重要的地位。最新的迭代式生命周期模式的代表是模式驱动架构（MDA）和敏捷（Agile）软件开发。MDA模式是基于可执行规格说明的思想，是现代转换模式的代表，其核心技术是组件技术。而敏捷开发生命周期的典型代表是XP编程，是把传统的系统设计和实现由敏捷软件开发过程中的验收测试、重构和测试驱动所取代；把传统的集成和部署由敏捷软件开发中的持续集成和短周期所取代。
具体介绍敏捷开发的过程
敏捷开发主要包括三个角色，四个仪式，和三个物件，下面一一介绍
三个角色
产品负责人
产品负责人（Product Owner）：它是开发团队和客户或最终用户之间的联络点。
- 代表产品线的利益,与Scrum Master和Scrum Team合作
- 负责管理和确定产品记录的优先次序,角色负责产品的远景规划
- 侧重于投资回报ReturnOf Investment
Scrum Master
Scrum专家（ScrumMaster）：Scrum专家负责指导开发团队进行Scrum开发与实践,它也是开发团队与产品拥有者之间交流的联络点。
- 为Scrum Team服务,确保每一个成员都认同Scrum价值观和遵守其游戏规则
- 组织每天的DailyScrum会议
- 负责保证Scrum Team的持续进展
- 决策和免除障碍
- 帮助Scrum Team规划Sprint计划
团队
团队成员（Team Member）：即项目开发人员。
- 自我管理,自我组织,多功能,通常由6 – 10人组成
- 负责将ProductBacklog转化成Sprint中的工作项目
- 所有团队成员协调,合作和完成Sprint中每一个规定的工作
- 所有团队成员和ScrumMaster负责每一个Sprint的成功
四个仪式
Sprint计划会议
每日站会
- 开发团队成员召开，一般为15分钟。
- 所有成员必须参加，每个人给全体成员汇报工作进展。
- 更新燃尽图。
- 每个开发成员需要向ScrumMaster汇报三个项目：
遇到了障碍无法继续下去？
明天要做什么？
- 通过该会议，团队成员可以相互了解项目进度。
Sprint评审会议
Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner. Produc Owner会组织
- 这阶段的会议并且邀请相关的干系人参加。
- 团队展示Sprint中完成的功能
- 一般是通过现场演示的方式展现功能和架构
- 不要太正式
- 不需要PPT
- 一般控制在2个小时
- 团队成员都要参加
- 可以邀请所有人参加
Sprint回顾会议
- 团队的定期自我检视，发现什么是好的，什么是不好的。
- 一般控制在15-30分钟
- 每个Sprint都要做
- 全体参加
- Scrum Master
- 产品负责人
- 团队
- 可能的客户或其它干系人
Sprint回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬。
三个物件
产品Backlog
一个需求的列表：
- 一般情况使用用户故事来表示backlog条目
- 理想情况每个需求项都对产品的客户或用户有价值
- Backlog条目按照商业价值排列优先级
- 优先级由产品负责人来排列
- 在每个Sprint结束的时候要更新优先级的排列
Sprint Backlog
将整个产品的backlog分解成Sprint Backlog，这个Sprint Backlog是按照目前的人力物力条件可以完成的。
团队成员自己挑选任务，而不是指派任务。
每个团队成员都可以修改Sprintbacklog，增加、删除或者修改任务。
燃尽图
燃尽图直观的反映了Sprint过程中，剩余的工作量情况，Y轴表示剩余的工作，X轴表示Sprint的时间。随着时间的消耗工作量逐渐减少，在开始的时候，由于估算上的误差或者遗漏工作量有可能呈上升态势。
当然，知道了敏捷开发的组成部分，更要知道敏捷开发的流程，下面用一幅图来说明：
敏捷开发的先决条件
很多人会问，既然敏捷开发这么好，可以解决这么多的问题，为什么不是所有人所有项目都在使用敏捷开发呢，这就涉及到了实行敏捷开发的先决条件：
一、团队有三名或以上的研发工程师；
二、团队内有一名合适的Scrum Master。
当团队内无法找到合适的Scrum Master时，不要轻易推行敏捷。如果你的团队是由新人组成，或者即使有资深员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的Scrum Master出现。
1176
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
