多年来帮助大大小小的公司转型为更加敏捷，我学到一样东西：公司越大，应用Scrum的时候，精益思考就可越有效地提供帮助。精益对于拥有独立的团队的小公司来说，并不那么必须。但它对大公司至关重要，比方说有100人或者更大的公司。如果你所工作的是大公司，那么这篇文章就是为你量身定做的。
忘掉你听说过的精益源自丰田和制造的说法吧。从另一方面看也确实如此，人们通常这么理解。与其这样，不如将精益当作一个知识、心态、方法的主体，以及应用到我们的工作的工具 (1)。精益是由以下三个知识主体构成：精益科学、精益管理和精益学习。在接下来这篇文章中，我将讲述每一个主体，其中包括他们如何帮助Scrum团队。
精益科学
维基百科(维基百科，2010) 这样定义科学：
“企业创建和组织关于自然世界的可测的解释和预测的知识 ”(2).
不可否认，软件开发有相当大的不可预测性。尽管它不是可以完全预测的，我们仍然能将科学的流程应用其中 (3)。 我将会用到“精益科学”这一术语，来指软件开发和产品开发工作的知识。敏捷已经描述过一些这样的“规则”或曰“法则”。对于大项目而言，一条软件开发的“规则” 是这样的，你不能提前预知一切。这也不是说你欠缺这样的能力，而是事物发展的方式就是这样的。这导致诸如“分步骤创建然后看如何学以致用”的方法——这也是敏捷/Scrum称“检查与应用”交互式发展为一种学习模式。
这种法则包括很多。其中的一些最重要和软件相关的包括：
- 事事平等，过去花在编写代码和检测之间的时间越多，发现错误之后进行修正的时间就越长。
- 不同背景的人交流（比如客户和开发员）尚不存在的东西（比如即将开发的软件），双方不能很好地理解，同时一些误解也不易被察觉。
- 一次做太多的事，会让生产量下降，同时出错率上升。
- 知识随着时间降级。这暗示着过早定义要求将会导致返工或者需要你从就的信息中倒腾。
- 缩短周期时间(从开始概念性的工作开始到用户使用）将使得质量和产量上升的同时成本有所下降(4)。
根据以往的经验，有经验的敏捷开发员知道很多其他的法则。这些法则，确实，要求我们改进我们的实践来与他们匹配。在很多情况下，Scrum就是的设计就是用来处理这些法则的。
举例来说，交互式发展实践本身是不做过多的提前分析。在每个sprint的最后，从用户那里得到反馈是快速发现我们的错误理解的好方法。一个sprint的两周时间盒很自然地限制了他们多项事情执行的方法。团队群（两个或更多的团队成员共同做一个故事）也限制了一次所能完成的工作量。一个更加重要的Scrum实践——一个团队专注于一个产品订单——遵循基本法则——协同定位和专注于一个项目不仅增加产出，也提高产品质量(5)。
Scrum是 通过在可能的情况下用快捷传导增长创建软件达到缩短周期时间的一种实践。看板软件方法将这一步发展得更深入。看板是另外一种实践，它基于精益科学，考虑到 人员方面的改变——太多的话会叫人害怕，让工作人员抛弃掉他们已经学到的东西也有点失礼。它的设计是用来提高公司更快发送高质量软件的能力。看板允许公司 从任何起点开始，包括团队结构和角色。
要改变方法，公司首先需检查这个流程是如何运作的，然后通过限制每一步进展中工作量来寻找改良方法。基本的信条是延迟原因瑕疵，同时增加修复瑕疵的时间。看板为工作进程障碍创建可视性，为团队提供最具优势的方法。工作缓慢的最大一个典型的原因是同时操作的东西太多。所以, 看板建议在每一步都对工作量有所限定。
在 看板中，团队发展工作流程的明确条款——关于进展中工作的限制，关于工作优先级，关于进入和退出的标准，等等。团队同意遵守这些明确条款，如果条款有助于 或有害于工作进展时，就进行修改。借助于此，团队能够根据当前状况做出适当的调整。另外一个优势是团队能够在讨论流程以及他们对于所做工作的信念的时候相 互学习。明确的条款反映了团队当前的理解。
后一点很有力量。当团队谈及他们的工作进展，他们可以做出改变。这通常都比坐等 sprint 结束然后在事情都结束之后来追溯要好，这样的追溯通常会变成老掉牙的活动， 通过明确的条款每日探讨工作方式方法，可帮助团队凝聚在一起并专注于工作实践变动的影响。我的经验告诉我这样的对话能够避免多余的会议或者耗费工作时间，在任何一种情况下，在如何工作上没有达成共识的话都会给团队带来挑战。
精益管理
当前关于管理的许多思考都是两个范例范围之中，任何一种管理都很知道怎么做并且告知团队他们需要做什么，或者是团队很知道怎么做，汇报给管理他们在做什么以及工作结果都已经足够。第一种方法导致微观管理和完成更大工作量的荒唐要求。第二种则让管理置于暗区, 当需要给予团队帮助的时候而出不上力。它暗示这管理的角色仅仅是给团队分配工作，而不参与干预工作。这反映了一个普遍的担忧——管理干预工作。
我所称的“精益管理”提供了第三种方法：经理作为领导/教练。起点是管理和团队有对话的基本共识。在团队成员能更好地理解如何展开工作的同时，管理能够有更好的全局角度，同时能更好地规划团队的工作环境。这种方法将团队自身的状况和管理的更高远的视角完美结合起来。每一方都在完成公司工作的协作中发挥着作用。
领导/教练的角色只管只要，远不止仅仅是一个促进者或者进程教练。他为企业和进程承担责任。领导/ 教练介入进来帮助团队用新的方法，及时地观察，及时地指导，及时的提出问题来帮助团队解决问题。或者在团队碰到麻烦或不知所措时给予帮助。举例来说，有的时候，开发人员很热心于一直解决问题，他们一直坚持用同样的方法在做。他们需要一个强势的教练来帮助他们运用新的方法。
这个是从Scrum中的普通方法做的一点点变动。我不是建议Scrum团队应该有经理来直接辅导他们。那样的话就太费事了。尽管这样，我认为Scrum 团队应该保证他们能从Scrum精通人士 那么得到训练来帮助提高他们的方法，如果他们还没有进行这种训练。我见到过 许多精通人士限制他们的推动角色，而教练的角色则更加有价值，哪怕他有的时候对于团队而言有点对抗的意味。
Scrum 团队需要认清且尊重管理知道团队进程的需要。生产线和产品经理在公司的有效性同团队一样。他们提出的问题应该意味着他们需理解团队的方法。大卫安德森在他的研讨书看板(安德森, 2010)中，讲述了一个案例，产品经理迅速知道了他们让团队“再多做一件事情”，却起到了相反的作用，不利于团队的工作。他们中间开始讨论任何特殊的要求加进到这个混合当中。这比告诉管理要做什么然后需要终止sprint更加有效。 退出终止sprint卡几乎不用是很明显的无效。
精益学习
精益是科学思考和尊重人员的结合。精益并不是为软件开饭的人员方面而考虑，而是恰恰相反。尊重一线人员意味着怒仅仅让他们知道要做什么。它意味着更加注重人的主观能动性。它能认识到这种改变对于公司很难，甚至会带来损害(6)。看板就是在这种情况下设计出来，作为一个管理改变的系统使得团队能加快他们最拿手的工作进度。这是最后一个方面，让工作人员能够熟练地进步而不是让他们做力所不及的。
经常性的短期的学习比非经常性的大量的学习效果更好。我所称的“精益学习” 将会让我们专注于我们的方法和方法理解方面小的改进。创建明确的条款，测试，然后改变……如果必要的话，每日一次。尽管这样， 局部的改变不影响全局进展也一样直观重要。
迅 速专注于编码，不惜付出付出测试的代价是不应该做的负面例子。精益和看板专注于清楚步骤之间的拖延——通常是要么减少工作事项要么是改变工作的次序——来 将延迟降低到最小。工作是怎么做的再项目板上有体现。这样让开发团队的进展一目了然。通常能很容易看到一个延迟对于其他步骤的影响。这点，当然，是需要实 时更新项目板以得到迅速的反馈。
精益能够帮助Scrum 团队的最好方法
到这里，我们已经讨论了Scrum内部的精益/看板如何实践，这是非常有用的。尽管这样，将精益实践应用于价值流优先于开发团队会更具影响。
在《精益——敏捷软件发展：达成企业敏捷》(Shalloway, Beaver, & Trott, 2009)中，我引用了一个上游销售的问题导致20%的产量损失的例子。我有这样的假设——低质量的代码是罪魁祸首，在销售环节中这确实是流程的一个挑战。过分关注团队会导致疏忽全局的后果。
尽管这样，更为典型的是，精益在怎样更好地确认、规模和优先团队要做的工作方面给企业股东和产品经理提供帮助。这必须以在任何同一时间减少工作量为目标。我在大公司得到的经验是，最大阻碍团队产量的因素是他们的工作量过大。Scrum尝试着他们认为自己能在sprint中让团队减少产品订单的故事，但现实情况是团队总是工作量过大或者做的事情太多。减轻上游的压力对于团队有着非常积极的效果，让他们专注于最重要的事件，以及占有工作所需要的所有资源。
由于产品负责人不是时刻在做已经很庞大的产品，这样团队能够更轻松地找到他们。产品订单的超前工作，经常让团队无法找到产品负责人—— 但这样他们离团队更近了。实际上我给每一个企业主管指出后，他们都已经意识到这是个问题。他们理解在团队工作过程中，需要产品经理和产品负责人能够便于联系。但他们可能还不知道延迟的成本，但他们知道找人找不到的成本。
同主管和管理讨论如何分配给团队工作量会影响他们的效率，他们通常能够在真正为客户增加价值这方面更加注重选择性。由于大公司涉及许多不同的产品，所以对于单独的产品负责人而言，这个工作是庞大的。
总结
将精益看作是科学、管理和学习的结合，能让Scrum的实践者从包括精益/看板的实践开始他们的Scrum实践。明确的条款，管理工作进程，创建可视性对于团队的生产量（速度）有着很直接、明显的影响。承认一套必须遵循的法则，我们同管理和团队展看可能性的对话——这样管理不仅能帮助团队工作，也能理解他们的工作。 精益建议，通过检查团队工作的结果，用少少的学来证实这种假定，如项目板所显示的那样。
精益提供一个了重要且有用的环境，在这种氛围里，团队能够更有意识的学习实践。这样能有让他们清晰地决策，同时也创造了自然而有益的协作，它还使得工作导向更加明确。哪怕Scrum团队的许多外部实践类似于基于精益的Scrum团队或是看板，它依旧是有着更强大环境的优先骨架。
尾注
1. 有兴趣的读者最好听听我的播客 ——重新定义精益或阅读管理设计工厂(莱纳特森, 1997) 。尽管完全没有提到“精益”，但它是我所读到的最好的描述之一。
2. www.wikipedia.com/science, 2010年10月
3. 如果对预测性和可控性有什么疑问，希望我的博客 进程的种类 ——堂莱纳特森能为你解答疑惑。
4. 这是精益的关键原则。它超越了制造，服务，以及产品发展，这是为什么精益思考不限于制造。
5. 我见过团队的创建——从一个矩阵的组织离开——在实际产量上创造出200%的提升。为什么呢？因为让工作人员更专注可以有更好的沟通；让工作人员在同一时间专注多个事件并不能让他们发挥作用。欲知更多详情，参见我的博客，Challenging Why (not if) Scrum Works.
6. 我是指很多矩阵组织创建真正Scrum需求的团队所遇到的困难。
原文地址：http://www.scrumalliance.org/articles/355-using-leanthinking-to-help-scrum-teams
