作者介绍

邱戈川，现任唯品会基础架构部分布式服务框架、定时任务调度系统以及容器化管理平台产品经理。16个年头的IT老兵，除了销售和老板角色，做过IT中的各种角色，游走于架构与产品间。关注Docker、Mesos等容器化技术领域的实践。主导的分布式服务框架已经广泛用于唯品会各大核心业务系统，以高性能、低延迟广受好评。个人订阅号：vipdocker。

 

写在前面的话

 

写这个系列文章的目的不是为了说明什么是Scrum，毕竟讲Scrum的书和文章已不计其数。我写这个文章是希望总结我在唯品会一年多来实行Scrum开发模式的一些回顾、总结以及后续可能需要改进的地方的探讨。

 

另外有时有些人喜欢将Scrum和DevOps等同，这个个人不是太认可。毕竟我理解的Scrum还是产品开发范畴，DevOps更多是开发运维一体化的概念。但两者也是有密切关联的，因为对于一个开发理念上还是很陈旧的无法接受敏捷开发的团队，DevOps的实行也顺畅不到哪里去。

 

为什么会在唯品用Scrum

 

时间需要倒流到2015年7月，多轮面试后终于进入唯品会平台架部–基础架构部。不过每次换工作都是在上一家经历很长的时间后，所以面试技巧都不怎么样，总觉得懂啥说啥，因为就算忽悠进来也做不出啥来，所以基本上面试也没准备什么。或许属于你的地方通常都要先考验你，也不怕笑话，进入唯品会我前后半年面了3次，最后还是这个部门的领导有眼光要了我。虽然中间有被打击到，但是后来想想也没什么，本身找工作就是一个缘分的过程。这些都是插曲了。

 

回归正题，进入唯品会后，工作上的氛围则相对宽松，因为之前已经有两个原来的同事先进来同一个部门了，一个江湖人称“江南白衣”，一个人称“隔壁老王”。因为部门广州的人少，所以我们三个就延续了原来的工作方式，照例施行Scrum模式。一开始还担心部门领导或公司对于工作方式有明确要求，后来才知道，其实唯品会在公司范围没有明确的工作方式的指引，全靠团队自身。另外部门领导远在美国，经（shi）历（mian）比我们多，抓大放小就让我们自己管自己了。不过源于之前公司的文化熏陶，大家工作上自觉性还是很高的，也没有什么需要特别管理的地方。不过现在回头看，还好我是在平台部门，而不是业务部门，不然施行Scrum模式将会遇到巨大的困难，因为在平台部门产品规划、发布等都是自主安排，而不是外部驱动，不然由业务计划倒推产品计划将是Scrum最大的敌人。当然也有些业务的团队也是实行Scrum，不过他们具体的困难和痛点，容我深入了解后再表。

 

所以在广州我们这个基础架构的团队就自然而然的开始了Scrum模式开发。也就是说因为人员的过往经历使我们继续走在了Scrum的道路上。

 

那么对于其它的团队的借鉴意义呢？其实就是找对人。Scrum不是什么灵丹妙药，一切都是通过人在实施，不同的人使用相同的方式还是会产生出不同的效果。当然如果你有足够的资源找到最好的人，那么什么模式都是虚的，就像我问阿里的有些团队（当然不是每个团队）一样，他们其实不需要什么模式，因为团队的人的经验和能力差不多，很多的Soft Skill都是很高的，对于这样的团队，没有比“放养”更好的开发模式了。现在至少我在的团队还不是，或者以后也难遇到，所以Scrum还是对我们有帮助的。不过站在我的部门领导的角度看，其实我们就是“散养”的模式。

 

团队的组成

 

既然谈到人，团队的组成与Scrum的顺利实施密不可分。从Scrum教科书上看，一个Scrum团队分为产品经理（PO）、Scrum Master，开发成员。但是在实施中，这个人员配置并不合适很多公司，特别是原来是比较传统模式开发过来的公司。我们结合实际，以及人员情况作出了调整。目前的角色安排是这样：

 

产品经理：对于我们这种比较纯技术类型的产品的开发，比较合适的是技术产品经理。两者的区别主要体现在“技术”两个字上，因为相关的产品管理更多是体现在技术的相关性上。这里面可以讲的东西足够再讲一篇文章，简单先做下阐述。

 

首先从产品的需求上，技术产品经理需要在产品功能需求的同时兼顾关心自身产品的技术导向性和新技术的使用，并以技术解读的方式来判定产品的需求。如现在比较热门的容器化技术是否合适自身的产品，是否能解决产品的某些短板。我们目前也在某个产品中引入容器技术，归根到底是为了解决机器资源服用降低成本的问题。而这些对于业务型的产品经理是不关心，因为他们通常的出发点是业务流程。

 

