在做敏捷咨询的这些年头里，小马哥最深的体会便是在大部分客户眼里，”敏捷“一直等同于”改变“，并且敏捷就必须要改变。相信这些场景对于在做敏捷交付的团队来说都是切肤之痛：

场景A: 项目临近交付，上线在即，客户突然要求加一个新需求，当团队尝试解释时间上来不及时，客户爸爸说：”你们不是敏捷吗？怎么加个需求都不行？“

场景B：团队花费两个月做好了一套登录系统，且已经被客户成功验收了，结果过了两天客户跑来说：”哎呀我之前没想好，我觉得微信登录这一块得重做。咱们是敏捷团队，肯定没啥问题吧？“

场景C：迭代开始后，客户突然要求所有人停下手中的工作，去抢修一个生产环境的bug。奋斗两天后bug终于修好了，客户却告知团队原先的迭代计划也必须要完成，理由是”敏捷团队嘛，你们每天少开点会，多干一会儿活肯定能补回来的。“

以上的场景只是冰山一角，当客户或者团队的敏捷素质普遍不高的时候，”敏捷“通常只会成为一个空泛偏激的理解，是客户随意改需求的理由，也是团队成员偷懒，不愿写文档的借口。

作为敏捷团队的项目经理，我们必须要身兼数职，既要做客户和团队的敏捷教练，也必须要以scrum master的身份，将真正的敏捷实践融入到项目开发流程当中。今天要着重分享的，便是在项目规划阶段，以及执行过程中如何通过贯彻敏捷思想去做交付计划。

为什么要用敏捷交付计划?

用敏捷的思维去做项目的交付计划是快速响应市场环境变化的最优对策，相对于预测性计划或者说瀑布式的计划它具有以下几个非常明显的优势：

1. 能够应对在交付开始后的优先级改变，并接受在整个项目开发周期的需求变更，快速修改计划

2. 能够在需求尚未完全清晰的情况下完成计划，并通过适应性生命周期的开发方式渐进明细，最终在规定的时间盒内完成交付

3. 能够通过MVP的短周期形式向客户提供增量式的商业价值，在计划阶段清晰标出里程碑

那么，具体要怎么做才能体现出以上几个优势呢？

需求收集阶段

任何的项目都源于原始需求，在需求收集阶段，敏捷项目经理需要和商业分析师紧密合作，力求在项目初期收集到尽可能多的需求，对于项目的整体范围有一个相对清晰的理解。如果想要达到最佳实践，需要做到以下几点：

敏捷宣言强调交流，弱化文档，最好的收集需求的方式是客户或者产品经理能和团队面对面坐下来，进行充分的讨论和协同设计，在尽可能早的阶段达到一定的align。为了达到这个目的，任何的前期投资都是必要的 （飞机票或者酒店贵？这笔钱花的超值!）。

采用撒网 – 收网的收集方式。不要一开始就拘泥于需求的细节，而要更专注于big picture，充分理解完整的流程。

尽可能的收集相关信息，比如项目的假设、风险、依赖和一些限制条件

以下是一些常用的敏捷工具，可以很好的帮助团队完成需求的收集，我以后会专门写文章来详细介绍它们的用法：

用户旅程地图（User Journey Map）

User Journey是在需求收集工作坊里最常采用的工具之一，它通过关注实际用户的完整交互体验来完成设计，发现需求和痛点。使用用户旅程地图的一大好处便是可以从全局出发，由大至小的去总览整个项目，确保不漏掉关键的史诗级需求和功能。以下是一个常见的用户旅程地图的操作指南：

先为产品完成Persona和场景设定。 找出将用于旅程地图的关键用户角色,为整个User Journey活动做准备。

准备好一大卷纸或者白板,用于绘制顾客旅程地图,并且要 可以在整个工作坊期间粘贴即时贴

