KANBAN AT NET-A-PORTER – 重新获得对流的控制

KANBAN案例分析系列

他们没有履行承诺，就像他们两周前没有履行承诺一样! 约翰森-斯旺很恼火。他和他的队友们一起，试图在被称为 “迭代 “的两周工作时间范围内交付所承诺的工作项目数量。而就在他们认为终于实现了这一目标时，有些东西却被卡在了测试中。约翰森不喜欢固定迭代的压力，但更不喜欢自己的承诺失败。在2012年的那个夏天，团队里的人都感到很沮丧。

现在，在2013年末，约翰森-斯旺正忙于改进工作流。约翰森不必再考虑他是否能将该工作流–或其他任何事情–纳入迭代。该团队正在努力改进他们的代码和系统响应的逻辑，这对利益相关者在工作中花费的时间有很大的影响。

到目前为止，约翰森的团队通过让系统反应更快，已经为他们的同事节省了几十个小时。随着迭代和发布计划的最后期限的消失，约翰森和他的同事们现在觉得他们在控制之中，而且他们实际上更有效率。

迭代工作源于这样一个概念：如果工作有时间限制，就会使团队更好、更有效率。对于约翰森和他的团队来说，这需要付出很大的代价。他们把问题掌握在自己手中，通过遵循看板方法的教导，逐步改变了他们的工作方式。

“它彻底改变了团队的工作方式：使我们能够更多、更快地发货，并赋予团队更高的目标和能量，”产品所有者和集团采购总监保罗-布伦南说。

但这更像是一个进化的故事，而不是革命。

背景

“你能在网上销售时装吗？”娜塔莉-马塞内在21世纪之交的时候问过自己这个问题。

她在21世纪初开设了电子商务实体NET-A-PORTER.COM。

13年后，NET-A-PORTER仍然通过其三个子品牌在网上独家销售高端时尚。NET-A-PORTER，MR PORTER，和THE OUTNET。

这三个网站页面上展示的所有东西都是由这家位于伦敦的公司雇用的买手挑选和策划的。他们不断考察数百名领先的设计师，并作出购买决定，然后在www.net-a-porter.com、www.mrporter.com和www.theoutnet.com，展示给170多个国家的数百万客户。

不过，要使一个项目可以购买，有许多步骤必须执行。约翰森的团队负责其中的部分后台系统。成为一家销售时装的技术公司是一个缓慢的过程，因为所使用的IT系统是内部建立的。

“早在2006年，当我来到公司的时候，IT团队只有20人，”现在的服务交付主管卡姆-乔维特说。

当时没有业务分析员、项目经理或测试人员。他们是开发人员，通过电子邮件收到工作请求，并在他们可以的时候发布到生产中。

卡姆继续说：”那些在企业中喊得最响的人，他们的事情由开发人员完成。

随着NET-A-PORTER的发展和技术团队的增加，缺乏结构和流程的影响开始显现出来。卡姆是想改变这种状况的人之一。她编写了规范文件，帮助建立团队，并创建了交付周期。

“2009年，我参加了一个关于敏捷实践的会议，在那里我遇到了一位敏捷教练（Sally Ann Freudenberg）。我在以前的公司里有过敏捷的经验。我很想让它在NET-A-PORTER发挥作用，并认识到有必要请一位专家来帮助我们在这里实施它。

到了2010年，像Scrum【1】这样旨在改变软件生产和交付方式的敏捷方法论得到了广泛的普及。当卡姆从会议上回来后，她立即想尝试这种新的敏捷工作方式，并与Sally Ann取得联系，帮助推广。敏捷的潮流，特别是Scrum，使开发人员感到兴奋。

【1】1990年代中期开发的一种敏捷软件开发方法。Scrum是以 “Sprint “为基础的，”Sprint “是为交付系统的一个工作部分而设定的期限。每个Sprint从两到三小时的计划会议开始，包括预先定义的角色。”客户”（产品所有者）、”引导者”（Scrum Master）和跨功能团队。客户描述待办列表内的最高优先级，在团队同意做多少并承诺做多少之后，团队就可以在Sprint的时间内独自完成。

不过，项目管理办公室没有那么兴奋。

“这个敏捷是什么东西？如果没有完整的规范，我们怎么会开始一个项目呢？为什么企业会从一开始就参与进来呢？

教育每个人了解这些变化以及这些变化将如何影响他们，这需要大量的时间和许多有经验的外部教练。

