初识敏捷的时候，我对它情有独钟。现在回想起来，到底是什么让我对它信赖有加。我在方正和IBM做过开发和测试的工作，却远不如在ThoughtWorks获得的那般对于软件构建的体验和认知。像是被彻底打开了一扇明亮的窗，不再只是埋头做被分配的任务，而是看清楚我的前后左右，以及窗外那个完整的世界。是的，我想说的是，敏捷给了我得以观察软件构建整个周期的全局视角。

就此知道自己手里的任务，和前置的客户、需求、设计有千丝万缕的联系，也决定着交付的质量，以及上线后的反馈。孤立无援的螺丝钉，也可以身处轰鸣的机器中的位置。那是一个更完备的时刻处于生动运行中的图景。有了全局视角，信任感和责任心也油然而生，填满胸间。非比寻常的体验，仿佛在这个行当就此迈入了一个新的境界。

现在会慢慢意识到，这种所谓的全局视角，跟认可软件构建这件事本身的复杂性，心中所褒有的持续改进和追求极致的热情，又有莫大的联系。敏捷的工程和管理实践之间有不可轻视的整体性，更需要我们在面对问题，以及主动决策时，适当地跳出此时此景，去看更大的景观。在冷静周详的分析和考虑中，寻找最优的选项，而不是迫不及待跳入水深火热之中，胡搅一番搞到自己也觉得莫名其妙。

但现实中窘迫的例子比比皆是。

系统上线之后，爆出严重的功能问题。如果只是嗔怪测试人员没能及时发现危机导致全员被动，于是增加测试人员，加班加点手工测试。而忽视自动化测试覆盖率、回归测试的设计甚至开发人员对于系统易于测试的专门设计，就会显得片面而有推卸共同责任的嫌疑。

同样，团队交付的吞吐能力下降，如果只是质疑开发人员的技术能力，而遗忘业务和设计人员对于需求的分解到位、准确清晰的需求沟通，以及更具有弹性和可维护性的架构，也是必然偏颇的。

这些手段只会在短期内博得同情和煞有介事的效果，长期看仍然于事无补。倒像是水缸里始终不能全部摁下去的葫芦瓢。

团队的各类角色，各司其职，信息和数据流转其中，再现了一个彼此联动的系统。只是每每由于系统的某个部位的失察，意料之外的后果又总是处于更下游的部位。让我们有了可以轻易怪责的对象。而回溯的能力，可以帮助我们习惯全局优先，而不是局部优先的思维。

木桶原理也许可以引起一些延展的思考。通常在初期，团队的能力配比总是不够完美，短板的技能更像是随时会报错的缺陷，时间紧任务重刻不容缓。但出于全局优先的考虑，我不会任由能力出众的团队人员一骑绝尘，而是要关注知识和能力的传递，加强代码规范，内建质量这类更加注重长效而整体的行动。

还有另外一些帮助全局优先思考的方法，比如正反馈环，还有系统化思维。

其实全局优先在管理的语境中同样适用。我们憎恨官僚，官僚的原因在于，企业的局部部门各自有自己的目标，各自为战，没有形成整体。在我的同事张松撰写的《从领导力的角度谈ThoughtWorks的团队间协作》一文中，他有如下描述：

……组织效率的一个来源是清晰地结构、边界和责任，因此我们建立了一个个的团队，每个团队都有自己的目标。驱动力的重要来源则是Autonomy，我们的团队和leader被授予很大的操作空间来达成目标，这是我们很多TWer热情工作的驱动力之一。我们都知道全局优化的重要性，但当每个独立团队都盯着自己的目标，坚持自己的方式的时候，却经常会让我们偏离全局优化的目的。……全局上下文的缺失是团队做出局部优化行为的主要原因，对其它团队视角、能力缺乏了解，是信任感下降的症结所在。