敏捷开发方法综述

Posted 2020-06-29

此次我分四个板块介绍敏捷开发方法综述：1 什么是Scrum？2如何进行Scrum开发？3 Scrum 的流程 4 敏捷项目管理和传统项目管理  

一.

   什么是Scrum？

 Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。 

二.

   如何进行Scrum开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

三.

   Scrum 的流程  

 1、 将整个产品Backlog 分解成Sprint Backlog ，按照目前的人力物力条件可以完成的。 

 2、 召开Sprint 计划会议，划分、确定这个Sprint 内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算，长度不超过8 小时。 

 3、 进入Sprint 开发周期,每个Sprint 迭代周期为连续30 个日例日（2-4周）。在这个周期内，每天需要召开每日Scrum 简会，时间为15 分钟。在会议中每个团队成员仅就以下三点发言:自上次Scrum 会议后你做了什么?从现在到下次Scrum 会议的时间里你准备做什么? 你在工作中遇到了哪些困难? 
 4、 整个Sprint 周期结束，召开Sprint 评审会议(Sprint review meeting)，将成果演示给Product Owner ，该会议限定时间为4 小时。 

 5、 团队成员最后召开冲刺回顾会议( Sprint retrospective meeting) ，总结问题和经验，该会议限定时间为3 小时。 

 6、这样周而复始，按照同样的步骤进行下一次Sprint 

四.

  敏捷项目管理和传统项目管理 

传统项目管理： 
• 事先对整个项目进行估计、计划、分析 
• 反对变更; 变更需要重新估计、重新规划 

• 严密的合同来减少风险, 如果改变需求要走CR流程. 
• 项目作为一个“黑盒子”，对客户与供应商的可视性差. 
• 产品化和测试阶段是分离的. 
• 文档和计划驱动的方法. • 软件交付时间晚, 意识到风险的时间晚

敏捷项目管理: 

• 对整个项目做一个粗略的估计,每一次迭代都有详细的计划. 

• 鼓励变化, 客户价值驱动开发. 

• 信任和赋予权力;合约使变更变得简单，增加价值. 
• 客户和开发人员之间是紧密的连续的合作关系  
• 每次迭代都产生可交付的软件  
• 专注于交付软件.  

• 第一次迭代就可交付能工作的版本，风险发现的早