面子文化和敏捷的冲突

敏捷是西方搞出来的一套东西，不适合我们中国人。

大概是两年前，在团队Scrum转型之初有人提了这么一个说法。当时我对这个观点大概是嗤之以鼻，因为整个软件产业都是从西方舶来的，不管是开发使用的语言，还是用到的工具，还是所谓传统非敏捷的开发方式，都是西方搞出来的，没有哪一个是来自四书五经或者社会主义核心价值观，而且这几年敏捷开发在国内的软件开发行业特别是在互联网公司那叫风生水起，怎么到我们这就变成水土不服了呢？

随着敏捷转型的推进，作为试点的团队敏捷慢慢推广到项目和部门以及更大范围的组织中，在最初的一段时间里一切看起来都很顺利和美好，各种漂亮的 PPT 中，展示着斜率陡峭的折线图、柱状图，证明敏捷转型以来我们取得的巨大成就。但如同婚姻一样，度过了完美的蜜月期之后，不合拍的现象开始慢慢出现，刚开始可能是偶尔的抱怨，然后是非正式的调侃，再到后来变成论坛上上时不时冒出来的“炮轰贴”，对敏捷的怀疑就像孢子繁殖一样,悄无声息的传播的到处都是。

image

在经历过所有这些转变之后再回头看文章开头的观点，也许正像是黑格尔的名言一样，既然这个观点存在，那一定是有其合理之处呢？

image

面子文化

Scrum 有所谓 3 大支柱，简单的理解就是先提升透明度，比如通过计划会的形式让整个团队对所有开发任务达成共识，在站会上同步每天的工作进展和风险，可视化的 DOD/AC 定义；然后从这些透明化之后的过程和数据中寻找问题，并且分析其原因所在；随后是找到解决问题的办法，比如回顾会。

• 透明（Transparency）
• 检视（Inspection）
• 调整（Adaption）

虽然很简单，但其实威力无穷。

问题在于当我们认真去做这些事情时会很容易陷入尴尬的境地，原因是我们经常会发现问题的根因在我们自己的能力上，比如交付节奏不稳定可能是因为 PO 故事没有拆分好，比如 CI 经常失败是因为新来的 QA 测试用例设计的太糟糕，比如单元测试开发进展缓慢是因为开发人员无法做好低耦合度的设计。按Scrum的说法我们应该可以进入下一步检视和调整了，然后问题就解决了。

但是，咱们国人有一个面子文化，我们没办法接受在一个正式的会议上一本正经的分析某个角色的问题和改进办法，有一些愣头青可能真这么干了，结果就驳了人的面子，带来对立和敌意。有人可能会说采取的方法不对，我们可以营造安全的“关键对话”，但是，要知道我们的目的本身就是为了暴露在能力上的短板并进行补齐，当能力上的短板是针对一个群体时（比如是整个开发团队对于某项关键技术的理解不够深入），我们还能在群体内找到安全感，而当短板指向某个具体的个人时（比如 PO / SM / QA 这些角色在一个 Scrum 团队中往往只有一个），所谓的安全感是不可能存在的。

于是尴尬就出现了——如果我们坚持Scrum的方法来透明化问题，就会带来对立和敌意，这显然会导致Scrum失败，而如果我们回避这些问题，某种意义上也证明了Scrum的失败。

image

怎么破解这种尴尬呢？从我个人经验来看，一个优秀而且自信的人通常不会有那么多奇怪的自尊，他会很欢迎外部的意见并接纳和改进，反之如果是一个半吊子，对于这种问题会非常敏感，一点点的疑问就会引来狂风暴雨。所以，还是得像google和facebook一样，坚持只招聘最优秀的人才，宁缺毋滥，只有优秀的人才不会有那么多关于面子的顾虑，才能做好 Scrum。