【IT168 专稿】

    敏捷软件工程专家Craig Larman最近发文，总结在编写《规模精益&敏捷开发：Scrum中的学习与企业工具》中"企业"一章时，由一组在大型公司工作的敏捷开发专家们列出所遇到的最大困难，并依此整理出以下十大管理障碍。

    10. 无法解决企业结构上的困难

    Jeff Sutherland是Scrum方法的创立人之一，他认为组织结构上的困难是当前大型企业所面临的主要难题。"我们一直都是这么做的"以及"我们投资了那么多，所以我们不想改变"是造成这种局面的主要原因。

    9. 对成本节省与协作的错误理解

    Peter Alfvin是Xerox公司的资深研发经理，也是精益原则的提倡者；Petri Haapio是Reaktor公司敏捷教练部门的主管。他们两人一致认为，中央机构经常对成本节省与协作有错误的理解，形成局部优化妨碍总体优化的情况。他们列举了几个这种案例。第一个是中央工具部门要求所有部门使用相同的工具。这个减少成本的好意却造成了至少一个小组的效率低下，因为这种"强迫"式的工具无法满足他们的工作要求。他们还举了一个例子是用材监督强迫所有小组使用小隔间，从而易于规划成本并使成本最小化。这同时也降低了许多团队的工作效率。还有一个例子是IT部门限制视频会议的带宽，这使得主要依靠这种方式进行交流的团队无法高效地进行工作。

    8. 缺乏训练

    Sami Lilja是诺基亚西门子网络公司敏捷开发活动的全球协调人，他发现许多企业似乎都认为学习是一种"时间浪费"。这些企业只有在他们认为"合适"的时候才对员工进行训练、培养。这种扭曲的观念造成了"救火"式的恶性循环：由于有限的开发技能造成错误，进而开始紧急修复工作，而管理团队却不愿意分析造成这种错误的原因，于是又导致更多的错误。

    7. 单职能团队

    Larry Cai是上海爱立信的一位专家，他提到职能性组织（单职能团队）是敏捷之路的最大障碍之一。这些单职能团队会造成交流上的障碍，容易导致互相之间的指责。

    6. 局部优化与全局优化

    Esther Derby身兼顾问、教练、职业导师等职，还是两本有关企业结构的著作的著者。她认为"把局部优化放在全局优化之上"正是企业取得成功的一大障碍。她还列举了几个涵盖目标管理（MBO）和预算系统的案例。

    5. 以为书本上的知识已经足够

    Mike Bria是西门子制药的前敏捷教练，他提到"自我修行"有可能会成为一种障碍。他认为，许多人读过一两本书就觉得自己已经"知道了"。这种一知半解的行为实际上是很危险的。这些企业通常不会去聘用外部专家，而是依靠自己解决所有问题。Lasse Koskela是《测试驱动》一书的著者，他也提到了类似的障碍，称之为"不愿面对企业外部的世界"。

    4. 个人业绩评估与奖励

    一位大型电子商务网站的培训员提到个人业绩评估与奖励是他所见到的一种主要障碍。这种陈旧的机制会让敏捷团队的开发人员和管理人员感到泄气，从而影响团队的效率、促成命令与控制式的管理方式。

    3. 不现实的承诺

    杭州诺基亚西门子网络公司的培训员兼开发经理吕易认为，无意义的承诺是企业的一大问题。虚无的期待会造成取捷径、不停地救火、和遗产代码等问题。这一点在《规模精益&敏捷开发实践》"遗产代码"一章中有详细讨论。

    2. 以为敏捷只是开发人员的事

    专业导师Diana Larsen和《敏捷回顾》一书的著者Esther Derby认为这是一个很大的障碍。通常，企业会错误地认为敏捷只是开发人员才需要学习的东西。他们不明白要向敏捷转型需要企业各层都在观念和行为上做出改变。

    1. 功能较多药和表面现象

    几乎每个人都认为功能较多药和表面现象是企业的主要障碍。OTI创立人Dave Thomas对此侃侃而谈。他说，许多公司错以为敏捷赞同于生产效率，而没有认识到其适应性。再加上一些没有经验的领导人，往往会导致敏捷就是一剂功能较多药这一错误想法的产生。于是，许多人觉得只要说说"我们在做敏捷"再做做表面工作，就可以解决掉一些很重要的问题，而领导团队也不会采取一些深层的、有意义的措施。更讽刺的是，因为这些行为无法产生有意义的改变和实际结果，因此这些企业最终会放弃精益或敏捷，因为他们觉得"一点作用也没有"。

    与此相关的一种错误想法是，在很短的时间内，比如仅仅几年的时间就可以使大型生产部门得到显著的提升。而实际上，大型企业的显著提升通常需要五年甚至十年的时间--这还是在领导团队的持续支持的前提下。

    在这份列表之前，Larman和他的团队也有他们自己对企业障碍的认识。他们认为，第一个障碍是个人代替团队及团队合作。许多个人组成的小组伪装成团队的样子并且表面上在做Scrum，但是他们心里想的却是"Jill做了自己的那份工作，Raj没有越职"，诸如此类。这些企业需要以团队的方式行动，结对工作，共同学习。

    第二个障碍是管理人员与前线工作人员之间的鸿沟。最常见的是，管理层做出的决定对实际工作没有产生任何影响（或者说，至少没有积极影响）。与此相似，前线人员做出的决定却与企业的方针无法吻合。这个鸿沟是由于管理人员没有对工作环境进行"实地考察"造成的（可能他们已经丧失了这种觉悟），而工作人员又不能积极地考虑"本份工作"之外的事。这就导致了表面敏捷和精益的产生：仅仅是管理层发生了变化而技术实践上没有任何改变；或者只在开发层次上发生变化，企业中却没有任何改变。"实地考察"和"管理者即指导者"的精益实践可以解决这种问题。

    从敏捷开发专家得来的反馈证明了Larmen他们想法和经验是正确的。

    这份十大管理障碍的列表也引来网友和专家的热评，Luis Xavier Baena表示赞成：“最大的障碍绝对是‘功能较多药与表面现象’，他们会说‘对，做吧，但是不要打扰我’。而且这个问题很难解决，因为你必须勇于面对那些给你发薪水的人，而这些人的看法实际上毫无价值。所以很不幸，我目前还不知道有没有较好的方式让那些靠自己的劳动过活的人能够敢于向CEO提出问题而不用担心自己的工资单。现实是，很少有Scrum实践者那么勇敢，不担心自己的薪水。只要管理层一天不给出实际的支持，那么你就无法控制这种情况，它只会像一种潮流一样慢慢淡去。而如果刚开始的时候即是这种状态，那么利益相关人及团队就必然无法避免以上这些障碍。”

    Vetrivel Shanmugasundaram留言道：“我曾经见过软件供应商在接受敏捷摆脱传统的软件开发模式的过程中遇到文中提到的障碍。大部分情况下，软件开发团队会在接受敏捷方法的同时继续使用他们传统的过程。这样团队就会在每日站立会议之后再举行一个状态会议、在跟踪待办事项的同时还要列一个详细的计划、短期回顾后还要进行过程审核。这会极大地影响团队的士气，因为他们会觉得敏捷给他们带来的只有负担。”

    Juan Banda则认为：“在我看来，第2条可以扩展为‘认为敏捷只是开发人员和质量工程师的事’，或者更广泛地说成‘敏捷只是技术层面的事’。我之所以列举出质量工程师来是因为我曾经在一些企业中看到，虽然开发人员相信并且在实际中应用了Scrum方法，但是质量工程师却坚持使用旧的规则。此外，从传统的管理方式来看，是该使用容易评估的指标来监督团队的时候了。而这本身又会造成另一种障碍。”

    Nicholas Cancelliere分享了自己的经历：“就我亲身经历而言，我遇到过的最大障碍就是：表面接受、以为这只是开发人员的事、缺乏训练以及个人业务评估。我以前在一家公司工作的时候，他们的业务部门希望能在特定的时间内完成某些功能，但是无法对其进行优先分级，结果他们只是猜测应该在什么时期完成什么功能。并且，他们从不编写需求的验收标准，通常只是说‘怎样’去执行一项功能而不是描述功能的具体内容。简单来说就是他们陷入了表面敏捷的陷阱，所以命令与控制的方式继续保留了下来，而‘仆从式的领导’就变成了让人忌讳的词。他们会说他们用的是敏捷方法--但是他们是有选择地使用。结果就是，一切都如以前一样混乱。”