我看Scrum(2)-团队协作与全功能团队

四、团队协作

提到团队协作，听到最多的就是团队责任制。在一个小团队里，形成对外的团队责任制是很容易的（因为集体荣誉感），这也是Scrum鼓励小团队的原因之一。但在团队内部，使每个人都能做到团队责任制却并不容易。

找到反例似乎很容易。在一个分特性到人的项目里，产品出现bug，几乎总有程序员说，恩，这块不是我开发的，你要找某某某。在另一个项目里，业务分析师越过业内的最佳实践，忽略程序员的意见，一定要在地图上一次性显示所有地点，而不是延迟分批加载，结果导致这一功能的数次返工，程序员们抱怨不已。

在团队内部做到团队责任制，最重要的就是要鼓励所有人都参与团队的任何事情。参与不一定是去做，最起码是一定要了解。试想一个模块从头到尾我都不了解，这个模块的任何决定我都不知道，要我承担责任这可能吗？就好像很多工厂门口贴出的大标语：工厂是我家，我是主人翁一样，只是一句空话。为了广泛参与，我们需要做到代码集体所有权；为了广泛参与，我们需要频繁切换结对对象；为了广泛参与；我们需要业务分析师、程序员、测试坐到一起共同分析讨论故事，当然这样做的另外一个好处是避免知识交接产生的浪费；为了广泛参与，我们有意弱化专家的角色，并在团队里做到知识分享；为了广泛参与，我们设立一个想起来就激动人心的项目前景。

这些就够了吗？不够。在微软项目求生法则里，软件的需求阶层被划分成了5块，从下到上依次是：生存需求，项目没有被取消的压力，工作条件合理；安全需求，满足个人对时间和功能的承诺，不安排不可能完成的任务；归属感与爱，健全的团队动力；自尊，感到团队生产力，相信项目重要性；自我实现，持续发展。

关于自尊，我们强调对事不对人，原则如此，操作困难。一个例子是当一个设计违背了设计原则时，直接对程序员进行了批评，认为其不负责任，导致了该程序员的离职。另外一个例子是在回顾会议上批评了不愿重构只想赶进度的行为，某程序员认为这就是在批评自己。在具体到某个人和某件事的时候，需要的是了解团队中的每个人，每个人的性格特点，周期性私下沟通是每个迭代经理的职责。什么事情拿一个大的原则来框，反而会忽略了人本身。一个极端的例子是，有观点把敏捷之所以推行不了全部归结到人的问题上，但他显然忽略了一点，敏捷本来就是来解决人的问题的，一个解决人问题的方案不能实施是因为人的问题，这莫不是一种反讽。

五、全功能团队

Scrum提倡全功能团队。有一种观点认为追求卓越的团队，就得所有人会做所有事，不认可分工。从我个人的角度说，我并不认可这种观点，我的观点是追求卓越的团队，就得所有人专注自己的事同时思考所有的事。即我是赞同分工的，为什么分工，分工才能专业。正如路边小诊所包治百病一样，专家只存在于特定领域。

一个反例是当一个项目遇到严重的性能问题时，开发人员使用selenium来进行性能测试，他们耗费了好几个月，其中很多时间用来搭建环境，最后起的效果却并不大。这时需要的是测试人员的专业技能。

另外一个反例是在一个项目后期引入专门的测试人员后，bug被源源不断的发现出来，一个功能是在列表页面弹出编辑框，在列表达到20条数据页面需要滚动时，编辑框没有跟着滚动，造成最后几条数据用户看不见编辑框而不知所措，程序员都没有发现这个bug，但测试人员却几乎是立刻发现。这时需要的是测试人员不同的思考问题的角度。

那么，为什么我们又要强调全功能团队，强调从其他人的角度思考问题呢？

首先也是最重要的是避免浪费。软件开发是脑力活动，业务分析、开发、测试之间存在工作的交接，这种交接其实表现为知识的交接，知识的交接让分工变得模糊。业务分析更多站在客户的角度分析问题，程序员更多站在技术的角度分析问题，测试人员更多站在客户使用（易用性、各种边界）的角度分析问题，最后故事的实现必然是三者协调后的结果，因此每个人都需要从其他人的角度进行思考，越早越频繁的非正式交流越好，能减少返工。在上面提到的例子里，由于业务分析师没有注意到技术的约束，而程序员没有坚持自己的意见（其实是没有更多的深入思考），导致地图的实现反复折腾，产生浪费。

剩下的就都是附带作用了，比如由于广泛参与带来团队责任感，某个测试人员对写代码非常感兴趣偶尔尝试由此带来的激励，以及当测试人员偶尔不够而程序员进行暂时替代从而平衡生产。对于平衡生产，我想说的是偶尔为之是没有问题的，但一个团队如果频繁需要程序员代劳测试，那么问题显然是测试人员不够，合适的解决方案应该是增加测试人员而不是要求程序员测试。