农行基于TFS工具的敏捷转型实践

2018-04-27   出处:DevOps  作/译者:孙健、王晓敏  

“春天工程”项目组是应用开发二部最早采用敏捷模式的项目组,项目组在项目推进过程中使用Scrum框架,结合“看板+站会”形式,积极探索项目推进新措施。结合TFS工具逐步实现了电子工具与物理看板的有机融合,并在过程管理、版本管理、交付质量三大方面取得了突破。


物理看板作为“春天工程”项目组日常管理的核心工具,实现了从“影响地图”出发的需求研制与分析,利用“用户故事地图”将需求拆分成用户故事及任务,以两周一迭代的频度交付产品。


截至目前,项目组已完成15轮迭代。“春天工程”团队依据自身特点,逐步摸索形成更加合理的团队组织结构,并明确了Scrum 主管、产品负责人(PO)、产品设计负责人、开发团队负责人(TL)等角色的职责定义。


敏捷宣言中有这样一句话:“个体和互动高于流程和工具”。物理看板有助于团队的互动和协作,有助于褒优贬劣,营造竞争氛围。将物理看板置于工作区内,所有人高度可见,以清晰把控和推进工作进度。尤其在试点初期,项目组基于项目具体情况,对看板系统作出变化调整。项目组在敏捷试点中深刻体会到物理看板的强大优势。


为进一步节约人力成本,沉淀历史数据,项目组不断摸索,结合TFS工具提供的强大功能,逐步实现了电子工具与物理看板的有机融合,在工作项、拉入请求、部署工作流等方面持续研究实践,最终通过七项措施,在过程管理、版本管理、交付质量三大方面取得了新的突破。


成果一:TFS工作项与物理看板相结合,使过程管理变得更加容易


物理看板具有易于实施、直观灵活、沟通快捷等特点,但也存在一些不便:


1.从物理看板上无法清晰看到用户故事与实施任务的层级对应关系2.已完成的需求和故事归档后,在需要复盘时查找起来比较费时3.过程数据的收集比较困难,需要人工整理便签并手动归档4.每轮迭代交付版本时,代码与故事的对应关系不够清晰


为了改进上述问题,充分发挥物理看板的优势,项目组启用了TFS工作项来管理需求和用户故事,在需求、用户故事和代码间建立了清晰的关联,过程数据的收集也变得更加容易。


措施一:通过TFS工作项管理需求和用户故事


使用TFS工作项管理需求和用户故事后,在积压工作中,可以清晰的展现需求与故事的对应关系。通过累积流图,可以清晰的统计出需求与故事的交付情况,便于及时发现问题,精准把控迭代进度。

每日站会时,PO会根据物理看板上需求和故事的完成情况,拖动电子看板上对应工作项,及时更新工作项状态。PO只需在TFS中建立简单的查询,迭代评审回顾会时便可及时统计出迭代故事的完成情况,无需再进行人工统计。

需要对用户故事复盘时,可以直接按迭代序号,查找出要复盘的需求和故事,操作简单、且清晰明了。


措施二:通过TFS工作项实现代码关联


通过TFS工作项维护需求和用户故事以后,开发人员只需输入工作项ID选择关联工作项,便可实现用户故事和代码的关联。在构建程序版本进行分支合并时,也能够清晰地知道本次提交的代码实现了哪些需求及用户故事。

成果二:使用代码库和拉取请求,让版本管理变的清晰有效


项目组前期使用git库进行代码管理,遇到以下瓶颈:


1.因项目包含的模块众多,开发过程中测试版本的匹配相对模糊 2.多人开发的情况下,缺乏便捷的代码评审机制,评审后难以追溯代码的修改情况


为了解决上述瓶颈,项目组做了以下实践。


措施三:通过代码库拆分,实现代码隔离


项目组按模块对代码库进行了拆分,将原来的一个git库拆分为17个独立的git库,实现了不同模块代码的隔离,便于各模块独立更新代码,易于版本匹配。同时,基于Master分支分离出测试分支,实现开发、测试、投产代码的全隔离。


措施四:设置TFS分支策略,保证代码评审简单有效


项目组在dev与rel,rel与Master分支间分别设置TFS拉取请求,在迭代中使用拉取请求的diff功能进行代码评审。代码经过评审并完成集成测试后合并至rel测试分支,进而完成部署版本的构建。


以dev分支为例,当开发人员提交本地代码至dev分支时,在拉入请求中可以清晰的看到上次合并以来所有的分支提交情况。同时,拉取请求还为代码评审工作提供了清晰的对比界面,在界面中评审人员可以直接在代码中添加评审意见,并设置意见的状态。代码的作者或其他评审人员可以直接对意见进行回复。程序作者可以根据实际情况把评审问题的状态置为“已解决”、“不是问题”、“已关闭”等。


结合TFS分支策略,强制要求代码经过评审且审阅者批准后才能完成拉取请求,进行分支合并操作,保证了代码的质量。

措施五:建立BUG分支,通过拉取请求实现问题修复


在测试过程中遇到问题时,项目组会基于测试分支(rel分支)新建一个BUG分支,BUG修复完成后提交至测试分支时创建一个拉取请求,通过拉取请求将修复后的代码提交至REL分支。代码归并至rel分支后,通过diff将完成修复的代码回退至dev分支,保证各环境代码版本的准确无误。


成果三:利用TFS部署工作流,提高交付质量和频率


在部署过程中,项目组陆续发现了以下不便:

1、开发、测试和投产代码构建缺乏隔离机制,可能会将开发中未经测试的代码带入生成分支;


2、项目组前期采用的是IDE手动构建WAR包,部署三个模块耗时较多,影响项目组的开发效率。


措施六:先隔离再归并,持续集成,实现部署过程自动化


为优化部署流程,项目各模块在自己的git库中通过拉取请求将迭代完成的代码匹配成正确的版本,归并至rel分支,同时触发自动构建和自动部署,持续集成,保证了发布版本的正确性。部署过程自动化,释放了人力成本,保证了版本正确,提高了部署效率。

措施七:利用仪表盘功能,便于查看每日构建及部署完成情况


项目组rel分支自动构建和部署的基础上,对dev分支配置了每日构建和部署,并在项目首页添加了构建情况一览,可以清晰的看到每日构建的完成情况。


总结


通过上述七项措施,春天工程项目组实现了需求和用户故事的的电子化跟踪,结合物理看板的使用,项目进度有了清晰的把控,度量数据的收集变得更加容易。通过代码库的拆分、需求及故事同代码的关联、TFS拉取请求及分支策略的运用,项目组建立了代码版本管理机制。通过自动构建及部署流水线的运用,提高了团队的持续集成和交付能力。


项目管理办公室与应用开发二部密切协作,持续深化产品经理思维,努力实现任务驱动型团队向自组织团队转变。目前应用开发二部敏捷试点项目已推广至8个,每个项目根据自身特点,增加电子看板试点,结合影响地图、用户故事地图、TFS、AXURE等一系列方法和工具,不断探索改进,团队分工更加明确,组织结构更加合理,研发效率稳步提升。


我们将会继续探索实践,坚持总结分享,希望所有试点团队能够少走弯路,尽快找到适合自己的敏捷模式。



欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
166°|1663 人阅读|0 条评论

登录 后发表评论