CMMI 的严谨之处，同时也体会到严谨背后带来的低效与冗余。
后来我开始在团队中大量引用敏捷观念，通过频繁的交付来验证用户与市场需求，也在技术社区中与许多朋友交流项目管理与软件开发方法，我看见越来越多的人想拥抱敏捷，但同时我也发现，许多人对敏捷其实一知半解，并且对 PMP 及 CMMI 有着错误的偏见。
对研发体系来说，永远都要追求更快、更好、更有价值，但别用战术上的勤奋，来掩饰战略上的怠惰。
关于瀑布式或敏捷开发方法的选择
PMP 强调程序、输入 (input)、输出 (output) 与权责，这与功能型组织不谋而合；相较之下，敏捷强调的快速响应、迭代，则与产品型组织或战斗小组更加匹
需求具备高度不确定性，重要性高，但时程紧迫度一般
这样的团队基本上不会有太明确的分工与流程来局限他们，团队可以选择自己熟练的工具，协议合适的分工，唯一的目标就是把问题给解决掉。
需求有一定不确定性，且时程紧迫
在这类项目中，为了同时兼顾效率与质量，团队基本上会依循一定的程序进行项目目标定义、需求厘清、开发、测试与布署，而在分工上，一个人可能会同时兼任多种角色，例如资深工程师除了要写代码外，也要负责架构设计与需求厘清，而产品经理可能同时兼任项目经理与原型设计。
复杂度较高的项目，可能设有独立的项目经理，否则多数状况下产品经理必须兼任项目经理角色，他们必须对项目负责；而架构师与用户体验设计师则不见得会参与每个项目，除非项目涉及较大的架构变迁或选型，以及明显的用户体验缺陷或改进。分工的方式会根据不同的项目而有所不同，唯一的原则就是，分工必须是必要的，如果只是在工作流程上卡一关，但没有对项目带来实质效益，那分工便非必要。
需求具有高度确定性
例如与战略伙伴合作的项目，彼此已经先把所有需求厘清，并且敲定了验收时间。这样的项目一般我会另外组织项目团队，按瀑布式开发流程推进，并切出几个重要的里程碑进行阶段性验收。
如果敏捷是藉由更快且更频繁的交付，以期降低不确定性并更快的创造价值，那么在目前的项目中，需求基本上已经非常明确，时程也按着彼此协议好的时间进行，中间其实不存在太多需要通过迭代来验证的内容。唯一需要的是按表操课、如期如质的将成果交付出来。
独立的团队，明确的计划、分工与权责，加上里程碑查核，这类案子的稳定度是最高的。多数的外包项目，都还是依循着这种程序，否则将在报价、管理与验收上产生诸多困难。
根据目标与需求的不确定性的高低，所采取的项目管理方法、团队组织与分工方式也不同。如下图所示：
追求敏捷，但更要重视项目管理基本功
在领导团队时，我特别强调项目管理的基本功，因为我认为多数的问题都是出在基本功不够扎实。
在项目启动阶段，一般会由团队就已知信息先拟定 draft plan，其内容主要是陈述项目要做哪些事？打算如何进行？由谁来做？预计花费多少时间？以及将得到什么样的结果？而当团队将计划产出后，我会问产品经理：“这个项目中有哪些不确定性，可能会导致你无法准时交付？”项目管理早期的主要问题大多是“需求不够清晰”、“不确定人力资源能否配合”、“对工作的估时过长或过短”、“技术可行性待验证”、“老板可能还会改动需求”等等，而这些，就是导致项目进行阶段会频繁发生变更 (change) 的原因。
这些对我来说都是项目管理的基本功，敏捷虽然强调拥抱不确定性，并欢迎随时的更动，但不意味着我们要对那些不确定性置之不理，而是要尽快的让不确定成为确定。 敏捷强调不断进步与反馈，我们必须通过一个又一个项目的磨练，让自己能把需求看得更清楚，对时程估算得更准确，能更有效的对齐老板的期待，而要做到这些，团队就需要逼着自己不断进步。
若你对 Scrum 架构有所研究，你便会发现 best practice 里头强调的架构，其实正是针对上述几个最常见的项目不确定性而来的。例如，针对时程，Scrum 强调固定的交付周期，以 1-4 周为佳，而且强调是固定团队，在过程中也尽可能避免团队成员同时参与多个项目，在这个基础上，再来讨论这样的团队，在一个迭代时间内可以完成多少工作。
进步，是永远不变的追求
如果需求管理不当、时程估算误差过大、未以正确的态度面对不确定性、项目过程控管差劲，却总是靠着团队加班来填补落差，团队可以靠着热情撑过一小段时间，但随着时间延长，团队总是会乏力，身为技术领袖应该要以持续进步为己任，而不该沾沾自喜于团队的超时工作。
记得，永远都要追求更快、更好、更有价值，别用战术上的勤奋，来掩饰战略上的怠惰。