2008年的小艾，一个刚入行的项目经理，渴望月薪过万，但是.......

2008年10月22日：

晚9点了，小艾头昏脑涨，其实这个“收银模块”早已上线，小艾今天被客户叫来谈优化需求，居然讨论了10个小时，客户天马行空，什么都要，可范围还是没有咬出牙印，明天早8点继续，生无可恋啊！

2008年11月8日：

大小需求38项，这得设计到什么时候，什么时候才能开发，这么大的需求，研发老大会不会把我骂死，我都能想到，“小艾啊，你介个需求咋谈得这么大，等着吧，排不上队哈”！

2008年12月16日：

“小艾啊，明天12月18，我们要跟业务口汇报，开发的怎样，明天先给我们做个Demo，后天我们好上会”，啥，小艾接到客户的电话后，想死的心都有了，啥Demo，刚做了设计，啥有没有呢，Demo的啥子嘛？

......

这些故事看着眼熟不？还是您正在经历呢？还是刚刚从业，要去准备接谈需求呢？艾姐（微信公共号：Ivy爱项目管理）带您读一本马克莱顿先生的《敏捷项目管理》，希望对您的困境有所帮助。

01 Agile Project Management 什么是敏捷

敏捷是一系列技术和方法的总称，他们具有如下共性： 1. 在多次迭代中开发，成为迭代开发； 2. 强调简洁、透明和因地制宜； 3. 跨职能、自组织团队； 4. 将可工作软件作为测量进度的标准 敏捷项目管理是一种凭经验主义的项目管理方法。换言之，在项目管理实践中，敏捷团队根据经验而不是理论来调整你的方法。

-《敏捷项目管理 第四章》

上述的敏捷定义，如果有些拗口，我们一起看一个简单的例子。艾姐在知乎跟微信公众号上都有写文章，我们就以项目任务目标为“在微信订阅号上发表艾姐的项目管理故事”来做例子吧。

项目任务目标：在微信订阅号上发表艾姐的项目管理故事。

面对这样一个项目任务，我们应该如何操作呢？是否需要将微信公众号的后台操作，各种功能，各种规范全部都研究透彻后，然后在各种摄图网站上开满账号，购买图片，然后在各种微信信编辑器开通账号，购买模板成为黄金会员，再开始着手准备内容材料，着手写第一篇文章吗？可能多数老写手们看到这样的流程会心一笑，应该不会使用这种“瀑布串行”的模式，更有效率的方式又可完成任务目标的方式是什么呢？

第一阶段：

1. 完成微信订阅号（Ivy爱项目管理）的开通，个人用户的开通很容易；

2. 登入微信订阅号后台，打开图文管理；

3. 着手文字内容编辑；

4. 寻找与内容相关的必要图片（可选）；

5. 看看有没有错别字，填入标题作者，点击保存并群发；

第一阶段里程碑完成，任务目标达成：在微信订阅号上发表了第一篇艾姐的项目管理故事。

第二阶段：

1. 网上寻找合适的微信公众号的排版工具，选择合适文章内容的模板；

2. 在排版工具中使用模板，填充下一篇故事文章；

3. 同步至微信公众号；

4. 在微信公众号图文管理中，选取并浏览同步内容，如有错位适当调整后，保存并群发；

第二阶段里程碑完成，任务目标进一步达成：在微信订阅号上发表了第二篇艾姐的项目管理故事，图文并茂，排版布局合理。

第三阶段：

1. 已有有两篇文章，仍然在不断填充新的图文发表；

2. 开始研究微信公众号的更多后台功能，开始关注用户订阅数量，查看“用户管理”；

3. 文章多了，要考虑结构与往期内容了，那么开始设计公众号“自定义菜单”，“关键词自动回复”等功能；

4. 同时写的文章多了，可能需要考虑购置图片或者使用免费但需署名的图片，开始浏览更多的摄图专业网站。

第三阶段里程碑完成，任务目标进一步优化：微信订阅号加入菜单，内容更加丰富。

这样的结构下来，是否项目任务达成，同时更有效率与成就感呢？这就是使用“敏捷”这个概念了。

其实敏捷这个名词并非先有理论再有实践的，而是业务，特别是IT软件、互联网产业的实际工作模式下，自然就要有这样的要求。当艾姐还是学生时代，在最初接触软件工程时，传统的“瀑布”模型是教科书中的主体内容，而随着互联网，IT产业的蓬勃与发展，成熟的软件产品日益丰富，从需求收集到开发上线的自主开发项目日益减少，更多的是使用成熟产品加之本地化的开发，以便快速的适应市场与客户的需要，“敏捷”已经成为必须，并对传统方式进行了替代。

