scrum敏捷开发方法介绍

1：什么是敏捷开发

敏捷开发以人为核心，采用迭代、循序渐进的方法进行软件开发。

我更赞同这个定义，网络上有的定义强调以用户需求为核心，突出不了人在整个敏捷开发过程的作用，后续的阐述也是围绕着人来阐述的。软件开发不以需求为核心，还以什么为核心呢。

 

2：为什么需要敏捷开发

更快更好完成用户需求，快速试错，及时迭代优化。

 

3：敏捷开发的分类及差别

现在主流的敏捷开发分为两种：scrum敏捷开发和xp敏捷开发，两者的差别是scrum强调过程，xp强调实践（XP的核心是沟通、简单、反馈、勇气四大价值观，它们是XP的基础，也是XP的灵魂）后面我们的讲解只针对scrum敏捷开发。

 

4：什么样的团队才能采用敏捷开发

敏捷开发指导思想并不是一把万能钥匙，得看团队情况而定，并不是每个团队采用了敏捷开发方式，团队面临的问题就能解决。那么什么样的团队适合采用敏捷开发模式呢？总结如下

 

第一：团队成员善于沟通和自我管理。

每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力。

 

第二：团队成员人数5-10人。

可以是临时从其他团队抽调组建的临时战斗单元（战斗结束随即解散）。短时间内能够完全专注于某一件事。团队必须包含三个角色（政委，长官，战士）：

 

– 产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

 

– 流程管理员（Scrum Master）

负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发，ScrumMaster是Scrum团队中的服务式领导。

 

–开发团队（Scrum Team）

 

第三：团队人员稳定。

由于敏捷开发弱化了对项目文档的依赖，如果项目人员不稳定，在交接过程中会出现很大的困难。

 

5：怎么样做才是敏捷开发（四个会议，三个物件）

5.1：四个会议

以主人翁精神全员参与Sprint计划会议、每日例会、Sprint评审会议和Sprint回顾会议。

 

Sprint计划会议内容：

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

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

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

关键点：

1) 充分参与：Scrum Master(项目负责人)确保PO（产品负责人）和Team（开发人员及UI美术）充分参考讨论，达成理解一致

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

 

每日例会（不超过15分钟）

 

 

聚焦主题：

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

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

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

每日站立会议好处：

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

2）及时暴露风险和问题

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

 

Sprint评审会议

Sprint结束时，Scrum团队和相关人员一起评审Sprint的产出。每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定，并适当地调整产品待办事项列表。

 

Sprint回顾会议

在每个Sprint结束后，Scrum团队会聚在一起开Sprint回顾会议，目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好，哪些做得不好，并找出潜在的改进事项，为将来的改进制定计划。

 

5.2三个物件(产品待办事项列表（ProductBacklog）、Sprint Backlog和燃尽图)

 

ProductBacklog – 产品待办事项列表

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

 

 

SPRINTBACKLOG

Sprint 代办事项列表是一组为当前 Sprint选出的产品代办事项列表条目,外加交付产品增量和实现 Sprint目标的计划

 

燃尽图（Sprint Burn-down Chart)

 Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。

 

6：敏捷开发流与传统开发流程的对比

 

优点：

1.   敏捷开发的高适应性，以人为本的特性。

2.   更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

缺点：

1.   由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。

 

 

 

（传统开发瀑布模型流程图）

优点：

1. 为项目提供了按阶段划分的检查点。

2. 当前一阶段完成后，您只需要去关注后续阶段.

3. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

 

缺点：

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4. 瀑布模型的突出缺点是不适应用户需求的变化。

 

阶段	瀑布模式	敏捷开发
业务需求	强调需求文档	注重沟通交流
管理进度	管理文档（需求计划、进度表）	看板（任务开发状态是否顺利进展、<br/>有没有阻塞）
任务分配	开发人员被动安排	开发人员主动自我管理、责任心强
版本迭代	产品整体需求计划	小版本迭代
研发	开发人员安照需求文档要求开发<br/>较少沟通业务场景使用情况	开发人员站在用户需求角度对接需求
研发周期	版本周期较长	版本周期短(2-3周)

 

7：scrum开发流程

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 RetrospectiveMeeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

 

8：敏捷开发总结回顾

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

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

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

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

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