到2010年中期，所有的IT团队都改用Scrum规定的仪式【2】和角色【3】。工作周期被分割成两周一次的迭代。在迭代开始时，他们被指定的PO分配了一定数量的工作。他们必须在Sprint结束时交付这些工作。到2010年底，正式的发布计划和日期被引入–IT团队不仅要在固定的时间段内工作，而且还要在固定的三周时间段内发布。

在这种新的工作方式中，团队之间的依赖性变得很明显。无论各团队之间的合作有多好，都很难在固定的迭代中协调顺利的交付。

2011年，NET-A-PORTER经历了一次重大的组织变革来解决这个问题。人们不再按工作类型划分团队，如开发或测试，而是重组为一个个小队，指定为前端、后端和应用开发。我们的想法是，这些小组将包括具有不同角色的人，这样他们就可以独立地提供一个需求。

那年秋天新成立的团队之一是产品管理系统小组，其职责包括主要网站日常使用的部分数据库和后台解决方案。约翰森于2012年1月加入这个小组。该团队的工作从下达和管理采购订单和定价工具到产品数据的整合都有。

随着IT部门的不断发展，团队的规模也在不断扩大，对辅导和指导以帮助敏捷性和协作的需求变得更加明显。大卫-洛维是常设员工中的几个内部敏捷教练之一。他被分配到两个团队，其中一个是约翰森的团队。

问题

“当我来到THE NET- A-PORTER集团时，这是我第一次不必从头开始推销敏捷。它已经采用了Scrum框架了，最初我对此非常高兴。然后，我看到人们是如何与之斗争的，”大卫说。

迭代是Scrum的核心，在让技术团队更快地交付小块工作并满足企业的期望方面有很大帮助。与几年前相比，运营开销已经减少，团队中出现了协作行为。

图1–约翰森在看板上的头像。

【2】有助于保持工作内容正轨的过程性行动。在Scrum的背景下，这些行动是。Sprint计划，开发团队预测在即将到来的Sprint中可以完成的故事，并创建Sprint待办列表；每日会议，团队讨论自上次15分钟的会议以来所取得的成就，以及在下次会议之前对成就的期望；以及Sprint回顾会议，作为反馈回路，评估到目前为止所做的工作。

【3】产品负责人，负责决定要做什么工作；ScrumMaster，帮助Scrum团队的其他成员遵循流程；开发团队，其成员负责交付产品的增量工作。

正如该方法论的理念所期望的那样。固定的、重复出现的终点，要求每次提交一定数量的已完成的代码，这被证明是有帮助的，是一种激励，它使团队更有效率。

然而，Sprint–以及两星期又两星期的飞驰的最后期限–给产品管理团队的人员带来了压力。完成他们承诺在Sprint中交付的所有故事似乎是一项无法实现的任务。他们通常都没有达到他们原先认为可以达到的故事点的数量。

在Scrum中，故事点衡量背后的逻辑是，只有当故事完成时，才能 “实现 “这些点。如果某项任务的一点工作–例如一些测试（实际上可能相当于一个点）–仍然存在，那么就不会给该任务的团队提供故事点。

“他们知道他们只需要多一点时间，但他们感到很沮丧，因为在Scrum的背景下，他们认为他们没能实现他们承诺的目标，”大卫说。

团队继续努力，以实现Sprint目标中的承诺。”有时我们走捷径，只是为了能实现迭代[承诺]，这影响了我们的生产质量。我们希望把质量作为我们的主要目的，而不是一个最后期限，”约翰森说。

一个额外的问题是每三周进行一次全公司的发布。每个小组负责打包所有经过测试的代码，并将其提供给合并小组。在所有东西都被上传之后，各团队必须对他们的代码进行最后的测试，但现在是在其他人的修改的背景下进行。这种做法在迭代过程中多次打断了团队的工作，导致他们无法履行承诺，增加了他们的挫败感。

“我相信，延长迭代的长度，使其与发布周期相匹配，对情况没有帮助，”大卫说。

他认为，一个迭代的时间跨度越大，这只会导致团队更多的承诺，更少的关注，从而使承诺与交付的比例更差。这将会牺牲掉迭代的好处–做一点工作，然后停下来进行现实检查的小步骤。

大卫说：”我们还不够成熟，也不够规范，所以不能去做。”

“我认为我们对Scrum的特殊解释是浪费和不灵活的，我们都是以同样的方式来做。我们不能根据我们的需要来调整它，”约翰森说。