为适应频繁的检查和调整，敏捷按照“迭代”的方式，就是把整个项目分解成更小的片段运作。在敏捷项目中，仍然需要执行与传统瀑布项目相同的工作：创建需求并设计开发，并与其他产品集成。

02 Core Value 敏捷的核心价值

价值1：个体和互动高于流程和工具 价值2：可工作软件高于详尽的文档 价值3：客户合作高于合同谈判 价值4：响应变化高于遵循计划

-《敏捷项目管理 第二章》

在开篇的悲惨故事中，小艾作为一个初级项目经理，面对客户的收银模块的优化需求，敏捷方式的价值如何体现？

个体和互动高于流程和工具

小艾作为初级项目经理，可能对产品设计与模块开发并不熟悉，仅有项目经理独立面对客户天马行空的需求，并不合理；这个时候应该形成必要的行动小组，由产品，开发，小艾，与客户干系人组成，判定38项需求中是否对本次的开发目标均有必要，以清晰的面对面沟通方式，合理的划分需求优先级的高中低。小艾做为项目经理，在这里做必要的项目会议输出文档，交付双方确认。

可工作的软件高于详尽的文档

拿到客户38项需求，梳理出需求中的优先级。小艾作为初级项目经理，是否应该与产品经理坐在一起开始编写38项“产品定义说明”书呢？答案应该是NO。根据梳理出的高中低优先级后，在高优先级中，与行动小组一起讨论并记录任务难度，在所有高优先级的任务项目中，列出任务量大中小（即工时估算），综合考虑可交付的情况，产品经理优先定义高优先级任务（除非任务间有强关联关系，可调整），与研发经理确认资源，计划排产周期（制定本次迭代目标）。小艾作为项目经理，在这里做好沟通协调，整理任务优先级与排产计划表后，与客户进行沟通与情况说明。

同时专业人员做专业的事情，共同制定迭代目标后，将由产品与研发对目标进行开发，在开发的过程中，一般说来，繁杂的文档确实影响交付效率，但是建议可以以Technical Notes的方式对本次开发进行主要说明，例如增加的字段，以及主要逻辑，与测试建议。

客户合作高于合同谈判

传统的项目管理，对项目经理的要求是，“按时按量按钱”完成合同内的工作内容。这个原则没有问题，但是在实际复杂的项目过程中，一定会出现超出立项初期对产品或工程落地的范围要求。当小艾的收银模板优化需求从38项，增加至38.5项，如何处理？每每出现这种情况时，如果不是严重违背各方利益的情况下，建议从业务的实际要求出发，增加的0.5项是否对最终用户的使用有很好的用户体验帮助，如果有，那么值得做。而不是，拿出合同咬定范围，因为聚焦合同，将使客户与项目组之间形成对立关系。艾姐记得自己合作的一位资深客户经理的一句话，“跟客户扣合同，那永远都是最后一件事儿了！”

同时与客户的合作，也在与长期关系的培养，也是情商在项目管理中的应用价值。艾姐写过的一个小文章，可以供大家参考，书评《高情商的项目经理》。

响应变化高于遵循计划

实施整体变更控制是项目管理PMbok中项目整合管理知识领域中过程之一“实施整体变更控制”，要求“审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程”。别急，在你被这些文字弄晕之前，幸好，这不是今天讨论的细节。简言之，是通过变更控制保证项目在可控范围内遵循项目计划进行。但是在艾姐过去的十几年接触的项目中，现实是，多数低级别的优先级通常在项目的进行中会发生变化，通常也一定存在比项目计划中高优先级更高优先级的任务出现。

所以在小艾在面对38项优化需求时，与团队，与客户在确定高优先级的同时，要考虑到高优先级是否可以组合成一个可交付功能，可以与客户呈现，通常在可见的成品上，客户的需求会进一步修正。作为项目经理，应积极地响应这种“修正”，进行分析与计划调整，当然提前是这种修正将为最终用户带来实际收益，对“天马行空”也要说NO。

03 Srcum and Sprint 敏捷框架

方法1：精益 方法2：极限编程 方法3：Scrum

-《敏捷项目管理 第四章》

