技术开发 频道

敏捷实施的十大组织障碍

    3. 不切实际的许诺

    诺基亚西门子网络(NSN)杭州研发中心的敏捷培训师、一个大型研发团队的部门经理吕毅指出,“承诺竞赛”和不切实际的许诺是最大的组织障碍之一。不切实际的期望往往会导致抄捷径、持续救火、遗留代码等问题。在本书姊妹篇Practices for Scaling Lean & Agile Development 的 “遗留代码”一章中我们将对此做更深入的探讨。

    2. 认为敏捷只与开发人员有关

    敏捷推广专家 Diana Larsen 与《敏捷回顾》(Agile Retrospectives)的作者 Esther Derby 都提到了一个障碍,即“认为敏捷只与开发人员有关”。许多组织经常错误地认为敏捷和精益只牵涉到开发人员,而不理解成功的敏捷转变其实需要一个组织内的各个层次上,人们思维和行为方式的转变。

    1.  银弹思维与表面实施

    我们采访过的所有人几乎都提到了某种形式的“银弹思维与表面实施”是一大障碍。OTI 的创始人、大规模精益产品开发顾问、ObjectMentor 公司总经理 Dave Thomas 对这一问题和现象作了精彩的分析。他说,许多公司错误地将敏捷等同于高生产率(productivity),而非适应性(adaptability)。这一误解,加上受过有效培训的高层管理人员的缺乏,导致了认为“敏捷就是某种形式的银弹”的误解。而这又进一步地促使某些人相信,任何有意义的实质问题只要通过说一句“我们正在做敏捷”,并据此采取一系列所谓的行动就能获得解决,而不需要一个组织的领导团队作出深刻理解和相应的改变。具有讽刺性的是,由于这种做法既不会导致任何真正的改变,也不会获得任何真正的效果,最终这些组织将会放弃精益/敏捷原则,因为“它们不起作用”。

    与此有关的另一个障碍是,一些人想当然地以为大型产品研发团体的敏捷改进不需要几年的时间,就能迅速获得显著的效果。而事实上,大型组织的显著改进往往可能需要花上 5 到 10 年的时间(在高层管理者的持续支持下)。

    我们的两点补充

    在发布了这份十大清单之后,我们决定再添加两个我们认为重要的组织障碍。第一个障碍是,一种突出员工个人而非真正的团队及团队合作的组织文化。有太多这样的团体,他们实际上由许多分离的、缺少凝聚力的个体组成,却伪装成一个团队,表面上实施了 Scrum,心里想的却是" Jill 做 Jill 的工作,Raj 做 Raj 的工作,等等"。这些组织中的开发团体无法以一个整体团队集体行动,开展彼此的结对工作和相互学习。

    第二个障碍是,管理者与一线员工之间的隔阂。常见的情况是,管理层做出的改变对实际的一线工作没有产生任何影响(或至少没有正面的影响);同样,一线开发人员所做出的决定,也往往不符合组织的方向。形成这种隔阂常常是因为,管理者没有到实际工作的一线环境中去"实地查看"(go and see) —— 有时候是因为他们已经丧失了这么做的技能 —— 而开发人员又不关心属于自己岗位正常职责之外的事情 —— 他们在自己的岗位上已经“退休”了。这种隔阂会导致浅表的敏捷和精益实施,结果是只在管理层面上发生了变化,而技术实践没有任何改变,或者只在开发层面上发生了变化,而组织本身没有任何改变。精益做法"实地查看"和"担当教练的管理者"(managers-as-teachers)可以帮助缩小这种隔阂。

    以上来自诸多敏捷开发专家的回答,证实了我们已掌握的经验,表明我们所研究的话题是恰当的。本书“组织”一章中余下的部分将进一步探讨这些组织障碍及其应对措施。

0
相关文章