这种挫折感已经转移到他们流程的其他方面。由于时间紧迫，他们怀疑是否有必要召开这么多的会议（日常会议、回顾会议、计划会议）。他们错过了关于下一步的信息。

我们拥有的 “燃尽图【4】 “对我们解决如何改善我们的状况没有什么帮助。如果有的话，它们会伤害到团队。大卫说。

在某种程度上，这是因为燃尽图测量的是天和小时，而故事使用的是点。

最终，团队一起得出的结论是，遵守承诺本身就会成为一种目的，并不能帮助企业销售更多的时装。他们还意识到，不遵守承诺并不是什么大问题。

因此，他们决定不再担心打破现有的僵化规则，而开始将迭代的承诺视为一个灵活的目标。无论他们是否实现，都不会那么重要。但他们仍然觉得在预测两周的迭代上损失了太多的时间，尤其是在大多数时候他们可能会错过。

“团队知道，他们希望有重大的改变，”大卫说。

【4】燃尽图显示了随着时间推移所剩余的工作。其中使用的测量方法可以是故事点、天数或小时。

看板即将登场

“我第一次听说看板是在2006年。我知道它能使工作流程更顺畅，我把它归结为多任务处理的限制。

约翰森回忆说：”我甚至在2012年春天就建议过它，但当时似乎并没有引起什么兴趣。

由于Scrum对团队不再起作用，而且他们无论如何都在破坏规则，到了同年的冬天，约翰森向大卫和团队重新提出了他的建议。

“我以为看板是增加了WIP限制的Scrum。你很少看到一个开发者对流程和工作方式感到兴奋，所以我提出要多读一些关于看板的书，以便更好地理解它。

教练承认，他被他深入参与的敏捷社区引导到了大卫-J-安德森的关于看板的书。大卫答应读一读，并给团队提供他对该方法是否合适的看法。

“当我在圣诞节期间阅读看板书时，我看到了关于看板方法的一个优点–它缺乏指示。听起来，团队将能够以最适合他们情况的方式应用改进和想法，”大卫说。

与此同时，约翰森也决定阅读这本书。在这些页面上，他进一步阅读了关于协商优先级和时间尺度的内容，以及关于由团队本身激发和执行的工作方式的变化。他把这本书看作是对Scrum的单行道框架的拯救，也是对随之而来的对这些规则的反叛的拯救。

他们一起把看板方法及其原则和教义带到了团队中，相信它可以改善团队的交付。

两人解释说：”最初不会有什么变化，但随着时间的推移，我们将能够共同找出适合我们这个团队的方法。”

“在规则范围内，减少强制的僵化，增加灵活性，听起来不错。团队很高兴尝试逐步转向一种最终会有意义的工作方式。

图2 – 一个样本工单。

拯救之旅

2013年1月，该团队做的第一件事是绘制每个工作项目的流程步骤，并在白板上将其可视化，称为看板。他们的第一个看板有10列，每列代表工作流程中的每一项主要活动。他们都认为这是对他们目前工作方式的反映。唯一新增的一栏是 “分析中”，它的作用是让每个人都知道即将发生的事情，这是他们之前抱怨过的。工作项目被写在工单上（图2），并保留了对故事点的测量。正如看板的第一条原则–从现在做的事情开始–所允许的那样，保留这些项目有助于大卫感到安全，如果因为某种原因看板不起作用，团队将能够回到原来的方式。

保持故事点也很重要，因为他们觉得他们为达到一个大小的认同所经历的过程使他们能够确保对需求的共同理解。

大卫说：”这个过程当然比所产生的点的大小更重要。”

看板一建好，大卫就开始琢磨在每一列上放什么工作进展（WIP）的限制。限制在制品是看板的一个指导原则，因为大家都知道，专注于某项任务可能会提高其质量，同时减少花在该任务上的总体时间。

最初，他们把限制放在2到8之间，他们认为这很低。大卫从一开始就非常清楚地告诉团队，看板应该完全反映现实是多么重要。尽管它很诱人，但它不应该描绘出团队希望达到的理想化形象；它需要显示团队的实际情况。大卫担心人们所做的工作可能比看板上出现的项目更多。

“为了在Scrum期间做出对迭代的承诺，团队成员习惯于在同一时间做很多事情，希望这样做可以更快地交付工作。事实上，我认为在不同事情之间切换所花费的时间产生了相反的负面效果，”大卫说。这是一个需要时间来改变的习惯。

