一、使用看板方法管理项目
我是项目经理，看板对我来说意味着什么?
我是项目经理，我的组织正在采用Kanban，它对我意味着什么？以及我应该在工作中如何使用看板？在企业已经实施的看板体系中，你的现有角色并未发生改变，仍然是项目经理。然而，为了在已经实施的看板系统中充分利用可预测性和风险管理，你应该对自己的工作进行适当调整。我们相信，看板方法的理念和实践，会帮助项目经理提升到一个新的高度。
如何使用看板来制订计划及排列工作优先级？
通常，项目经理们会问：“如何使用Kanban来制订计划，以及排列工作优先级？”当然，在项目管理中，还有很多的事情要做，但是这两件事非常重要。
非常重要的一点是：我们应该深刻领会到，看板方法中对项目管理产生重大影响的核心实践是制订更明晰的规则。使用了看板方法之后，项目管理就演变成了一种更好地促进和实施风险管理的活动。项目经理在整个项目交付周期中，负责制订各种规则。这样一来，项目经理的角色，就不仅仅是简单的项目管理者了。通常，项目经理会做好多事情，例如：收集并汇报项目进展、组织会议、制订计划、发布管理与变更管理等。另外或许还有一些更细致的工作，诸如：进行任务分配，或者更为直接的命令和控制方法，以达到完成工作的目标。这样的项目经理，实际是专注于“管人”的，只是在苦苦寻找与特定任务技能相匹配的人。我认为，拥有这种职能的项目经理，其角色更像是“项目秘书”或者“项目协调人”。这不是一种创造高价值的项目管理实践。
好的项目管理实践应该是：有些活动能够辅以自动化手段，而且团队成员应该在一些约束条件（或者“规则”）下进行自组织管理。在军事组织中，这些约束条件，被称作“约定规则”。以我的经验来看，美国的军队比企业更懂得如何授权。
关于规则
所以，我们不再孤立地去谈“制订计划”与“排列优先级”。我们更希望项目经理以区别于传统思维的角度去思考问题，同时也强调一些细微差别和更明晰的概念。
在看板方法中，我们探讨的是：调度 (scheduling)、排序(sequencing)、选择（selection）（即：3S）以及可选项、承诺、产能分配、风险管理与规避。我们使用预测来替代估算。预期是建立在概率报告基础上的，调度是基于对风险承受能力的评估，与之相对，经济损失是基于特定成果发生的概率。我们教给项目经理们如何建立规则来管理这些活动，如何去调整这些规则去管理项目的业务目标和业务风险。传统意义上的“制订计划”与“排列优先级”这些具体的工作，就会从项目制订的规则中分离出来。计划实际上只是规则所产生的一个附属成果。
收益
在项目管理中使用看板方法能够改进产出物的质量，看板方法提高了项目的可预见性，并改进项目可接受的经济指标。整个项目进程更加透明。虽然关注重点是在规则的制订上，但是管理却得到了改进。项目经理转变为主抓风险管理，同样，风险管理也得到了很好的改进。使用看板方法后，项目经理为项目团队和整个组织，创造了更大的价值。
二、使用排序规则制订计划
不排优先级，怎么定计划？
看板方法中，我们不倾向用“排优先级”一词，因为对排优先级这件事来说，并非是做一两次然后形成一份按优先级排序的清单那么简单，在每个工作项在看板系统中被拉动时，都需要动态排优先级。看板方法中，排优先级不再是一种活动，而是当看板系统中形成拉动信号时，根据可选工作的风险情况动态决策所产生的结果。
基于风险评估进行项目排期
由于不再专门排优先级，我们的方式是根据排序策略来制订项目排期。排序策略是基于风险信息的，在项目待办列表中的每个工作项要使用某种风险评估框架进行分析（通常是定性分析）。风险的所有维度中，“变化带来的市场风险”是最具影响力的一个。按照这个维度工作项大致可分成5类：必须项（Table stakes）、成本缩减项（Cost reducers）、法规变更项（Regulatory changes）、搅局项或尾随项（Spoilers或Catch-ups，即跟进竞争对手的差异项）、差异项（Differentiators）。在我所著的《Lessons In Agile Management: On the road to Kanban》一书中，对此进行了介绍。这种分类方法也可以加入其他可能的类别。有时，我也会加入诸如“误导类”等其他类别加以充实。然而，这里所提到的5类是最常见的。要点在于选取与项目相关的风险维度和分类方式。如果项目的交付物是某种客户可交付产品或服务，并且需要与市面上的类似产品或服务进行竞争比较，或许所处行业还会受法律监管，那么这种特别的分类方法就会非常有用。
项目中，如果每个特性或需求都使用这个分类体系加以分类，我们就能够基于风险分类设置不同的策略，并根据这些策略制订排期。
必备项（Table stakes）在项目生命周期中没有变更风险，因此它们可以先开始。虽然法规变更项（Regulatory changes）也是必备项，如果没有这些项你的项目就无法完工，但它们需要被单独列为一类，因为这些法规会根据政府和法规制定者而进行调整和变化。
如果可能，最好将法规变更项（Regulatory changes）分成在整个项目生命周期中都不会变化的项、以及哪些会因为监管审查、申诉、或政府和法规制定者的变化而受到影响的项。任何可能变化的日期都需要加以注意，以便能够清楚该项何时不再受变化影响。例如，如果已知某个需求会受到政府换届选举的影响，那么就应当在需求定义中标注出选举的日期。
（如上图）向上到成本缩减项（Cost reducers）、搅局项（Spoilers）、再到差异项（Differentiators），需求的不确定性的程度就会发生变化，所以，需求定义发生变更或工作项必要性发生变化的风险随之升高。我们不希望接手可能会从范围中删除或因重大变故而受影响的工作项。所以这些项应当推迟到项目更晚些时候再开始。
创建用于排序和产能分配的策略
如果项目不存在提前交付的风险，我们就应先对所有的必备项（Table stakes）排序，然后对所有成本缩减项（Cost reducers）排序，然后是所有的搅局项（Spoilers），最后是差异项（Differentiators）。对于法规变更项（Regulatory changes），一旦我们知道它们在项目交付日期前不再受到变更影响，就要尽快排期。
那些没有交付日期提前风险的项目，大多具有自然规律或与季节性业务或行业相关，例如，常见于服装、服饰、时装制售行业，或者世界杯或奥运会这种重大体育赛事。所以，如果我们遇到了具有这种性质的项目，并且已经评估了变更带来的市场风险，我们便能够为看板系统的排序工作定义出一条简单的策略。具有相同类别的工作项，比如成本缩减项（Cost reducers），能够按照任何顺序加以完成，因为无论多么细致地对它们进行排优先级或排序，都无法获得风险管理带来的好处。当然，前提是因变化导致的风险是我们所专注管理的唯一风险维度（更多风险维度请关注Agilean公众号）。通常，我们还会考虑其他风险维度，所以策略会比这里所描述的更加错综复杂。
如果存在交付期提前的风险，尤其对于商业产品或服务类的项目，那么我们就应当对冲这种风险。根据战略与市场定位，最有价值的当属搅局项（Spoilers）和差异项（Differentiators），因此，我们应当通过在看板系统中将产能更多分配给具备更高价值、更高风险的项来对冲交付期提前的风险。
我们可以通过细分需求来使得这种对冲的方式更容易。如果我们的产品或服务面向多个市场细分或用户角色，那么每个需求都应当标记上其所支持的市场细分或用户角色。我们应当让市场人员根据他们的倾向性（更多是基于当前的市场目标）对这些市场细分和用户角色排优先级或排序。比方说，我们希望针对服务于青少年来提升市场占有率，就应给青少年这个细分或用户角色更高的优先级。
此外，我们应当在项目生命周期内，制定按照一定比例增减产能分配的策略。举例来说，我们希望最开始给必备项（Table stakes）分配80%的产能，项目收尾前降至0%，而最初差异项仅分配10%的产能，项目结束前增长值80%。这种产能分配会影响到系统中的看板（信号），并给出具体的拉动信号来告诉我们在任何给定的时刻应当拉入哪种需求。
风险是个多维问题
当然了，这篇文章中只关注单一风险维度，而项目风险是多维的。在这个领域，有太多的知识需要学习，有太多的实践需要思考。因此，我们的排期策略要远比上面描述复杂得多。例如，我们会考虑技术风险。如果某差异项工作项存在技术风险（以前从未做过，并且不清楚如何来做），那么我们应该制定一条策略，规定需要将这种类工作项拆分为两部分。拆出的第1个工作项是用原型判定可行性（或者叫做"spike"），安排在项目早期以便及时为可行性分析提供有用的信息。拆出的第2个工作项是基于新技术能力开发高保真特性。这种差异化特性的实现应当推迟到项目后期再做。
基于策略的排期胜于传统的待办项排优先级
没有必要对项目范围内的每一个工作项进行排序。实际上相互独立的工作项不应排序。当看板信号指示有能力开始一项工作时，如果制定了一系列基于风险评估的策略，我们就可以遵循它们来选择工作项。这些策略比按优先级排序的项目待办列表更容易维护，还是一种更强大的风险管理工具。要解释为什么要制订某一条策略是件很简单的事情，而且当环境发生变化，也很容易判断策略是否也需要变更。策略的改变会立刻反应在看板系统中新的工作项选择决策上。因此没必要维护项目待办项列表。确保项目范围内的所有工作项在承诺时得到风险评估，并且根据项目经理所提倡的风险管理方法对项目排期策略进行维护，这些就是所要做的全部。
总结
这篇文章，仅仅是给大家一个关于使用看板方法进行项目管理的初步认识，您从中了解到我们如何制订计划，对工作项排序与选择工作项。学习完整的相关技术，您可以考虑参加LKU相关课程。
三、项目预测
2008年，看板方法第一次震惊了整个敏捷社区：它不必使用敏捷专家们大力推崇的一些实践，包括带有时限的迭代、优先级的概念，甚至可以不使用估算！问题来了，如何才能借助一种不使用估算的模型来做项目计划呢？答案是：使用历史数据或者具有预测能力的模型构建针对项目产出的概率预测。以下简要介绍一种简便而常用的模型，可用于对项目交付进度作出预测。
项目预测的统计学支柱
使用看板时，我们可使用两个关键的理念进行项目预测，一是看板系统所拉动工作的前置时间分布，二是源自排队论的利特尔法则（Little's Law）。
前置时间分布
图1 前置时间分布
图1展示了针对在看板系统中流动的工作项（通常指项目的功能或需求）的前置时间分布。使用类似图中的历史前置时间分布前，我们有必要理解几个假设，以确保选择了正确的数据。此外，还必须相信，将来观测到的表现与过去的相似。对于流动效率低下的工作环境来说，这一点尤其重要。这样的环境中，个体技能和所采用的技术实践对前置时间有重大影响，而需求的规模或者复杂度没有那么大的影响。因此，对于流动效率低下的环境，可以在更换人员、大幅改变需求捕获方式和变更技术工作实践的同时，保持观察到的前置时间分布不会受到重大影响。在流动效率较高的环境下，我们要注意保持个体的技能和经验与采集历史数据时的高度相似，保持工作实践与分析和需求开发方法高度相似。这就可以保证我们可以预期将来的前置时间分布会与现有的数据充分一致，从而使用历史数据进行可靠的预测。
其次，要作出准确的预测，需要单一模态的数据。要获得这样的数据用于前置时间分布，对于不同种类的工作或不同级别的风险，需要有各自的分布曲线。因此，对需求进行风险评估，根据风险类型对历史数据进行聚类和过滤，是作出准确预测的关键所在。
再次，要创建最适合自己的分布曲线，要知道应该从过去多久开始对前置时间直方图进行采样。这时候前置时间趋势图就派上用场了。我们可以观察趋势图中系统设计的变化，关注平均时间和数据点变差的分散程度。不连续的点通常反映了系统设计的变更（有望是改进），如果找到这样的点，只需采集到均值和变差分散程度发生改变的点即可。换句话说，我们需要一张能够反映当前状况且不混有早期数据点的数据直方图。还有一种找到这一时间点的方法，就是监控看板系统的流动性，寻找流动性水平发生较大变化的日期。这样的日期可作为制作直方图时数据采样的历史时间起点。
只要有了针对项目范围内各类风险（服务级别）或各类工作的直方图，并假设项目范围和需求由工作或者风险的类型表示（本系列文章的第二部分已有讨论），我们就能应用利特尔法则对项目进度作出预测。
图2 利特尔法则
利特尔法则应用于看板时，可表述为：离开看板系统（所有工作完成后被存档）的工作项的平均交付速度等于系统中看板的数量（即WIP限制）除以平均前置时间。因此，只要我们知道看板系统的WIP限制以及前置时间的均值，就能计算出已完成的工作交付所需时间。
建立进度预测
图3展示了在大、中型规模项目中常用的一种简单的三阶段模型。该模型在为期短至六周、长至数年的项目中已验证有效。模型中的参数是笔者所选，读者可更换成适合自己的，不过三个阶段应该足够。假定时间轴的前20%为第一阶段，流动效率相对较低。接下来的60%为第二阶段，流动效率高，一些敏捷专家称这种效率为“超生产力”。在时间轴上剩下的20%的时间里，流动效率降低。笔者2003年出版的《软件工程的敏捷管理（Agile Management for Software Engineering）》一书中首次阐述了该模型。虽然这里描述的概率预测方法早于看板方法，但在看板系统的使用过程中，前置时间的稳定性得以不断提升，从而提高了预测的精准度。
图3 三阶段项目进度预测
图3假设项目中的需求是同质需求。换句话说，这些需求属于相同类型，具有相同的风险级别。具体什么意思呢？如果多种需求都通过同样的方式（如用户故事）获取，则这些需求可视为同质需求如果一些需求依赖于供应商，而其他的没有，那么前置时间分布中会有多个模态的数据，因为供应商依赖将会导致某种延迟，从而影响交付时间。在这种情况下就不应对所有需求一视同仁，而要对需求是否具有供应商依赖进行区分。所以，我们要从有无供应商依赖的角度，对需求进行标记。如此一来，需求就不再同质，而是分为两种不同的类别，需要分别进行估算。
使用产能分配管理需求风险
我们会按照类型将需求划分为多个批次，并针对各个批次构建模拟仿真。例如，对于如本系列文章第二部分中所描述的调控性需求，我们将其与项目中非调控性需求分开预测。正如第二部分所讨论的，调控性需求一般具有固定的交付日期，并且项目交付日期通常具有法规效力。一批调控性需求需要在项目结束前交付，如此一来，我们可以在看板系统中引入产能分配，在整个项目的生命周期中以稳定的速度拉动调控性需求。
知道了调控性需求的规模、交付日期和当前的日期，我们就可以计算出需求平均交付速度。通过看板系统可以得出拉动调控性需求的前置时间分布。有了这些参数，就可以计算出调控性需求的在制品（WIP）限制数量。这将成为在整个看板系统中的产能分配。我们在可视化看板上设计一个泳道或者使用不同颜色的卡片用来标记调控性需求。至此，我们已卓有成效地建立了看板子系统，用以按照需要的节奏来拉动调试性需求。从现在开始，可以确保所有的调控性需求在交付项目的截止日期之前完成。
是否应该对法规变更（Regulatory Changes）需求进行排序？由第二部分讨论可知，这取决于某些这类需求是否仍可能发生变化——原因可能包括游说、管理者决策多变或者是政治领导层的变化。如果需求没有变化，则从业务风险角度来看，调控性需求是同质的，可以按自己喜欢的顺序进行拉动，而不需要对它们进行排序。如果部分调控性需求仍然有可能改变，则这些需求应该推迟到项目的后期。在项目开始和早期阶段，应该对需求进行排序，并且选择那些已知的比较稳定的调控性需求，而推迟不稳定的需求，直到所有不确定因素被消除。
总结
尽管使用历史数据构建前置时间直方图、绘制最合适的分布曲线、预测项目完成进度、建立WIP数量限制、构造产能分配并将分配策略付诸实践听起来都比较复杂，而且需要对统计学有基本的了解，但这样进行项目计划实际上却非常高效、简便。由于已对需求进行评估并就风险类别进行了标记，数小时之内便可建立项目预测模型。即便对于周期超过1年、成本超过1000万美元的重大项目，几个人花上不到一天的时间对必要的数据进行收集和分析，就能构建出可靠、高质的预测模型。
传统的决定性的计划方式中，需要对项目中的工作项逐一评估。相比之下，用本文所介绍的方式做出的概率预测，通常要准确得多（与实际结果更加接近），同时构建起来也快得多，成本也大幅减少。概率预测的一大好处是，不需要让专注于客户所关心的工作的员工停下来，对未来的（经常是带推断意味的）工作进行估算。打断工作是对资源的浪费。许多看板案例研究都显示，消除这种打扰之后，项目的交付速度、前置时间、可预测性和质量等方面都有大幅改观。
本文介绍了具有三个阶段的预测模型（所谓“Z型曲线”模型）。如果使用LeanKit或者Swift Kanban产品，还可借助蒙特卡罗模拟功能，对项目的结果做出更加靠谱的预测。预测效率更高、成本更低，结果通常也较传统的估算、计划方法准确得多。看板系统让预测能更广泛地用于项目风险管理，同时也让进度管理和产能分配相关的策略更加清晰，从而确保能较好地把控项目。
四、风险审查与阻碍集群
本部分阐述了项目经理如何促进风险管理并对平均前置时间与前置时间分布进行控制。其重要之处在于确保在第3部分中所描述的预测在整个项目周期内是准确、可信的。以及描述的阻塞项归类技术最早由Klaus Leopold提出，不仅可以用于管理项目风险，还可用于促进过程改进。
归类阻塞项(Blockering Clustering)
上图中的例子是某次阻塞项归类实践的输出。其中这些便签在使用看板过程中收集到的一个月内的阻塞项。每个便签都记录了阻塞原因和阻塞天数。本例中，我们把阻塞归为外部阻塞和内部阻塞，然后再根据根因做进一步归类。
事件风险分析
风险 = 可能性 × 影响
上面这个计算公式大家一定很熟悉，它属于经典的项目管理知识。目的是计算给定的风险事件发生的严重性。通过对阻塞项加以归类，我们就能够得到代入公式所需的信息。如果仔细查看图片，你就会发现，“客户”（德语为"kunde"）这个阻塞归类影响共130天（德语为"tage"），若我们准确地知道这个归类的阻塞项总数（这里貌似有13个便签），就能推断出，由于等待客户响应，会造成平均每个为此而阻塞的工作所受到的阻塞影响为10天。因此我们就可以知道，风险（顾客拖延）平均对每个阻塞项的影响为10天。如果在这段时间内，所有我们处理的便签共有65张，则由于某客户而导致某便签被阻塞的可能性为13除以65，即1/5或20%。
客户拖延的风险 = 20% × 10天
因此，阻塞项归并实践使用直接从看板墙上收集到的便签，便可以直接得到项目的风险计划。
风险审查会议
看板方法第5个主要实践是“实现反馈循环”。目前只有三种具体实践：每日站会、服务交付评审会议和运营回顾会议。在精益看板《现代管理框架中》，我们增加了第四个具体的反馈循环实践，即：风险审查会议。而阻塞项归并则是风险审查会议中关键的协作活动之一。
过程改进
阻塞项归类的输出不仅可以预示出项目风险计划，还可以用来促进过程改进。我们可以有针对性地对影响更大的延迟源有针对性地采取风险降低和缓解措施，以图消除延迟源或显著降低发生延迟的可能性及影响。从这个角度来说，阻塞项归类能够在组织内形成某种模型驱动的改进和不断改进服务交付的进化过程。
作者介绍：David Anderson，软件看板之父，管理咨询公司 DJAA 的 CEO，国际看板认证机构 Lean Kanban University 的核心创始人。拥有近30年的软件开发行业经验，曾在Sprint、摩托罗拉、微软、Corbis等公司从事软件开发管理工作，倡导以敏捷方法进行项目开发。2005年，他将Kanban方法引入软件开发流程并取得显著成效，之后，他将精益与敏捷思想与实践更深入地应用于IT交付、技术创新、产品运营等领域，在深层次催化组织的渐进式变革。曾任全球精益Kanban大会的主席，经常应邀在知名的国际会议上演讲。著作包括：《Lessons in Agile Management》、《Kanban》、《Agile Management for Software Engineering》等书籍。
