管理 | 两种敏捷开发方法
一、什么是敏捷开发？
-
传统开发方式：如迭代式开发、瀑布式开发
- 软件的开发过程是确定的、可测的
- 在一开始努力收集到需要的信息并指定好计划
- 忠实地执行计划就能够成功
-
敏捷开发(Agile Development)
- 无法从一开始就收集到确保陈功所需要的所有信息
- 随着开发的进行，对正在做的东西的认识越来越深刻，才能发现产品中的一切缺陷或需要调整的地方
二、敏捷开发的核心是什么？
-
敏捷开发的原则是：
- 快速验证
- 价值驱动
- 团队自组织
-
敏捷开发的目的是：
- 更早验证产品模式
- 获得投资回报
- 降低投资风险
-
敏捷开发的核心是：
- 以人为核心！
- 人为核心！
- 人为核心！
敏捷开发是增量式的迭代开发，需要应对多种可能的需求变化并快速感知响应。
增量迭代开发就是定期产出可工作的软件并收集软件反馈，然后做出相应的调整战略。
形成所谓的快速反馈循环，以迅速应对变化。
三、敏捷开发的两种方法
1）Scrum
Scrum表示橄榄球运动的“争球”动作；
大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它。
2）XP
极限编程（eXtreme Programming）是敏捷方法中最被推崇的一个
3）Scrum和XP的区别是什么？
区别之一： 迭代长度的不同
- XP的一个Sprint的迭代长度大致为1~2周
- Scrum的一个Sprint迭代长度一般为 2~ 4周.
区别之二: 在迭代中, 是否允许修改需求
- XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换，替换的原则是需求实现的时间量是相等的。
- Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰
区别之三: 在迭代中，User Story是否严格按照优先级别来实现
XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.
区别之四
软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
四、如何实现敏捷开发？
Scrum开发流程中的三大角色
一）产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
二）流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
三）开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
什么是Sprint？
Sprint是短距离赛跑的意思，在开发里面指的是一次迭代。
而一次迭代的周期是1个月时间（即4个星期），
也就是我们要把一次迭代的开发内容以最快的速度完成它，
这个过程我们称它为Sprint。
- 我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
- Scrum Team根据Product Backlog列表，做工作量的预估和安排；
- 有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
- Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
- 在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
- 做到每日集成，也就是每天都要有一个可以成功编译. 并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
- 当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
- 最后就是** Sprint Retrospective Meeting（回顾会议）**，也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
五、Scrum开发流程中的一些场景图
每日的站立会议
任务看版
任务看版包含 未完成、正在做、已完成 的工作状态
假设你今天把一个未完成的工作已经完成，
那么你要把小卡片从未完成区域贴到已完成区域。
每个人的工作进度和完成情况都是公开的，
如果有一个人的工作任务在某一个位置放了好几天，
大家都能发现他的工作进度出现了什么问题
（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
计划纸牌
计划纸牌怎么用的呢？
比如A程序员开发一个功能，需要5个小时，
B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，
最后摊牌，如果时间差距很大，
那么A和B就可以讨论A为什么要5个小时...
希望详细了解学习的同学可以购买这本书《硝烟中的Scrum和XP》作者Henrik Kniberg讲 述了他在一年的时间里，带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸（3～12人）、sprint长度（2～6星期），定义“完成”的 不同方式，不同的backlog格式，各种测试策略，在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱 动开发等等，还试过了把XP跟Scrum组合。
