“摘要：作为管理学三大定律之一的帕金森定律在职场有着广泛的表现，在软件项目研发中也不例外。除了减少组织层级及在少量节点设置时间冗余，采用敏捷的项目规划方式，也能很好地规避帕金森定律的负面影响。”
1958年，英国历史学家诺斯古德·帕金森通过调查研究，出版了《帕金森定律》(Parkinson's
Law)一书，用来解释官场或官僚主义现象。该定律在时间管理上的解释是：只要还有时间，工作就会不断扩展，直到用完所有时间。MBA智库百科
帕金森定律在软件项目开发场景中表现为：无论给一个项目多少时间，时间总会被耗尽。可进一步解释为：如果给团队分配了充裕的开发时间，团队总会将所有时间用掉。
项目计划中的“官僚主义”
先来看一个经典的项目计划故事：
客户要求项目10天完成；
老板为了给自己留缓冲时间，给经理说8天；
经理为了给自己留缓冲时间，要求主管5天搞定；
主管也留了缓冲时间，给员工说3天搞定；
然后，员工就只有3天时间，搞了一个漏洞百出的东西；
最后，客户本来能拿到一个8天的质量较好的东西，实际拿到的东西只花了3天时间。来源：浅谈软件开发定律之帕金森定律，
https://blog.51cto.com/eilfei2000/718353
以上是一个“自上而下”的任务下达和项目计划过程。现实中虽然少见这种简单、戏剧化的场景，却也很讽刺性地说明了一些问题。
我们看到项目计划时间被层层压缩，组织层级越多、时间被压缩得越厉害。如果管理层一定要求员工在3天内拿出一个10天质量的东西，撇开其他因素不谈，加班将不可避免（甚至加班也完不成任务）。可以想象一下，这个团队的管理方式，以及在这样的团队工作是怎样一种癫狂状态。
如果一个团队，多年来一直采用这种“按层级压缩时间”的方式运作，对团队效率的影响将是致命的。项目经理给你安排任务，说得言之凿凿，但你心里清楚，项目经理的计划肯定会有很多水分，他给的Deadline（最后期限）不是真的。你按计划行事，最后完不成，项目经理会触发项目延期。
这种节奏下，大家对承诺、对项目计划看得很随意，执行力非常差。而且团队成员越来越油滑，俨然一个官府衙门。这样的团队，说严重一点，价值观都出了问题。
进一步分析原因：
1. 传统组织中管理层很难知晓基层执行细节
即便是离软件项目更近的IT/互联网领域，也不是所有管理层都懂技术。或有技术出身的，若长时间脱离一线进入管理岗位后，对快速变化的技术细节也会逐渐模糊。
管理层不知道基层做事的细节，做计划做决策时又不愿意（或条件不允许）提前花时间进行细致调研，武断拍脑袋式作风将难以避免。同样，这样的体系下，身居管理层也较难参与到项目执行细节中。
2. 缺乏互信的组织文化
表象上我们看到的似乎是人性的心理定势，本质上是“官僚文化”导致的管理者与员工信任缺失。管理者潜意识中认为“团队肯定会用掉所有给定的时间”，原本可以给8天的时间一定要压缩到5天。而员工心里清楚管理者的心思，也自然要求更多时间给自己留有余地。这样双方会形成一种彼此猜忌和怀疑的心理恶习。
如何规避帕金森定律带来的负面影响？
既然是因为层级太多导致了项目时间被层层压缩，自然，我们想到减少组织的层级就可以减少时间压缩。比如，客户要求10天，只在老板这个层面下达8天的任务，同时让团队明确这就是Deadline，无延期的可能；或者只在经理环节设置Deadline，...。总结而言，应该考虑只在唯一的环节设置冗余时间。
从这里我们也可以看出，为什么现代企业组织架构更推崇扁平化、小团队模式。
但仔细想，上面故事中8天计划时间的设定，好像也并没有什么依据。怎么就知道8天时间能完成项目？是先经过基层团队评估、再提供给高层拍板，还是单方面只由老板定的？
显然，“组织扁平化”或“只在一个环节设置冗余时间”还不足以解答这个问题，我们需要更“科学、量化”的项目时间规划方法。这就是“敏捷规划”要解决的问题。
敏捷规划与估算
“规划”，在敏捷上下文里，主要侧重于指制定项目计划的过程，常与“估算”联系在一起。“估算”作为敏捷规划中一个非常重要的组成，是预先对工作任务量及团队生产力（或开发速度）进行数据化估计和度量。有了量化的数据，做计划就有了信心依据。
初建团队，一开始是没有任何历史研发数据的，这时候团队会以一个粗糙的、甚至拍脑袋式的迭代计划开始工作（当然，团队只要不全是新人，以往的工作经历、项目经验都是新项目开始的基础）。但只要动起来了，耕耘1-2个迭代了就有了数据。历史数据就成为后续迭代重要的参考，如：多长时间内完成了多少用户故事、各工种投入的人力及时间、缺陷率有多少，等等。
所以，所谓的敏捷规划，并不能一开始就可以给管理层提供一个较准确的项目时间（也不建议这样做，前面提过，这个时候“帕金森定律”的心理定势会起作用），而是会告诉管理层，“我们将预计进行多少个迭代后交付这个项目”，而这每个迭代时间周期到底多长是暂不确定的，只会有1~4周这个经验范围设定。这种“进行多少个迭代后交付项目“也仅是一个粗糙的估计而已。
任何项目计划方法，都不能做到精确可达，都只是一个方向和目标指引。敏捷规划当然也从来不会标榜自己做出的计划是精确的，相对传统计划方法而言，它只是一种更科学、可量化的计划方法。而妙处就在，敏捷迭代一旦启动，团队的工作方式会不断进化，计划和估算会越来越趋向准确，生产力和交付时间变得越发可预期。
我们从以下几个方面来分析敏捷规划与传统项目计划方式的差异。
迭代式的项目计划
在「我们怎样进行研发迭代？」中，曾详细描述过敏捷迭代过程：通过多个层面、长短计划结合的方式，构成研发计划体系。远期计划负责目标指引，短期迭代计划承担执行过程。
在迭代时间和工作集规划时，采用：先给定一个任务集（交付增量）、再估算迭代周期，或者在固定的迭代周期内、推导出团队可交付的任务集。后者为经典的Scrum迭代模型，迭代周期固定而有节奏。前者可视为一种迭代变体，根据任务集决定迭代周期长短。
迭代变体中，这个时间周期如果大于3~4周，则应考虑将任务集拆分成多个迭代。在项目开发前期、有大范围的功能待开发时常常使用这种迭代变体，也可以适具体情形灵活穿插在不同迭代中。（关于迭代更多细节，请参阅「我们怎样进行研发迭代？」）
与管理层对以上达成共识很重要，不然你的长期计划太过粗糙、缺乏说服力，短期又在频繁做计划、团队似乎很浪费时间，这将不足以获取足够的支持来达成目标。
另外，敏捷规划鼓励管理者或项目高层决策者一起参与到项目规划中来（只要时间允许）。团队将迭代计划、需求列表、开发进度等均纳入SaaS工具系统进行管理，管理层可随时查看项目状态。
任务规模和团队生产力度量
确定了迭代的用户故事集后，团队需要着手估算用户故事点并拆解为 Task (估算和拆解的工作也常在 Refinement 会议完成)。如下所示，一个经过估算并拆解后的迭代用户故事集：
图中每个“故事描述”后面的数值为故事点数，最右边一列的数值为拆解出的Task需花费的小时数估算（统计后总故事点数为37，需要投入的工作小时数为82）
Task常以不同工种工作内容作为拆分依据，每个用户故事所需的总工作小时数，为各Task小时数之和。如下图所示，“API接口文档设计及开发”常作为后端工程师的开发任务，而“前端组件开发”则往往成了前端工程师的工作。
每个Task所需要的工作小时数，可由各工种的工程师（或任务负责人）根据自身经验单独来估算。
要注意的是，用户故事的点数和故事内包括的任务总小时数，是一个用户故事的两个维度的规模度量值（更多关于故事点，请参阅「Scrum，一个橄榄球术语...」）。
故事点数更多用于在迭代的宏观层面描述团队的整体迭代速度，如团队在迭代完成100个故事点功能开发，则团队迭代速率为100点/迭代（也可考虑每周多少故事点）。如果已进行了多个迭代，则可由此计算团队平均迭代速率。这个历史数据，可作为团队后续迭代计划中可接受多少新开发任务的估算参考。
团队对自身迭代速度估算，初始并不能做到清晰、明确。好比写一本小说，刚开始写的时候可能预测自己一天至少能写5k（5千字），实际进行中发现一天只能写出1k，有时甚至很多天写不出一点儿东西。后面写得越多、经验技巧提升后速度会逐渐趋于稳定，每天能产出3-4k左右。团队的开发迭代速度也是这般。
用户故事总小时数，则主要用于与团队整体“实际可投入工作小时数”进行匹配，以决定团队在迭代计划内真正可接受的任务量。
为了计算“团队实际可投入小时数”，先看下面一个简化的例子：
迭代计划任务量：用户故事点90，分解出的任务总小时数200；
团队工种构成：后端工程师2人、前端工程师2人、UI设计1人；
迭代周期：2周（除去周末共10天，每天按8小时计算）；
投入因子：选取0.6（一天8小时，实际心流状态可全情投入工作时间仅为4.8小时）。
根据以上数据，计算出团队实际可投入小时数为：51080.6 = 240 hrs*。这个值大于计划的任务量小时数200。
初看起来，2周的迭代内团队完成这90个故事点、200个小时的工作任务是完全没问题的。但实情可能是，这200小时的任务量构成为：后端需投入120hrs（hours)、前端需投入60hrs、UI仅20hrs，团队其实很难完成这个任务。
进一步分析，团队后端仅2人、后端可投入时间仅为96hrs（21080.6 < 120hrs），在不增加后端人手的情况下，后端实际约需要13天（120 / 28*0.6）才能完成任务。这样整个团队完成迭代任务实际就需要13天，而在这个迭代内前端仅需投入7天，UI只要5天。如果这2周迭代时间已确定，那显然团队需要将计划的任务量消减到可完成范围内。
所以，在迭代进行中，一个团队内部的各工种工作量常常是不均衡的。某个工种多出来的时间，可规划别的工作内容或者引导迭代工作往前走。
通过先选取新迭代中团队计划要完成的用户故事集（计算出任务量总小时数），然后计算出团队实际能投入的小时数，再参考团队的历史迭代速度，三者比较后即可确定团队在迭代中真正可接受的任务量。
这样的工作量度量方式，使得团队成员每天的工作投入基本是饱和的，想懈怠工作比较困难。团队成员每天工作的投入度，另有任务面板可时时查看，有早会机制可监督、同步。
对于绝大部分职场人士，平均投入因子能做到0.6已是很可贵。它已去除并兼顾了迭代里的流程管理开销、沟通环节、人的状态变化及组织内部其他干扰。
让团队加班加点，或可提高一点投入因子，能达到0.7~0.8已是极端优秀。但自驱动力强的人，在工作时间高度专注、高强度投入，达到投入因子要求后，到点就该准时下班了。
由此，传统管理者可能会认为，敏捷是“偷懒的文化”，觉得按固定的迭代周期和投入因子式的行动方式输出相应的工作成果，与公司确定的、按时间节点交付业务目标许多时候相违背。但这样思考的管理者，或应该尝试多了解团队采用的项目规划方式，从而设定更科学合理的业务目标。
如果管理者不希望看到那种上班时间“偷着摸鱼”、下班时间“尽情表演”的恶性氛围形成，应该能做出明智的选择。
结语
总之，通过鼓励管理层积极参与到项目规划中来，采用量化、有数据可依的工作任务估算方式，建立SaaS工具体系让进度清晰可视，促进了研发计划与工作进展的透明，有助于建立组织上上下下的互信。
当然，团队在项目规划方式上的变通也是必要的。许多时候，高层管理者也会希望能在项目迭代开始前提前了解项目工期和预算，以便于进行前期决策和业务规划，即便这时团队会告诉管理者，“我们只有深入到项目开发过程中、知道更多细节、甚至完成几个迭代后，才能给出详细的计划和较准确的项目工期”。
若考虑到大部分外包项目，客户也常要求研发团队能先提供一个预算和工期，不然客户心里没谱、没法进一步决策，这样团队也就更能理解管理者的上述要求了。这时“帕金森定律”总会来干扰项目计划者，而此时“只在唯一的环节设置冗余时间”就显得十分必要了。
所以，“敏捷”的广而传播和深入推行，研发团队责任首当其冲自不必多说，客户(用户)、组织管理者及其他利益相关者的积极参与，也十分必要。工程与管理方法论的进步，需要全民努力。
推荐阅读
Scrum，一个橄榄球术语为何颠覆性地改变了软件行业？敏捷迭代：我们怎样进行研发迭代？
作者简介：
熊俊，技术工程师，敏捷研发教练、精益实践者。10多年软件开发、技术架构与研发团队管理经验，曾在社交网络、企业级Saas方向创业2年多。技术上以Python/Django体系见长，在代码重构、领域驱动设计（DDD）方面有丰富的实战经验。
...公众号：码斯基之矛
如需转载，请关注公众号与作者联系。