IBM敏捷转型前所遇到的最大障碍

　　IBM一旦决定拥抱变化，成就客户，所面临的实际问题很快涌现出来，虽然恰恰是敏捷所能够解决的最核心问题，但仍然在这个问题上需要艰难的抉择;过去的 80年代、90年代我们虽然总结出了强大的IPD软件开发过程，甚至迭代式开放方式，但是所有的计划和迭代需求在一开始就已经确立，团队会参考长期和短期计划完成所需任务，每个人都有非常清晰的明确定位，知道各自的目标和所需完成的工作量;大家形成了一种完全适合传统开发的习惯，那就是设立目标，严格执行之直至完成;项目经理在进度和项目的方向的掌控上有着较大的权力，大家也习惯了服从指挥，做好螺丝钉;当然，与之俱来形成了的规则就是，但凡我要开展工作，我一定要确定“我可以进入”， 每每完成一项工作，大家也非常喜欢以“退出标准”作为尺度标定工作的完满结束;传统的工厂式软件开发的流程逐渐变得沉重，项目经理疲于奔命的忙于各项指标的度量，做各种报表以满足各级领导的视觉需求;而各级团队不得不在各种指标和进度的选择下，为了使得流程得以顺利进行，都极可能的去维系自己的“角色职责”，概要计划、详细计划方方面面，计划面又包括了“首要优先级、次要工作”， 并明确排除了职责可能涉及的“但没有足够掌控能力、或者被可能影响严重"的工作. 因此，延迟和工作流程的臃肿，不同团队之间的壁垒加深，保护意识过强。因此，软件部的智囊团终于发现了IPD，这个本来就基于瀑布式模式所研究出来的开发方法，需要重新调整;

　　IBM 2009年的软件部规模看来， 全球有26065人广泛分布在各大洲地区， 超过500个来自各个时期的收购，非常独立的产品线;独立而大量的工具和开发平台在公司内被采用;从明眼人眼里看来，IBM分明就是成千上万个小公司组成的;正因为“每家”都有自己的小九九，都充分相信了自身的成功法则;虽不是每个项目组风格各异，但是从IBM的5大品牌来看，行事作风迥异;势必没有一种技术、一种工具、一种流程、一种组织结构能够一统天下;

原文转自：http://blog.csdn.net/u012936954/article/details/16917007