浅谈敏捷项目管理

敏捷,近几年是火出圈的一个词,以前是软件开发或者往大点说是IT圈的名词,现在已经是各行各业争相追捧的热词。姑且不说此敏捷非彼敏捷的事情，但就这个现象来说，敏捷是有可取的地方，值得去研究。

咱们还是说回老本行-IT圈吧，很多IT企业尤其是软件企业，随着市场规模不断增大、客户越来越多、员工越来越多，随着而来的问题也就越来越明显，市场竞争越发激烈、客户的需求总在变化、员工的堕怠导致效率降低。很多的企业已经开始敏捷实践，用敏捷项目管理来应对上述问题，并已经有了卓有成效的结果。但如何进行敏捷实践，如何做好敏捷项目管理，对于大多数还没开始的企业或者项目经理来说，还是一件相对困难的事情，笔者根据自己的实践，总结了几条经验，分享给大家。

一、敏捷项目管理不是颠覆传统的项目管理的理论和方法，而是在原有基础上的提升改进。

    这点在敏捷宣言里就有所体现，可能大家更多的关注的是敏捷宣言里的个体和互动高于流程和工具、可工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划这四条，其实在这四条之前和之后各有一句话，“我们一直在实践中探寻更好的软件开发的方法”和“尽管右项有一定的价值”，这两句话就很明显的表明了两件事，一个是敏捷是从实践中总结而来，一个是传统的项目管理的方式是有价值的。

            另外我们来看看敏捷的由来吧。敏捷的起源普遍的共识是2001年2月13日发表的敏捷宣言为标志的，敏捷宣言是由17位软件开发领域的领军人物经过两天的时间讨论形成的，这17位参会者分别来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。其实仔细分析一下，敏捷就是来自于经验和实践，是对传统软件开发方式的补充、改进的方法的总结，形成了敏捷的普适性的理念-敏捷宣言。也就是敏捷从诞生开始就是在传统软件开发理论或者说传统的项目管理理论的改进和实践，敏捷诞生的过程就是发现问题-制定改进计划-实践改进方法-检查改进效果-再总结改进的过程，这就是朴素的管理理论PDCA循环。由此可以看出敏捷也是要遵从基本的管理理论的，是在此基础上的实践，是经验和实践的积累和总结。

    从以上两点，足以说明敏捷项目管理不是对传统项目管理的理论和思想的颠覆，而是在传统项目管理的基础上，进行提升和改进。

二、敏捷项目管理要从形式回归本质，重内涵而不注重表象，做到手中无剑心中有剑。

    敏捷有很多的方法和工具，使用最广的是Scrum框架，也就是我们通常说的3355，三种角色（产品负责人、敏捷团队、敏捷教练）、三种工件（产品待办事项、冲刺待办事项、产品增量）、五种仪式（每日站会、冲刺计划会、冲刺回顾会、冲刺评审会、待办事项梳理会）、五种价值观（专注、勇气、开放、尊重、承诺）。很多项目经理在实践敏捷的时候，经常纠结于要不要严格的按照这些去执行，少了一个或者是没有采用同样的方式去做，是不是就不算是敏捷。

    其实，前文我也讲述了敏捷宣言和敏捷原则的由来，就是从众多的敏捷方法中提炼出来的，据不完全统计，敏捷现有500多种方法和工具。从这也就可以看出，在敏捷宣言的框架范围内的就是敏捷，不在乎你采取的是那种方式，或者说不在乎你是不是严格执行了3355。更多的我们是要理解敏捷宣言所要阐述思想的精髓，就是我们如何才能敏捷，我们尊重团队的每个成员、充分沟通；我们使用可工作的软件提升效率；我们拥抱变化、用积极的心态应对变化；我们和客户合作、促使客户深度的参与项目，这些能使我们敏捷，只要我们能够秉持这些理念和思维方式，我们能够总结出或者创新出更多的方式，这就是敏捷。

    用中国的古话来说就是形神兼备，不拘泥于形式，手中无剑心中有剑，将敏捷的思维铭刻于心，自然就有由内而外的敏捷实践。

三、敏捷项目管理是以激发团队成员的自主自治为终极目标，要润物细无声的让团队不知不觉地践行敏捷。

    传统的项目管理也好，敏捷项目管理也好，最重要的都是如何管理好团队成员。敏捷项目管理更注重激发团队成员的自主性，在充分尊重团队成员的前提下，引导团队成员的积极性，促进团队成员的充分沟通、互帮互助，从而让团队达到不断提升的最佳状态。这里对项目经理就提出了更高的要求，需要项目经理从命令式的管理者，变身为仆人式的促进者，发挥自身的领导力，身体力行的去影响团队，带领团队实践敏捷。通过一点一滴的潜移默化的影响改变团队，让团队不知不觉地践行敏捷。

总之，敏捷和传统是同根共生的，敏捷项目管理是要和传统项目管理相融合的，是要循序渐进的，润物细无声似的渗透。