最近研究敏捷项目管理，发现其中很多的最佳实践体现出了非常多的项目团队的文化变革，在此小结分享。
相 信很多人还记得五年前曾经非常火过一段的软件工厂的概念，当时有一些公司基于软件工程工具平台，建立起覆盖软件交付全生命周期的软件交付生产线。生产线上 的每个开发人员就像是汽车生产线上的工人，关注如何基于流水线的速度，根据任务单的要求，高效地完成自己负责的软件交付环节的工作。甚至每个开发人员工作 的工作终端没有存储接口，不能浏览Internet，所有的信息确保被安全的保存在公司的配置管理库。在当时的软件工厂的概念中，一向被认为是从事高智商 和高知识内涵工作的软件交付人员被毫不留情的称为软件蓝领。
然而，软件毕竟不是汽车，软件的生产速度也不是靠生产线的流动速度来决定的， 泰勒的科学管理思想在软件的世界里明显显示出来对人性本身分析和利用方面的不足，作为软件交付主体的人和团队，在软件交付过程中起到至关重要的作用。而整 个软件行业从业人员在被各种重量级的软件交付流程，各种软件成熟度模型折腾得筋疲力尽，终于迸发出解放思想、追求变革的呼声。加之很多业务快速变化或需求 快速变化的行业，例如游戏开发、Internet应用、电子商务等，要求开发团队必须在更短的时间内能够交付新的发布版本，必须能够对需求做出更加快速的 响应。敏捷运动正是在这种软件交付文化革命的大背景下，快速的发展、成熟和广为接受。
很多喜欢敏捷开发的朋友都喜欢用RUP作为对比对 象。然而，平心静气、仔细思考之后，我们不难发现，RUP其实和敏捷一样，它提供给我们迭代式软件开发、业务驱动的团队协作、有效平衡干系人需求、持续质 量保证、两级项目规划和合适的流程等最佳实践，并且提供了企业采纳这些最佳实践的客户化工具RMC。因此，在敏捷革命来临之际，喜爱敏捷的人们很快就基于 RUP，定制出面向敏捷的AUP和OpenUP，广为敏捷爱好者接受。因此，在软件交付的世界里，错不在RUP本身，而是我们在推广RUP的过程中没有做 好的非常关键的一件事，就是流程推广的文化导向，关注适用还是标准化；关注作为软件交付主题的大多数人:开发人员，还是少数软件过程管理者需求；关注客户 的需求，还是开发商的资质。因此，认真思考敏捷带给我们管理中的文化变革，理解其精髓，是我们能否真正敏捷的关键。
原文地址：https://www.ibm.com/developerworks/mydeveloperworks/blogs/
作者:宁德军
