首页>
广州慧翔企业管理咨询有限公司pmp培训，坚持只做对学生有用的内容原创
2018年第六版PMBOK在中国大陆地区出版后，考生们发现在这版PMBOK中，大量引入了敏捷项目管理的思维和管理理念，有很多在敏捷项目管理中常用的工具技术也引入作为第六版PMP培训的重要补充内容，今天我们就来谈一下什么是敏捷项目管理，出现在第六版PBMOK中的“用户故事”又是个什么样的工具和技术，应该如何展开。
什么是敏捷项目管理？
从中文的字面意思不难理解，敏捷代表快速响应，快速行动。快是它的核心，敏捷项目管理在很多方面都很好的诠释了“快”。敏捷项目管理思想在什么情况下适用：当面对项目范围不明确，且种类相关方需求快速变化的环境下，最适用敏捷项目管理理念。
敏捷项目管理在上述的环境中能体现出哪些优势？
1、降低项目风险,使风险更为可控
风险是项目的特征之一，pmp培训知识体系告诉我们，风险是由项目的不确定性带来的。对于范围不明确，需求变化又敏捷调整的项目显然风险更大，不确定性更强。在这种项目中，早期就根据有限的信息或是“不定性”的需求，完成项目的完整详细规划再展开项目工具的可行性很低，以这种思路管理这类项目本身就是危险的。敏捷项目管理强调在这种情况下，尽可能缩短和压缩前期需求调研和规划的周期，强调以有限的信息进行快速规划、快速设计、快速交付、快速反馈、重新规划、迭代开发、重新反馈、重新规划。在这种情况下缩短反馈周期、减少误解、降低修正错误的代价、确保正确研发方向，根据用户体验，验证适应变化是。
二、敏捷项目管理的的几个核心思想
第一点：敏捷项目管理强调人和相互面对面交流效果远胜于用流程和工具进行交流。
第二点：让用户体验实际可用的产品做出反馈效果远胜于编制各种综合性文档，将项目精力重点放在可执行程序上。
第三点：和项目相关方尤其是客户进行合作觖问题，效果远胜于合同谈判。
第四点：能够快速适应变化效果将远胜于按部就班。
三、敏捷项目管理过程中经常涉及到的3个角色
产品负责人（Product Owner，简称：PO）有时候称为产品经理
Scrum Master/技术leader（简称：SM）技术领导，技术负责人
Scrum团队（包含前后端开发，测试，设计，运维等，前2类为全职项目工作岗位）
四、敏捷的3个工件
第一点：产品Backlog（Product Backlog）：产品Backlog指根据初始需求分解出的任务列表，包括功能性和非功能性的所有功能，由Product Owner为Product Backlog中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。
产品Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之制定一个充分、详细而包罗万象的计划。可行的方式是，先为一个项目写下所有它该具备的显著特性和功能，数量不必很多，做好能保证团队的第一个Sprint有活可干。
第二点：SprintBacklog：随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也会随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。
第三点: 产品增量（Increment）
四、敏捷项目管理中常开的的几种会议（与pmp培训常见会议略有不同）
1、Sprint计划会议（Sprint Planning Meeting）
2、每日站会（Daily Scrum Meeting）Sprint
3、评审会议（Sprint Review Meeting）Sprint
4、回顾会议（Sprint Retrospective Meeting）
五、敏捷项目管理的5个价值
1、承诺 – 愿意对目标做出承诺，这和PMP培训理念完全相同。
2、专注– 把所有思考力和行动力都用到所承诺的工作中去
3、开放– Scrum 把项目中的信息公开透明给每个项目团队成员（广义和狭义）
4、尊重– 每个人都有他独特的背景和经验
5、勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
六、那么什么是敏捷项目管理中的用户故事?
用户故事描述对用户而言，系统或软件有价值的功能。
由以下2方面构成：
1、一个故事描述
2、验收测试
用户故事描述公式如下：2、验收测试
作为XXX，我想XXX，以至于XXX
pmp培训中标准写法样例：作为家电生产制造商，我们想通过网络电商平台尽可能多的展示我们的商品并且将商品信息以互联网手段主动推送给客户，以至于客户可以随时了解并通过在线支付来购买我们的产口由于原型已经构造出来，作为功能用户故事简写为：用户可以将需要购买的货物加入购物车。
验收测试用来验证实现的用户故事是否符合项目相关方特别是客户和用户的期望。它的作用类似于用于检查肉是否已经炖烂了的筷子。所以需要尽可能把所有满足此用户故事的情况都考虑进去。
单独的一个功能用户故事要尽可能的小，分解的大小需要遵循八小时原则，刚好满足一天的工作需求。对于需求多变的项目需要用前面我们讲到的每日站会及时的发现及修正问题，如果工作分解的足够小，显然修改起来也更容易，对于项目管理的其它因素造成的影响也相对较小。
这个过程的注意事项：在同一张纸上，正面描写用户故事描述，背面写验收测试。
用户故事编写注意以下六个特征：
1、独立的（Independent）：用户故事尽量避免故事间相互依赖。发现有用户故事发生依赖可以采用如下方法解决：首先可以将相互依赖的用户故事合并成一个大的独立的故事，然后用一个不同的方式去分隔故事，和开发人员一起讨论每个用户故事，是否有依赖。
2、可讨论的（Negotiable）：故事是可以讨论的，它不是签署的合约或软件必须实现的需求，细节处可以和开发人员以及客户团队讨论。
3、对用户或者客户有价值的（Valuable to Purchasers or Users）：“每个用户故事必须对用户有价值”，这句话听起来很吸引人，可那是不对的。比如“所有数据库连接要通过一个连接池”，这只是对开发人员有价值，并不是对用户有价值，用户只关心实现后的结果，比如“我可以修改个人信息”。
4、可估计的 (Estimatable)：可以根据开发人员以往开发过的功能进行大概估计，或者把故事再拆分小一点。
5、小的(Small)：前面讲过的一天工作量（8小时原则）。
6、可测试的(Testable)：便于用户操作，可以让用户独立测试的相关要求，界面友好，反应快速。
以上这些内容就是PMP培训知识体系第六版PMBOK中所提到的用户故事。
广州慧翔企业管理咨询有限公司原创 优培东方 禁止转载
粤公安备案 44010602008731号