全局优先 | 敏捷的哲学

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

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

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

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

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

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

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

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

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

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

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

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

0 Comments

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注