研发运营一体化标准解读---开发管理 --- 方炜

北哥

讲师简介

方炜

本文解读下我们敏捷开发管理的标准，涉及到背后的故事会比较多一点，因为我觉得敏捷开发这一块很难说标准，但是我们做了一件非常难的事情。我代表整个敏捷开发管理团队的所有专家对标准进行解读，
先介绍下团队的成员，何勉中国最牛的精益专家。林伟丹原先是做金融的，出来做敏捷、做DevOps这块，成为独立的咨询师，能从企业很安定的地方出来做是很厉害的。李海传是浙江移动团队资深架构师。申健全中国唯一一个CTC。徐毅原先是IBM的首席咨询架构师。

我有三个身份，第一个身份我是敏捷开发组的代表，第二个身份我是唯一两个被评的企业，第三个身份在所有的开发组里面，组长唯一一个来自传统企业，我代表传统企业的人，如何看待标准。这三个身份其中背景企业和产生企业是能代表很大一部分的。

1. 标准总体介绍

作为被评单位我们做的最好的是环境管理，做运维是做质量的，找到自己最大的差距，这是最大的事情。我做的最好是环境管理，其实不是持续交付，我是开发出身，是浙江移动的产品经理，后来才到运维团队去的。关于环境管理我碰到一个巨大的事情，当时我在做开发的时候，商品系统测试环境没起来，影响到客户各个开发团队，导致我的交付就慢了。为了我的交付，为了企业业务价值，环境管理测试环境要7x24小时跟生产一样，因此我们把环境管理做上去了。持续交付是提高企业整个价值和敏捷度。我们最后使用容器做到了最高，就是我们第三个标准里面提到的要利用架构。整个标准不能只看某一个点，而是整个标准带来的整体价值。

传统企业如何使用标准，我们每个月都测评，而且成立了ETC企业转型组织，我们拿测评，看自己差异在哪里，然后再去解决它，同时改进回顾用的也是标准。

我经常会碰到一个问题，很多专家建议把最佳实践写进去，有的时候最佳实践不一定每个企业都一样。在实践的过程中，我希望每个企业都跟我们一样有个实践表。

敏捷开发在整个标准里我认为是最重要的，这很凸显业务价值的，做DevOps最重要就是实现企业业务价值，帮企业赚钱，敏捷开发很多在讲价值如价值交付、价值流，所有信息都围绕着价值。像刚才所说环境管理一样，把环境管理做到最高，就是为了价值交付，不能让业务停下来，这才是关键。所以我把整个标准做成“两实践三支撑”，敏捷开发属于管理实践，持续交付技术运营做成工程实践。三个支撑是我们的应用架构的支撑，安全的支撑和组织架构的支撑。

这是我们写的第一稿，也是浙江移动原来的那一稿，实际上有问题的。我们把中间过程一个一个拆出来，跟CMI基本上没差别，是科学化管理，但是并没有突出敏捷，还是针对一个个过程进行管理。

这是第二稿，我们要关注交付，关注协作，这是DevOps，要打破部门墙，要去协作。实际上还是有问题的，还是并没有突出敏捷真正的精髓。敏捷真正的是价值驱动，协作不是关键，如果一个团队足够想协作，自然而然就会来，要突出的是价值。

这是第三稿完全突出价值，包含了价值交付。我们把需求过程中的所有事物全部写到需求工件里，在做需求活动时发现并不是真的是需求活动。DevOps讲三部工作法，更多的是反馈，在需求活动里面更多是反馈，而不是真正的需求分析。

在敏捷过程管理里，价值流能体现整个敏捷交付价值驱动。还有仪式活动我认为很多时候就是仪式不是说会议。

敏捷组织模式原先没有，但是我们发现协作不是关键，而是组织变革才是关键。

DevOps标准分为五个等级，在敏捷开发管理这一部分，我们对五个等级又更加详细的做了一些阐述，认为在第一级相当于会有一些改变，有一些萌芽。第二级会发现敏捷在讲守破离，传统企业做敏捷的时候，最大问题是如何开展起来。在第三级有一些价值流的产品，但是还不够全面。到了第四级的时候，希望能够从产品创意到产品运营整个价值流的视角，横向和纵向都能够看待这个问题，并且深度的实践。第五级的时候希望这个实践能够根深蒂固，带来组织的变革，持续的改进，源于敏捷而高于敏捷。

2. 开发管理分册内容解读

需求工件分为四个方面：

• 需求内容与形式
• 需求测试用例编写
• 需求测试用例验证
• 需求测试用例管理

需求内容和编写的测试用例其实也是一种反馈，在这个过程中，反馈用户的故事更多些。《实例化需求》这本书就是希望写实例化，是一个代码，这个才是真正更加往前走的过程。在需求工件会写需求于用户故事是最佳实践之一。第三级要求用户故事必须符合INVEST标准。第四级就是实例化需求，测试为先。第五级就是希望了。

在过程中能够互相协作和团队内外的验证，能多角色共同细化我们的用户故事，而不是各自为政出现割裂。希望在规模敏捷的时候能形成符合DEEP原则的产品列表，做到有价值驱动需求活动。第四级会有价值驱动需求活动，能够让需求更加贴近用户价值。卓越级希望我们的所有的需求能够和企业的目标对齐，这是非常重要的。IT部门做敏捷做DevOps最大问题在于自娱自乐并没有给整个企业带来变化和价值，这与DevOps目标是不符合的。如果仅仅围绕的是提高效率提高质量这是错误的观点，我们的目标要跟企业目标相一致，帮企业赚钱。

在过程中我们要突出业务价值，突出最终用户的体验。在基础级要跟用户体验相挂钩，有指标和业务价值评估标准，交付节奏也要足够稳定，当然稳定不是关键，这里的稳定是相对的，做敏捷就是要能适应变化能力。在卓越级的时候要求提升需求和加强敏捷活动，不停的去改进适应变化能力。

仪式活动是一些会议和设计我们团队能够参入。要有各角色价值的对齐活动，同时建立特性团队，减少变更带来影响的活动，把外部的沟通变成内部沟通。同时在卓越级的时变革组织，按需交付。

在协作的时候有很多角色，敏捷只有三种角色一个开发，一个产品经理，一个敏捷教练，在基础级和全面级，敏捷教练作用非常大。往后就弱化了敏捷教练角色，各个成员敏捷能力趋于同质化了。

团队结构不是只强调协作而是分层DevOps的协作，一个团队两个人干的活超过了其他企业十个人干的活，才是最牛的。在第三级要求大家要有特性团队，跨团队的产品经理，跨团队能力和自组织能力。那么多会议最重要的是回顾会，回顾就是改进。实践的好不好，其实看你维护的好不好。

在标准里面不会讲最佳实践，但是我们希望后面研究一些实践的案例。上面这幅图是公认的最佳实践，大家可以去下载研究，上面有解释，这个实践可以跟企业价值连在一起。