PMP
计划! 计划! 计划!
转移
PMP 理论所要解决的场景, 是我们常见的传统的软件外包(包含内包). 在此场景下, 甲方将产品交付和项目管理的责任转移到了乙方.
对于甲方而已, 向乙方提供需求说明后, 剩下的事情就是乙方的工作了. 详细设计, 编码, 测试等一系列的工序后, 乙方向甲方交付可以满足需求的成果. 甲方如果满意, 验收. 大功告成.
整个过程, 对于乙方而言, 始终是以满足需求的最终可交付成果为导向的. 详细设计视为了分析甲方的需求, 编码是为了实现甲方的需求, 测试是为了验证是否完成了甲方的需求. 总之, 一切是为了满足需求.
甲方虽然将大部分的责任转移给了乙方, 但是为了控制和监控实施过程. 甲方比如会要求乙方提供关于如何满足需求的实施过程(含设计,编码和测试等)的实施计划. 而对于乙方来说, 提前做好各方面的计划, 也有利于明确项目的边界, 理清己方的责任. 所以, 要有计划, 而且会有各种计划, 需求, 成本, 进度, 干系人管理, 沟通, 变更流程, 都会做出计划.
计划
为了说明计划对于PMP 管理理论的重要程度. 给大家贴一张PMP 中经典的"九五之尊" 图. 可以看出, 大部分的过程, 都是归属于规划也就是计划过程组的.
核心理念
同时关注过程和结果.
虽然是结果导向, 但实现结果的实施过程, 也同样要得到重视. 实施过程与计划的匹配程度, 是考核团队尤其是项目经理(PM) 的重要指标.
符合计划的实施过程, 让甲乙双方都能够对项目的实施有良好的控制.
以干系人管理为中心.
每个项目, 都会影响一些人, 或者受一些人的影响, 他们被统称为干系人.
不同的干系人对项目有不同的影响和期望, 作为项目经理, 项目实施过程中需要始终关注和管理干系人. 对不同干系人的期望做平衡.
避免镀金或范围蔓延.
镀金和范围蔓延值的是没有经过整体控制的变更.
一种常见的场景, 团队成员觉得增加某种小功能, 如短信通知, 只需要调用第三方API 接口即可. 能够给用户带来很大的便利. 而这是合同中没有规定的需求. 交付后, 客户习惯使用短信通知功能后, 有一次重要的通知没有收到短信. 那这个项目是不是有问题的?
要有风险意识.
根据复杂性理论, 事情都不会按照我们的计划发生.
对于项目, 我们一定要在做计划时, 识别风险和规划风险的应对措施. 最常见的就是预留出一定的储备来应对将来可能会的风险.
前车之鉴, 后事之师.
由于计划是项目实施的核心和标尺. 以前成果的案例, 对项目就有很大的借鉴意义. 而以前识别的案例, 对项目来说, 也是能够学习到教训的宝库.
Agile
价值! 价值! 价值!
协作
Agile 实施的前提, 是客户与团队共同为产品交付和项目管理负责. 我们常说的客户要在敏捷现场, 至少也是远程协作, 就是这个意思.
客户会与团队一起承担从需求收集到验收测试的整个项目过程. 并在整个过程中给予团队反馈. 而团队也能给出自己的意见.
双方是以及早交付和快速响应变化为导向的. 及早交付的是有价值的成果. 响应的是对价值理解的变化. 总之, 一切都是为了价值.
从瀑布到敏捷
通过敏捷与瀑布的对比, 可以看出计划驱动和价值驱动的转变.
核心理念
Iteration
把项目的开发过程切分为固定节奏的迭代, 让双方聚焦于优先级高的价值, 保持对价值的敏感.
User Story
不同于瀑布中以开发视角描述的任务, 敏捷中的用户故事是站在能够给用户提供的价值的角度, 对项目工作进行拆解.
BDD
BDD 是价值导向在测试中的体现. 完成功能, 是以向用户交付价值来验收的.
Show Case
定期的给用户展示项目完成的价值, 让用户对产品有直观的感受. 以即使验收以及之后调整价值的实现路径.
CI/CD
为了能够随时能够向用户提供价值, 从代码提交到程序运行的间隔要缩短到极致, 也就是持续交付.
