文档介绍：XPP设计与规划
Agenda
极限编程实践(XPP)
如何持续快速交付高质量产品
Q&A
XPP的背景和目标
构建更加快速、高效的研发体系,持续提升产品价值。
每个开发人员会将需求分解成多个技术任务后开发。所以在所有
任务完成之前,应用程序一直处于不可用状态,一些意想不到的
问题往往在最后的联调环境才被发现。
因为有测试环节的存在,开发会期望通过测试环节来发现问题,
甚至明知道问题存在,期望通过测试人员来获取问题的具体细节。
提测的代码质量不高,且测试环节都会伴随有代码的修正,测试
过程不顺畅,测试激情被消磨,提测到上线无论花多长时间都不
会感到奇怪。
开发需要投入大量的精力来关注发布过程和系统监控,不能专注
于功能设计和开发。
需求的频繁变更使得产品经理和开发往往不能及时更新需求文档、
功能文档,实现的具体功能需要反复的沟通。维护成本也较大。
XPP的模式
PD Developer QA Ops
面向
测试需求设计编码测试交付
开发
PD Developer DevOps
面向
交付需求设计编码交付
开发
代码审查用例审查
单元测试验收测试
持续
集成
集成测试自动化回归
XPP的模式——角色技能的变化
QA QA QA
PD DEV DevOps
PD Dev PD Dev Ops
QA变成三个重要角色的一个关键技能
XPP的模式——DevOps职责与定位
自动化测试任务的创建、执行
QA 和管理
自动化测试用例审查
线上故障Review
DevOps
Dev Ops
线上故障分析与定位(注:
发布过程中的bug视为线上 XPP流程的推动,全局观和自动化
故障,也需要分析与定位, 配置管理和工具选择
最理想状况帮助定位到代码环境部署和发布
行。) 执行监控和分析
单元测试用例的审查
XPP的变化
第一阶段: •在8周内共成功发布32次
XPP •需求到发布的时间:小的需求2天,大的需求1周
以前端应用为•发布操作时长:半小时以内
•发布后线上遗留问题平均值:1~2个
试点正式启动•0 线上故障
第二阶段:新•发布频率:,后端 1次/周
•发布时长:前端 1 小时,后端10分钟
增2个应用加入•发布后线上遗留问题:前端 2个,后端无
•0 线上故障
试点•前端页面自动化工具尚在开发中
•后端应用正在改造加速阶段,预计改造完成后发布频率
第三阶段:又可以达到每周至少3次
增加2个应用
Agenda
极限编程实践(XPP)
如何持续快速交付高质量产品
Q&A
如何持续快速交付高质量产品
如何更快的交付(效率)
如何更好的交付(质量)
如何更快的交付——需求管理
小步快跑
需求一
需求二版本一发布一
需求三
注:将需求拆分为小的端到端可测试的用户故事,一个需求必须
在一次发布中完成。在实现每一需求之前,开发和devops进行充分
沟通,对需求和验收条件达成共识。开发每完成一个用户故事,就
进行测试,并用自动化测试进行覆盖。