主讲人：姚冬，华为云DevCloud首席技术布道师；资深DevOps与精益/敏捷专家、软件工程专家；中国DevOps社区核心组织者；中国DevOpsDays大会核心组织者。

问答一：

八戒：在企业的DevOps转型当中，一般都会伴随组织机构和业务的重组，在这个重组的过程中，传统的瀑布项目走出来的项目经理要如何重新定位自己，才能更好的帮助自己适应这种变化？

姚冬老师：核心一点就是传统的项目经理更多的是项目的思维，实际上我们更应该转变到产品的思维。这里有几个方面，第一，项目的思维是典型的甲乙方签一个工作说明书，每一期做的事情都是相对比较固定的，我们会跟甲方有一个谈判的过程，这是一种交付的方式，等到项目完成以后，这一批人就会分散到下一个项目当中去。而产品思维的团队相对比较固定，由于团队本身内部的磨合，人员之间的相互信任，包括沟通协作的方式，其实是非常难得的，那就至少需要三个迭代以上的时间来做这样的磨合，然后把整个团队的速率稳定下来，也就是说首先团队是一个长期存在的团队；其次，做的事情也是长期存在的，产品思维中，整个产品的生命周期，即这个产品的生老病死，从这个产品的初期一直到开发、上线、上线以后的版本更新升级，以及上线以后的相关运营，其实是非常重要的，所以第二点就是产品的整个生命周期是要完全参与并全权负责的；第三就是需要有产品的思维或者业务的视角，例如以商业模式画布的9个维度来看，整个过程里需要考虑市场的竞争是什么，目前的定位是什么，自己的优势、劣势是什么，能够利用的渠道是什么，整个的价格策略等等。所以传统的项目经理需要往产品思维方向去转型，最后一点就是需要有服务的意识。

八戒：如果在敏捷转型或者说在DevOps转型当中，PM（Project Manager，项目经理）必须要转成PO（Product Owner，产品或业务负责人）或者是BA（Business Analyst，业务需求分析师）或者是SM（Scrum Master，敏捷专家）的话，您建议PM向哪一个方向转型？

姚冬老师：其实跟个人的职业发展路径或者兴趣爱好是相关的。这里有很多可能性，比如说PM向PO这个方向转型，其实有两种类型的PO，一种是偏业务的，他可能会到前端一些或市场侧的位置跟客户沟通等等，实际上是业务和产品之间的一个桥梁，也有可能这个PO会变成一个产品经理，需要考虑在实现层面上哪些是共性诉求，怎样将它们进行产品化，并且把整个产品的规划做出来，所以更多是产品和实现或者跟技术之间的一种角色。可能还会有另外一种角色，就是会变成一个Scrum Master，这可能也是我们比较常见的一种类型，当你做了Scrum Master之后可能又会由单团队的Scrum Master逐渐变成多团队的，然后逐渐变成培养Scrum Master的角色，就变成一个教练，甚至是变成一个独立的咨询顾问，去对外做传播。也有可能这个PM的技术能力非常强，他有可能会变成一个架构师，也有可能他会去做一些协调类的工作或者做一些管理类的事情，那么他可能之后就走管理的路径了，所以这些路径都是有可能的。

问答二：

大理段誉：现在我们想实施敏捷开发模式，我们讲究的敏捷开发就是小版本迭代、持续交付，我需要一个月开发出一些模块，然后上线，之后进行客户培训，再进行用户测试，但客户表示由于时间关系无法每个月进行一次培训，这个问题该怎么解决？

姚冬老师：其实敏捷是说我们要保持跟客户的沟通，并不是说做每个迭代都要发布出来，未必是每个迭代都需要上线到生产环境的。我们依然可以按照客户的节奏去做发版计划，这个发版计划可以是一个月或者三个月等等，但是在这期间需要有一些小的迭代交付，然后去找客户的干系人或者客户代表，跟他保持沟通，比如说两周一个迭代，做出来一些东西可以演示，然后跟他去沟通，去澄清自己做的是不是客户想要的东西，是不是高优先级的东西，如果他认可就接着进行下一个迭代，如果有问题就及时做调整。真正的迭代完成以后实际上被叫做“潜在可发布版本”，所以真正在发版之前还是会有很多工作要做，比如培训的事情，跟客户的工作交接，还有帮助文档、培训文档等文档补齐的事情，所以在真正发版之前会有一个短的迭代去做这些事情。

大理段誉：在需求可能会变化的情况下，如果和客户签固定期限的合同，限期上线，跟实行敏捷是否没有太多关系，就只是在自己内部实施敏捷开发就行了？

