我们的敏捷之路——技术转型篇

前言

在上一篇敏捷之路中主要讲述了我们软件开发方法方面的改进历程，有近一年的时间里完成了试点团队由DO Whatever向敏捷开发的迁移。在这一篇文章中讲介绍这个迁移过程背后的技术转型的故事。

背景

核心背景就是我们已经决定采用敏捷的模式来提供我们的软件研发水平。试点团队包括四个人，开发经验平均下来也就一年。
试点项目属于典型的遗留系统，由外协公司开发的信息化管理系统，下文简称UAV系统。该系统采用自研的OSGI架构，外协公司东拼西凑的完成后匆匆交付，没有经过实际测试，实际属于演示的原型系统，开发人员众多加上人员流动大，代码质量惨不忍睹，外协的技术支持也是有心无力。
同时用户作为典型的政府部门，需求非常不稳定，自己也不知道想要什么东西。
就这样我们开始我们的故事。

分析

我们的问题

采用敏捷开发的模式，每两周进行一次迭代，因此我们每两周内就要完成系统优化，测试和部署。这对于设计良好的系统并不难做到，但我们面对的是一个不甚了解的遗留系统，我们提交的系统总是上线后发现存在bug，造成了不良影响。周期短，技术不熟，测试不充分，难以发现问题。
由于敏捷开发对于持续集成和自动化测试还是比较推崇的，我们自然也希望实现系统的持续集成，但我们发现目前jenkins无法解决osgi框架的构建问题。jenkins无法构建，缺乏测试技术

怎么办

1.调研构建技术
2.学习自动化测试技术
3.上线前充分测试

转型过程

惯性阶段

在这个阶段，还是属于过渡时期，通过采取最简单的措施，遏制住线上产品bug率居高不下的问题。为此采取了如下措施：
1.设立专门的测试人员，负责提高产品质量
虽然敏捷方法中比较推崇全员质量并淡化测试与开发人员区别，但结合到我们的实际情况这个目标还是有一些距离，为了最短时间起效最后还是决定设定固定测试热源
2.搭建bugfree
对于发现的bug进行跟踪，由于遗留的bug过多，无法全部实时处理，因此搭建了bug追踪系统，由测试人员进行管理。
3.人工测试确认开发功能
开发人员完成开发后，由测试人员进行功能的确认，确认后才能提交代码，功能开发才算完成。
4.完整的手工验收测试
上线前要进行完整的手工测试。
此外还进行了：
构建框架选型，经过反复查阅资料和论证，确认这个自研的osgi框架没救了，着手进行新框架的调研
单元测试选型，学习单元测试知识。

摸索阶段

在设立了专门的测试人员并执行了严格的测试标准后，产品质量得到明显提升，但开发速度有了不小的下降。同时测试人员工作量巨大，重复工作多，在结束前的验收测试总是加班才能完成，再加上修复发现的 问题，总是存在产品上线推迟的现场，后来将验收测试提前到截至两天前才勉强能赶上迭代结束。因此这个周期我们集中精力来通过自动化测试技术来提高测试人员的效率，提高整个团队的效率。
这个阶段的自动化测试又可以分为两个小阶段
1.引入自动化冒烟测试
由于系统代码量大，局部的单元测试覆盖提升的效果有限，经过研究我们决定先构造一套支撑系统完整业务流程的自动化冒烟测试，测试人员可以轻松在3分钟内的完成任务流程的测试，而之前人工要进行近两个小时的测试。
完全自动化后，由测试人员每天执行，并负责通知开发人员进行修正。
冒烟测试的引入大大提升了测试人员的工作效率，缩短了开发和测试的反馈周期，提供了产品质量。
2.引入selenium自动测试
在完成了冒烟测试后，并完成对核心业务的单元测试覆盖后，我们并没有去完全补充单元测试，相反我们针对测试人员每次迭代结束前的验收测试进行了自动化，即利用selenium实现UI的自动化测试，这样测试人员通过selenium的测试完成了之前验收测试中80%的工作。基本解除了团队测试的瓶颈，当然这个工作给开发人员带来了不小的工作量，但经过权衡和回顾我们认为这是非常值得的。

最后实现了测试人员进行人工复查和探索性测试即可。
截止到目前之前系统的质量问题得到了质的改变，很少出现线上bug的反馈。

在解除了质量报警和测试瓶颈后，我们又反过头来解决项目构建问题。
由于我们通过两个试点项目进行之前没有应用过的技术研究，即项目框架springboot的研究以及maven和hibernate的研究。值得注意的是KSXT项目是公司的小项目，ZZH项目则是我们团队内部进行的验证性项目。经过两个月的时间两个项目均完成了开发，取得了至关重要的实验结果。KSXT试点项目实验maven，hibernate。ZZH试点项目实验springboot。
在两个试点项目中为了解决maven资源库问题，我们在内网搭建了私有库Nexus，从而解决框架迁移的最后一个屏障。
搭建jenkins

正轨阶段

在完成两个试点项目后，我们抛弃osgi的决心已经定下来，这是正好有SC项目上马，新项成了完美的试验场，鱼鱼SC项目成了springboot+maven+junit+hibernate新一代平台的验证项目，由于有了KSXT和ZZH项目的基础，新框架虽然遇到了一些问题但还算是顺利的搭建完成了。

在我们搭建新平台时，测试人员也顺理成章的搭建了jenkins，SC项目成为了jenkin是的第一个常驻项目。
jenkins在成功运转后将我们的问题发现时间大幅降低，进一步提升了开发效率和产品质量。

同时由于在生产，测试，开发环境的不一致问题，让产品的部署非常困难，从而激发了学习docker技术，来将jenkins的持续集成提升为持续部署。

成熟阶段

随着测试覆盖度的提升，测试的复杂度也越来越高，于是通过向junit补充mock技术来降低编写测试的困难和工作量。

同时为了提高代码的质量，引入了sonar作为代码质量评价工作，开始是通过sonar-runner客户端手动进行，后来完成了jenkins对sonar的整合，持续集成系统如虎添翼，代码质量得到了有效改善。

同时新项目ZHJK项目上马，经过SC项目的锤炼新平台在兼容性稳定性上得到了大幅提升，同时与docker结合为平台的微服务化提供了技术基础。

在这个周期为了提升团队的交流效率，搭建了wiki系统，进行培训和技术分享以及项目资粮的管理。

还远没有结束

改进之路永远没有尽头，下面是我们正在进行的改进：

1.引入TDD提高核心代码测试覆盖率
2.引入BDD，jenkins整合fitenesse
3.jenkins对接docker，目标CD
4.前端的大规模重构，组件化

关键词

分析
分析当前状况是解决问题的第一步也是最重要的过程，我们针对我们的实际项目情况和团队技术水平，制订了相应的策略。
改进
自组织和追求卓越的团队文化，是改进的基础，同时改进措施要符合实际情况，不能心急，小步快跑，持续优化是改进的方向。

总结

技术不是目的而是手段
一切都离不开应用场景