在看板前的第一次站立会议上，团队查看了所有的工单–从完成较多的到完成较少的，或者从右到左—贯穿整个看板。

“突然间，我们拿到了一张似乎没有人知道的工单。这是一个完全被遗忘和放弃的东西，”大卫说。

以前的站立会议是关于每个人前一天的工作内容和当天的计划。

“我认为每天的这十五分钟让每个人都感到防备，必须证明他们在努力工作，特别是在有未完成的工作项目的迭代背景下。当我们把焦点从个人转移到工单上的任务时，人们……放松了，[足以]提及有问题的事项。他们自己的表现不再是聚光灯下的焦点，我们立即看到了改善，”大卫说。

我们在测试前的阶段不断遇到瓶颈；我们不断地调整在制品限额，但我们无法避免被许多工单卡住。大卫说：”要实现流程，就不能简单地不进行多任务处理。”

经过多次讨论和思考是什么造成了瓶颈，该团队意识到他们的看板从一开始就少了一栏–代表将任务合并到共同环境中进行测试的一栏。这是一个早期的教训：他们了解到留出足够的时间来批判最初的流程图是多么重要。带着开放的心态和批判的眼光，看板改变了许多次。

最初设定的工作进度限制被证明是很高的。他们仔细审核了他们的流程，发现他们可以在多个栏目中共享工作进度限制。团队引入了作为缓冲区的列的概念，比如通过代码审查（图3），项目可以停放在那里，直到有人可以拿起它们进行下一步工作。该团队的看板最终有11列（图4）。

图 3 – 通过的代码审查列有非常具体的已完成的定义，并且有一个共享的 WIP 限制与相邻的 “合并到分支 “列共享三个WIP限制。

“来自其他部门的同事仍然认为我们很傻，有一个如此详细的看板。

但我们很欣赏这种详细程度，因为我们从来没有忘记过什么，也没有留下任何项目，”大卫说。”他补充说：”当然，随着我们对看板的使用日趋成熟，我们很可能在未来改变这种做法。

站会变得更加轻松和富有成效。这给了大卫信心，让他开始实施另一项他想了很久的变革–回顾性会议的形式。过去，每次迭代后的会议都要持续一个小时，在他看来，这样的时间不足以让团队在现实的时间范围内达成具体的行动要点。大卫认为，团队需要投入足够的时间和精力来真正推动改进。

只有这样做，他们才能够不断地改进。他建议团队每月进行一次为期半天的回顾，之后非正式地聚在一起吃披萨和喝酒。团队喜欢这个主意。

在第一次回顾会上，团队成员讨论了当一个人闲着的时候，他的活动栏满了会怎么样的问题。在这次谈话的启发下，约翰森决定进一步探讨这个问题，并提出建议，说明除了一些测试之外，开发人员还可以做些什么来改进。

渐渐地，团队开始更快地交付，并提高了质量。滞留在看板上的错误越来越少了。

因此，他们开始对自己感觉更好。他们试图只做一个大小的故事，避免过大或过小的故事。

在参加了一个经过认证的看板课程后，大卫熟悉了衡量和评估完成工作项目绩效的各种方法。终于有了关于工作项目需要多长时间以及在完成过程中发生了什么的数据，他感到很有信心，团队对现实有了更好的洞察力。

“我们知道某件事情大约需要多长时间，我们也看到了这一情况是多么的近似，因为在那些所谓的相同规模的任务中存在着巨大的差异。我们终于可以看到并解决这个问题，”大卫说。

图4 – 截至2013年10月，团队的看板。

超越自我改善

2013年4月的一天，团队的产品负责人保罗-布伦南坐下来讨论一个新的工作流程。与采购、工作室、仓库和其他团队一起，他非常希望产品管理部门能够领导一项举措，专注于改善新产品上传至网站的流程。

这些系统是为比目前支持的用户少得多的用户建立的。随着他们的成长，这些遗留系统需要越来越多的维护和支持。这影响了许多人，并导致许多小的请求不断地冲击着团队。

机会是巨大的，保罗相信，随着他们交付能力的提高，产品管理团队可以承担这个项目。

习惯了敏捷和协作的心态，团队做的第一件事就是直接与利益相关者交谈，询问他们的主要困难是什么。

“图片和内容制作所需的时间；转换和存储多种尺寸的新产品图片所需的时间；建立一个内部系统的页面所需的时间 “是他们在举办的训练营中得到的答案。

