UBS

从组件团队和发布火车到LeSS之旅

(作者Gordon Weir)

一切要从2005年说起。那年我加入了UBS，觉得有点失意。在此之前我曾经在IBM一直做相当大的系统集成项目，这些项目大部分都可以用受到质疑或者不太成功来形容。与其在IBM继续干出一番事业，我决定离开，并且我相信一定有更好的方式来构建软件系统。那个时候我还不知道，这个想法会改变我和我身边很多人的生活。

我在为IBM做最后一个项目的时候，听到了一个叫RUP的方法，还偶然发现一个叫DSDM的方法。老实说，我在那时还从没听过敏捷。同时发生在我身上的另一件事是，我在一个项目中遇到了一个相当具有启发性的人，他向我介绍了真正能学习如何做好工作的广阔世界。我吞噬般读了诸如《人月神话》、《死亡行军》、《人件》、《与熊共舞》、《规范软件交付》等很多很多书籍。对我而言，这就像被闪电击中一般。在业界大家已经对敏捷主题进行过深入研究，然而实际工作中这么多年没有看到任何具体变化。

当时我被要求做一个项目来支持资产服务，但我不知道它到底是什么。我于是召集了几个团队在一起，但是不知道预算和财务如何运作，需要的人也比我的预算要多。我们所有人都决心按正确的方法做事，在用例（Use Case）的驱动下进行正确的分析和设计建模，与用户进行深入互动，我们有一个非常强有力的干系人，他知道他想要的解决方案，就没有他不想要的需求。这是很有意思的一段时光。我当时的想法是：“开发此软件需要多长时间就花多长时间，我们要正确地做事”。

不幸的是，现实世界给我当头一棒。 从三月开始，股息处理进入旺季，如果在此之前未实施该应用程序，则必须要等到7月甚至8月。那可不行。 我们认真思考，团队中的一个人说：“为什么我们不能只实施第一个用例，它提供了很多用户需要的东西； 用户不再需要打印SWIFTS并将它们放在过时的文件柜中，它会为他们执行大部分的计算，只是没有邮寄和自动化，这真的就能带来很大不同“。 这让我们开始思考，嘿，我们可以实现这部分，然后随着时间的推移构建更多功能，实现第二个用例，然后再实现第三个用例。我们定义了时间盒，并且有了我们认为可以实现的范围。

我们按照这样的方法去做，方案投入使用，并且在实施后每天与主要用户会面，我们开始每周开发改进功能。以及另外两个范围更大的用例也是用同样的方法实施。我们首次成功地尝试了迭代式交付，这是我们每个前咨询师有的交付软件系统的最大乐趣。

接着到来的是另外一个非常大的项目，我们需要替换现有基于IBM大型机的处理系统，该系统上运行着COBOL和Java。项目的目的是消除巨大的成本、知识风险（它最初是一个ICL大型机，并且依赖于开发人员对ICL应用程序主语言的熟练程度）和增加灵活性。资产服务的成功交付恢复了客户对我们交付能力的信心。我想要按我们之前的方式来做，并开始进行了一些研究，你可以想象当我发现这个方法有个名字 - 迭代和敏捷开发 - 的时候，我是多么的惊讶。

并且，我们使用的迭代、增量和用例驱动的方法也在Craig Larman的书《UML和模式应用》有很好的记载，这本书成为了我们的新圣经。我们还与Ivar Jacabson咨询人员进行了交谈，他们在被IBM合并后，又和Rational拆分，刚刚起步。他们正在开发轻量级RUP方法EssUP-Essential Unified Process。我们喜欢这个方法，因为它的结构比较接近我们最近用的迭代和敏捷开发。

结合Craig Larman的书中的迭代、增量、用例驱动的方法与其他系统的以组件为中心的“小瀑布”思想，虽然当时是一个很好的起点，但是现在回头看，不利的地方是保留了我们原有的“分离”的文化。我们团队中有一个业务分析师来写用例和领域模型，“设计团队”将其翻译成架构模型，并由团队开发人员实施，最后是测试工程师和测试阶段。现在回想起来令我发笑的是，该项目一度有50个人参与，而这其中总共只有6位写代码的开发！

