本下篇主要内容章节：
一、敏捷实施的参考步骤
1、思想动员
2、差距分析
3、环境工具准备、敏捷技能准备
4、确定开发模型和应用实践
二、Scrum开发流程
1、产品backlog
2、召开产品backlog计划会议
3、任务墙
4、举行每日站立会议
5、绘制燃尽图
6、sprint评审会议
7、sprint总结会议
三、敏捷实施过程中的关键点
1、三个角色
1.1产品负责人
1.2团队负责人
1.3团队成员
2、三个工件
2.1产品功能列表:Product Backlog ( PBls )
2.1.1用户故事
2.1.1.1故事描述
2.1.1.2验收测试
2.2冲刺列表:Sprint Backlog ( SBls )
2.3燃尽图:Burn-Down Chart
3、四个会议
3.1迭代计划会 Sprint Planning Meeting
3.1.1 估算
3.1.2功能设计
3.2每日站会 Daily Meeting
3.3迭代评审会 Sprint Review Meeting
3.4迭代回顾会 Sprint Retrospective Meeting
一、敏捷实施的参考步骤
图一：首次实施敏捷参考步骤
1、思想动员
推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不会好。要能推行下去的任何东西一定要大家接受的，才能被认可。
首先需要人员承担敏捷指导者的角色，召集所有技术团队开会准备推广。开会时先指出我们现在问题，让大家看看有什么好的办法解决问题吗？在大家讨论后，抛出敏捷开发的优势，一般情况下大家都会认可的。大家可能会问到如何执行、落地，可以尝试找一个项目试点，如果实施成功就可以让大家全面推广，不成功也只影响了部分项目。
2、差距分析
差距分析，一方面要分析之前采用的开发方式与敏捷之间的差异，另一方面要分析需要执行敏捷的前提条件以及带来的好处。
3、环境工具准备、敏捷技能准备
大家要实施敏捷开发，需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件：nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》。
在敏捷实施前和过程中，对团队成员要持续进行培训，在敏捷基础知识，开发过程中的技能要求，流程要求等。让敏捷能深入人心。
4、确定开发模型和应用实践
选择适应项目的开发模型，并确定在哪个项目上开始进行实践。一般会采用Scrum开发模型进行开发。
二、Scrum开发流程
Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。
Scrum中发布产品的重要性高于一切。
图二：Scrum的基本流程
1、产品backlog
根据市场及客户的需求，产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表（backlog可以理解为需求或者要做的事情）。
2、召开产品backlog计划会议
召开产品backlog计划会议，预估每个backlog的时间，确定哪些backlog是需要在第一个sprint中完成的，即sprint的backlog（sprint可以理解为一个团队一起开发的一个任务集合）。
3、任务墙
把sprint的backlog写在纸条上贴在任务墙，让大家认领分配（任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上，这样大家都可以看得到任务的状态 ）。
4、举行每日站立会议
举行每日站立会议，让大家在每日会议上总结昨天做的事情、遇到什么困难，今天开展什么任务（每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内）。
5、绘制燃尽图
绘制燃尽图，保证任务的概况能够清晰看到（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0 ，这个sprint就完成了）。
6、sprint评审会议
sprint评审会议是在sprint完成时举行，要向客户演示自己完成的软件产品 。
7、sprint总结会议
最后是sprint总结会议，以轮流发言方式进行，每个人都要发言，总结上一次sprint中遇到的问题、改进和大家分享讨论。
三、敏捷实施过程中的关键点
1、三个角色
1.1产品负责人
1.2团队负责人
1.3团队成员
在团队确定采取实施敏捷前，由团队成员自己讨论定制出一套所有人都认同的规则（针对日常活动）；
制定出来的协议需要每个人都能遵守和互相监督；工作协议要满足下面几条：
制定的协议要是可实行的；
有具体的判断标准；
每个人都认同的。
在此基础上再实施敏捷开发。
2、三个工件
2.1产品功能列表:Product Backlog ( PBls )
产品功能列表包含用户故事内容，优先级及工作量估算的列表。
下图是一个产品功能列表示例：
2.1.1用户故事
用户故事是首创于极限编程（XP）的管理用户需求的基本方法，目前已广为各个敏捷实践方法和技术所借鉴和使用。Scrum将用户故事作为最基本的需求管理工具，组成了称之为产品功能列表（Product Backlog）的用户需求列表。
用户故事从用户的角度描述用户渴望得到的功能和实现的价值。
用户故事描述对用户，系统或软件购买者有价值的功能。由以下两方面构成：
2.1.1.1故事描述
一个好的用户故事描述包括三个基本要素：
◉ 角色：谁要使用这个功能。
◉ 活动：需要完成什么样的功能。
◉ 商业价值：为什么需要这个功能以及这个功能带来什么样的价值。
用户故事描述公式为：作为XXX【角色】，我想XXX【活动】，以至于XXX【商业价值】。
2.1.1.2验收测试
验收测试用来验证实现的用户故事是否符合客户团队的期望，有点类似于之前的需求描述。需要尽可能把所有满足此用户故事的情况考虑在内。
用户故事拆分的要尽可能的小，大小是一天的开发工作量。
注意：在一张纸上，正面写故事描述，背面写验收测试。
下图是用户故事的一个示例：
2.2冲刺列表:Sprint Backlog ( SBls )
下图是用户故事地图和冲刺列表示例：
用户故事地图就是从左至右按时间顺序罗列用户行为（也就是流程的每一步），在每个用户行为下从上至下罗列相应的细节，包括所需要的开发点，构成一个二维的“地图”。基于这个地图，还可以对每个开发点的业务价值进行审视，找出最小可用产品（MVP）并制定发布计划。
将用户故事进行拆分，拆分成团队成员可以认领的任务，并定义好每个冲刺需要完成的功能内容，建立冲刺列表，形成用户故事地图。
2.3燃尽图:Burn-Down Chart
燃尽图是在Scrum开发过程中一个非常重要能够反映出当前冲刺执行情况的图表。典型的燃尽图横坐标表示冲刺的具体日期，纵坐标表示剩余工作量（或故事点），虚线表示理想趋势，实线表示实际工作量（或故事点）变化情况。
如下是一个项目迭代周期内的一张燃尽图示例：
燃尽图作为敏捷可视化管理的工具，发挥着重要的作用。作为敏捷教练应当能够从每一张图表、每一条折线，分析出项目背后的问题，防范于未然。燃尽图的数据来源于日常工作，出自于团队本身。所以数据的准确性，直接决定了燃尽图的价值。
要想团队的燃尽图是有价值的，必须做到下面几点：
◉ 数据要真实，统计全面。这样才能反映出task的执行情况。
◉ 对于工作量的预估要尽量准确，这就对团队的技术水平有一定的要求。
◉ 粒度的分解要尽量落实到每一天。太大的粒度无法跟踪，而且不利于工作的估计。
3、四个会议
3.1迭代计划会 Sprint Planning Meeting
◉ 参与人员：PO（产品负责人）、SM（团队负责人）、Scrum Team（团队成员）
3.1.1 估算
估算采用相对估算的方法，以故事点为单位，以某一个故事点为基准，其他故事点估算以0，½，1，2，3，5，8，13，20，40，100为单位。（此方法可以评估团队每个冲刺可完成的故事点，为后续项目评估作为参考）
可采用敏捷估算扑克进行相关评估。
拆分任务，将用户故事进行拆分，决定当前Sprint内容。由PO组织，按优先级顺序询问团队是否能完成，能完成就下一个，不能完成就停止。
3.1.2功能设计
包含系统架构、接口、数据表、流程图和界面简图。然后将任务按顺序贴到看板的To Do中，形成看板。
3.2每日站会 Daily Meeting
◉参与人员：SM、Scrum Team
◉ 时间不超过15分钟，主要讨论下面三点：
· 总结昨天完成了什么、遇到什么困难，今天开展什么任务。
· 陈述自己做的事情和问题，并移动看板。
· 会议结束后更新燃尽图。
3.3迭代评审会 Sprint Review Meeting
◉ 参与人员：PO（或客户）、SM、Scrum Team
◉ 由团队成员演示本次Sprint完成的功能；
◉ PO发表接收或拒绝的意见。
3.4迭代回顾会 Sprint Retrospective Meeting
◉ 参与人员：SM、Scrum Team
◉ 每人反思，总结过程中好与不够好的地方；
◉ 识别问题的优先级，并对高优先级的项讨论出每个人都认同的改进方案；
◉ 总结此阶段的冲刺问题及成绩，并在后面的Sprint中进行改进。
以上就是敏捷开发的基本流程。我们要总结怎么结合敏捷开发解决现有项目的问题，要记得任何措施都是为了保证按时按质按量把软件交付给用户，不要为了敏捷而教条实施敏捷，公司不能产生商业价值，任何先进的理念或者技术都是无意义的，适合自己的才是最好的。
文章来源：PMO之路 Mason
383
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
