窥探IBM项目管理（三）

窥探IBM项目管理（三）

敏捷越来越流行了，IBM也开始向敏捷转型。我们可以参考下蓝色巨人如何一步步迈向敏捷，这对很多的传统型企业很有帮助。

敏捷开发小百科

敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

敏捷软件开发（或称快速程序开发RAD）描述了一套软件开发的价值和原则，在这些开发中，需求和解决方案皆通过自组织跨功能团队达成。敏捷软件开发主张适度的项目、进化开发、提前交付与持续改进，并且鼓励快速与灵活的面对开发与变更。这些原则支持许多软件开发方法的定义和持续进化。

首先先统一开发流程。对传统企业来说，团队都有自己的良好实践，贸然转向敏捷并不可取。

可以通过团队在大型项目上的经验优势、数据分析上的工具优势，以及高端技术人才优势发掘出更有深远意义的研发理论。同时转型推动者需要有愿景设计并充分理解当前环境下“存在即合理”的最佳实践模式。让每个团队对自己的优秀实践活动进行发掘、抽象、提升。使用优秀过程设计、方法论设计能够指导不同成熟度的团队，同时调整“过程参数”来满足团队各自的差异性附加价值。

开发流程示意图

同时，转型过程中需要不停地向团队各个成员安利敏捷开发带来的优势：

相比与只是猜测性的传统的需求文档，敏捷在了解项目需求与功能的用途会更好

敏捷在快速回答和澄清相关问题是可以预测的（一些时候相关问题是错误的或者不完善的）

做错误的事情也比不做事情好一些，尤其是在迭代过程中

转型过程中可能会遇到一些困难，IBM有很好的经验：

不能成为“理想主义者”或者“敏捷狂热之徒”，为了改革而蛮横地强迫团队服从个人意志，破坏了团队生态

不能以粗放的方式任由团队走入误区却视而不见

应该基于数据分析，采用循证型方式将团队引导进入敏捷的领域

在团队产生自我持续改进的愿望后，系统地规划团队的敏捷转型

在IBM促成敏捷具体方案时，其设计了以下几个步骤：

邀请权威人士向部门做过程改进和流程设计的同事和管理层介绍要推动的敏捷具体方案

安排组织内部的几次头脑风暴，与其他部门交流当下流程的“利与弊”，将大家共同的重点问题作为下几次会议的主要主题进行讨论和经验分享

联结IBM全球敏捷社区领导团队，寻找可借鉴的转型案例，将话题提上领导团队的日常会议日程，使得各种意见都能够被充分地探讨

制作组织内的新闻栏目，每隔一定时间发布工作总结和团队的阶段性收获，分享国内外有影响力的专栏内容转载、国际敏捷社区的文章和经验

将工作的创新点、成绩和组织目标结合，在组织内部寻找高阶的支持者与组织内部几位有影响力的技术、管理人士进行了一对一的沟通

在组织内的各个团队中寻找感兴趣人才组成“敏捷学习小组”，参与过程改进和开发，通过他们影响周围的同事、上级和管理团队，并让他们从这项工作中受益

IBM的”Discipline Agile Delivery“敏捷方案

时间关系，今天就介绍到这，有谁想了解Nokia的转型故事么？想的话可以提前打赏一下，哈哈！

关注精彩内容，要先点击这里哦~