现在敏捷项目管理比较火，越来越多的组织和人士探索并应用敏捷思想到实际项目管理中，这对项目管理的发展是好事，传统项目管理似乎有些束缚，大量的文档、会议、流程，让众多项目团队忙得焦头烂额，敏捷项目管理更注重人的因素，更关注客户价值，似乎抛弃了文档、计划等一些传统因素，尤其让开发人员感觉到了久违的自由。

今天我们就聊一下敏捷开发与开发计划制定的话题。

我身边就有大力推行敏捷项目管理的同事，该同事A负责研发管理，带领好几个开发人员，项目经理新接手一个项目，进行完初步的需求调研与分析工作以后，研发经理A出马了，要求组成4个敏捷小组，管领导要人，每个小组有前端、后端、移动、测试等人员，领导大力支持，说给你配人。

项目经理在客户现场，客户问你们什么时候开发完啊？

项目经理赶紧问A，A来一句，我这里都是用户故事，敏捷开发，用户故事开发完了，项目就开发完了，至于什么时候，我不知道。

项目经理一听，傻眼了：你倒是好说，我怎么跟客户交代呢？

敏捷开发，到底需不需要开发计划呢？每2周一个迭代，到底啥时候迭代完？

其实不管敏捷项目管理还是传统项目管理，其最终目的，是为了交付项目，为客户、为公司创造价值。

想到了《高效能人士的七个习惯》里提到的“以终为始”，意思是开始做一件事的时候脑海里要对结果有个预期，然后根据这个预期结果去开始，去展开行动。

就项目管理而言，实现项目目标，就是这个终，而一切活动或工作的开展，都将围绕这个终来进行，所以，敏捷与否，只是形式，核心还是要交付项目。

那怎么交付项目呢？

项目经理主要做的工作还是沟通，跟各种利益相关者沟通，其中，客户可能是最关键的利益相关者了，怎么去跟客户沟通？一定是拿着对客户有益的好处去跟客户沟通，不然谁闲得有空搭理你、帮助你？沟通的时候，得有点料，比如项目计划、里程碑节点，总不能全是靠嘴，显得太虚了。

客户问到时间节点的时候，项目经理得拿出清晰的项目节点，路线图，给客户讲，什么时候交付什么成果，让客户看到希望，他也好向他的领导去汇报。这就需要有计划。

从这点上来说，项目管理必须有计划，那么，敏捷开发在哪里？别着急，敏捷开发还是很有必要的，也非常有价值。

在以前的文章中我提到过，项目计划是怎样做的，一般来说，是分三级来制作。

在本文里，可以叫做多层次计划，分别是高层级的长期计划，时间往往长于半年、一年，只包含关键里程碑节点，这个计划是签合同的时候就定好的，阶段验收和回款，是按照这个计划来的，这个计划基本不会改变，是死的；

其次是季度里程碑计划，以3个月为周期，细化了里程碑的颗粒度，也是交付的相对重要的成果物；

最后是迭代计划，这里一般按照月度、双周来滚动了，这时，就可以应用敏捷开发了。

由此可见，敏捷开发的迭代，是作为落地执行的计划，通过敏捷的方式，来实现一个个里程碑，从而完成项目交付。

制定前2个计划，可以使用excel、project、EdrawProject等软件，便于提供给客户查看，后1一个迭代计划，则可以使用一些敏捷项目管理工具来创建，例如tower、worktile等软件，结合看板、每日站会来实施计划，敏捷开发。

回到研发经理A的回复上，即使是采用故事的方式，也需要按照计划来分解，划分故事，交付成果，而不是为了敏捷而敏捷，一敏捷起来，啥都不管了，这样就无法交付项目了。

现在回头看一下A负责研发的项目，已经严重延期，项目成本严重超支，可见敏捷也不是万能的，而且还存在用得好、用不好的问题。

如果经历过大型项目，就很容易发现，越是大型的项目，越采用传统项目管理模式。而敏捷项目管理，通过多层次的计划制定，可以与传统项目管理结合，用于快速交付优先级不同的功能。

头条号/公众号：项目管理沉思录，专注分享项目知识技能、实战经验，关注程序员发展规划，欢迎对项目管理感兴趣的朋友关注，共同探讨，开启更精彩的人生。