团队中知识的流动

当很多人关注于敏捷的宣言、原则和实践，纠结于实践起来原汁原味还是变味走样，以及争执于真敏捷还是假敏捷时，我多少会认为我们正在遗失掉一些敏捷本质的东西，就像是在明晃晃的光芒之间，黑暗的缝隙里难以被觉察到的东西。

比如这一篇想谈的关于团队中知识的流动。

不谈不远的过去，即使在当下，多数软件公司的团队运作方式，仍然在遵循一种“承包责任制”的形式。团队中严格区分角色、职责以及层级，并以此制订固定的流程，尝试在彼此之间定义规范的输入输出，进而要求每个成员遵守，并以此评定业绩。他们认为这是高效的保证，奉为圭臬。

现在我们知道这多少是不合理的，对于软件需求这种会剧烈变化的东西，固守意味着僵化、浪费、风险、官僚以及低响应力等一切我们能想到的负面词汇。当然这里还有更严重的影响，在我看来，就是对人的能力、意愿以及情绪的物化，以及对软件构建这种创造知识的工作本质的漠视，都会极大地伤害每个人的积极性和承担力，而这对团队潜能的挖掘是致命的伤害。

在不以为然的僵化，和不可挽回的伤害之间，是潜移默化的效应的累积，效应之一，就是这样的区分、流程、规范在制约团队中知识的流动（速度）。而关于项目和软件本身的任何知识，如果能加速在团队内流动，都会带来诸多益处。

以下的诸多敏捷实践，我们多少都在施行，但让我们来留意一下，它们对于知识在团队中流动的细节：

• Scrum 的计划会议，是让后续迭代的需求、范围以及共同责任的知识，在团队所有角色间共享并讨论，进而做出合理的技术决策及风险预测。
• Story 的 Kickoff 以及 Desk Check，是 Story 的价值、范围、验收条件的知识，在团队的 BA、QA 和 Dev 之间取得一致的意见，并尽可能避免缺陷和返工。
• Pair Programming、Switch Pair 以及代码集体所有，是关于代码的标准、结构的变化（重构）、架构演化的知识，在 Dev 们之间尽可能以无缝的形式流动，取得共同理解和学习，并减少代码对特定人的绝对依赖。
• Code Review，不仅仅是代码的变更、规范，更重要的是对于业务的实现及理解，在 Dev 们之间达成共识，并寻找可能得遗漏，以及错误的实现。
• Showcase，不仅是团队和客户一起分享阶段成果，还是从客户那澄清业务知识的场合。
• Retrospective，仍然是一个共享信息的场合，对项目迭代的回顾，以及加深对团队成员彼此关注点的理解和共鸣。

这样的实践还有不少。敏捷的诸多实践是一个整体系统，彼此影响和关联，但都在不遗余力让知识在团队中顺畅快速的流动。流动的是知识，是场景，是经验，以及团队对合作的共同认知。试着去想一下，如果没有这些可以提供共享知识的机会和场景，会意味着什么？

除了 Scrum 和 XP 中会显著提升知识共享的实践，团队也可以借助一些可视化手段来强化知识的公开和透明度，比如我们熟悉的 CI Monitor，以及帮助全团队关注迭代和发布计划进度的 Burn Down/Up 图表，还有很多。

所有这些，都或多或少在帮助团队建立公开、透明的环境，以及流动在团队成员心中的因为开放氛围而带来的感受到的被信任和理解，相信自己对团队有独一无二的价值贡献。这样也从一个方面激发了每个人为团队工作的动机。

相反地，我们很容易看见一些因素会对知识的流动有阻碍的作用，快速扩大的团队规模，资深成员的懒惰和优势心理，由职权所带来的信息特权，都会阻碍知识流动，进而阻碍信任感、责任心，是对团队的最大伤害。