其次，在平台部门技术产品经理对接的上游是技术开发部门，而不是业务／商务部门，需要以技术的视角来沟通和协调业务开发上遇到的困难，并推动相关的产品的实施与运作，而不是去做商务分析如RoI等。

 

再次，对于开发过程中出现的问题或者团队中有争论的点，需要以技术的视野来判定对产品的影响，从而决定事情的优先级，从而推动产品的进展。

 

最后技术产品经理，更多是整体协调产品，让大家更顺畅的干活，从而符合产品的路线图规划。当然如果能将业务的产品经理和技术产品经理融合到一个人是最好的。可惜这个很难，而且工作负荷也高。在有资源的团队，可以同时设置业务产品经理和技术产品经理。不过目前看到最多的情况是没有产品经理，更别谈明细分工了。

 

Scrum Master：设立该角色是否有必要?在唯品会之前的公司，通常需要这个角色来完成一些Scrum中的日常工作，如贴任务条，组织planning game等。但是在唯品会中单独设置这个比较难，最主要是大家人为认为该角色工作含金量低。所以实践过程中，这个角色就不特定去强调了，相关的任务就分摊给技术产品经理或者开发Leader就可以。

 

Developer Leader/Architect：开发负责人或者开发架构师。在做纯技术产品的团队，很多时候技术产品经理的角色被团队的架构师兼任了。这里无好坏之分，关键在于是否能承担相应的工作负荷，是否同时能把产品架构设计好也能完成对外的相应工作等。但是更多是看到这样的架构师分身无力，反而没有把足够精力放在架构设计上，最后造成产品开发实施中问题多多忙于救火。如何区分技术产品经理和架构师呢？最简单一句话：产品决定做什么，架构决定怎么做。在Scrum中通常没有说明这个角色，但是在国内很多团队的人员技能经验不均等的情况下，还是需要这个角色来指导团队的开发。

 

Tester：测试人员。在Scrum模式下，通常是不再强调传统意义上测试人员的角色。Scrum更追求是开发的自行测试与自动化测试。但是在团队开发人员本身对于测试技巧，测试理论不深入的情况，设置独立的测试角色还是很有必要的，特别是从传统的开发模式转型到Scrum模式的团队。但是需要这个测试角色并不意味着依然像传统方式那样去执行人肉测试，更多是需要这个角色从测试专业度去设计测试要点，彌补开发者测试理念或经验上的不足，同时从产品端到端的角度开发相关的测试程序满足自动化要求，并从非功能性上着手测试开发过程中难以做的部分，如性能测试、稳定性测试等。这里需要特别强调是测试点设计（Test Point Desing），这个和产品的架构设计同等重要，是驱动开发更好思考实现中有哪些遗漏的地方。这里可以通过xmind等脑图工具帮助更有条理的做测试设计。但是看到太多的团队都是通过Excel来发散性做测试设计，想到哪里做到哪里。这里还有一个问题，就是传统测试理念喜欢提到的“提测”。其实我个人比较反对这个名字，因为它无形中割裂了开发与测试。那么测试和开发如何配合呢？埋个关子，我下篇再讲。

 

Developer：似乎最不用说明的是开发者了。但是这里还是需要提的是，无论是什么模式，现在的开发对于开发者的要求已经不简单的coding了，而是要求开发更加全面，特别是需要编写好的自动化测试。

 

是不是漏了什么角色？是否想说我们没有项目经理的角色？是的，对于Scrum的方式，其实更注重的是产品本身，而不是项目。因为产品是有Roadmap，项目犹如一次性的纸杯，做完就不会再有相同的了。但是是否就不需要项目经理了呢？取决于公司情况，据说硅谷多数公司都是没有项目经理的，不过对于系统庞多的公司，还是需要项目经理在特定事情上协调多个产品团队的。如双十一活动的公司级项目。

 

人员配比

 

一个比交容易自管理的团队规模，从实践是1+1+3+2的方式，也就是一个PO，一个Architect，三个开发，两个测试。7人的组合是比较好的配置。很多时候Scrum无法开展也因为人员配比的原因，如我们有个团队负责组建的开发，一人一个组建，这样基本就连站会沟通都困难。

 

最后

 

最后，一个好的团队，在具体事情角色分工和配合是清晰的。但是对于技术的提升是融合。借用我们团队Chembo同学一句拗口的话：不想做好测试的开发不是好的PO。

 

这是系列文章的第一篇，后续陆续推出。下篇预告：

• 产品开发节奏的思考

• 产品路线图的定义

• 需求的管理

• 开发与测试的配合

本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-11-03