下载掌阅APP，畅读海量书库
立即打开
正如《黄帝内经》提到的“上工守神，下工守形”，我们要获得每个实践指南的“神”，而不要拘泥于它们的“形”。将本来就定位不同的“神”整合，而不是让敏控项目经理面对丰富多彩的各类项目管理实践指南无从选择。我们结合目前比较主流的、最新的、各有侧重的通用项目管理实践指南给出了敏控项目管理一体化整合框架，如图3.2所示。
图3.2 敏控项目管理一体化整合框架
单纯关注项目管理容易走向过度控制的误区，单纯强调敏捷则容易走向个人自由而组织失控的局面，整合二者将兼顾组织受控和团队敏捷的诉求，这也是敏控项目管理的终极追求。
从图3.2可以看出，项目管理和敏捷实践指南的关注点并不相同，PMBOK是全球范围内最为人熟知的项目管理知识体系，类似于武器库，它可以帮助项目经理掌握项目管理的基本知识。PRINCE2是全球范围内应用最广泛的项目管理方法论，类似于阵法套路，它可以指导项目经理直接开展项目管理实践（MSP与PRINCE2一起使用来实现项目收益），但PRINCE2关注项目管理方面，对如何管理产品交付则涉及不多。敏捷实践指南恰好将重点放在交付层面，对项目管理方面反而涉猎很少。
项目管理和项目群管理的关系
随着项目管理理论的研究和发展，学界将项目进一步细分，提出了项目群的概念，认为项目只负责完成交付物，而交付物之后能否产生收益由项目群负责。在学术层面，我们有必要区分项目和项目群，这种区分有精细化管理的意义。但在实践中，对组织，特别是对组织的高层管理者而言，项目承接组织战略部署，项目管理就应该确保战略成功落地，就应该聚焦成果收益。本书谈及的项目并非方法论中狭义的项目，也参考了成功项目群管理方法论。
如此整合的挑战是，组织高层、项目管理团队、交付团队之间如何互相理解彼此的理念，如何相互支持彼此的方法。
例如，组织高层希望看到项目的周报，以确保项目受控。在他们的传统认知中，周报应该是正式的。而在敏捷实践指南中，组织希望各种信息透明、可视化、易学习，以提高沟通效率。那么，高层能否接受敏捷思想，愿意通过非正式的项目周报获得项目进展信息，甚至移步到项目管理团队的工作区域，通过现场白板上的可视化信息快捷地获得项目进展呢？毋庸置疑，这对传统职能型组织中的项目经理是个挑战。
反过来，交付团队能否理解项目管理的出发点是为了让项目受控，从而能够主动从高层的视角，将他们需要的信息，采用易学习且可视化的方式展示在现场白板上，以便高层及时获得，而不是仅体现产品交付所需的信息？这对采用敏捷实践指南来完成产品交付的团队来说，也是个挑战。
由此可见，要想真正做到项目既敏捷又受控是不容易的，需要项目经理理顺实践指南之间的关系，参照整合框架，适应敏捷受控的价值观挑战。
反面教材——“传统项目管理”是什么
我们经常看到敏捷或项目管理实践指南将自己与“传统项目管理”进行比较，以此说明自己的优势。那么，所谓“传统项目管理”到底指的是什么呢？
简单来讲，传统项目管理与敏捷项目管理的区别就像乘坐火车旅行与乘坐船舶旅行。乘坐火车旅行的预测度较高，可以严格遵守计划、执行、监督、结束的瀑布式路径，而乘坐船舶旅行则不然。因为我们不知道乘坐船舶的途中会发生什么，很难预测并计划到细节，所以只能规划起点和终点，并制订一个整体的、粗颗粒度的计划。有经验的高水平船长知道他在哪里，并在整体计划的框架下根据当时的情况不断调整航向（拥抱变更），以确保抵达终点。并没有一个主流的项目管理理论承认自己是传统项目管理，PRINCE2如此，PMBOK亦然。实际上，PRINCE2既可以应用在传统项目管理实践中，也可以应用在敏捷环境下。
项目开发方法是在项目生命周期内创建和演变产品、服务或成果的方法。因为使用的开发方法不同，不同的行业可能使用不同的术语来表达各自的开发方法。三种常用方法是预测型方法、混合型方法和适应型方法（敏捷型方法）。这些方法通常被视为一个频谱，从频谱一端的“预测型方法”到另一端的“适应型方法”逐渐变化，如图3.3所示。
图3.3 项目开发方法频谱
采用预测型方法时，通常需要更加重视预先规划、测量和控制。在项目开发方法频谱的另一端，适应型方法（敏捷型方法）通常先交付MVP，然后通过迭代持续交付价值。
项目交付物的类型决定了选择何种开发方法，接下来从两种类型的项目交付物出发，用示例说明自定义敏控项目开发方法。
某互联网公司业务导向型项目开发方法
一般情况下，业务导向型项目是通过运营一系列业务策略，促使业务的一个或多个业务指标数据提升，进而带来成果收益。项目交付物是一系列经过验证的业务改善策略，项目成果是业务指标数据的提升。此类项目一般会先确定业务年度末要达到的数据目标，然后再将目标拆解到每个季度，这个过程采用预测型方法，通过明确每个季度要完成的目标进行监控。而在每个季度内，采用适应型方法（敏捷型方法），通过持续迭代交付上线相关业务运营策略，促进业务指标提升，进而达到季度目标。业务导向型项目开发方法如图3.4所示。
图3.4 业务导向型项目开发方法
某互联网公司App日常迭代项目开发方法
为了适应公司内部业务发展和外部商业环境变化，成熟的App产品通常要保持日常的功能迭代，持续优化App用户体验，一方面促进现有业务发展，另一方面积极探索孵化新业务。项目交付物是持续优化的具体功能点，项目成果是提升用户体验或孵化出的新业务，开发方法采用适应型方法（敏捷型方法），即基于工作流转的单周迭代方法。根据团队各角色资源、上游输入等优化交付流程，最大限度地减少下游团队的等待时间和资源浪费，优化团队协作效率和可交付物的产出量，动态持续交付。敏捷型单周迭代方法如图3.5所示。
图3.5 敏捷型单周迭代方法
敏捷型单周迭代方法
所谓单周迭代，就是把团队各角色[包括产品策划、交互设计、视觉设计、后台开发及测试、双端开发及测试（安卓和iOS）]的工作时间盒固定在一周内，每个环节完成后交付下游环节一周时间内完成，使各环节工作流转化，每个环节循环交付，减少各环节等待时间，提高可交付物产出量。
在单周迭代方法下，团队的工作安排基本上是在固定的时间点：每周一需求收集；每周二需求优先级评审，确定下一个周迭代需求清单；每周三后台集中评审，经过一周后台开发和测试，后台接口上线；同步视觉设计完成，下周三双端启动会评审，双端经过一周开发和测试，本次迭代交付，进入下一个单周迭代周期。
迭代交付不等于版本上线，代表了版本集成可交付能力。为了节省集成测试资源，团队安排三周迭代集成发版一次，当然也可以随时按需集成发版。
采用单周迭代，通过每周固定时间评估需求优先级，确保高价值需求优先进入迭代开发，实现了价值持续交付。