本下篇主要内容章节:
一、敏捷实施的参考步骤
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