SCRUM如何最大程度发挥团队潜力
很多大公司，因为待遇优厚，工作环境舒适，吸引了大批的人才，所以开发团队顶尖高手比较多，工作压力不大，是很容易实现高效率高质量的软件开发的。但是对于大部分规模较小的公司，没有经济实力吸引最好的人才，大部分人能力在平均水平，在这样的公司如何实现高效率的软件开发呢？俗话说“三个臭皮匠顶一个诸葛亮”， 在个人能力不是很突出的情况下，团队协作就非常重要，SCRUM正是一种很好的team work开发模式，但是如何利用好SCRUM模型实现最好的质量和效率呢？
首先团队要有协作的文化和机制。协作的文化就要求团队成员包括领导都要有协作精神，同事之间要摒弃竞争关系，拥抱协作关系。领导和下属之间要建立互信，同事之间要互相尊重、互相帮助。同时公司的考核激励机制也要符合协作的文化，有利于员工之间的协作。试想一个公司如果采用SCRUM完成的工作量人天来评价一个人的绩效，那么谁还有心思去帮助别人解决问题，审查别人的代码呢？如果一个公司以发现的代码数量去惩罚程序员，大家报Bug的时候都会犹豫一下，这样由如何帮助大家提高产品质量呢？大家可以反思一下我们周围是否流行一种追责的文化，当发现一个问题的时候，如果发现不是自己的问题导致的是不是长舒一口气，或者发现问题的时候还没有解决问题领导思考的竟然是追责。这些可能都是影响大家协作的重要因素，只有建立好了协作的文化和机制，团队才能进行真正的协作，从而达到三个臭皮匠的效果，否则就进入了三个和尚没水吃的状态。
当我们有了团结协作的开发文化后，我们在SCRUM执行中有可以从以下几个方面来帮助我们发挥团队的潜力。
从需求定义和产品设计的角度，团队首先要发挥一切渠道接近用户，了解用户，发掘真正的需求。当我们的产品经理没有足够的经验来设计优秀的产品的时候，团队必须发动各自能够动用的资源来帮助他。比如产品经理可能希望了解对手的产品，但是自己总不能买一套对手的产品，那么如果你认识使用这个产品的朋友，那么可以要求这位朋友演示软件系统的功能给产品经理，并进行深入的用户访谈，那么一样可以达到很好的效果。我们可能没有能力去购买咨询公司的报告，但是我们总可以参加一些开放的论坛，从中也能了解到一些行业的趋势。我们的客户没有大型企业的高管，但是我们的朋友或许就用大型企业的关键用户，这些关键用户可以给我们带来龙头企业信息化的最佳实践，帮助我们完善软件的需求。任何事情困难时有的，办法也总是有的，只要大家齐心协力，总能找到解决问题的办法。其次要尽早的深入细致的测试，对于产品开发过程的每一个迭代，产品经理或者团队其他人员都要参与进行深入细致的测试工作，通过测试来验证需求的合理性，普适性和价值，基于测试的反馈来修正产品的需求和设计，逐步完善产品的功能。通过不断的测试，不得的设计修正，迭代的实现一个产品从原型到优秀的进化。
从产品架构师的角度，当架构师经验不那么丰富的时候，我们可以通过尽可能使用经过时间证明的开源框架来弥补可能的架构风险，比如Web应用可以采用Spring，界面开发采用React或者vue。但是要避免使用太新的开源组件，或者技术不成熟只是一时新鲜，或者只是在某种细分场景下效果比较好，对于自己的项目可能不一定合适。另外开源组件使用的时候尽量规避太庞大的组件，比如你只需要数据绑定，那么vue可能就能解决你的问题，Angular那种什么都包含的组件就有点儿太重了。
从开发人员角度看，需要依赖团队和骨干的力量，通过合理分工，相互帮助的方式来提高效率。在任务分解的时候，需要进行更加细致的任务分解。通过任务分解的过程，大家一起讨论如何实现思路，识别出可能遗漏的逻辑，同时在讨论过程中将讨论好的实现思路梳理出来，当把任务交给经验不太够的开发人员的时候，他们的实现就不会因为经验不足偏离需求太多。任务分解完毕，骨干开发或者架构师要承担更多的设计和程序骨架搭建的工作，他们可以把关键的类写出来，接口定义清楚，然后把具体的实现交给初级程序员进行实现。通过合理分解任务，能够极大的降低项目质量风险，同时也能够合理分工，人尽其才。为了利用开发人员之间的互相的督促来提高效率，避免懈怠，则可以适当增加开发人员之间的开发依赖，通过A开发人员发出信号给B我等着你的开发完成来促使开发人员B能够更加专注，更有效率的完成自己的任务。最后因为我们假定团队的开发人员经验都不是那么丰富，所以更加密集的代码审查就会变得尤其重要，早发现问题，需要返工的工作就越少，能够尽可能的减少资源浪费。
从PO的角度来出发，当团队资源技术能力不强的时候，我们要从功能上做减法，但是不要在质量上做减法。只要产品的backlog优先级定义正确，在功能列表上做减法总是能保证最大的ROI，但是在质量上做减法，则可能带来更大的维护成本和重构成本，最后是一种得不偿失的折衷。