敏捷开发流程详解

敏捷开发流程详解 

1       敏捷开发流程

ü   敏捷软件开发核心是迭代式开发,增量交付。 

ü   每一次迭代都建立在稳定的质量基础上,并作为下一轮迭代的基线,整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表(外部或内部)验收,提供需求是否满足的反馈。

ü   迭代型的方法就是将整个软件生命周期分成多个小的迭代,每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成,每一次迭代都可以生成一个稳定和被验证过的软件版本。

ü   迭代建议采用固定的周期(1-4)周,可以每个迭代周期不一定要相同,但迭代内工作不能完成,应该缩减交付范围而不是延长周期。

1.1      敏捷流程详解图-敏捷流程图

1.2      敏捷流程三种角色及其职责

角色名称

角色定义

角色职责

注意事项

Product Owner(PO)- 产品负责人

确保Team做正确的事

l   代表利益相关人(如用户、市场、管理等),对产品投资回报负责 l   确定产品发布计划 l   定义产品需求,根据市场价值确定功能优先级 l   验收迭代结果,并根据验收结果和需求变化更新需求清单和优先级

l   除了客户需求之外,内部任务如重构、持续集成环境搭建等也由PO纳入统一管理

Scrum Master(SM)- Scrum 教练

确保Team正确的做事

l   辅导团队正确应用敏捷实践 l   引导团队建立并遵守规则 l   保护团队不受打扰 l   推动解决团队遇到的障碍 l   保证开发过程按计划进行,组织站立会,冲刺评审会,冲刺回顾会议

l   不命令和控制Team

Team – 开发团队

负责产品需求实现

l   负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量 l   向PO和利益相关人员演示工作成果(可运行的软件) l   团队自身管理、持续改进

l   一般由5-9人左右跨职能领域人员(开发人员、测试人员、设计师等)组成 l   团队车管员构成在sprint内不允许变化 l   有共同的目标、共担责任 l   团队成员严格遵守团队规则

1.3      敏捷开发流程详解

1.3.1   流程图详解步骤

1.          制定产品需求列表

ü   PO收集来自客户、市场、领导等渠道的信息,从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表;

2.          召开计划会议

ü   PO召集TM和SM(也可邀请其他利益相关者参加)召开计划会议(发布计划会议和冲刺会议一块开),发布计划主要是说明产品完整交付给客户的计划时间和交付物,

ü   冲刺计划就是确定该冲刺阶的长度(建议冲刺长度1-4周)、目标和冲刺任务单及其工作量估算(以理想人天manday=7.5h估算,单位为小时计算),会议时间建议不要超过6h时间;

ü   在计划会议上就需要进行确认,是否需要使用持续集成;若使用持续集成,团队需要每天下班前至少提交一次私有构建成功的代码到服务器,并且要求写详细的日志信息;若不使用持续集成,团队每天有完成任务单的情况,都需要在svn上以增量形式发包并通知到相关人员;

ü   项目计划会议上可以确定每天站立会时间及其规则要求(建议会议时间在15-20分钟左右),每个人回答3个问题:昨天做了什么,遇到什么问题,今天要做什么。具体问题讨论及其解决,在私下进行沟通,不要在会议上讨论。站立会上只有TM人员有发言权,其他人员不要干预,SM主要是维护秩序、规则及其引导作用。

3.          需求分析、设计、编码和测试:

ü   计划会议结束后,TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试;

ü   这里特别要说明的是,开发和测试是并行工作,必要的文档还是需要输出(如:讨论次数较多的功能点、备选方案很多但最后确认一种、重要功能、业务逻辑复杂的等等)。具体情况,需要项目组根据实际情况决定,但客户要求交付的文档必须要输出;

4.          冲刺任务单和燃尽图更新

每天SM需要根据每日站立会上TM反馈的情况,进行更新冲刺任务单和燃尽图或SM和TM之间达成共识,TM各自完成后进行更改状态,这里涉及到的文档都会有相对应的模板供参考使用。

5.          迭代周期结束点

ü   已到迭代周期结束点,只有哪些经过测试通过的冲刺需求列表才能算是真正的完成,其他未经过测试或测试不通过的不能算是完成。

ü   这里要特别注意,所谓的测试通过不是说要把所有的问题都解决才算是通过,这个要根据项目具体的要求和规定来定。还没有达到迭代结束点,该冲刺任务需求列表就完成,可以从产品需求列表中挑选优先级高的进行开发。

6.          冲刺评审会议

ü   TM需要召开冲刺评审会议,邀请PO、客户或客户代表来参加,由这些客户或客户代表来表决是否满足需求和期望目标。一般会议时间建议不要超过2个小时,参加人员除PO及其相关利益人来参加外,TM全体成员,也可以邀请其他相关人员参加。

7.          冲刺回顾会议

ü   迭代输出的增量交付可能会引起原产品需求列表的改变,可能需要更新原产品需求列表;最后TM需要开展本次迭代的好的实践和不足的改进机会,最终稿由SM整理汇总,作为下一次的迭代的经验参考。回顾会议建议时间不用太长,一般15-30分钟即可,全体人员都需要参加,包括:PO、SM、TM,其他相关人员也可以参加。

ü   这里要说明的是在每次的计划会议上要注意安排时间做冲刺评审会议和冲刺回顾会议。下一次迭代的计划会议建议在上一次迭代的冲刺回顾会议结束后再开展。

8.          重复2-7步骤

ü   直到所有列入本版本规划的任务单都完成,最后发布版本;

