2018.07.20 丨 壹佰案例
DevOps平台的“精益创业”之路
2018.07.20 丨 壹佰案例
本文内容节选自第六届全球软件案例研究峰会，时任中国移动通信集团浙江有限公司罗琼老师，申健老师分享的《DevOps平台的“精益创业”之路》实录，重点分享：DevOps产品研发过程，对外实施敏捷DevOps研发管理的推广实践经验（PPT+文稿）。
罗琼，时任中国移动通讯集团浙江有限公司，DevOps工具链产品经理，致力于敏捷DevOps转型和DevOps平台建设以及推广工作。
申健，自2007开始实战敏捷产品研发方法，在工程技术实践、团队管理、领导力、组织转型方面都有自己的经验和研究。是国际Scrum联盟国内唯一的最高级CST认证讲师，也是国内各敏捷社区活跃分子。
编者按：2017年11月9-12日，第六届全球软件案例研究峰会在北京国家会议中心盛大开幕，现场解读2017年「壹佰案例榜单」。移动通信集团浙江有限公司《DevOps平台的“精益创业”之路》。
【内容简介】本案例围绕浙江移动在DevOps平台建设上的敏捷开发实践，根据精益创业的原则“用最低成本交付最高价值”，用敏捷的方法做敏捷的DevOps产品开发。适用于建立以用户体验为中心的混合云平台。
1
敏捷交付云：ADCloud
浙江移动从2014年开始推行敏捷，希望能够探索出从传统的开发模式到以价值交付的开发模式的转型。
下图是我们首创的DevOps实施框架，囊括了浙江移动从产品、开发到实施的各个过程。并以此建立了我们的管理平台ADCloud。
ADCloud实现了从代码编写开始到自动构建的过程，通过自动化的方式能够自动测试，交付上线。能够提供多种一键的能力，包括一键的部署，一键的回滚能力，以此来缩短产品研发周期。
2017年，此产品和云管理平台进行对接，在对接过程中以应用开发为中心，实现了从资源申请到代码、构建、部署和交付整个生命周期全管理一站式的服务。
接下来，将介绍此平台开发过程中的一些经验。
2
发现问题与准备
最初研发团队参考市场上的DevOps产品功能来实现我们的产品，结果得到的是一个大而全的平台系统。入手就做大门户，但功能上没有太大亮点。不能解决客户实际痛点，且反馈周期太长。
出现这些问题的主要原因在于：
1.开发人员做开发的时候，不了解ADCloud平台是为了做什么，实现什么目标，不清楚用户使用场景。
2.我们的用户群体，他们不同于互联网用户天生具有敏捷或者DevOps的“基因”。
我们认为产品应更加贴近用户需求。产品的目标理应是实现价值最大化，不应只顾做大而全的产品，而要做更多有亮点的东西。
众所周知，缩短反馈周期和不断迭代是敏捷的特点，而DevOps也是敏捷的一种延伸。我们也计划用敏捷的方式打造一个敏捷的产品，然后投给用户使用。
实施敏捷DevOps应从更繁杂的组织和团队中找到突破点，系统思考，放弃任何对“完美”方案的幻想。把时间更多的花费在“高附加值”的事物上，集中精力不遗余力的解决痛点，以此辐射找到适合团队发展的敏捷DevOps之路。
3
实施过程
1.组建高效实施Scrum团队
首先敏捷的实施是需要管理者的支持才能继续推行的。
我们从外部引进了新的具有权威性的教练来全程辅导，帮助我们解决问题。
并且重组了我们的管理架构以避免不能持续交付的问题：我们开发和产品经理要融合，既要了解客户的需求也要知道团队可以做到什么。
其次要让大家习惯新的工作模式，并且养成这种工作习惯。
2.约定，高效的组织日常
在开始的实施过程中，我们的站会经常因为某些人临时有事而一再推迟。并且会议效果也不理想。
于是我们针对这些问题，在团队内部约定了两条规则：一是团队约定是第一优先级，二是团队协作是第一优先级。
3.建立透明化，拉动式的研发过程
通过引入看板以用户故事来管理我们的需求。我们的完成定义是故事结束，故事结束则来自于故事中的每个任务完成。
随着项目成员增多，我们会进行团队分组，并且每次迭代不会同时做超过两件的事情。
看板的另一个好处在于团队成员都有机会看到问题，并和相应人员沟通改进。
1.影响地图，更好地关注产品价值
借助敏捷的影响地图，从目标以及涉及相关角色出发，观察他们在做什么，来判断核心用户在哪里。
最终通过整理，可以看到核心用户以开发，测试以及管理者居多。
通过和每个角色进行沟通访谈，询问在实际工作中的问题，例如大部分人提到的环境稳定问题。
如果我们的平台能够解决此问题，我们会将其列入到规划中。
2.信息架构，更好地用户体验
通过信息架构设计，能让我们更好地梳理信息并合理的呈现出来，提供给用户更好的体验。
3.用户故事地图，端到端的需求管理
用户故事地图能让我们看到需求的全景，它将所有用户信息整理出来再归类，之后按照影响地图我们可以确定其优先级，并以此作为迭代的输入，生成迭代的用户故事。
用户故事地图的好处在于可以为我们后续的开发和迭代做可扩展性设计做准备。
4.探索与改进，不断尝试和试错的迭代过程
更多的观察用户行为：例如在开发过程中我们发现，产品的部分按键放置位置与多数用户实际习惯不符，在改进之后，可以发现用户访问量会有所上升。
鼓励用户发现产品BUG。
用户体验“紫外线”：减少不必要设计或者改为可隐藏的。
1.解决开发任务燃尽之痛
在迭代刚开始的几天，开发总是不能及时完成任务。于是我们考虑将准备期提前到上一个迭代，及时拆分用户故事，准备预习看板，降低用户故事变更。
2.解决测试任务燃尽之痛
下图是一个业务团队的迭代图，蓝色是开发任务完成率，红色是测试任务完成率。
可以发现其中存在一个问题是开发已经完成，但测试不能立刻工作。
在与开发人员沟通，代码能否做成多分支管理模式过程中，我们得知切换代码分支耗时太长成本太高。
针对这些，我们希望平台能够通过一些辅导功能，来降低切换成本以及学习成本。最后推出的平台兼容GIT，即使不会创建，也可以在平台上一键创建分支，以更细的粒度改进任务，持续交付。
3.解决运维发布复杂场景下系统依赖之痛
运维团队的发布过程更加复杂，里面包括160个以上的应用且内部关系复杂。所以我们设计出固化的发布模板，能够支持从应用级到系统级的发布。
4
效果评价
在我们敏捷DevOps发布后，客户满意提升了15%，用户满意提升了25%，开发能力提升了10%，测试人员减少了1/3。平台最大可支持100人以上同时修改系统，最多可运行700万以上的代码，最大可容纳5个环境的系统。
总结
1.最好的架构和设计师会从团队中涌现出来的。架构想要敏捷，需要持续、频繁的重构我们的代码，甚至是架构。
2.团队人员控制在7-9人比较合适，这是规模化遵循敏捷的基本原则。
3.保证每个同学在他的专业里面能够更深的去进行扩展，同时通过这个形式让他们在业务知识和其他的领域有更多的收获，打造T型的人才。
4.抛弃模仿，关注实际重点问题。
Q&A
Q：请问现在的故事完成是否能发布给用户？
A：用户故事是能交付的，我们会将用户故事拆分成多个任务，包括开发测试还有其他的任务。当所有的任务完成之后，用户故事才完成。所谓的完成定义就是用户可以用，这是它的条件。每次完成之后，在新的迭代开始之前，都会对其进行新的上线。
Q：改进实践中没有提及自动化测试，可以介绍一下相关实践吗？
A：我们团队内部没有专职测试的人员。在之前团队中有测试这个角色在。如果对这个方面不懂，可以向测试人员请教，测试人员有义务把这个告诉他。最初没有测试人员的时候的确会经常出现BUG，但我们后面借助自动化测试工具，去解决它。刚才提到的自动化的测试技术，就是我们正在做的基于RF的UI自动化测试，以及用相关的接口测试。
以上来自罗琼老师和申健老师的分享。
壹佰案例榜单
TOP100summit是科技界一年一度的案例研究峰会，每年甄选有学习价值的100个技术创新/研发管理实践，分享他们在本年度最值得的总结、盘点的实践启示；TOP100summit于2018年12月1-3日在北京国家会议中心举办，与其在别处仰望，不如来这里并肩。
案例来源（部分）：