在水平方向上,标记出整个生命周期中的关键舞台(例如: 触发点,考虑因素,支付,消耗,拥护）

在垂直方向上标记出和顾客接触的渠道,例如媒体、商店、 在线或是电话中心

用不同颜色的即时贴,识别出接触的层级,例如痛点,奖励, 以及行动

作为一个团队,邀请参与者为顾客旅程每个舞台贡献他们自己的见解

史诗故事（Epic Story）

用户故事(User Story)是敏捷开发的基础，它从用户的角度来对需求进行描述，而史诗故事可以看做是颗粒度较粗的用户故事集。比如”注册“就可以理解为一个史诗故事。在项目初期，需求往往还不明晰，如果强行写用户故事可能会产生无法定义验收标准（AC）的情况，这个时候史诗故事便可以很好的缓解这个问题。史诗故事通常没有细致的AC，它的估算往往通过专家经验（合理的拍脑袋）的进行。史诗故事可以帮助团队在不完全了解需求细节的情况下进行估算和计划，然后在交付阶段对其进行再分解和精确估算。需要注意的是史诗故事也必须满足INVEST原则。

RAIDs分析法

RAIDs分析法是在项目初期以及项目交付过程中记录和跟踪项目相关信息的重要工具，非常的简单实用。简单来讲它就是一个四分图表，从风险(Risks)， 假设 （Assumptions）, 问题（Issues）以及依赖（Dependencies）四个维度来识别项目的相关信息。这些信息对于项目计划的缓冲设计以及估算的精确度都有着非常重要的影响，是敏捷计划中不可缺少的一环，并且建议越早做越好，并且在整个项目阶段持续更新。

排列需求优先级阶段

软件开发里一直有一大误区，便是绝大部分的团队都喜欢先对整个项目的各个需求进行估算，然后再进行需求的优先级排列，其实这是一个错误的操作步骤。 需求的优先级应当永远以商业价值、用户体验以及功能的依赖等作为输入，交付层面的信息永远都不应成为决定因素之一，只有这样才能真正的实现以用户价值为中心的开发理念。那么，在需求优先级排列阶段又需要注意哪些事情呢？小马哥大概总结了这几个原则：

商业价值驱动原则。除了上面说的，项目经理必须具备战略层面的视角，看到功能背后的商业价值。

MVP原则。高优先级的需求集必须是一个能够独立上线的完整产品，这是敏捷持续交付的核心。

关注依赖原则。尽管我们尽量符合Invest原则，但在软件开发中，由于组织架构或者系统复杂性的原因，互相依赖的需求总是会存在，而项目经理必须确保处于被依赖方的需求要排在依赖方之前。

前两个原则往往需要项目负责人或者产品经理的高素质产出，但是项目经理对于第三原则是有绝对的发言权和责任的。通常在一些大型的IT公司中，部门的划分往往并不和业务线高度吻合。比如一家大型的游戏公司可能服务端和客户端就是两个不同的部门，这就导致了在做一款大型游戏时依赖的必然存在。 为了化解这种依赖带来的浪费和损失，项目经理必须在计划阶段完成依赖的识别。具体的依赖方式通常有这么几种：

完成到开始 （Finish to Start） 即前面的活动完成了，后面的活动才能开始。这个最常见。

完成到完成 （Finish to Finish）即前面的活动完成了，后面的活动才能完成。比如单元测试和代码的提交

开始到开始 （Start to Start） 即前面的活动开始了，后面的活动才能开始。通常用于并行但共享资源的两个活动

开始到完成 （Start to Finish）即前面的活动开始了，后面的活动才能结束。比如新的系统上线了，老的系统才能关掉。

需求估算阶段

敏捷需求的估算是一套复杂的方法论，但它也并不难操作。项目经理只需要强调一点，并让团队充分执行便可以了：估算是有依据有道理的猜测。

敏捷项目的估算分为迭代级别的估算和项目初期的整体估算。在项目初期的估算其实并不要求花费太多的精力，也不要求太高的精确度，这是遵循了提高效率，避免浪费的原则。敏捷之父Martin Fowler说过：””Estimation is valuable when helps you make a significant decision”。只有当团队对达成一个目标的工作量以及完成它之后的“收益”有明确的认知， 才能做出明智的决定。所以关键点其实在“达成一致”而不是”精确的估算“。

因为，就我个人的经验而言，项目初期的精确估算是并不存在的，并且它遵循如下原则 （请原谅我拙劣的画技）：

“二八原则”一定是这个世界上最伟大的发现，小马哥认为对于项目初期的估算，我们只需要投入团队20%的资源就能达到80%的效果，而这对于适应性生命周期的敏捷开发而言，其实已经足够了。

关于估算我会另外专门写文章来详述，这里就抛砖引玉啦。

计划阶段

终于，在完成了以上的一系列操作之后，我们终于进入了制定计划阶段。如果你认真的执行了上面几个阶段，并达到了预期的效果的话，相信你一定会发现：哎？怎么感觉做计划其实很简单的样子？？是的，在完成了所有的紧前活动后，真正计划的制定其实只是一个整合的过程而已。

不信的话，和我一起来试着看一下这个标准的敏捷交付计划(真实的计划会比这个复杂很多，但意思到了就对了哈)：

这个计划大概体现了如下一些元素：

来自移动端，网页端和平台不同用户场景的全景式需求 （需求收集阶段）

需求的优先级排列以及依赖 （需求优先级阶段，FS, SS, SF, FF都有体现）

粗颗粒度的估算 （需求估算阶段，严格意义上讲只精确到了月）

项目两大里程碑分别为网站，安卓和IOS产品的上线 （需求优先级排列阶段，两个里程碑充分体现了MVP原则，每一个里程碑都是一个可以上线的产品级交付）

这个计划跟很多瀑布计划的甘特图比起来看似简陋，但其实却表达了敏捷交付计划的本质：我们关注的永远都不是计划本身，而是支持计划制定的一系列的核心要素。一旦搞清楚了这些核心要素，我们便拥有了应变的资本，在每一次变更到来的时候，我们便可以用充满信心的去拥抱变化，而不是束手无策。

轻量级项目管理计划或者规则

最后，即使再敏捷的项目，都需要制定最基本的一些管理规则，来保证项目计划能够在可承受的带宽里面进行变更。毕竟哪怕是弹簧，也有自己的极限。和传统项目管理需要制定详细的管理和变更计划相比，敏捷项目管理计划满足以下一些特征：（都是实践出真知的干货哟！）

轻量级，往往并不会单独写一个计划，而是将其归类到WoW （Way of Working）文档中。

并不会制定专门的变更计划，敏捷拥抱变化的本质并不会随变更范围而改变，所以并不提倡用文档来约束变更。但同时，项目经理需要对敏捷素质不高的客户或产品经理进行一些基本的敏捷训练，确保他们对于变更的理解，并保持高效的沟通来尽早识别变更的可能性。

专注于对每个迭代的管理。敏捷开发以迭代为周期，理想情况下每个迭代作为一个短开发周期，不提倡进行大范围的需求变更和计划更改。如果有变更往往会通过更改下一个迭代计划的方式来实现。从这个角度来考虑的话，每个迭代周期的长短其实也反应了团队应变带宽的程度。

必要的文档：变更的记录。 虽然敏捷不那么重视文档，但是对于变更的记录也是非常必要的。作为敏捷项目经理，我们可以通过用户故事卡（物理或者虚拟）等形式对于变更的需求进行记录，这样更方便于风险与范围管理等。

以上就是完成一个敏捷项目计划的手把手指南。以后我会写一些具体工具的推荐和实操手册，不过我相信，只要你能掌握敏捷交付计划中几个阶段的实践原则，搞定客户，带领团队实现目标是一定木有问题的！

更多有趣的文章，欢迎来小马哥的个人网站：www.himateng.com