两年后，新的Java解决方案运行良好，大量业务流程已迁移到新的方案，虽然以后的路还很长。该团队已经有了很大的发展，我们一直在使用Unified Process（统一流程），但发现它不再适合我们的工作语境。新系统的许多部分解决了它的技术风险，并且拥有相当可靠的软件架构。我们需要大规模实施和交付，而不再需要经过启动和展开阶段。

我们采用了我们自己发明的项目实施模式，该模式基于我们已学习了解的一些大规模实施理念。这是一个基于组件团队的模式，其核心组件的作用类似于向业务应用程序的服务交付。我们将现有大型机作为核心组件，因为它仍在执行业务的大多数处理和控制功能。新系统中的每个新流程或功能都需要在大型机中进行更改。我们实施了“敏捷发布火车”，其长度为4个两周时长的迭代。最终迭代就是所谓的“稳定”迭代。我们每天召开跨组件团队会议，以尝试协调正在进行的工作。我们仍然有单独的业务分析和功能测试部门，但是我们尽量让它们与编程团队更紧密地结合在一起。就算这样，冲突和挫败感还是很普遍，我们经常听到业务分析说 ，“这是开发人员的错，他们没有完全按照我的用例做”。或者开发人员通常用 “用例对我无用，无法按这样做”来回答或者“这种分析是垃圾”。在那时，我们也开始体验到以前从未见过的事情，包括严重的生产系统上的问题，内存泄漏，软件程序异常。。。事情开始变得非常恐怖。我们感觉到有地方不对，但是看不到在哪里。因为我对自己创建的交付模式感到非常自豪，一切看起来都很合逻辑。我太自豪了，所以在伦敦举行的QCon金融行业会议上分享了这个方法。

然后，我的一个团队成员告诉我，Craig Larman将于2008年初来伦敦。。。

因为他的书《UML和模式应用》，我很想知道Craig对我们创建的交付模式的看法。我想向这位帮助我们起步的专家展示我们真的可以做到。你可以想象一下，当我们在电话会议上与他交谈，详细解释了我们的工作方式，在等待他的答复以及也许有一些如何“调整”的想法时，他却指出了其中的所有缺点，这让我感到惊讶和少许的失望。没有挖掘太多他就知道我们已经进入停滞期，我们的步伐比以前快很多，但却无法从组织系统中获得更多收益。此外，他问质量是否开始下降以及组织系统是否失控。是否有些人工作时间非常长，在某些情况下，在“稳定迭代”中他们甚至通宵加班。他到底是怎么知道这些事的？

然后，他用基于组件团队的交付模型解释了这个问题：交接的复杂性，零散知识，局部优化，复杂的依赖计划和协调管理问题，功能给到了错误的地方，同一个功能重复被实施，以及系统中各个部分造成我们看不到（至少在我们有限的观察测量范围内）的瓶颈。

坦率地说，这不是我所期望的。最开始我感到不高兴。我当时处于对敏捷和精益学习了三年，以为我知道了一切的阶段。我读过数十本书，书的作者们包括Ivar Jacobson，Dean Leffingwell，Scott Ambler等行业专家。我曾经与全行人士谈论过我们在这方面做得有多出色，我的意思是，Craig怎么敢这么说？我是专家。。。不是吗？

问题是，当我想得越多，就越觉得他说的有道理。我们现在用的方法是不行的，很难。我们跨组件的站会已经变成了一个小时到两个小时的“坐会”，有很多组件之间的交互和应用复杂性需要处理。而且，不管我们的计划有多详细，就是没有人能总是做到按计划进行。我们每两周迭代结束时进行集成测试的想法就永远不会发生，我的意思是从来没有奏效过。“发布火车”毁了。 总是有一个组件或者有时是两个组件还没有准备好。而.NET图形界面。。。好吧，那从来没有对齐过，而且总是在“稳定迭代”才被完成，实际上好像是从那时才开始做，认为它在底层数据准备好之前什么也做不了。

消化了一段时间后，我决定改变绝对是有必要的。只是调整-改善-已达到此模型的极限，我们需要进行彻底的大修。Craig所说的，拥有跨职能的包括业务分析师和测试在内的跨组件特性团队，是有意义的。这真是太疯狂了。 我们邀请他来做为期一周的培训，3天CSM+课程包括Scrum和大规模Scrum（LeSS），加上2天结合实际的领导力教练和组织设计的咨询，真正地在工作坊中“向我们展示怎么做” 。我坚信，仅有培训几乎没有效果，边做边学和实践应用是必不可少的。

