敏捷项目管理是项目成本管理和项目交付管理的一门管理艺术，为啥这么说呢？每一个人都会唱歌，但只有唱得好的人才能是歌手，才能是演唱家，而项目管理也恰恰与之相似，看似一件简单的社体活动，其实复杂多变，过程坎坷，管理容易，管好难。每一个项目，过程就像中国神话西游记一样，历经无数坎坷，只有怀有坚定信念，才能取得真经。

　　庆幸的是，经过前辈的披荆斩棘，无数的历练，有了当今比较流行的软件项目管理理论，敏捷项目管理。今天就总结一下敏捷软件项目管理里面两个比较出色的方法论，极限编程和Scrum管理。极限编程强调可适应性而不是可预测性。极限编程认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象。极限编程相信，更有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。其最终目的，降低因需求变更而带来的成本，是软件项目管理中对成本管理的一种解决方案。

　　极限编程中有五个核心价值：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、尊重（Respect），时刻牢记这五个核心价值，就能很好的完成极限编程项目管理。

　　谈完了极限编程，再谈谈敏捷Scrum项目管理，在谈Scrum之前，先给大家讲一个故事：

一天，一只鸡散步时遇见了猪。

鸡对猪说：“嗨，我们合伙开个餐厅吧。”

猪说：“好啊，那准备取什么店名呢？”

鸡说：“要不，就叫火腿和鸡蛋吧。”

猪直接拒绝了：“那可不行。我要割肉，你只要下蛋。这样下去，我迟早要完蛋。”

　　开心一乐之后，细细体会，软件项目管理未尝不是一场项目中不同角色之间利益平衡的问题。Scrum管理，强调把客户拉进项目组，成为一个整体，大家都有共同的故事，为了共同的故事，一起努力，当大家的目标一致的时候，项目组整体效率往往会出现意想不到的效果，这就是Scum 项目管理的精髓。

　　Scrum 项目管理，更像一个故事的演绎，项目首先需要划定三个角色，产品负责人PO（Product Owner），仆人型领导SM（Scrum Master），开发团队（Team）。PO往往有项目的甲方核心负责人主演，SM由乙方项目领导负责主演。

　　产品负责人PO：他负责在限定期限内拟定可能的最有价值的产品，简单讲，就是提前规划好需求故事，评价每个需求故事的价值和优先级别。然后通过管理流向团队的产品待办事项，该角色维护产品待办事项列表（Product Backlog），并确保大家都知道故事的内容以及优先级。该角色比较特殊，可能需要其他人的支持，但只能是一个人。

　　仆人型领导SM：他负责帮助PO理解如何创建和维护产品故事列表（Product Backlog）。确保团队在Sprint结束时能够完成故事，他和开发团队一起发现并实施技术实践。SM的另一个职责是保障开发团队前进的障碍已被清除了。这些障碍可能来自团队的外部，比如缺乏另一个团队的支持，也可能来自内部，比如PO负责人不知道如何恰当地准备产品待办事项列表。

　　Scrum项目的角色已定义完成，就开始故事的演绎。PO是导演，他会提前准备Product Story剧本，每次迭代计划会议都会用到，每个场景都由PO进行管理，PO掌控着Product Backlog，并由他来决定每个Sprint周期需要迭代的Sprint Backlog，Sprint Backlog的开启和关闭在每个Sprint Planning Meeting迭代会议上讨论的，创建和关闭都是由PO决定的，由SM负责监督和督促Sprint Backlog的推进，促成项目组交付物的产出。

　　PO和SM还要定期的组织项目组进行Review Meeting，回顾项目的交付物演示，SM负责项目回顾和交付物演示，也可以由项目组开发自己进行交付物演示。

　　最后要演绎的就是SM每天主持的站会Daily Stand Up Meeting，PO理论上是需要一起参加，但往往只是理论。SM确保Team一定要站着开项目晨会，确保每次会的时间不会太长，快速的沟通项目组上一天遇到的问题和本天的开发计划，以及需要的项目资源。

　　总结，Scrum项目管理，需要和客户扭打在一起，将大的任务拆解成可持续交付的小任务，保证项目的持续交付，出现问题可以及时迭代，风险共担。在Scrum的实践过程中，Sprint Planning Meeting最好是一周或者两周开一次，Sprint 任务为每周可以完成的任务。

　　最后推荐Scrum项目管理使用Azure DevOps工具的Azure DevOps Boards这个工具管理，好用、方便、标准模板。