精益的重点是实现商业价值和是产品开发之外的活动最小化。主要方法包括：

1. 不开放哪些不大可能使用的特性； 2. 以开发团队为中心，因为他们创造的价值最大； 3. 让客户确定特性的优先级； 4. 利用工具来支持并优化有关各方的沟通；

极限编程的重点是客户满意度，原则包括：

1. 编码是核心活动； 2. XP团队做大量测试； 3. 让客户和程序员之间直接沟通； 4. 对于复杂的系统，超越任何具体功能的、某一层次的总体设计是必不可少的。

Scrum是软件开发中最流行的敏捷框架，是一种迭代的方法，核心是冲刺（Sprint），为了支持这一过程，Scrum团队使用特定的角色，工件和事件。

Scrum角色

产品负责人：带边项目的业务需求方； 开发团队：执行日常工作； Scrum主管：负责保护团队远离组织的干扰。 此外，Scrum团队与另两个非Scrum特定角色（感谢人，敏捷导师）一其密切工作，会更有效或高效。

工件（有形的可交付成果）

产品代办列表：完整的需求列表； 冲刺代办列表：一个给定的冲刺中的要求和任务列表； 产品增量：可用的产品。

事件（关键会议）

冲刺计划会议：在每个冲刺开始之前召开； 每日例会：每天召开，时长不超过15分钟； 冲刺评审会议：每个冲刺结束时召开； 冲刺回顾：每个冲刺结束时召开，与上述的不同在于这是个内部会议，主要对本过程中的好与坏进行回顾，是否需要在下一个冲刺中优化或改进。

理论知识介绍完了，我们以当下较为流行的Scrum框架，来一起看看让小艾头疼的事儿怎么办。从2008年10月，11月，12月的三个故事实例，其产生的原因分别为：项目范围的界定问题，产品代办任务的安排问题，以及工作展示与交付的预期问题。

敏捷核心价值体现之敏捷项目范围管理

让小艾觉得需求范围的讨论天马行空，看不到头，主要是因为，通常在一个新项目开始的初期，既然立项，从客户的角度自然尽可能的希望把需求包括的更加全面，避免遗漏，希望付出的成本得到最大的收益；那么作为任务的服务方或者执行方，自然希望任务的定义明确（因为这个时候，可能对产品的需求怎么落地尚未有明确的准备），或者说有限数量；由于这种期望的偏差，自然会使得在项目范围的圈定上会太过发散，讨价还价，难于达成共识。按照传统的项目范围管理的理论，项目经理就是要合理与客户明细项目范围，但是鉴于我们提到的这种双方的期望偏差，需要使用新型的，更符合IT项目实际的范围管理方式。

1. 需要与客户澄清，减少客户的顾虑，不会存在项目交付过程中不允许变更的情况或追加惊天费用；其实我们经历过较多IT项目后，通常客户在初期提及的很多需求，在实施与实际上手后，会有所改变，需求被替换，甚至根本就不需要了。这是想与用的差异。
2. 在圈定范围的时候，双方形成合作关系，讨论形成需求列表并尊重客户的期望，一起形成需求的优先级，放入产品代办列表；
3. 分解与细化“近期的高优先级”代办任务，按照约定的冲刺时间周期，形成可交付的最好是“可使用”的功能集合。

下图为大家介绍了传统的项目范围管理与敏捷项目管理的差异：

敏捷框架下的组织结构与敏捷团队应对产品代表列表

敏捷框架的全面实施，是需要整个组织结构配合并认同的。涉及的职能部门，可能包括产品部门，实施部门，研发部门，客户支持部门等等。那么，在敏捷框架的组织环境下，当小艾作为项目经理与客户进行基础沟通后，建议组织项目人员组成“敏捷小组”，产品专员，研发技术代表，小艾（项目经理，或者说是项目督导员），在这里建议把对应的客户接口人也加入小组成为小组一员，以及高级顾问可作为技术专家以及敏捷交付指导；同时给团队创造条件，最好集中办公。

敏捷小组的首要任务是，明确记录38项需求作为产品代办列表，通过小组沟通确认高中低的优先级，并根据实际情况，确认合理的冲刺周期（例如，每周，每两周，或者其他）。在这里要综合考虑可交付的产品任务集合，是否按照高优先级形成的产品功能可交付最终用户核验或使用？有些项目可能会与其他项目有交集，是否要优先完成其他项目必要的前置任务，这是项目经理要组织敏捷小组（包括客户）一起探讨的重点。