姚冬老师：需求变化就是一个最大的问题，首先客户的需求是模糊的，其次即使是签了合同，甲方依然可以在过程中发生调整，所以需要保持跟甲方频繁地面对面沟通，不断做一些小版本的发布或迭代，然后跟甲方做澄清。

问答三：

sujuan feng：我们公司的敏捷的推行过程跟一般流程不一样，正常来说从上到下推行是比较顺畅的，但是我们目前是从中间层推行敏捷过程。经过一年多时间，大家的工作习惯、生产效能、内件质量确实有提高，但是目前我们想和项目发起人进行沟通，实际上我们在统计数据的时候发现数据并不好看，公司内部的项目发起人可能是一个高层领导的角色，他对敏捷不会特别了解，也不会给我们太多时间去讲解中间的过程，在这种情况下，定期汇报，我们如何给他呈现出实行敏捷之后的一些效果？

姚冬老师：首先这里面肯定是有问题的，在发起的时候，一开始是可以自下而上或者先做一些小的尝试，见到一些效果，及时地跟决策层进行沟通，便于把敏捷试点的事情在更大的范围做推广，一定要有这样的意识。如果跟上层领导沟通比较顺畅，更好的一种方式是在一开始就去了解上层领导关注的点在什么地方，然后根据他的诉求去拆解落地到实践中能够展现出来的一些数据或度量，如果一开始没有做这件事情，也需要在中期开始做这件事。

sujuan feng：我的思路是先跟高层领导做一个非正式交谈，看干系人的期望到底是什么，但是目前领导要求一个正式的沟通过程，给作为事业部领导的项目发起人做汇报，该如何进行呢？

姚冬老师：如果现在不了解领导的诉求，这个过程其实类似挖掘客户需求的过程。如果把这个过程作为一个敏捷开发的案例，可以先做一两个迭代，跟领导做非正式沟通，用例如缺陷率、需求变更率、人员速率等数据和度量的变化把效果呈现出来，之后可能会发现研发的结果和业务的指标诉求不相符，就要考虑调整，这是一个逐渐匹配的过程。所以这个过程实际上就是一个大的瀑布模型，这个过程对于项目发起人来说也是一个黑盒子，就需要把这个过程重新做一遍。如果已经要做汇报，可以收集现有数据，例如管理类和工程类数据，重点寻求与业务匹配的数据，寻找亮点。如果目前的敏捷仅在开发团队实施，没有纳入业务团队，后期就要考虑纳入业务部门，及时了解业务指标的反馈。

问答四：

王重阳：我们公司是做房屋租赁业务的，一般项目周期为一个月，在公司里，领导也有这个意识，觉得敏捷应该去做，但是一直没有进行。如果一下子拿出一个大的框架，团队可能会畏难，如果仅在开发内部实施，意义又不大。现在我想要聚集一批核心层的领导来讲解我们目前能够用敏捷做什么，我该如何准备材料？

姚冬老师：可以找一些同行业或相近行业的案例来讲解，甚至是把一些相关行业的榜样请过来跟领导做沟通。如果项目周期较短，在做完两周的迭代之后要交付上线，对内部或外部客户进行开放，由于业务诉求的重要性，就要把内部或外部的客户代表拉入整体闭环当中。另外要考虑清楚为什么要做敏捷这件事，要用敏捷达到什么目的，这个目的如何与领导的诉求进行关联，实际上应当由领导的诉求拆解得到应该做的敏捷实践，再去看这些实践的采纳路径是什么，先做短期并且能够快速见效的事，便于快速与领导汇报沟通，从而让领导认可这件事并支持自己继续向前走。

王重阳：测试这个环节并非需要专业团队来进行，开发和测试需要分开，但在我们公司里，又往往是开发结束了，测试才接入，这个过程中开发就需要等待，所以我尝试过几次让开发人员互相测试，但没有形成一个规范，该怎么解决人员效率浪费的这个问题？

姚冬老师：涉及到角色调整或组织架构调整的事情并不容易，可以等到领导真正支持的时候再去做这件事，在此之前可以以拉动各部门的沟通协作的名义，在前期更多地把测试人员拉进来，这样汇报线其实没有改变，但测试做的事情已经与开发团队融合在一起。例如看一下测试有哪些事情可以前置，开发去帮测试做一些事情，或者测试资源有限，尝试把测试环境自动化，甚至是集中测试等就由开发人员去做，承认测试的专业性，在此基础上由测试人员去教开发如何去做这件事，逐渐就达到了技能共享，下一步就可以把团队打散，把测试人员融合到开发的团队中，事情就会进行得更顺畅了。

以上文字内容由【内容众创小组-栀】整理