ü   特别说明:通常最后一个迭代可能是全量进行验证的周期,

1.3.2  管理

结合目前jira进行管理“使用敏捷开发模式的项目”也是很方便。每一个迭代在jira中作为一个版本控制,每个迭代下面的任务单,参照迭代计划预估的时间进行创建,实际工时根据每个人的实际填写日报为准计算。可以考虑安装一款支持jira的敏捷开发插件GreenHopper,完全实现电子版的看板功能和图表功能。

在confluence上以项目名称创建项目,然后二级目录是每个迭代名称、产品需求列表,三级目录放每次迭代冲刺评审会议纪要、冲刺回顾会议纪要、站立会纪要、燃尽图、迭代任务订单。

说明:燃尽图使用excel表格式的模板,项目组可以参照使用。

1.3.3   度量

类别

指标

XX项目

迭代1

迭代2

迭代3

范围

计划交付任务订单数

26

14

15

实际交付任务订单数

26

13

15

价值交付率

100%

92.85%

100%

工作量

实际完成率

开发任务完成100%(遗留大量BUG)

100%(所有任务完成,BUG清空)

100%(遗留2个偶现BUG)

计划估算精准度

偏差31%=(实际-计划)/计划

偏差31%=(实际-计划)/计划

偏差31%=(实际-计划)/计划

开发计划估算精确度

偏差20%=(实际开发-计划开发)/计划开发

偏差20%=(实际开发-计划开发)/计划开发

偏差20%=(实际开发-计划开发)/计划开发

测试计划估算精确度

偏差30%=(实际测试-计划测试)/计划测试

偏差30%=(实际测试-计划测试)/计划测试

偏差30%=(实际测试-计划测试)/计划测试

质量

开发测试工时比

开发工时:测试工时

开发工时:测试工时

开发工时:测试工时

测试效率

发现有效bug/测试工时

发现有效bug/测试工时

发现有效bug/测试工时

测试验证一次通过率(按任务单)

一次通过任务订单/本迭代预计要完成的任务订单*100%

一次通过任务订单/本迭代预计要完成的任务订单*100%

一次通过任务订单/本迭代预计要完成的任务订单*100%

测试验证一次通过率(按用例)

缺陷总数

缺陷密度(个/开发工时)

缺陷级别

1:20:10:4:3

测试用例内BUG占比

系统测试前后BUG比

NA(无单独系统测试)

NA(无单独系统测试)

系统测试前:系统测试后

成本

不良质量成本占比

修复bug所耗工时/总工时

总工时数

800人时

团队工作负载

100%

112%

80%(学习其他)

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

电信云保障之旅

随着通信服务提供商(CSP)正在谋求数字化转型,在云环境中运行其业务,销售数字服务和像网络级互联网公司一样运营,以确保电信云环境和业务流程的高度优先性。随着网络...

35310
来自专栏程序员互动联盟

【答疑解惑第三十三讲】大数据和云计算有啥关系?

疑惑一 大数据与云计算有何关系? 大数据(big data),是指无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理的数据集合。 大数据的4V特点:Vo...

4367
来自专栏云计算D1net

2015年IT发展四大趋势与云计算三大预测

存储资源日益减少 对于大多数人来说,预测未来是非常困难得。但是人们总是喜欢关注未来会发生什么事情。在IT领域,人们同样喜欢关注趋势发展。到了2014年底了。又该...

33710
来自专栏云计算D1net

混合云迁移:长期多云战略的第一阶段

如今,每个采用云计算的企业平均有六个云,当遇到混合环境中的应用托管时,就会面临一些特殊的挑战和一些误解。 ? 在某个地方,仍然有使用拨号电话和通讯录的业务。这可...

3275
来自专栏Java学习网

看看未来的应用开发

记得巨大的庞然大物应用程序部署在前提与client-owned服务器?还记得矛盾修饰法是速度和质量?由于云及其作为催化剂作用加速创新周期、速度和质量可以一起工作...

2787
来自专栏云市场·精选汇

如何提高小程序的用户留存率?用完即走,走了还会回来

对商家来说,如果用户“走了不再回来”,即小程序不能被用户反复使用,那就有些令人局促不安了。这就关系到小程序的留存能力,那么,如何才能有效地提高小程序的留存率?

2982
来自专栏云计算D1net

随需而变 下一代安全如何定义云计算?

云计算已经成为一个更为确定的平台,现在我们看到比以往更多的案例越来越多的企业开始瞄准云计算模型。我们有着更好的基础设施、更多资源,还有更多联网用户。所有这一切都...

2923
来自专栏人称T客

公有云与私有云优劣对比分析

T客汇官网:tikehui 撰文 |Felix 选择公有云或私有云并不是一个二选一的问题。行业分析师指出大部分的公司使用了多云战略,也就是说明他们至少使用了两种...

5.9K6
来自专栏CDA数据分析师

干货|微信公众号运营必须学会这些数据分析!

很多微信公众号运营者,对数据分析都没什么概念,更不用说建立自己的数据分析方法了。 一般人只会看微信公众号的粉丝数,只会看单篇文章的总阅读数。总粉丝数衡量不了粉丝...

6188
来自专栏phodal

为什么说全栈工程师是未来?| 长文多图

谨以此文献给每一个为成为优秀全栈工程师奋斗的人。 节选自《Growth: 全栈工程师学习手册》 ? 技术在过去的几十年里进步很快,也将在未来的几十年里发展得更快...

2828

扫码关注云+社区

领取腾讯云代金券