问题

有朋友向我咨询关于认证方面的问题。他们问:"Scrum和PMP，该学哪个？Scrum和Kanban，该学哪个？” 我这样回答：“你的业务环境是怎样的？你需要解决什么问题？你希望在什么方面有所改善？一把钥匙开一把锁。业务环境不同，需要解决的问题不同，需要采用的方法也不同。”

软件开发活动包括从创新型产品开发到现有产品维护和支持等各种工作，我们逐个分析。

分析

创新型产品

创新型产品开发的业务环境是不可预测性大于可预测性。例如，产品需求不明确，能够明确的通常只是产品的愿景，一个大概的方向和蓝图。产品具体要有哪些特性，不同的人有不同的想法，很难说的清。在产品开发的过程中，客户需求又存在很多变数，很难说的准。客户满意的产品到底是个什么样子？等到产品开发完成了，客户真正满意了，我们才能知道，"哦，原来客户想要的产品就是这个样子！”

开发令客户满意的产品，不能靠碰运气。恰好猜中客户的需求，就像中大彩一样，是极其理想的情况，也是及其少见的情况。我们需要解决的问题是，如何才能持续的获得到客户对于产品的实际体验，让客户理想的产品的模样逐渐浮现出来。所以我们需要采用迭代开发的方法，每个迭代产出可以工作的软件，让客户体验我们的产品，给我们提出反馈意见。像做科学实验一样，我们首先假设客户喜欢某些产品特性，去探索一下。然后通过让客户体验，去感知客户喜欢哪些产品特性，不喜欢哪些产品特性。最后根据这些感知及时调整方向。就这样重复"探索一感知一调整"的循环，摸着石头过河，走一步看一步，收集越来越详实的客户反馈，从而开发出令客户满意的产品。Scrum就是这样一种开发方法，特别适合创新型产品的开发。

现有产品维护和支持

现有产品维护工作包括修复缺陷，为客户添加一些定制化的小特性，也许还要优化软件性能。这样的业务环境，需求是明确的、具体的，不需要"探索一感知一调整"这么麻烦。这种业务环境，Scrum可以用，但不是最优的解决方案。缺陷什么时候被发现，客户什么时候要求添加新特性，这些都在事前难以预料，产品用着用着，发现了缺陷，就报告到开发团队这边了。用户灵机一动，说我想添加一个这样的特性，就要求开发团队添加。所以从维护和支持邀请到来的时间上来看，不可预测性大于可预测性。

我们需要解决的问题是，怎样用最低的成本，提供最优质的维护和支持服务。所谓最优质的维护和支持，包括但不限于，优先级方面，重要客户的重要服务邀请，要优先响应；时间方面，缺陷修复的快，客户要求响应的快。然而，在不增加成本的情况下，人少事多，怎么才能保证优先级，提高响应速度呢？我们需要做到至少2点：首先，工作流程可视化。有多少个邀请，哪些优先级最高，要能够一眼看的见。一个支持邀请在哪个环节堵住了，我们很快就可以发现，采取措施解决它，从而保证它可以很快被完成。第二，控制进行中的任务的数量，让开发团队可以专注于响应优先级高的任务。一个人同时承担多个任务，在多个任务中间切换，会造成很大的精力上的浪费。开发者也分不清并行的任务中，哪个是重点，同时做多个任务，哪个也做不完。第三，持续优化现有的工作流程。这就像一个管道，如果我们把维护人力比作管道口径，把交付给客户的价值比作出水量，那么如果不能增加口径，又想获得更高的出水量，我们要想办法加快水流的速度。看板就是这样一种像管道一样的敏捷开发方法，特别适合用于产品维护和支持。

跟风产品

所谓跟风产品，就是国外有个什么新软件，国内照抄。竞争对手有个什么新产品，自己照抄。这样的业务环境，可预测性高。具体的说，产品需求在开发初期就能明确，产品开发的技术可以借鉴别人的，在开发过程中，需求变更比较少，大部分事情是确定的，那么瀑布是最简单实用的方法。PMP对传统软件管理方法讲的很透彻，学瀑布的话，从PMP开始最好。

总结

PMP讲到的项目管理方法也是通用的原则，当然近来PMI-ACP 也出现了。我就是先学的PMP，然后学Scrum，再学Kanban。管理的基本原则是相通的。这就好像一个公园有东、南、西 、北四个门，从哪里入门都可以，重要的是在公园里漫步，欣赏风景的过程。无论学什么，最后都要落实到“学以致用”。

回到开头的问题。Scrum和PMP，该学哪个？Scrum和Kanban，该学哪个？你现在明白了，业务环境不同，需要解决的问题不同，需要采用的方法也不同。Scrum和Kanban，哪个更好？Scrum是个循环，适合用于创新型产品开发；看板是个管道，适合用于产品维护和支持。一个环儿，一个管儿，各有各的好。