敏捷方法的应用场景

关于敏捷管理，相信大部分都有所了解，甚至经常提及它的口号“敏捷迭代，小步快跑”。那么，除了口号之外，我们在实际项目中又做了哪些实践呢？敏捷管理真的为项目管理带来了哪些不同呢？

设想一下，公司决定引入敏捷管理的模式，开始采用两周一次的迭代周期。

在以往的工作模式中，我们可能会简单地对需求进行优先级的排列，紧急且重要的需求会迅速进行原型设计和需求文档的评审。然后开发团队开始工作，偶尔询问进度，完成开发后进行测试，到了第二周的周五晚上进行上线。

这是真正的敏捷管理吗？其实这只是用传统的“瀑布型”模式去套用敏捷管理，并未真正体现敏捷的核心价值。

真正的敏捷项目管理，其方法论和实践是有系统且具体的。我们可以从“规划”、“需求”、“拆解”、“跟进”、“回顾”五个方面深入探讨如何进行敏捷管理。

我们要明白项目管理有多种类型，如预测性、敏捷型等。选择哪种模式应基于项目的实际需求和特点。敏捷并不是神，它只是众多项目管理方法之一。其中，Scrum是敏捷管理的一种重要方法论，包含四条核心：个体和互动的优先级高于流程和工具、工作的软件价值高于详细文档、客户合作的重要性超过合同谈判、响应变化的重要性超过遵循计划。

接下来，我们从实际操作出发，看看如何进行敏捷管理的实践。

一、规划

在采用两周一次迭代的形式时，规划至关重要。关键在于团队和关键时间点的把握。建议每个团队人数控制在十人以内，以确保沟通的高效。设定Scrum Master（团队负责人）来管理每个团队的任务。通过甘特图明确关键时间点和每个职位的处理时间。每次版本迭代都根据规划的时间节点进行。

二、需求

有了规划后，需要明确本期迭代的内容，即设定“Sprint Backlog（当前冲刺需要解决的事情）”。对需求进行详细分析，根据优先级排列本期迭代的内容。对涉及内容广泛的需求进行细化拆分。确定好本期的“Sprint Backlog”后，即可开始策划需求。

三、拆解

在需求评审后，不要急于让开发团队立刻开始开发，首先要让他们对开发任务进行“拆解”，确定每个开发步骤和工时。这称为“I”。有了I后，可以实时跟进开发进度，通过任务项来预测功能风险。因为前一个工作项的完成情况可能会影响整个功能的上线。

四、跟进

跟进开发进度需要借助工具——看板。看板可以呈现工作项的流转和完成情况。通过小卡片的形式实时跟进每个开发工作项的状态。看板可以是实际的黑板或网络工具如TAPD。每日站会也是跟进任务情况的重要方式，每个团队成员分享自己昨天的完成情况、今天的计划和遇到的风险。