首页 > 客户案例
摘要
在微处理器行业中，产品开发工程设计（PDE）团队提供相关测试来进行经济实惠的设备检验和分类。PDE 夹在实际设计团队和工厂制造团队之间，由于缺乏对于（团队级别的）期限、范围、需求或可交付产品的控制，他们时常承受着巨大的压力。
为了更好地协调PDE 内各个子团队的工作，总数约50人的7个团队自主探索了一个协调度更好的方式来进行产品开发。要实现这种协调和整合，笔者认为Scrum 是可以采用的项目管理框架，同时还要结合敏捷工程设计的实践。本文说明了该企业对于Scrum 的学习和探索，以及这项投资的结果。
介绍
在采用“敏捷”和Scrum 方式的软件工程设计领域中，存在大量实践。其中许多实践针对利用小团队的中小型企业，他们采用面向对象的语言开发软件。位于美国俄勒冈和太平洋地区（OAP）的PDE 团队是一个大型企业，需要跨越多个团队和站点、跨越多种文化和环境来实施Scrum 和“敏捷”软件开发。我们的工作产品是一款在自动测试设备（ATE）上运行的测试程序。ATE 拥有专属的操作系统和接口语言，这有碍于我们使用行业标准和现有的软件验证解决方案。事实上，我们正在一个使用专属语言的环境中工作，而且既没有现成的单元测试框架，也无法进行离线测试。此外，长期以来我们一直深受以下问题的困扰，包括需求探讨、过度承诺、未赶上时间安排、日以继夜的工作周、士气低落和很高的职员流动率。
长久的构建和制造历史导致Intel 具有浓厚的瀑布式软件开发的文化氛围，而且他们普遍将瀑布式软件开发视为通向成功的先进途径。团队通常以孤立的职能“竖井”（functional silo）形式进行组建，遵照时间安排定期将可交付的产品移交给其他职能竖井团队。其结果就是：某些团队在产品生命周期的后阶段承受着巨大的重负，而且在项目末期存在着很高的职员流动率。最终导致每个团队收纳各种领域专家，他们所具有的技能很少与其他团队成员一致。因此一个团队中的各个成员很难成为搭档共同负责一些任务。
尽管面临那么多挑战，我们还是决定勇往直前，不过准备采用不同的方式来管理项目，以便更好地团结测试团队，更顺利地交付我们的工作产品。在项目的初始阶段，我们选择为企业引入Scrum，其中大部分工作为硅前（presilicon）基础设施的开发和一些准备工作。如果我们能够在第一阶段使Scrum有效地运作，我们认为在一个项目相对平稳的阶段中习得的实践可以为我们指明方向，通往压力更大的执行阶段——在此期间，日常工作量完全取决于实际硅片的健康状况、不断变化的外部商业景气、以及客户对于设计、生产和制造的要求。
第一阶段：针对硅片的准备工作
第一个要进行转变的小组包括六个团队和许多子团队。一开始我们聘请了CollabNet 提供Scrum 教学和培训。大约20个小组的负责人和技术负责人参加了为期两天的ScrumMaster 认证培训，以便深入了解Scrum 的原理和实践。遗憾的是，三名高级经理错过了这次培训，导致其后的转变流程中出现了不少障碍。负责人的参与对我们的成功而言至关重要。由于我方三名职位主要负责人缺席了首次培训，导致他们对于我们设法做出的改变缺乏一定认知。
培训结束后，参与者们出席了一个回顾会议，在CollabNet 代表不在场的情况下讨论了他们对于Scrum 项目管理方式的看法、保留意见和接受程度。团队负责人同意在质疑新流程是否有效之前或按照Intel 需求对其进行定制之前，先用三个月时间“按照规定”来实施Scrum 原理和习惯。我们组建了一个流程行动团队（PAT）来监控试点团队内的Scrum 开发，并为流程中遇到的问__________题提供技术支持。即使达成了上述协议，我已然能够感觉到企业中支持Scrum 的人员分成了“猪”和“鸡”两派。
小组和团队负责人作为所有七个团队的“产品负责人”，而我作为ScrumMaster（Scrum 主管）。我强烈地意识到Scrum 是要在这些团队内实施的重要框架，我愿意承担风险来支持这种框架。虽然承担这种风险的结果十分乐观，但要管理七个团队来实施Scrum 长达整整一个季度，这使我差点撑不下去！
我们与CollabNet 顾问Michael James 和Dan Rawsthorne 一起研究，认为有一个自愿担当ScrumMaster 的人员对于各个团队的成功和稳定至关重要。首先，我们和Intel 管理层协商，以便确保ScrumMaster 这个职位在绩效评估体系中需要发挥的重要作用：是简化并促进Scrum 流程而非注重于管理经费。然后，那些报名担任ScrumMaster 职位的人员对于他们要负责的团队在技术方面不存在厉害关系。这有助于避免在他们的技术项目和促进Scrum 流程的职责之间产生任何利益冲突。预算的存在不是让ScrumMaster 为了促进ScrumMaster 的工作而放弃其自身的工程设计工作。不过，可以向报名担任ScrumMaster 的人员提供支持来适应职责的变化。
三个月过后，又有三个额外的ScrumMaster 来管理七个团队。此外，第八个团队自愿开始使用Scrum。大约五个月过后，调整所有Scrum 团队中的工作量是我们面临的最大挑战之一。在增加后来逐渐组建而成的额外五个团队之前，企业必须了解有关如何管理多个团队间相互依赖的更多知识，并实现团队间更好的交流。
我们再次聘请了Danube 为原先上过ScrumMaster 认证培训课程的员工和错过第一节课的高级经理教授有关对于Scrum 的工作量调整进行定制的课程。此次为期一天的培训不仅回顾了发布规划和冲刺规划的主要原理，还着重说明了如何跨多个团队调整工作量。我们再次采用了“学习、尝试、检验和适应”的方式来调整工作量。
学完一些有关工作量调整的“先进实践”后，我们开始分析团队中的问题，并尝试采用一种课堂上学会的调整模型，然后根据团队的实际环境对其进行定制。增加一些新职位来处理技术性依赖问题，并管理逐渐产生的更多部门后，该小组在一年内扩展成12个Scrum 团队，每个团队拥有5-9名开发人员。
我们与CollabNet 顾问讨论后得出：促成企业成功转变的两大因素是自愿性和自组织。虽然我们要求被委任三个月内“按规定”实施Scrum 的团队遵照关键原理和实践，显然适应比遵循更加重要。管理层所表现出的“请先试一下”的这种态度促使团队能够更好地接受。三个月试用期过后，这些团队被给予很大的自由，在每个冲刺中对自身进行组织和管理，并检验和适应他们采用的方式。虽然这些团队必须在一起工作，他们拥有尽可能多的自由来决定有效的方式。每周在与所有产品负责人和ScrumMaster 举行的PAT 会议中，我们讨论了偏移问题，但没有对其做出评判。我们在这一阶段的目标是团结和整合，而非达成一致。
可视性对于这个流程而言也是一个重要因素。内部的“维基”（Wiki）允许团队编写文档，指明哪些方式和信息对其很有帮助，哪些不太奏效，并对实践提出建议来更好地适应Scrum。
“按规定”实施Scrum 是让所有团队接受并采用Scrum 的一个必要环节。不过，就OAP 这种规模的企业而言，必须符合企业的某些组织结构和特定需求。长达三个月的试用期过后，我们对Scrum 方案做出了一些修改，使其能够符合并适应我们的文化和环境。首先，团队必须定义对其目标有用的角色。我们定义了以下角色：
· 业务负责人：高级经理或工程师负责人，主要职责是监督多个团队或为所有团队协调技术问题。业务负责人设置“路线图里程碑”（发布规划）并定义每个里程碑的“所需”功能。Scrum 团队仍然可以根据他们的速度对承诺的任务量进行调整，以便实现功能目标。
· 产品负责人：通常就是小组管理员。
· 技术负责人：技术负责人来自各个职能团队，他们可以共同处理整合、依从性和结构问题，来确保团队间相互关联的产量是一致的。技术负责人举行特别会议来将“史诗”分解成可以在各冲刺阶段中完成的“故
事”。
· ScrumMasters（Scrum 主管）：跨团队工程师，对于他或她作为ScrumMaster 的项目团队没有特定的利害关系。这有助于控制ScrumMaster 不合理的鞭策，使其在技术性解决方案中保持中立。
· 团队：团队负责此测试包的特定产量，很少与跨职能团队成员共事。几乎始终是一个孤立的职能竖井团队。
· 临时工：具有专门技能的小组成员，多个团队每次仅在一两个冲刺阶段中需要这些技能。他们在各冲刺的交接时期加入或退出。
· 沟通人员（Conduit）：这类团队成员既可以是承包总监（contractorsupervisor）也可以是远程团队的本地成员。沟通人员可以比常规的团队成员签署更多的故事点（story point）工作量。
· 故事负责人：了解如何完成一个“故事”的技术专家，他可以分配任务，也能要求特定的团队成员参与进来以便完成这些任务。他能准确告诉您“故事”的状态和进展。
最后，在这一产品开发阶段中，整个Scrum 团队小组从本质上而言都是其自己的客户。我们只是在构建基础设施以便支持硅片调试和制造。在项目的第一年里，基本不存在要求特定功能的外力。这使我们很难区分业务价值的优先级。因此，产品负责人和业务负责人设法通过预估业务价值和整体优先级来区分这些功能的优先级，大致上类似于依存性管理战略。
到第一年末，Scrum 已在我们的企业内扎根，成为我们工作规划和需求管理的默认框架。PAT 已获得关于“定制的Scrum 方案”是否奏效的大量数据。马上就要进入硅片阶段了。该流程能顶住实际的业务压力吗？还是在实践中会趋于“旧”方式而将这个新流程“扔出窗外”？
第二阶段：硅片阶段的生存考验
对于产品开发工程师而言，处理第一块硅片是十分艰巨的时刻。当硅片出现时，所有需求都不太明确，需要我们花费数周时间来收集有关硅片设备的必要数据，以便决定如何实行该项目。
根据在第一块硅片上发生的情况，我决定重新“检验并调整”我们公司所采用的Scrum 方式。我所看见的情况真的令我十分震惊。我有一个Scrum 团队已恢复他们的旧习惯。其他一些Scrum 团队决定对第一块硅片采取Scrum 方式不过都陆续失败了。其余那些坚持使用Scrum 方式的团队就像试图抓住救生圈的溺水者。
在这种环境下不可能继续保持我们为期两周的冲刺，大多数Scrum 团队转而采用了为期一天的冲刺。他们每天用一小时时间来开会，回顾和探讨过去的情况并规划接下来24小时要完成的任务。在处理第一块硅片的重压下，Scrum 的四个会议被浓缩成一个会议。不过，当我出席这些会议时，我发现Scrum 所主张的关键举措都在有条不紊地进行着，包括基于业务价值的优先级区分、团队规模的调整、任务范围不超过“产品订单（backlog）”的内容、改善流程并回顾工作成品等，只不过是随着对于设备认知的增长，以更小的规模和更快的速度进行着这一切。
在企业的所有负责人和经理都会出席的每日调试例会中，每次有任何专门的需求被提出时，我就会听到产品负责人询问：“产品订单中存在针对这个需求的故事吗？”我还发现不少开发人员抓住项目执行人或产品负责人并将他们拖拽到测试设备前，以便亲眼证实添加到他们程序中的内容是符合其验收标准的。
这一高强度的调试和开发阶段持续了几周。在该阶段末期，存活下来的Scrum 团队看上去安然无恙，并将他们的冲刺周期像手风琴一样重新延长至两周。他们在周五举行的调试会议上宣布了上述变更，并在下周正式实行，这种为期两周的冲刺延续至今依然十分有效。
第三阶段：为制造做准备
随着硅片的状况日渐健康，我们开始为制造做准备，我发现在硅片阶段后期这种环境下，职能竖井Scrum 团队被任务移交（handoff）搞得疲惫不堪。每当职责、知识、行动和反馈相互分离时，就会产生任务移交：
· 第一个人决定要做什么（职责）；
· 第二个人定义如何完成上述任务（知识）；
· 第三个人执行任务（行动）；
· 第四个人验证工作（反馈）。
此外，康威定律（Conway’s Law）指出：那些设计系统的企业受着产品设计的约束，而产品设计正是其企业通讯结构的缩影。我知道跨职能团队是Scrum 方式所规定的一部分，我感觉他们能够消除上述特定障碍，但是目前还未找到可行的解决方案，以便在企业内形成这种有效的组织。这时，我注意到团队成员组建了若干“特别行动组”（Task Force）来处理硅片内容问题。在Intel，“特别行动组”是一个为了解决危机而形成的跨职能团队。如果派您加入“特别行动组”，那是因为您是某一领域的专家。您必须先放下手头任务，立即投身于这个小组并为了成功完成该小组特定的任务尽心尽力，而且您无权拒绝。如果不改变企业的组织结构，我不知道如何获益于“特别行动组”的跨职能特点。
于是，我和Mary 与Tom Poppendieck 为该团队安排了一些“精益产品开发培训” ，“精益”培训向我们透露了一个有关如何在这一阶段有效使用Scrum 方式的重要线索：
· 保留职能团队：这些是十分有用的企业组织结构，因为团队中既有知识理论专家又有技术专家。还为Scrum 团队成员在项目间提供了一个类似于“家”的场所。
· 创建跨职能的“功能”性Scrums 团队：职能团队向跨职能的功能性Scrum 团队出借尽职尽责的专家。跨职能的Scrum 团队成员在冲刺期间需要全部地投入工作，不受其职能团队经理的制约。
当我听到这两点时，真有一种英雄所见略同的感觉。跨职能Scrum 团队就是不存在危机情况的“特别行动组”！
我们快速对一种内容类型进行了试验，结果团队成员都十分赞赏这种方式，它不但大幅度减少了任务移交，还促使团队成员一起处理问题。此外，知识的传递和交流也变得十分顺畅。如果在一个冲刺中不需要一个特定团队成员的职能，他可以和另一个团队成员搭档，通过相互培训来做一些力所能及的事情。
需要再次重申的是，时机就是一切。在我们年度现场会议中，非常及时地收集了有关跨职能团队试点的大量数据。
这是一个好机会来影响企业的领导，而且可以适当地对Scrum 方式做出调整和更正，使其能够比从前更有效地运作。我陈述了我的观察和见解，并提交了单个跨职能团队试点的早期数据，最终使企业领导批准了这种组织结构。事实上，所有反对者和企业内未表决的那部分人都接受了跨职能的Scrum概念。这使我们的流程新增了5个Scrum 团队，而且在两年后扩展到18个！
回顾：
我已使用了简单的（+）和（-）符号来明确说明哪些做法有效，哪些无效。
对于任务的完全定义（+）
由于我们没有编程语言，我们没有单元测试框架或离线回归。在微处理器产品开发中，单元测试意味着测试硅片单元！这促使我们专注于编写故事，当然重要的任务是编写良好的验收标准。验收标准（AC）通过详细说明实现客户满意度的需求来完整定义任务。
我们还实行了一个轻量级的验证环节，我们将其称之为“成对评审（PairReview）”。要完成一个故事，开发人员和产品负责人或项目执行人必须坐在一起探讨并对要符合的验收标准达成一致协议。我们通过“添加项”、“挽救项”和“遗漏项”这种形式来收集有关这一活动的简单衡量指标。
添加项是指项目执行人或产品负责人在“成对评审”过程中加入故事的额外验收标准，被当前冲刺周期内的开发人员所接受，而且可以作为针对模糊的故事验收标准的一项指示。挽救项是指在这个冲刺中创建并在稍后捕获的问题。遗漏项是指在上一个冲刺中创建并在当前冲刺中找到的问题。挽救项说明验证过程是否在有效运作，而遗漏项则表示该过程仍需改进。
此外，我们必须定义的验证过程。该验证不能泛泛而谈，因此每个Scrum 团队必须为验证规则建档，尤其要定义需要验证哪些针对其工作产品的任务。验证必须确保“故事”在相关工作产品中能够有效地运作，而且通常涉及的一项内容是在测试环境中运行这些设备。
只有完成了所有任务并通过了验证和检验才算完成一个“故事”。
概不“赊欠”（+）
在为下一个冲刺确定速度时，不会对基于上述定义未完成的故事网开一面。这似乎过于严厉，但是必须强制团队重视验证和检验需求，并确保他们的预估中包括这些步骤。此外，还必须强制团队重视他们的承诺。如果您承诺会完成任务，但是您只交付了90%的任务，那就表示您失败了。
为期9天的冲刺（+）
我们的冲刺周期为9天，并在每周五举行评审、回顾和规划会议。这能使团队在每周末脱离冲刺，有助于改善Scrum 团队的生活质量，并提高他们的士气。另一方面，每周末处于冲刺的中段，便于团队成员决定他们是否需要在周末工作以便达成其目标。前半年极少发生这种情况，我们已实现了平稳持续的步调和节奏。
步调（+）
为期9天的冲刺这种步调允许产品负责人、业务负责人和团队在必要时在频繁的间歇里改变方向。该步调通常有助于减少我们在以前项目中所发现的需求量过重问题，而高级经理也能在每周五逐渐了解团队能够生产出的实际工作产品。我们收集的数据表明：当冲刺被严重打断时，将丢失10%-20%的速率。我们将其称之为“冲刺中断税”。如果冲刺在第一周被打断，将丢失10%的速率，如果冲刺在第二周被打断，将丢失20%的速率。必须让经理们注意到这份统计，使他们避免破坏规划周期的步调。我们还增加了一个规定：如果对当前冲刺做出任何更改，都必须重新考虑和协商任务范围。此外，在出现必要的打断时，管理层也要积极响应，他们通常一起探讨并换出一些冲刺产品订单中的项目。
团队中的产品负责人（─）
为了促进产品负责人和团队间更好的交流，我们允许产品负责人作为各个团队的成员加入。在某些情况下，这十分有效，不过在另外一些情况下，产品负责人对团队进行了微观管理，他们指定日常任务，阻碍了团队成员间真诚的交流与沟通。这导致团队举行秘密会议，在产品负责人/职能经理的视线之外讨论实际的组织结构障碍。虽然这些问题会在日后解决，但它们严重削弱了团队的自组织能力。当我们组建跨职能Scrum 团队时，我们禁止了这种实践。
集中式的Scrum 工具（+）
Scrum 要求通过簿记来生成有用的衡量标准，例如每日的燃尽图表。实践表明的确如此，尤其是多个Scrum 团队在您企业内同时运作的时候。拥有一个开放访问的集成式工具对于转变的成功而言十分有益。在采用Scrum 方式的初始阶段，我们找不到支持Scrum 的工具，因此我们创建了自己的工具。我们从XPlanner 着手，并利用Java 和SOAP 从各方面对其进行了自定义，我们将最终成品称为“XPlanner2”。根据这些学习所得，我们创建了一个定制的Windows 应用程序。这款集中式工具一直作为一个钥匙启用器，用来管理多个团队。我认为您必须拥有工具来实现并促进大规模的Scrum 团队，由于现在已提供多种现成且愈加完善的工具，我已不再采用自创的工具了。
在微处理器行业中，产品开发工程设计（PDE）团队提供相关测试来进行经济实惠的设备检验和分类。PDE 夹在实际设计团队和工厂制造团队之间，由于缺乏对于（团队级别的）期限、范围、需求或可交付产品的控制，他们时常承受着巨大的压力。
为了更好地协调PDE 内各个子团队的工作，总数约50人的7个团队自主探索了一个协调度更好的方式来进行产品开发。要实现这种协调和整合，笔者认为Scrum 是可以采用的项目管理框架，同时还要结合敏捷工程设计的实践。本文说明了该企业对于Scrum 的学习和探索，以及这项投资的结果。
介绍
在采用“敏捷”和Scrum 方式的软件工程设计领域中，存在大量实践。其中许多实践针对利用小团队的中小型企业，他们采用面向对象的语言开发软件。位于美国俄勒冈和太平洋地区（OAP）的PDE 团队是一个大型企业，需要跨越多个团队和站点、跨越多种文化和环境来实施Scrum 和“敏捷”软件开发。我们的工作产品是一款在自动测试设备（ATE）上运行的测试程序。ATE 拥有专属的操作系统和接口语言，这有碍于我们使用行业标准和现有的软件验证解决方案。事实上，我们正在一个使用专属语言的环境中工作，而且既没有现成的单元测试框架，也无法进行离线测试。此外，长期以来我们一直深受以下问题的困扰，包括需求探讨、过度承诺、未赶上时间安排、日以继夜的工作周、士气低落和很高的职员流动率。
长久的构建和制造历史导致Intel 具有浓厚的瀑布式软件开发的文化氛围，而且他们普遍将瀑布式软件开发视为通向成功的先进途径。团队通常以孤立的职能“竖井”（functional silo）形式进行组建，遵照时间安排定期将可交付的产品移交给其他职能竖井团队。其结果就是：某些团队在产品生命周期的后阶段承受着巨大的重负，而且在项目末期存在着很高的职员流动率。最终导致每个团队收纳各种领域专家，他们所具有的技能很少与其他团队成员一致。因此一个团队中的各个成员很难成为搭档共同负责一些任务。
尽管面临那么多挑战，我们还是决定勇往直前，不过准备采用不同的方式来管理项目，以便更好地团结测试团队，更顺利地交付我们的工作产品。在项目的初始阶段，我们选择为企业引入Scrum，其中大部分工作为硅前（presilicon）基础设施的开发和一些准备工作。如果我们能够在第一阶段使Scrum有效地运作，我们认为在一个项目相对平稳的阶段中习得的实践可以为我们指明方向，通往压力更大的执行阶段——在此期间，日常工作量完全取决于实际硅片的健康状况、不断变化的外部商业景气、以及客户对于设计、生产和制造的要求。
第一阶段：针对硅片的准备工作
第一个要进行转变的小组包括六个团队和许多子团队。一开始我们聘请了CollabNet 提供Scrum 教学和培训。大约20个小组的负责人和技术负责人参加了为期两天的ScrumMaster 认证培训，以便深入了解Scrum 的原理和实践。遗憾的是，三名高级经理错过了这次培训，导致其后的转变流程中出现了不少障碍。负责人的参与对我们的成功而言至关重要。由于我方三名职位主要负责人缺席了首次培训，导致他们对于我们设法做出的改变缺乏一定认知。
培训结束后，参与者们出席了一个回顾会议，在CollabNet 代表不在场的情况下讨论了他们对于Scrum 项目管理方式的看法、保留意见和接受程度。团队负责人同意在质疑新流程是否有效之前或按照Intel 需求对其进行定制之前，先用三个月时间“按照规定”来实施Scrum 原理和习惯。我们组建了一个流程行动团队（PAT）来监控试点团队内的Scrum 开发，并为流程中遇到的问__________题提供技术支持。即使达成了上述协议，我已然能够感觉到企业中支持Scrum 的人员分成了“猪”和“鸡”两派。
小组和团队负责人作为所有七个团队的“产品负责人”，而我作为ScrumMaster（Scrum 主管）。我强烈地意识到Scrum 是要在这些团队内实施的重要框架，我愿意承担风险来支持这种框架。虽然承担这种风险的结果十分乐观，但要管理七个团队来实施Scrum 长达整整一个季度，这使我差点撑不下去！
我们与CollabNet 顾问Michael James 和Dan Rawsthorne 一起研究，认为有一个自愿担当ScrumMaster 的人员对于各个团队的成功和稳定至关重要。首先，我们和Intel 管理层协商，以便确保ScrumMaster 这个职位在绩效评估体系中需要发挥的重要作用：是简化并促进Scrum 流程而非注重于管理经费。然后，那些报名担任ScrumMaster 职位的人员对于他们要负责的团队在技术方面不存在厉害关系。这有助于避免在他们的技术项目和促进Scrum 流程的职责之间产生任何利益冲突。预算的存在不是让ScrumMaster 为了促进ScrumMaster 的工作而放弃其自身的工程设计工作。不过，可以向报名担任ScrumMaster 的人员提供支持来适应职责的变化。
三个月过后，又有三个额外的ScrumMaster 来管理七个团队。此外，第八个团队自愿开始使用Scrum。大约五个月过后，调整所有Scrum 团队中的工作量是我们面临的最大挑战之一。在增加后来逐渐组建而成的额外五个团队之前，企业必须了解有关如何管理多个团队间相互依赖的更多知识，并实现团队间更好的交流。
我们再次聘请了Danube 为原先上过ScrumMaster 认证培训课程的员工和错过第一节课的高级经理教授有关对于Scrum 的工作量调整进行定制的课程。此次为期一天的培训不仅回顾了发布规划和冲刺规划的主要原理，还着重说明了如何跨多个团队调整工作量。我们再次采用了“学习、尝试、检验和适应”的方式来调整工作量。
学完一些有关工作量调整的“先进实践”后，我们开始分析团队中的问题，并尝试采用一种课堂上学会的调整模型，然后根据团队的实际环境对其进行定制。增加一些新职位来处理技术性依赖问题，并管理逐渐产生的更多部门后，该小组在一年内扩展成12个Scrum 团队，每个团队拥有5-9名开发人员。
我们与CollabNet 顾问讨论后得出：促成企业成功转变的两大因素是自愿性和自组织。虽然我们要求被委任三个月内“按规定”实施Scrum 的团队遵照关键原理和实践，显然适应比遵循更加重要。管理层所表现出的“请先试一下”的这种态度促使团队能够更好地接受。三个月试用期过后，这些团队被给予很大的自由，在每个冲刺中对自身进行组织和管理，并检验和适应他们采用的方式。虽然这些团队必须在一起工作，他们拥有尽可能多的自由来决定有效的方式。每周在与所有产品负责人和ScrumMaster 举行的PAT 会议中，我们讨论了偏移问题，但没有对其做出评判。我们在这一阶段的目标是团结和整合，而非达成一致。
可视性对于这个流程而言也是一个重要因素。内部的“维基”（Wiki）允许团队编写文档，指明哪些方式和信息对其很有帮助，哪些不太奏效，并对实践提出建议来更好地适应Scrum。
“按规定”实施Scrum 是让所有团队接受并采用Scrum 的一个必要环节。不过，就OAP 这种规模的企业而言，必须符合企业的某些组织结构和特定需求。长达三个月的试用期过后，我们对Scrum 方案做出了一些修改，使其能够符合并适应我们的文化和环境。首先，团队必须定义对其目标有用的角色。我们定义了以下角色：
· 业务负责人：高级经理或工程师负责人，主要职责是监督多个团队或为所有团队协调技术问题。业务负责人设置“路线图里程碑”（发布规划）并定义每个里程碑的“所需”功能。Scrum 团队仍然可以根据他们的速度对承诺的任务量进行调整，以便实现功能目标。
· 产品负责人：通常就是小组管理员。
· 技术负责人：技术负责人来自各个职能团队，他们可以共同处理整合、依从性和结构问题，来确保团队间相互关联的产量是一致的。技术负责人举行特别会议来将“史诗”分解成可以在各冲刺阶段中完成的“故
事”。
· ScrumMasters（Scrum 主管）：跨团队工程师，对于他或她作为ScrumMaster 的项目团队没有特定的利害关系。这有助于控制ScrumMaster 不合理的鞭策，使其在技术性解决方案中保持中立。
· 团队：团队负责此测试包的特定产量，很少与跨职能团队成员共事。几乎始终是一个孤立的职能竖井团队。
· 临时工：具有专门技能的小组成员，多个团队每次仅在一两个冲刺阶段中需要这些技能。他们在各冲刺的交接时期加入或退出。
· 沟通人员（Conduit）：这类团队成员既可以是承包总监（contractorsupervisor）也可以是远程团队的本地成员。沟通人员可以比常规的团队成员签署更多的故事点（story point）工作量。
· 故事负责人：了解如何完成一个“故事”的技术专家，他可以分配任务，也能要求特定的团队成员参与进来以便完成这些任务。他能准确告诉您“故事”的状态和进展。
最后，在这一产品开发阶段中，整个Scrum 团队小组从本质上而言都是其自己的客户。我们只是在构建基础设施以便支持硅片调试和制造。在项目的第一年里，基本不存在要求特定功能的外力。这使我们很难区分业务价值的优先级。因此，产品负责人和业务负责人设法通过预估业务价值和整体优先级来区分这些功能的优先级，大致上类似于依存性管理战略。
到第一年末，Scrum 已在我们的企业内扎根，成为我们工作规划和需求管理的默认框架。PAT 已获得关于“定制的Scrum 方案”是否奏效的大量数据。马上就要进入硅片阶段了。该流程能顶住实际的业务压力吗？还是在实践中会趋于“旧”方式而将这个新流程“扔出窗外”？
第二阶段：硅片阶段的生存考验
对于产品开发工程师而言，处理第一块硅片是十分艰巨的时刻。当硅片出现时，所有需求都不太明确，需要我们花费数周时间来收集有关硅片设备的必要数据，以便决定如何实行该项目。
根据在第一块硅片上发生的情况，我决定重新“检验并调整”我们公司所采用的Scrum 方式。我所看见的情况真的令我十分震惊。我有一个Scrum 团队已恢复他们的旧习惯。其他一些Scrum 团队决定对第一块硅片采取Scrum 方式不过都陆续失败了。其余那些坚持使用Scrum 方式的团队就像试图抓住救生圈的溺水者。
在这种环境下不可能继续保持我们为期两周的冲刺，大多数Scrum 团队转而采用了为期一天的冲刺。他们每天用一小时时间来开会，回顾和探讨过去的情况并规划接下来24小时要完成的任务。在处理第一块硅片的重压下，Scrum 的四个会议被浓缩成一个会议。不过，当我出席这些会议时，我发现Scrum 所主张的关键举措都在有条不紊地进行着，包括基于业务价值的优先级区分、团队规模的调整、任务范围不超过“产品订单（backlog）”的内容、改善流程并回顾工作成品等，只不过是随着对于设备认知的增长，以更小的规模和更快的速度进行着这一切。
在企业的所有负责人和经理都会出席的每日调试例会中，每次有任何专门的需求被提出时，我就会听到产品负责人询问：“产品订单中存在针对这个需求的故事吗？”我还发现不少开发人员抓住项目执行人或产品负责人并将他们拖拽到测试设备前，以便亲眼证实添加到他们程序中的内容是符合其验收标准的。
这一高强度的调试和开发阶段持续了几周。在该阶段末期，存活下来的Scrum 团队看上去安然无恙，并将他们的冲刺周期像手风琴一样重新延长至两周。他们在周五举行的调试会议上宣布了上述变更，并在下周正式实行，这种为期两周的冲刺延续至今依然十分有效。
第三阶段：为制造做准备
随着硅片的状况日渐健康，我们开始为制造做准备，我发现在硅片阶段后期这种环境下，职能竖井Scrum 团队被任务移交（handoff）搞得疲惫不堪。每当职责、知识、行动和反馈相互分离时，就会产生任务移交：
· 第一个人决定要做什么（职责）；
· 第二个人定义如何完成上述任务（知识）；
· 第三个人执行任务（行动）；
· 第四个人验证工作（反馈）。
此外，康威定律（Conway’s Law）指出：那些设计系统的企业受着产品设计的约束，而产品设计正是其企业通讯结构的缩影。我知道跨职能团队是Scrum 方式所规定的一部分，我感觉他们能够消除上述特定障碍，但是目前还未找到可行的解决方案，以便在企业内形成这种有效的组织。这时，我注意到团队成员组建了若干“特别行动组”（Task Force）来处理硅片内容问题。在Intel，“特别行动组”是一个为了解决危机而形成的跨职能团队。如果派您加入“特别行动组”，那是因为您是某一领域的专家。您必须先放下手头任务，立即投身于这个小组并为了成功完成该小组特定的任务尽心尽力，而且您无权拒绝。如果不改变企业的组织结构，我不知道如何获益于“特别行动组”的跨职能特点。
于是，我和Mary 与Tom Poppendieck 为该团队安排了一些“精益产品开发培训” ，“精益”培训向我们透露了一个有关如何在这一阶段有效使用Scrum 方式的重要线索：
· 保留职能团队：这些是十分有用的企业组织结构，因为团队中既有知识理论专家又有技术专家。还为Scrum 团队成员在项目间提供了一个类似于“家”的场所。
· 创建跨职能的“功能”性Scrums 团队：职能团队向跨职能的功能性Scrum 团队出借尽职尽责的专家。跨职能的Scrum 团队成员在冲刺期间需要全部地投入工作，不受其职能团队经理的制约。
当我听到这两点时，真有一种英雄所见略同的感觉。跨职能Scrum 团队就是不存在危机情况的“特别行动组”！
我们快速对一种内容类型进行了试验，结果团队成员都十分赞赏这种方式，它不但大幅度减少了任务移交，还促使团队成员一起处理问题。此外，知识的传递和交流也变得十分顺畅。如果在一个冲刺中不需要一个特定团队成员的职能，他可以和另一个团队成员搭档，通过相互培训来做一些力所能及的事情。
需要再次重申的是，时机就是一切。在我们年度现场会议中，非常及时地收集了有关跨职能团队试点的大量数据。
这是一个好机会来影响企业的领导，而且可以适当地对Scrum 方式做出调整和更正，使其能够比从前更有效地运作。我陈述了我的观察和见解，并提交了单个跨职能团队试点的早期数据，最终使企业领导批准了这种组织结构。事实上，所有反对者和企业内未表决的那部分人都接受了跨职能的Scrum概念。这使我们的流程新增了5个Scrum 团队，而且在两年后扩展到18个！
回顾：
我已使用了简单的（+）和（-）符号来明确说明哪些做法有效，哪些无效。
对于任务的完全定义（+）
由于我们没有编程语言，我们没有单元测试框架或离线回归。在微处理器产品开发中，单元测试意味着测试硅片单元！这促使我们专注于编写故事，当然重要的任务是编写良好的验收标准。验收标准（AC）通过详细说明实现客户满意度的需求来完整定义任务。
我们还实行了一个轻量级的验证环节，我们将其称之为“成对评审（PairReview）”。要完成一个故事，开发人员和产品负责人或项目执行人必须坐在一起探讨并对要符合的验收标准达成一致协议。我们通过“添加项”、“挽救项”和“遗漏项”这种形式来收集有关这一活动的简单衡量指标。
添加项是指项目执行人或产品负责人在“成对评审”过程中加入故事的额外验收标准，被当前冲刺周期内的开发人员所接受，而且可以作为针对模糊的故事验收标准的一项指示。挽救项是指在这个冲刺中创建并在稍后捕获的问题。遗漏项是指在上一个冲刺中创建并在当前冲刺中找到的问题。挽救项说明验证过程是否在有效运作，而遗漏项则表示该过程仍需改进。
此外，我们必须定义的验证过程。该验证不能泛泛而谈，因此每个Scrum 团队必须为验证规则建档，尤其要定义需要验证哪些针对其工作产品的任务。验证必须确保“故事”在相关工作产品中能够有效地运作，而且通常涉及的一项内容是在测试环境中运行这些设备。
只有完成了所有任务并通过了验证和检验才算完成一个“故事”。
概不“赊欠”（+）
在为下一个冲刺确定速度时，不会对基于上述定义未完成的故事网开一面。这似乎过于严厉，但是必须强制团队重视验证和检验需求，并确保他们的预估中包括这些步骤。此外，还必须强制团队重视他们的承诺。如果您承诺会完成任务，但是您只交付了90%的任务，那就表示您失败了。
为期9天的冲刺（+）
我们的冲刺周期为9天，并在每周五举行评审、回顾和规划会议。这能使团队在每周末脱离冲刺，有助于改善Scrum 团队的生活质量，并提高他们的士气。另一方面，每周末处于冲刺的中段，便于团队成员决定他们是否需要在周末工作以便达成其目标。前半年极少发生这种情况，我们已实现了平稳持续的步调和节奏。
步调（+）
为期9天的冲刺这种步调允许产品负责人、业务负责人和团队在必要时在频繁的间歇里改变方向。该步调通常有助于减少我们在以前项目中所发现的需求量过重问题，而高级经理也能在每周五逐渐了解团队能够生产出的实际工作产品。我们收集的数据表明：当冲刺被严重打断时，将丢失10%-20%的速率。我们将其称之为“冲刺中断税”。如果冲刺在第一周被打断，将丢失10%的速率，如果冲刺在第二周被打断，将丢失20%的速率。必须让经理们注意到这份统计，使他们避免破坏规划周期的步调。我们还增加了一个规定：如果对当前冲刺做出任何更改，都必须重新考虑和协商任务范围。此外，在出现必要的打断时，管理层也要积极响应，他们通常一起探讨并换出一些冲刺产品订单中的项目。
团队中的产品负责人（─）
为了促进产品负责人和团队间更好的交流，我们允许产品负责人作为各个团队的成员加入。在某些情况下，这十分有效，不过在另外一些情况下，产品负责人对团队进行了微观管理，他们指定日常任务，阻碍了团队成员间真诚的交流与沟通。这导致团队举行秘密会议，在产品负责人/职能经理的视线之外讨论实际的组织结构障碍。虽然这些问题会在日后解决，但它们严重削弱了团队的自组织能力。当我们组建跨职能Scrum 团队时，我们禁止了这种实践。
集中式的Scrum 工具（+）
Scrum 要求通过簿记来生成有用的衡量标准，例如每日的燃尽图表。实践表明的确如此，尤其是多个Scrum 团队在您企业内同时运作的时候。拥有一个开放访问的集成式工具对于转变的成功而言十分有益。在采用Scrum 方式的初始阶段，我们找不到支持Scrum 的工具，因此我们创建了自己的工具。我们从XPlanner 着手，并利用Java 和SOAP 从各方面对其进行了自定义，我们将最终成品称为“XPlanner2”。根据这些学习所得，我们创建了一个定制的Windows 应用程序。这款集中式工具一直作为一个钥匙启用器，用来管理多个团队。我认为您必须拥有工具来实现并促进大规模的Scrum 团队，由于现在已提供多种现成且愈加完善的工具，我已不再采用自创的工具了。
服务热线：400-821-3806
深圳 0755-23706296
北京 010-82359258
上海 021-62650520
总机 021-52653259
扫一扫关注公众号
