周欣汶、罗海铭
杭州海康威视数字技术股份有限公司 浙江省杭州市 310000
阳光灿烂之时，没有人会想要“革命”
在团队和项目伊始，所有人都会习惯性地参照过往经验，在舒适圈里寻找一个合适的方式。云产品项目诞生的时候，熟悉的瀑布式开发流程顺理成章地成为了首选。
然而上线一个月后，问题接踵而至。分公司和用户反馈已经来了，而下一次发布是4个月后。作为一个新生产品，必须要根据市场反馈不断进行调整和优化。市场如战场，既要按时发布满足市场，又要不断落地来自市场的反馈。承诺市场的时间不能更改，项目中的变更却越来越多。
如何让大象起舞？惟有敏捷。
6个月到1个月，每月一版的“假敏捷”
当敏捷转型活动轰轰烈烈要展开时，叶工好龙似的矛盾情绪弥漫了整个团队。
经历了多次的假设、猜想、推演后，我们放弃了纸上谈兵，选择在战争中学习战争。根据市场的反馈，我们定下来“两个月一个大版本，每个月一个维护版本，月月都有发布”的产品发布目标。无论是“真敏捷”还是“假敏捷”，能符合市场需求的敏捷，就是好敏捷。在不断敏捷的过程中，完善技术、项目管理、质量管理能力。
项目流程调整
为了顺利迈出第一步，首先做的就是缩小需求范围，将原来6个月的项目范围进行精简至适合1-2个月开发的范围大小。然而，仅仅是需求的减少并不能满足大家的期望，研发效能的提升才是有意义的变革。
当敏捷转型被提出后，端到端的看每个工作组协作过程，竖井效应（各个环节和部门繁忙而“高效”，但总体效率和响应速度却很低）出现在我们眼前。
研发和测试团队都跟随着项目安排有明显周期性的忙碌和空闲。忙碌时，研发和测试都需要通过加班才能满足项目进度，而等待时间却不能充分地利用起来。
为了解决这个问题，我们采取项目并行的模式，在上一个版本实现阶段，产品经理就开始导入新的需求。很好的缓解了上述的等待问题，研发和测试都能持续保持稳定的状态。
同时，为了保证研发不处于特别忙碌的状态，有意识地减少了单个项目中的需求量。根据实际的项目执行结果来看，由于整体团队资源安排更合理，需求的吞吐量达到原来的1.5倍。项目发布版本数量也显著增长。
然而，工作并行同样带来了新的问题，在后续的章节会提到。
质量保证
从原来4-6个月的大瀑布模式切换到1-2个月小瀑布后，项目的快节奏也带来了质量上的挑战。
由于项目并行，在上一个项目的测试验证阶段，研发就已经开始了下个项目设计。如果前一个项目开发质量不高，研发就需要在这个阶段投入大量的精力修复缺陷，这个时候下一个版本的设计时间就无形中被压缩了，那么下一个版本的开发质量也会因此受到影响，恶性循环就开始了。
.png)
图1 并行项目中的质量问题
同时，观察缺陷情况，也能发现端倪。在传统的瀑布式模式下，缺陷在项目后期才被集中检出和修复。如下图所示，缺陷在项目后期被集中检出并修复，项目后期仍然需要投入大量人力进行修复，且发布时经常伴随着遗留缺陷。
.png)
图2 瀑布模式下的缺陷检出状态
问题发现越早，修复成本越低。我们在实现阶段引入了迭代测试概念，开发过程中测试团队提前介入，分模块进行测试，提前检出缺陷，保证开发质量。新的缺陷检出趋势如图所示。
.png)
图3 增加迭代测试后的缺陷检出状态
在实践中，取得了良好的质量效果。此举措也为后来迈向scrum、迈向持续集成奠定了基础。
3-2-1的突破，敏捷不再是叶公好龙
在“假敏捷”取得一定进展之时，新的scrum落地方案已经拟好，真正的敏捷已经箭在弦上，只待正中靶心。我们的目标是3-2-1，3周内70%需求交付，2周发布频率，1个小时发布前置时间。
?需求阶段
需求导入实行最小可交付的原则，加快需求交付速度。对产品经理和需求负责人赋能。敏捷团队周期短，需要将需求分解成一个个小的可用的需求，才能够快速迭代开发。
进行系统服务拆分，降低快速迭代成本。当我们的服务端耦合程度非常高时，经常“牵一发动全身”，使快速迭代变得很困难。对微服务进行拆分后，就可以准确的评估每个需求的影响范围。敏捷小团队的质量保证、测试准确性都得到了提升。
将UED设计纳入需求方案的一部分，减少后续流程误解，提高需求准确性。通过建立需求池、梳理需求优先级等一系列举措，使UED团队与敏捷小团队的协作紧密而通畅。
执行阶段
.png)
图4 敏捷团队组成
打破部门壁垒，研发测试点对点沟通，提高过程效率，打破竖井效应。
敏捷团队内部，减少流程和工具，增强个体和互动，实现快速迭代。一个团队5-8个人，声音所达之处，信息就可以被传达。
发布阶段
做过云项目的人都知道，哪怕是瀑布式项目模式，也会常常伴随紧急需求、线上缺陷的发布，整体发布频率明显高于非云项目。发布前置时间（也称为变更前置时间，是指最后一行代码提交后到功能上线花费的时间，它体现了团队发布的基本能力）就成了发布频率提升的前置条件。
通过对接公司云组件统一交付平台，提高打包部署效率，极大的缩减了发布前置时间。
自动化测试
根据scrum要求，每个冲刺发布前都需要做全量的回归验证。如果回归验证都通过手工测试，效率较低，通过引入自动化测试代替手工的回归测试则很好的解决上述问题，既提高测试效率，又能保证测试的可靠性，避免因为人为因素导致的测试结果不准确。
首先是接口测试，接口测试用例的编写由研发团队内部的测试人员进行，使用python脚本基于unittest框架进行开发。
在瀑布式项目中，一般测试人员会在接口文档输出后的一周开始编写用例，并直接用于集成测试、冒烟测试中。在scrum试点中，接口测试用例则可以达到和服务端开发同步输出的效果。
接口测试后，又引申出了场景自动化测试，即通过接口组合模拟用户使用场景，来进行自动化测试。测试的场景由研发内部测试人员和系统测试人员共同制定，会覆盖如设备添加、巡检等基础场景。
与此同时，在线上环境，通过调整接口测试的触发频率和间隔，达到了拨测效果，可以实时监控线上微服务链路状态。
团队组成
大部队进行瀑布式开发，同时抽调人员组成小分队（一般为6个人），进行敏捷开发的模式。小分队的数量、周期取决于当前市场需求的情况，进行动态分配调整。
适合瀑布式的需求，往往无法简单地拆解为一个个小的特性包，而营销类需求、小定制需求、市场经济需求等，就非常适合敏捷模式。该类需求往往变化快、有非常明确的市场交付时间，敏捷模式的小步快跑、拥抱变化则正中其下怀。
此外，为了解决每次选拔出来的scrum小分队成员能力良莠不齐的问题，在各个scrum团队外，我们同样形成了多个看护团队，为整体的项目活动保驾护航。
.png)
图5 看护团队
测试保障团队（TC）：由测试代表、测试组长、SE组成，用于保证产品测试质量，对每个团队的测试方案、用例、测试结果进行审核评估。
模块看护团队：由研发主管、研发工作组长、SE组成，用于识别依赖关系，把控模块质量，进行总体设计，对每个团队的概要设计、代码进行审核，在团队出现技术困难时给予帮助。
Scrum Master：由开发代表兼任，用于营造敏捷文化，推进敏捷落地，分享优秀的敏捷实践，对每个初创的敏捷团队进行指导，参加冲刺计划会、冲刺回顾会等。
援军已至，未来已来
在敏捷转型的时间里，我们经历了如无头苍蝇一般的乱转，经历了连敏捷项目管理软件都没有，经历了熬夜手动部署，慢慢的，越来越多的资源和力量加入到了这场由一个小小项目引发的变革当中，在各方推力的帮助下，我们一定能敏捷地走向远方。
参考文献
【1】何勉，《阿里如何定义团队的研发效能？》，https://developer.aliyun.com/article/689242
【2】杨学明，《IPD体系向敏捷开发模式转型实施成功的四个关键因素》，https://www.cnblogs.com/mikeyond/p/9110300.html
【3】林琳，《大象起舞正当时：中国银行业踏上敏捷转型之路》，https://www.mckinsey.com.cn/%E5%A4%A7%E8%B1%A1%E8%B5%B7%E8%88%9E%E6%AD%A3%E5%BD%93%E6%97%B6%EF%BC%9A%E4%B8%AD%E5%9B%BD%E9%93%B6%E8%A1%8C%E4%B8%9A%E8%B8%8F%E4%B8%8A%E6%95%8F%E6%8D%B7%E8%BD%AC%E5%9E%8B%E4%B9%8B%E8%B7%AF/