I am Hu Kai

就在前两天，我们一起合作的团队某PL在本地（而不是在专门的服务器上）手工编译大包时，忘记了清理几个文件夹，导致编出的大包不可用，发布组花了一天的时间才发现原因是编译引起的。

事实上，在持续集成服务器上，有一个项目是专门用于生成大包的，但是这个PL却宁可去手动编译，我本想给他再说教一遍自动化是如何的好，可重复，效率高，但话在出口时变成了：

你干嘛不在持续集成服务器上点一下呢？ 手工编多麻烦啊，还得改配置。

我也知道啊，但是不能点啊，我看不见那个按钮

你为什么会看不见那个按钮呢？把页面打开我看看

原来是没有权限啊，你为什么不让管持续集成服务器的人给你开个权限呢？

他不给开啊

我去问问。

于是我找到了负责持续集成服务器人：

嘿，你为什么不给XX开权限呢？他在负责生成大包呢。

如果给了他权限，几个人都一起点上面的按钮怎么办呢？

不会的，你看（演示给他看），服务器自己会处理的

你看，原来真正的原因在这里，负责持续集成服务器的人不了解持续集成服务器的工作机制，对未知的恐惧让他不相信任何人，打消了他的顾虑，我又回到之前犯了错误的PL那里，

最后一个问题，就算手工编译，为什么不在服务器上进行呢？你自己的机器多慢啊

服务器是Windows 2003，允许多人登录，我如果在上面手工编译，可能会有别人也在上面编译的，协调机会出问题的，而且还有别人在上面调试脚本，我可能会影响他们的。

于是我和他一起重新配置了2003服务器，只允许同一时刻一个用户登录。

并且我得到了下面的问题列表：

为什么不能同时编译不同的项目呢？ 问题在哪儿？

为什么有人在服务器上调脚本呢？ 服务器不是工作机，他们面临的是什么问题？

…….

还记得当初我们面对的问题么？

有人不去自动化的生成大包

我们解决了的是什么问题呢？

对持续集成服务器的功能不熟悉

服务器的操作系统没有经过精心的配置

当我们不断的追问时，你会发现问题的真相在不断的浮出来，用眼睛观察问题，也不见得为实。亲爱的咨询师同事们，我建议你们也在自己的工具箱里面加上这个工具：  5 Whys

“我们要做很有效率的事情，而不是那些所谓敏捷的招式”     —     摘自某大型通信公司某分公司某版本某团队PL

“站立会议一定要用令牌，一定要眼神交流么？”

作为一名初来乍到的ThoughtWorks敏捷咨询师，你如何回答？ 你的头脑里这时候是不是有两个小人在打架？

小黑人说： “我在ThoughtWorks的团队也没用令牌啊，我们的站立会议还不是很流畅。”

小白人说：“大师的教材里明明白白写着，这是最佳实践啊！”

参照咨询师永远正确定理，你给出了完美答案：

“令牌的作用是………, 当然在某些条件下……..，但是我还是推荐大家最好使用令牌”

滴水不漏的答案，多好！

其实你发出了很危险的信号，那就是敏捷的招式（最佳实践）是可以妥协和剪裁的 。如果有机会观察客户的站立会议，你会大吃一惊，那就是所有的团队都跑偏，跑得没边的偏。

敏捷的招式可以裁剪么？ 在回答这个问题前我再问一个问题：

“太极拳的招式可以裁剪么？”

如果你不是杨露禅也不是张三丰，我想你会乖乖的按照师傅的招式练下去，然后在每天的练习中体悟太极拳的精妙。我们的友邦对此总结了3个字：

守、破、离

守： 是模仿， 遵循，是无我的过程。
破： 是变，是自我意识逐渐增强,心智逐渐收缩的过程。这个阶段我们需要区分出好与坏而不仅仅是两分的对与错。
离：是返朴归真, 看似打破常规，举手投足却都遵循着道，这是持续而自由的创造。

回到上面的问题：

“站立会议一定要用令牌，一定要眼神交流么？”

我的回答将会是“一定要”，因为我们面对的客户大多处于“守”的阶段。那个“永远正确答案”却处于破或者离的阶段，客户很容易在一开始就进行了错误的跳步而没有得到最佳实践带来的好处。要知道处于守阶段的人是领悟不到其中的玄妙和差别的，与其给出带有误导性的正确答案，到不如给出现在正确的“错误答案”。