上一篇写的内容写这篇（系列）文章的目的不是解释什么是Scrum。毕竟，关于Scrum的书籍和文章数不胜数。看看维基百科的描述：SCRUM。写这篇文章的目的是总结一些回顾，总结，以及以后可能需要做的改进。另外，有时候有些人喜欢把Scrum和DevOps等同起来，我个人并不认同。毕竟我理解的Scrum还属于产品开发的范畴，而DevOps更多的是开发运维一体化的概念。但是这两者也是密切相关的，因为对于一个开发理念还很陈旧，不能接受敏捷开发的团队来说，DevOps的落地不会一帆风顺。为什么在唯品会使用Scrum？你需要回到2015年7月，经过多轮面试，你终于进入了唯品会平台框架部-基础设施部。不过每次换工作，上一个都经历了很久，所以面试技巧不是很好。我总觉得我知道该说什么，因为即使你进来了，你也无能为力，所以基本上我没有准备面试。什么。可能属于你的地方，通常都要先考验你，你也不怕笑话。进入唯品会后，上半年见了3次，最后这个部门的领导有眼光找我。虽然中途被打中了，但想想也没什么。找工作本身就是一个缘分的过程。这些都是情节。言归正传，进入唯品会后，工作氛围比较轻松，因为有两位前同事已经进了同一个部门。一个叫“江南白衣”，一个叫“邻家王”。因为广州的部门人少，我们三人延续了原来的工作方式，一如既往地推行Scrum模式。一开始担心部门领导或者公司对工作方法有明确的要求，后来发现唯品会在公司内部对工作方法没有明确的指导方针，全靠团队自己。再加上部门领导远在美国，经验（shi）经验（mian）比我们多，抓大放小管好自己。不过由于之前公司的文化影响，大家在工作上还是很自觉的，没有什么需要特别管理的地方。但是现在回过头来看，还好我是在平台部，不是业务部，否则Scru模式的落地会遇到巨大的困难，因为平台部的产品策划和发布都是独立安排的，没有外部驱动，否则Reversing业务计划中的产品计划是Scrum最大的敌人。当然，也有一些业务团队也在实施Scrum，但具体的难点和痛点等我深入了解后再说说。于是在广州，我们的基础设施团队自然而然地开始了Scrum模型的开发。也就是说，因为人员过去的经验，我们继续走在Scrum的道路上。那么对其他球队有何借鉴意义呢？其实就是找对了人。Scrum不是灵丹妙药。一切由人执行。不同的人使用相同的方法会产生不同的结果。当然，如果你有足够的资源找到最好的人，那么任何模式都是虚构的，就像我问过阿里的一些团队（当然不是每个团队），他们其实不需要任何模式，因为人在team他们的经验和能力都差不多，很多SoftSkills都很高。对于这样的团队，没有比“放养”更好的发展模式了。至少我所在的团队不是，不然以后很难遇到，所以Scrum对我们还是有帮助的。但在我的部门领导看来，我们其实是“散养”模式。团队的构成说到人，团队的构成离不开Scrum的顺利实施。从Scrum教科书上看，一个Scrum团队分为产品经理（PO）、ScrumMaster和开发成员。然而，在实践中，这种人员配置并不适合许多公司，尤其是那些最初从更传统的模式发展而来的公司。我们根据实际情况和人员情况做了调整。目前的角色安排如下：产品经理：对于我们纯技术产品的开发，技术产品经理比较合适。两者的区别主要体现在“技术”二字上，因为相关产品管理更多体现在技术的相关性上。这篇文章讲的够多了，先简单说明一下。首先，从产品需求的角度出发，技术产品经理在兼顾产品功能需求的同时，需要关心自身产品的技术定位和新技术的使用，通过技术解读的方式判断产品需求。比如现在流行的容器化技术是否适合自己的产品，能不能解决产品的一些不足。我们目前在某个产品中引入容器技术，归根结底是解决利用机器资源降低成本的问题。而这些对于面向业务的产品经理来说是不关心的，因为他们通常的出发点是业务流程。其次，平台部技术产品经理的上游是技术开发部，不是业务/业务部。需要从技术层面对业务发展中遇到的困难进行沟通协调，推动相关产品落地运营。而不是做投资回报率等业务分析。再次，对于开发过程中出现的问题或者团队中的争议点，需要从技术角度判断对产品的影响，从而确定事情的优先级，从而促进产品的进度***技术产品经理，更多的是产品的整体协调，让大家的工作更加顺畅，从而符??合产品路线图的规划。当然，如果能把业务的产品经理和技术的产品经理合二为一最好了。可惜这个难度大，工作量大。在有资源的团队中，可以同时设置业务产品经理和技术产品经理。然而目前我看到的最普遍的情况是没有产品经理，更谈不上细化分工。ScrumMaster：有必要设置这个角色吗？在唯品会之前的公司，这个角色通常需要在Scrum中完成一些日常任务，比如发布任务条、组织策划游戏等，但在唯品会单独设置难度更大。主要是大家人为地认为角色含金量低。所以在实践中，并没有特别强调这个角色，相关的工作可以分配给技术产品经理或者开发负责人。DeveloperLeader/Architect：开发负责人或开发架构师。在从事纯技术产品的团队中，技术产品经理的角色通常由团队的架构师接管。这里没有好坏之分，关键在于能不能承担相应的工作量，能不能设计好产品架构，同时完成相应的对外工作。但更多的是看到这样的架构师是无能为力的，只是没有在架构设计上投入足够的精力，最终导致产品开发和实施出现问题。朵朵忙着救火。如何区分技术产品经理和架构师？最简单的一句话：产品决定做什么，架构决定怎么做。这个角色在Scrum中通常没有明确规定，但是在国内很多团队技能和经验参差不齐的情况下，还是需要这个角色来指导团队的发展。测试员：测试员。在Scrum模式中，通常不再强调传统意义上的测试人员的作用。Scrum追求开发的自我测试和自动化测试。但是，在团队开发人员本身不具备深厚的测试功底和测试理论的情况下，设置独立的测试角色还是很有必要的，尤其是对于正在从传统开发模式向Scrum模式过渡的团队。但是，需要这个测试角色并不意味着人肉测试仍然以传统方式进行。这个角色更需要从测试专业的角度来设计测试点，弥补开发者测试理念或经验的不足，同时从产品端出发。从端到端的角度开发相关的测试程序以满足自动化需求，从非功能的角度开始测试开发过程中的难点部分，例如性能测试和稳定性测试。这里需要特别强调测试点设计，它与产品架构设计一样重要，是推动开发更好地思考实施中缺失的东西。在这里可以使用xmind等脑图工具帮助测试设计更有条理。但是我看到太多团队发散的用Excel做测试设计，想着哪里做。这里还有一个问题，就是传统测试概念喜欢提的“测试”。其实我个人是反对这个名字的，因为它无形中把开发和测试分开了。那么测试和开发如何协同工作呢？让我在下一篇文章中告诉你。开发人员：似乎是需要最少解释的开发人员。但是这里需要提到的是，无论是什么模型，现在的开发对开发者的要求都不仅仅是简单的编码，而是更全面的开发，尤其是需要编写好的自动化测试。是否缺少任何角色？你想说我们没有项目经理这个角色吗？是的，对于Scrum方法，重点是产品本身而不是项目。因为产品有路线图，项目就像一次性纸杯，完成后不会再有相同的。但是不需要项目经理吗？这取决于公司的情况。据说硅谷大部分公司都没有项目经理。但是，对于拥有大量系统的公司，仍然需要项目经理在特定事项上协调多个产品团队。比如双十一活动的公司级项目。人员比例比交易更容易管理的团队规模。实际上是1+1+3+2，即1个PO，1个Architect，3个developer，2个test。7人的组合是比较好的配置。很多时候，因为人员比例问题，无法进行Scrum。比如我们有一个团队负责编队的制定，一个人就是一个人，站会上基本上很难沟通。*****，一个好的团队在具体的事情上分工明确，配合默契。但技术的进步就是融合。借用我们Chembo团队的一句话：不想做好测试的开发不是好PO。【本文为专栏作者“VIPDOCKER-Leoge”原创文章，如需转载请通过联系作者】点击此处查看该作者更多好文
