敏捷案例研究 - Cayen Systems
5.00/5 (12投票s)
来自威斯康星州密尔沃基一家小型软件公司敏捷转型的信息和观察。
变革时期
2002年，美国教育部启动了《不让一个孩子掉队》计划。Cayen Systems已经有许多学区客户，因此接到了密尔沃基公立学校和其他几个学区的联系，要求为其当前的课后数据收集和报告的Web应用程序“APlus”进行增强，以帮助管理学区内NCLB授权的补充教育服务（SES）计划。2003年末，Cayen Systems推出了“APlus SST”（补充服务跟踪器）——其用于SES计划管理的基于Web的解决方案。
该产品取得了成功。第一年就有39个学区在使用该产品。到2009年初，已有200个学区使用APlus SST管理其SES计划。Cayen Systems利用其更广泛的客户群，为APlus平台创建了更多对学区/组织内其他部门有用的产品。增加了选择安置、GEAR UP、SES提供商、联邦库存和Title I的模块。他们构建了一个基于生物识别的考勤扫描插件。他们还为单一站点非营利组织管理构建了一个独立的基于Web的应用程序。此外，他们开始开发一个基于Web的日校管理系统，“Cayen SchoolAdmin”。
快速增长虽然对销售有利，但也开始暴露出公司软件开发生命周期中的一些弱点。在2009年全年，这些弱点逐渐变得更加明显和严重。转折点发生在2009年8月底；在APlus 6.0发布后的第二天，Cayen Systems收到了超过350个支持电话。很明显，需要一种新的方法来满足不断增长的客户群和日益复杂的软件系统的需求。
团队面临的挑战:
- 发布经常迟到，平均比目标交付日期晚4.5天。
- 发布的产品版本很大。典型的发布周期为8-12周。
- 工作估算严重不准确。平均而言，一个估算为10小时的任务，团队花费了21.4小时才完成。
- 质量正在下降。主要应用程序的现有bug数量超过220个，并且随着每次发布而增加。
- 角色和职责非常“孤立”。如果某些团队成员因“只有他们能做”而缺勤，某些任务就会完全停止，这会造成常规的障碍。
- 团队成员，特别是QA工程师，不断被要求去处理紧急问题。
- 开发人员很少直接与客户或客户服务团队成员联系，以听到“客户的声音”。通常不鼓励与其他团队成员直接交流。
- 系统集成耗时、缓慢且容易出错。测试和部署一个版本通常需要至少一周时间。
旅程
反思
团队开始通过改变内部流程来应对挑战。他们花时间修改了ERP系统，试图让公司里的每个人都能更容易地理解每个团队正在对某个工作项做什么，以及它处于开发生命周期的哪个阶段。各个部门也开始更频繁地开会；甚至偶尔也会跨团队会议。
大多数利益相关者（内部和外部）认为产品质量最需要改进。内部测试流程进行了修订和更新，以包含更多的审查点；现在将由两名团队成员测试一个工作项，而不是只有一名。客户服务团队成员被要求参与每个发布周期的版本/集成测试阶段，以获得对即将到来的更改的“客户视角”。
团队还开始为每个可交付的工作项编写“测试计划”（基于TMap的模板）。下面是其中一个测试计划的样本。
虽然这些努力旨在解决已知的问题区域，但通过内部来制定定制化的解决方案就是行不通的。所有额外的流程步骤、会议和文档都导致了更长的交付时间。质量和沟通实际上并没有得到改善。团队在克服挑战方面没有看到多少进展。
一些团队成员建议研究一个已建立的、标准化的开发生命周期模型，其他软件公司正在成功使用它。经过对选项的研究，Scrum模型似乎是一个不错的选择。幸运的是，团队从错误中吸取了教训——他们知道自己需要帮助。管理层决定聘请一位经验丰富的教练来领导这项工作，并与Redpoint Technologies找到了一个绝佳的合作伙伴。
我们的教练在他们最初的几个Sprint中每周2-3天在现场与团队一起工作，帮助他们理解和实施Scrum和敏捷的基本原则和实践。他花时间与管理层沟通，了解他们的目标和宗旨，并根据他观察当前实践的经验提出了一些建议。他还通过实施标准的Scrum“仪式”会议：每日站会、计划会议和Sprint回顾会议，帮助团队建立工作节奏。
团队装备了新知识、经过验证的技术和基于专家分析的行动计划，准备好应对挑战。
坚实的基础
团队对当前的版本构建和集成过程感到最痛苦，并同意这是他们首先要解决的挑战。在此之前，当前的流程是在整个发布周期内在一个隔离的开发环境中进行编码和测试。在目标发布日期前一周，团队会设置6-8个测试站点，每个主要产品一个，并将他们的工作部署到这组站点。计划发布的修改后的源文件列表是通过手工从ERP系统中检索的。开发经理通常会执行这项任务，将每个标记有当前发布号的工作项的“修改对象”列表中的文件名复制粘贴到一个Excel电子表格中。然后手动从源控制系统中签出文件，并手动复制到每个测试站点。
所有手动步骤使该过程极易出错且非常耗时。通常需要大约2天时间来生成修改文件的列表，从源控制中签出，重建测试环境，并部署更改。然后还需要一天时间来处理和纠正8-10周工作带来的集成问题。最后，还需要2-3天时间来完成所有分步的功能测试文档。有些版本，根据发现问题的多少，需要团队重复此过程2-3次。
团队决定实施一个简单的持续集成测试模型。几位开发人员一起创建了一个连接ERP和源控制系统的小型实用程序。只需少量用户输入，就可以快速收集和检索特定版本任何产品的所有修改后的源文件以进行部署。
团队还设置了一个专用的测试服务器，该服务器构建了客户数据的快照和站点，以确保他们像客户一样测试和审查他们的更改。他们还指定了一个构建工程师角色来管理和维护测试服务器和构建过程。现在，拉取和测试任何产品的最新构建都很容易。重建测试环境现在可以在几个小时内完成，而不是几天。
从那时起，每周一都会重建测试环境。从源控制中收集最新的构建并推送到测试站点。最新的客户数据库从生产服务器中拉取，覆盖上周的数据。任何集成问题都会在工作周开始时立即检测到，为团队在下一次构建发生之前解决它们提供了充足的时间。
该公司在进入生产环境的bug和集成问题数量上看到了急剧下降。在使用该过程几个Sprint后，集成问题几乎不复存在，bug数量开始下降。该过程和测试环境变得如此稳定，以至于客户可以访问他们自己的“测试站点”来预览自定义功能或重大更改。
讲故事
接下来，团队决定解决冗长的规格说明和测试文档。平均而言，他们编写这些文档花费的时间是编写和测试代码的三倍——而且文档很少可重用。
开发任务在规格文档中进行了描述。每个“spec”由分析师编写，经理评审，开发人员编码。大多数spec都有两个版本；一个供客户使用，一个供内部使用。经理总是估算工作量。下面是一个用于为客户构建报告的内部spec的样本部分。
|
SST评估报告 - SES vs. 非SES – [开发人员]/[分析师] 原始作者：[分析师]于2009年12月15日 由：[经理]于2009年12月21日评审 修订者：[开发人员]于2009年12月29日 由：[经理]于2009年12月30日评审 背景： 需要一份报告，显示所选测试的SES和非SES学生的平均分数、最高分数、最低分数、中位数和众数。 创建新的[报告]记录：
|
我们的教练建议尝试使用用户故事格式来捕获需求。团队开发了一个基本模板，并在实施后立即看到了生产力的提高。他们现在能够创建一个单一的文档，其中包含了需求、细节和验收/测试标准——同时仍然允许团队在如何完成工作方面具有创意灵活性。相同的文档也可以与利益相关者（内部或外部）共享和修改。这是一个来自我们为客户构建的报告的用户故事样本。
| 作为一名SES用户，我需要一份显示我项目学生申请状态的报告。 |
详细信息：创建一份按申请状态分组学生的报告。（图3）
|
12小时 |
估算所有可交付工作项的责任也转移到了团队身上。对于小型任务，团队中的1-2名成员会审查故事并提供估算。对于大型项目，团队开始举行Planning Poker会议来一起估算所有工作项。
创建工作项和需求列表，这以前是开发过程中最耗时的部分，现在是最简单的部分之一。它还使得工作估算更加高效和准确，因为所有参与者都可以轻松理解功能的范围以及交付它所需的内容。
敏捷的提炼
团队采用敏捷后不久，就发现我们的产品不稳定。每天都有注入（bug）出现，团队成员感到沮丧。我们采用四周一个Sprint然后发布，这显然太长了，因为每天都在发生大量的变化。为了解决这个问题，产品负责人和团队决定在Scrum板上添加一个“关键bug”部分。这一部分将与主要的Sprint具有独立的优先级，随后团队期望同时管理两者。这种新流程立即开始失败。团队被分裂，对产品没有清晰的愿景。需要改变，但我们不确定如何处理。
我们的教练建议我们做两件事。第一，缩短Sprint周期，以实现持续改进。在第一个Sprint中识别的用户故事可以在第二个Sprint中处理，而不会被视为“注入”。第二，将团队分成两组。由于我们不断收到客户的定制化请求，以及稳定产品所需的持续bug修复，因此让两个团队拥有独立且更具体的目标是有意义的。在第一个Sprint内，团队和产品负责人就开始感受到这些变化带来的成功。维护团队可以采用为期一周的Sprint——实现更快速的发布。而定制化团队可以专注于更长的Sprint来构建更大的功能。出乎意料的是，我们发现3-4人的团队运作更有效率；沟通得到改善，内部障碍最小化。改变奏效了！
Cayen没有“我”
我们教练最初向管理层提出的建议之一是专注于并鼓励跨团队协作。然而，现有的工作环境是分裂的。隔间将团队彼此隔开。管理层在楼上，客户服务和QA在一楼，而工程部在地下室。
为了缓解这一挑战，管理层决定将所有团队都搬到同一层楼。几乎所有的隔间墙都被拆除，为所有人腾出空间并创建一个开放的工作空间。
他们还在一个现在空置的办公室里设立了一个专门的Scrum房间。公司所有团队都在这里拥有看板和每日或每周Scrum会议，以帮助在整个组织中传播可见性和互动。
上面：IT/行政、新产品、客户关怀和业务发展。
下面：数据服务和经典（APlus）产品。
因此，自改变以来，跨团队沟通得到了显著改善。可以轻松地走到某人的工作站询问问题，或者将开发人员拉到客户电话中回答技术问题。协作的线程每天都在组织中贯穿。
迄今为止的结果
- 我们所有的内部团队/部门，包括管理层，现在都将Scrum框架和敏捷概念作为日常工作流程的常规部分。
- 发布几乎总能按时完成，过去两年只错过了两次目标日期。即使在那两次情况下，我们也提前1天交付了发布。
- 交付时间大大缩短，每3-5周发布一次。
- 估算准确，平均偏差为4.4%。一个10小时的任务现在团队大约需要10.4小时完成。
- 所有产品的bug数量下降了+65%，并且随着每次发布的进行仍在继续下降。
- 在客户关怀调查中，团队平均对员工互动的满意度为96.6%。
- 团队更具参与感，更有能力做出有利于组织和客户的决策。很少有支持工单会超出客户关怀和QA团队的处理范围。
- 团队合作和协作大大提高，使开发人员对客户的愿望和需求有更深入的了解。新功能/定制在投入生产之前会展示给内部和外部利益相关者。客户在定制功能开发期间还可以获得专用的测试站点，以便在部署到生产站点之前对其进行审查和验证。
敏捷强调持续改进。我们为我们的成就感到自豪，但也认识到我们仍然有很多可以做得更好的地方——为了我们的客户、我们的业务和我们自己。
结论
从这次经历中我们学到的一些东西:
- 始终将客户的需求放在首位。所有团队都应该尽可能多地听到“客户的声音”。尽可能多地让客户参与到开发生命周期中。
- 协作至关重要。在组织的各个层面以及外部客户群中，持续的沟通和反馈确实非常有价值。
- 高层管理人员的支持对我们的成功至关重要。他们渴望改变并推动了改变——通过投资于流程（引入专家指导团队、Scrum看板/材料、工作环境改变等），并不断传达他们改善日常流程的愿望。
- 拥有一位优秀的教练确实帮助我们顺利启动。除了他提供的经验、见解和绝佳指导外，他还通过作为中立的第三方和受人尊敬的专家，平息了在旅程关键节点上发生的内部分歧。
- 产品所有者角色是高效敏捷团队非常重要的一部分。拥有一个精心打磨的产品待办事项列表和一个最新的产品路线图，为项目的所有参与者——团队、管理层和客户——提供了更高的愿景和灵活性。
- 收集并发布指标。让你的结果（好坏）可见。好的结果是值得分享的成功；坏的结果是共同改进的目标。
- “不要成为你范式的受害者。”这是我们Scrum教练的一句名言。基本上，在组织的所有层面上，对新的想法、意见和技术保持开放的心态，是成功实现敏捷的关键。
资源
本文档中包含许多链接，详细描述了我们使用的术语或流程。我们还经常引用Mountain Goat Software的材料。这里有很多很棒的、精美的演示文稿，您的团队/小组可以加以利用。“Scrum概述”和“有效的用户故事”对我们特别有用。他们的书籍也是绝佳的信息来源。
我们还想分享一些我们在过程中收集或创建的简单工具（可下载内容 - 48kb）
- Roadmap.xls - 一开始，我们很难看到当前Sprint或发布周期之外的事情。这给我们规划大型项目或协调跨团队工作带来了许多问题——直到我们开始使用这个工具。现在，公司里的任何人都可以打开这个文件，在几秒钟内就能看到我们未来几个月的工作计划。
- Product Backlog.xls - 实际上就是一个简单的待办事项列表。我们的团队目前将故事保存在定制的ERP系统中，但当“白板”一个大型功能或项目时，我们仍然会不时使用这个模板。请注意，我们以小时为单位估算故事。我们这样做有几个业务原因；您的业务/团队可能希望使用更抽象的估算。
- Sprint Backlog.xlsx - 我们使用这个通用的Scrum工具来帮助提高每个工程团队的可见性。每天我们的ScrumMaster都会打印并发布新的Burndown图，以便组织中的每个人都能看到团队的进展。它也非常适合Sprint计划会议；只需打开一个新的工作表，然后开始粘贴你的故事承诺。
- User Story Template.xls - 由于我们接受客户的定制化请求，我们通常会为开发工作提供报价。我们需要一种简单的方法来在客户、开发人员和业务团队之间沟通用户故事、验收标准和工作小时数。这个模板对我们来说效果很好；好到我们将其用于所有大型项目，无论是内部的还是外部的。
有问题？想法？批评？我们很乐意听您说：engineering@cayen.net
历史
* 2012年5月30日：初次发布。
* 2012年6月2日：添加了可下载内容的链接。