一开始，该团队认为他们需要将一半的可用带宽用于改进流，所以他们将看板分成两半。

“我当时看了看看板，意识到我们实际上不需要手动分割。

反正看板把正在进行的事情可视化了。只要我们以某种方式指出改进项目，每个人都从中挑选，我们就会在任何时候知道我们的贡献有多大”。大卫说。每个人都有选择改进系统或其他项目工作的自由。

通过审查和改写零碎的内容，改进开始显现。利益相关者开始感到欣慰。

产品管理团队的业务分析员EmilyKindness决定不以团队所花的时间来衡量他们所做的故事，而是以他们为利益相关者节省的时间。这个想法变成了“节约时间的温度计”。

图像和内容制作的时间–包括产品的造型、摄影和视频、撰写产品描述和提供适当的尺寸指南–减少了25%。

因此，转换和存储多种尺寸的新产品图片（从缩略图到产品页面和全尺寸）的时间从20至60分钟减少到5至10分钟。

在几个月的时间里，四名开发人员、两名测试人员和一名业务分析师每周为内部系统的页面构建时间节省了多达20个工作小时。

Marmite

“我一直对数据感到兴奋。除了看板系统提供的直方图或累积流程图之外，我对人们的感受感到好奇。

我很好奇人们的感受。但不只是一次性的陈述，而是定量的，”大卫说。

2012年11月，他想出了一个他称之为Marmite的调查。他以这种粘稠的深棕色食品糊状物命名，这种食品糊状物具有强烈的味道，人们要么喜欢它，要么讨厌它。

同样，在每个月的月底，大卫一直在问团队，他们是爱还是恨他们的工作，他们的团队，他们的流程，以及其他指标。根据调查，从2012年11月到2013年11月，团队的幸福感一直在上升–他们对自己的工作有6%幸福感的提高，对他们正在工作的东西有8%幸福感的提高，对彼此的幸福感有12%的提升。

持续部署之路                                                        

大卫说：”我们处于一个很好的位置，可以控制我们自己的部署，并看到我们的努力是上线的，而不需要等待发布周期。”

在认识到产品管理团队的重要性和他们提供有价值的个人故事的能力之后，NET-A-PORTER集团的高管们给他们开了绿灯，让他们在独立于其他团队的基础上持续部署代码。这是一个有风险的努力，它需要大量的责任，因为新引入的代码可能会与现有的系统发生冲突并崩溃。但除非他们尝试，否则他们永远不会知道。. . .

在看板之前，团队有把项目捆绑在一起的习惯，只有在所有项目都完成后才能交付。大部分的穿插工作是在待办列表的早期完成的。

但是，新的工作方式从一开始就是一种文化上的改变，因为真正重要的是敏捷地交付小的部分，而不管发布时间是什么时候。现在，这种新的习惯可以让他们永远不必再考虑发布日期，并以连续的流程向利益相关者独立交付生产。

“我们仍然看到的一件事是我们的交货时间的变化，”大卫说。

他们试图制作大致相同尺寸的故事需要不同的时间。

时间，在五天到十八天之间。

“我们希望一旦我们开始持续部署，并且不为回归测试而停止我们的流程，就能看到变异性的下降，”大卫说。

持续部署定于2014年初启动。

结语

产品管理团队走过的路并不容易。它花费了大量的精力。看板让他们找到了一种更好的工作方式。没有僵硬的规则，但有大量的思考和实验，以确定他们的最佳交付方式是什么。

仅仅是想做好自己，为内部客户提供帮助，就足以促使他们玩转这个过程并不断改进。其效果不仅仅是他们对自己的表现感到高兴，而且作为一个结果，他们显然已经影响到了公司里许多其他人的表现。

这个团队在提供服务方面的能力提高，引起了其他团队的注意。大卫担心其他人会想复制他们的成功，只想到它的积极作用，而没有意识到它所付出的努力。大卫与使用过看板的人组成了一个看板指导小组。其目的是向团队询问他们使用看板的动机，并提供支持。

“我们不希望看板变成闪亮的、新的、单向的工作方式。我们想确定他们真的是出于正确的原因想要使用它。只有这样，我们才会致力于帮助他们使之适用于他们独特的情况，”大卫说。

到目前为止，共有七个团队在使用看板系统来帮助他们在NET-A-PORTER集团的服务交付。在不同程度上，看板方法正在帮助他们每个人。

进化仍在继续。

原文来源Kanban University官方网站看版案例。Cary Bao译。