在开始三天之后，我无法想象没做培训前的那三年我们是怎么过来的。我们了解了核心概念，和我们从未接触过的深层精益思想和实践。一场关于精益的阅读和学习狂热开始了，《丰田模式》、《改变世界的机器》出现在了桌面上。。。

我们召集了一个新的跨组件、跨职能团队组建会议来建立特性团队，对齐产品所有权，然后就开始了。我们并没有宣传，只是做了。我们知道这些理念对其他的技术团队来说会难以接受。

从组件团队转移到跨组件团队，这一变化是巨大的。我们在短短的一个月内的交付速度就超出了我们的期望。我们从每8周发布一次（按之前的发布火车模式）到每两周发布。不再有发布火车了；只是每两周创建并交付一个完全完成的产品。

这让我想起了大约3年前我对我的6人开发团队说过的话：“我想每两周发布一次”，当时情况是我们每6个月发布一次，6周一个迭代，他们听到后笑得很厉害，甚至可能都快笑伤了。。。

正如Craig所预料，所有这些都暴露出严重的组织弱点：我们的GUI团队没有足够的产能，而且不同的技术类型在损害着我们。我们最初的解决方案是将Visual Studio装在每个人的桌面上，让GUI与功能一起演进，这对大家来说是一个很大的思想转变，你是否曾同时运行Eclipse和Visual Studio？试试我们远程团队用Citrix VM以130%产能的方式。。。我们最后迁移到GWT中的轻量级GUI。我们当时也没有足够的业务分析技能，最终演进出了强大而简单的分析技术，因此我们开始使用Gojko Adzic的实例化需求方法，并购买了智能板，以便与用户和远程团队共同创建。这让我们有限的业务分析师能更多以咨询和支持的方式而不是作为仅有的生产者来工作。

我们喜欢特性团队的概念，一切都在一个团队中，他们负责从开始到生产（以及支持）的交付。在团队级别，这样能非常好的运作。我们确实发现，多个团队变成了部落。他们开始相信自己是唯一一支优秀的团队，所有问题都是其他团队的错。他们形成了团队个性，这有好有坏。

很长时间里我们都没有采用Craig在LeSS中的建议：专注于在设计工作坊中针对设计和架构进行敏捷建模，并由“动手”的架构实践社区提供真正的架构领导，认真关注整体架构设计。与之相反，团队采用的是一种我称之为“勉强过得去”的方式开始工作，觉得架构会随着发展而不断演进，尤其是在使用验收测试驱动开发的情况下。这是一种天真的想法。在这样的规模上，必须对架构和设计进行前瞻性思考，这是Craig在他的《UML和模式应用》书中和他采用LeSS的指导中所强调的。否则，你将开始发现同样的功能被不同团队在不同的架构部分被开发，都经过了很好的测试，但是用了不同的测试用例和不同的方式进行部署。个人英雄主义成员开始出现在团队中，他们花大量时间进行清理和对齐，他们成为团队的反派，因为他们与基于“团队至上，而不是个人”的团队文化并不一致。我花了很长时间来了解为什么会发生这种情况，以及为什么它对于该转型的成功至关重要。

我现在认为，在如此大规模的企业级别上，优秀的结构设计思想不仅仅是必要的，没有它是致命的。我还认为，需要有像《新产品开发的新游戏》中所叙述的真正具有跨职能和多技能的团队来推动产品和“交付工厂”。你需要一支具有组织领导技能、深入的架构和分析、以及了解开发技术的团队，这个团队所塑造的产品和愿景被所有团队采用。这个团队要有动手能力，可以编码，并且可以在幕后领导。

LeSS是一个框架，可以帮助我们在Scrum从未预设的规模上来实施Scrum。伴随的深度思考是最重要的，不要盲目采用Scrum的实践（这么做是一种不错的学习方式）。它带有经常被忽略的警告，这是我的好朋友丹·诺斯（Dan North）在我们最近一起进行的一次演讲中说的，“警告：可能包含思考”。就是这样。你所处的语境，业务、技术、人员，工作程序和领导力会驱使你采用不同的实践。我在这个案例中建议的是针对大型企业解决方案交付的情况。这可能不是你们所处的情况，它也不适合我当前的语境。但是，思想、原理、实验，它们是你从LeSS中得到的，学习他们 - 并思考。