什么是敏捷项目管理

敏捷管理如果用一句话高度概括就是：面对高度不确定的事件，思维、行动，快速反应、快速应对，并作出正确选择的行为，称之为敏捷。

如果再精炼的概括一下，那就是“对、好、快”。PO确保做对的事，SM负责快速推进，DT保证正确地做事。

如何进行敏捷项目管理

敏捷本身也有很多方法论，其中我要讲的是“Scrum”，主要有4条宣言：

• 个体和互动高于流程和工具
• 工作的软件高于详细的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

这4条宣言一定程度上涵盖了我接下来要讲的内容，当然这些宣言记不记住都没啥关系，最重要的是从实践找到方法，而不是在方法里面找到方法。

所以我们开始从传统的瀑布型开发转成敏捷型开发，首先要做的是——规划。

规划

项目假定采用2周1迭代的小步快跑形式，那么最核心最重要的其实是规划。

规划我认为主要有两个最重要的点，一则团队，二则关键时间点。

在团队的规划中，每个团队的人数需控制在十个人以内，因为人数一多，交流的信息会越复杂，这不适合敏捷的“个体和互动”的宣言。

如果团队超过10人，则需要进行团队拆分，每个团队需要设定一个“Scrum Master（团队负责人）”。

有了团队后，并且对团队进行具体的分工后，则需要开始规划关键时间点。

在具体的规划中，我们需要在两周的时间规划出关键的时间节点；我们可以采用倒推的形式去思考到底有什么关键节点。

如上线前，我们需要具体的“上线时间”，再往前我们需要具体的“测试时间”，测试之前我们需要知道具体“开发完结时间”，再继续往前我们需要知道具体“评审时间”。

这里的关键点在于“具体”，直接通过甘特图的形式标识出具体的关键时间，和每个职位在各自环节下的处理时间。

图片只是示例，并不代表具体情况

接着我们每次版本都根据规划的时间节点，按部就班的进行，有了指向标，才能让项目更清晰。

我们只有规划好整个盘子，才能往里面加东西，不会造成自己和团队的混乱。

需求

有了规划后，我们需要知道这期做什么，而做什么则是“需求”决定的，即设定“Sprint Backlog（当前冲刺需要解决的事情）”

本期需求迭代的内容需要进行详尽的分析，根据产品对需求的优先级来确定本期迭代的内容，这里优先级的排列可根据“紧急且重要”、“紧急但不重要”、“不紧急但重要”、“不紧急且不重要”四象限进行分析。

如发现某个需求涉及的内容非常广大，则需要我们产品经理对这个需求再进一步的细化，从整体拆成局部进行重新排列，以“天”为单位。

最后，我们确定好本期的“Sprint Backlog”后，则开始策划需求吧！

拆解

假设我们经过了需求评审，在评审中，我们可以提前和开发负责人沟通这些需求对应的开发人员，这样他们在评审的过程中参与度才是最高的，不过在评审后，按照平常的情况，可能我们直接让他们进行开发了。

但是先别着急，也请先别让开发的小伙伴直接进入开发，让他们首先对自己的开发任务进行“拆解”。

假设一个开发的任务是“筛选列表项”功能，按照一般的开发逻辑，可能从页面的元素、JS、接口、数据库索引、前后端联调等步骤进行开发。

这里面其实对于开发来说是可以详细拆解的。

所以我们需要让开发把具体的开发的功能项，按照“小时”进行拆分，确定好每个开发的步骤和工时，我们才能做到实际的跟进，从每个工作项着手跟进具体的完成度，才能做到有的放矢。

这整个拆解的最后的内容，称之为“SBI（和WBS同理，只是会更加细化开发工作项的内容）”。

有了“SBI”后，我们就可以实时跟进开发进度，当某个事项没有完成时，可以随时通过任务项反映出这个功能是否有风险。

因为前一个工作项和后一个工作项，相互之间大概率是耦合的，缺少这一点，可能也会导致整个功能无法上线。

跟进

有了具体的工作项后，则需要进行跟进了，当然这一节虽然说的是跟进，但是更注重“工具的使用”，这个工具是——看板。

看板主要呈现工作项的流转和完结情况，通过小卡片的形式，实时跟进每个开发工作项对应泳道下的情况，如这个工作项在“开发中”，过了几天工作项可以流转到“测试中”，每个工作项都是流动状态的！

举个例子：A开发者正在开发“A工作项”，此时对应的状态是“开发中”，开发完成后 ，则流转到“已完成”，等到工作项上到测试环境，此时工作项流转到“测试中”，最后上线，任务流转到“已完成”。

这个看板可以是实际的黑板，用线条画出来，也可通过网上的工具，如TAPD的网络看板进行管理，关键在于呈现任务项的流动状态，和当前节点状态。

看板完成后，还需要完成任务项卡片的制作，卡片主要描述具体的任务项，完成时间和工时，描述清楚即可。

此时有了看板和卡片，则这个管理项目的工具已经完成了。

但是有了看板还不够，我们还需要通过“每日站会”来面对面沟通任务情况，每日会议的时间不能超过10分钟，每个成员时间控制在一分钟内。

每个团队成员都需要说三点：

• 1.我昨天做了什么
• 2.我今天做了什么
• 3.当前有什么风险，需要谁进行协助

通过站会，我们才能做到真正跟进开发任务项的完成情况，才知道这个任务项是否有风险；有风险的情况下，是加班解决，还是这个功能只能延期等等的解决方案。

我们通过看板和每日站会这两个工具，实时跟进了每个冲刺的具体情况，才能做到心中有数，把风险下降到最低。

需要项目管理资料合集的同学可先关注然后私信我哦