敏捷团队之跨职能协作生存手册起因我们在网上常常见到“开发打产品经理”这样的新闻。又或者“产品经理不断改需求把开发累死了”。这样的新闻总是引起我的思考，难道软件开发团队内部的关系就应该是敌对的，而不是协作的吗？这也是这次分享的起因之一。不仅仅产品经理和开发之间，开发和测试之间也应该是协作的，而不是对立的。UI设计师和开发之间就不是上下游分离的，而是并行协作的。别人家的别人家的UI设计师出的图，连文件名，目录名都不用改，复制就能使用。别人家的程序员怎么变更都没有怨言。别人家的产品经理都能够一次性作对需求，不怎么变更。别人家的测试工程师就能够帮助程序员发现问题，而不是事后指责。别人家的ScrumMaster就能够帮助找到团队的问题，并且给出真知灼见帮助改进团队。别人家的发布到期了就一定能够发布。别人家都不加班，还能够很快的交付。别人家代码写好了没测试好都不提交。别人家的东西做的明明不怎么好，市场就是买单。其实抛开“别人家的”这个词这些不就是理想的协作模式吗？东西并不是只有别人家的好。角色也不是只有别人家的好。把这些协作方式拿来就是自己的。想要让整个团队有高效的协作模式，那就要从组织结构，团队成员个体的能力、发展以及团队成员之间的协作几个角度来全方位的改进。避免错误的改善GitChat避免错误的改善Scrum在提到团队的时候只是用到了“Team”这个词，并没有对内部进行详细分解。不同的团队当中需要的角色全然不同，无法直接给出各种细节定义。当然，ScrumAlliance也许想留给大家更多的余地自己操作。然而，团队内部的角色分工不同是客观存在的。团队中各个不同职能之间的协作是提升团队效率的一个重要的手段。除了提升团队成员本身的作为本角色的能力之外，提升如何在跨职能之间的协作也是团队持续改进的方向之一。如果不在意团队协作的改善的话，那就有可能会形成单个部门很好，但是整体协作缺很糟糕的情况。目标不一致目标不一致是形成局部优化的一个原因。当开发的目标是减少bug数量而测试的目标是找到更多的bug的时候，二者是无法协作的。当二者的目标变为改善质量，做入质量的时候，行动就会容易达成协调一致。当产品经理的目标是提交更多的Feature到市场上，而开发团队想要消除现在的技术债的时候就会形成目标冲突。当二者的目标变为交付更多的商业价值（而不是Feature）的时候，就会更容易形成一致的决议。当运维团队希望稳定而开发团队希望能够频繁交付的时候也会形成目...