在这个过程中，可能研发中心本身也是按照冲刺周期来进行排产的。现实世界里，资源永远是不足的，研发中心不会等着项目经理带回任务才开工的。所以当研发经理看到小艾带回没评估，没细节，没优先级的38项需求时，自然会有“抵触”情绪。所以，为了避免被研发老大K死，请：

1. 前期请研发代表参与任务细化，
2. 明确第一冲刺周期的任务项目，
3. 与研发团队讨论可排期的Sprint是也是很重要的一项任务。

对于敏捷团队里的项目经理或者说敏捷主管，艾姐多唠叨两句。在多年的工作中，艾姐很荣幸与高效能的团队一起工作，对仆从式领导感受很深。其实从团队的组成可以明确看出，Scrum主管也仅仅是团队的一个角色，需要有人员来承担这项工作任务。特别是与高效能，高水平技术团队成员一起合作时，无需审批产品说明书，更无需审阅代码质量，更多的是为团队提供支持，合理屏蔽组织或其他部门对资源或者本次冲刺相关任务的打扰，同时监控与流程推进。

团队角色，与优秀Scrum主管的特质小结请见下图：

敏捷框架下的计划发布与冲刺会议

合理引导客户期待的方式，减少小艾故事中始料未及的客户需要Demo或者交付的情况，就是与客户合作一起制定冲刺周期，工作展示，与计划发布。

那么哪些需求算是高优先级的评定，进入前期的冲刺周期呢？可以通过其严重程度，影响面积，发生频次来评估，当然比较流行的也有编制“用户故事”的方式，“用户故事”是指对需求的简单描述，特别要包含“为谁而完成”。针对一个“收银”优化的38项需求来讲，可能的最终使用用户会涉及前台收银，收银主管，财务等等。当然，请务必与客户核实与落实优先级，以及冲刺周期，虽然不能反复打扰客户，但是也要有多种形式，与客户对应的小组接口人强化周期交付的时间点，始料未及的惊悚事件，是任何人也不希望发生的。

但是：无论多么完美的计划，多么配合的客户，多么高效的团队，在现实的工作环境里，也可能会遇到为了赶上发布或者用户Demo而赶工期，追求速度的事件发生，只是一定要控制在尽可能小的情况下。

艾姐在带队的时候，也曾经为了追求速度，进行过“极限编程”，就是让客户（IT口的接口人）与程序员直接沟通，开发后客户可以直接验证测试。但是这样做，有直接的弊端，第一，没有对产品功能熟悉的人参加，本来可以通过已有的功能或工具完成，不必代码开发，反而无端加入开发工作量；第二，设计与技术文档没有传承，开发后验证，如果代码中再没有详细的注释内容，那么会为未来优化带来很大的麻烦，使得后续工作的程序员只能靠读代码才能明白之前的工作；第三，客户的对口人直接与程序员一起工作，在之后的任务分派上会有麻烦，产生一种不必要的依赖。所以建议项目经理要进行合理的判断，进行平衡。

有人说项目经理么，就是组织开会的，艾姐不支持也不否认，所以关于项目经理或者敏捷主管要召开敏捷会议，请注意：会议本身也是要耗时耗力的，所以对各种冲刺会议，限定时间提升效率。根据38项需求的高低优先级，在每个冲刺开始前与结束时，需要安排好定时的会议。在Sprint内，根据实际情况，需要限时碰头，及时了解是否其中有需要调整或协调解决的问题，以及整体的进度。

关于敏捷冲刺会议：

艾姐语录 IT互联网需要敏捷项目管理，艾姐认为局部重点任务也需要混合动力。不能为了追求敏捷，而在局部忽视传统流程方式（需求-设计-开发-测试-部署），可以结合必要的工具，例如Confluence，JIRA记录需求，设计，tech notes等。

理论教材： 《敏捷项目管理》 马克 莱顿

往期文章：

很幸运可以有机会与强大的团队一起共事，艾姐书评《高情商的项目经理》为你解读团队领导力。 - Ivy爱项目管理的文章 - 知乎 https://zhuanlan.zhihu.com/p/94203716

项目管理简单吧，做个饭就学会了！艾姐书评米泽创一《项目管理式生活》上篇 - Ivy爱项目管理的文章 - 知乎 https://zhuanlan.zhihu.com/p/92209826