国林哥在IBM时，几乎每天都会收到关于“敏捷”相关的邮件，公司鼓励我们去学习邮件里的知识，参加敏捷相关的认证和培训。刚开始我和大多数同事一样不管不顾，后来随着PBC里要求加上成长目标，比如要获得一个认证，我们就不能再回避这类邮件，并逐渐试图弄清楚它的"底层逻辑“，并在公司参加”Agile“相关认证，并在实际项目中运用敏捷实践。

       必须感谢蓝色巨人IBM给自己带来的敏捷文化，在服务华为研发管理时，我就讲敏捷相关的理念和实践带到项目中，并逐渐从0到1组建了一只近100人的研发团队。记得当时多次在团队分享《敏捷项目管理实践》这门我自己编写的PPT材料，我们团队的小伙伴也逐渐理解其中的意义，也清楚明白我们作为敏捷团队的要求，组织的工作效率比较高，大部分人干活都很主动，上班时打满鸡血，摸鱼者越来越少，为华为”活下去“贡献一点微薄力量。

       今天我就来讲讲敏捷项目管理的基础知识，为即将或已经踏入技术管理的小伙伴做一个抛砖引玉的碰撞，以期共同进步。

       首先，项目管理是什么？ 我们都知道，项目管理无处不在，项目管理是运用管理的知识、工具、技能和技术于项目活动上，来解决项目的问题或达到项目的需求，通过周密的计划，管理好项目中的人、事、物，达成项目目标。比如结婚，旅游都涉及项目管理，需要你的周密计划，组织。

        其次，敏捷开发的定义是什么？敏捷开发（Agile Development） 是一种以人为核心、迭代、循序渐进的开发方法，是拥抱变化的开发流程。

        再次，敏捷项目管理的定义是什么？敏捷项目管理规划和指导项目流程的迭代方法。 与敏捷软件开发一样，敏捷项目是在叫做迭代的小型部门中完成的。 每个迭代都由项目团队审查和评判；从迭代的评判中获得的信息用于 决定项目的下一个步骤。每个项目迭代通常是安排在两周内完成。

        传统的项目管理面临哪些挑战？比如：缺乏明确的目标、目的，组织与项目目标不一致；需求的不明确，不完整，与不断的变更；缺乏最终用户的参与；不明确的职责；没有做好计划等等。

       让我们来看看敏捷开发宣言：个体与交互高于流程和与工具；工作的软件高于详尽的文档；
客户合作高于合同谈判；响应变化高于遵循计划。

      基于敏捷开发宣言，我们总结出敏捷宣言遵循的12条原则：

      1. 我们最重要的目标，是通过持续不断地，及早交付有价值的软件是客户满意。
      2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
      3. 经常地交付可工作的软件，相隔几星期或者一个月，倾向于采取较短的周期。 
      4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
      5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支持，辅以信任，从而达成目标。
      6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 
      7. 可工作的软件是进度的首要度量标准。
      8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
      9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
      10. 以简洁为本，它是极力减少不必要工作量的艺术。
      11. 最好的架构、需求和设计出自自组织团队。 
      12. 团队定期的反思如何能提高成效，并依此调整自身的举止表现。

       项目管理铁三角是什么？时间，成本，范围。所谓“铁三角”，指的是三者中任意一方的变动都会对其他二者产生影响。项目管理的目标是平衡三者的关系，使之达到最佳的效果。各要素相互牵制，而对需求的管理就至关重要，否则就会带来时间，成本，范围的失控。因此，我们需要做好需求统一管控，实现一个”刚刚好“的交付。

     传统开发面临的问题有哪些呢？

       1. 交付周期长：往往是6-12个月甚至更长；

       2. 软件质量差：经常为了赶着上线而牺牲质量；

       3. 团队士气弱：员工积极性不高，相互抱怨产生隔阂；

       4. 按时发布低：长期累积大量任务债务，在临近交付日期时很难完成；

       5. 沟通效果差：员工经常因为小事情不沟通或沟通缓慢，导致进度延迟；

       6. 进度延期久：工作计划的估算靠拍脑袋决定，外行指挥内行。

      传统的项目管理追求”一次把事情做完“，而敏捷项目管理追求增量交付，通过故事分割，多次把事情迭代完成，过程中通过优先级和工作量的评审，与客户在各个版本阶段达成预期。

 

      为什么要做敏捷呢？需求为啥要变化呢？不能一开始多花点力气，想明白吗？

     首先， 项目需求的细节无法提前全都想明白，在做得过程中才逐渐清晰。项目管理过程中的不确定性太多，可能连用户自己都没意识到自己到底想要的是什么。
     其次， 世界变化太快，原本有价值的东西，随着项目的推进，可能会变得不那么有价值了。

     那么，敏捷软件开发的优势有哪些呢？ 

     1. 快速交付：1-4周迭代结束即可，并交付可运行的软件；
     2. 降低风险：短周期迭代持续反馈，提高预见性；
     3. 适应变化：小步快跑，快递验证产品需求及调整方向；
     4. 质量更好：持续集成及频繁测试，保证代码质量更高；
     5. 持续改善：迭代结束后进行回顾，频繁检查团队动向；
     6. 满意度高：高ROI的需求快速交付，早期实现商业价值。

      敏捷项目管理的特点有拥抱变化，快速试错，全民阶段性测试。不仅快，而且离用户近！

      敏捷推崇的工作方式是通过5-9人的跨职能小团队，通过2-4周的迭代周期，分批次增量交付需求，通过小团队在短时间内做出一小块需求，并有规律的集成组装形成整体功能。

     那么，什么项目适合传统项目管理，什么项目适合敏捷呢？

     如果需求和技术明确，就适合采用传统项目管理；如果需求和技术都不明确，属于复杂类型的项目，就适合敏捷。