超越Spotify和Assembla的敏捷

几周前，我们讨论了如何使您的文化超越敏捷 。 让我们在本周走得更远，研究其他公司在开发过程中如何弄清楚哪些对他们有用。

在Spotify打破Scrum规则

例如， Spotify最初是一家Scrum公司。 但是随着它们的发展，Scrum的实践逐渐受阻。 他们开始打破“规则”以适应公司的发展。

首先，Scrum大师成为敏捷教练。 然后，他们将他们的Scrum团队更改为从头到尾拥有流程的小队。 每个小队都有长期的任务，以及如何实现目标的自主权。 但是，该小组确实在执行任务和产品策略以及短期目标时必须遵守界限。

Spotify发现，赋予人们更多的自治权会给人们带来更多的乐趣，并使公司更快地响应变化。 决策是在本地处理的，因此中队可以Swift做出反应。 所有团队都有一个总体目标。 他们使用爵士乐队的类比，在该乐队中，演奏者彼此听，但自己演奏音乐。

异花授粉>标准化

结果，Spotify没有关于开发方式的正式标准。 每个团队都有自己的做事方式。 当中队彼此交流时，想法可能会通过异花传粉在团队之间传递，但是总体架构由每个团队从前到后拥有的小型服务组成。 如果一个团队需要另一个团队的帮助，他们可以询问另一团队是否有时间或自己编辑代码。

社区>结构

每个员工都是一个中队的成员； 许多中队组成一个部落。 总体而言，企业集团的流动性非常强，并且经常变化。 他们努力建立一个强大的社区，而不是建立僵化的公司结构。

Spotify致力于简化发布代码和更频繁地发布代码的过程。 这与典型的瀑布环境相反，在瀑布环境中，释放量大，很少发生并且可能很痛苦。 他们希望发布的内容是常见且常规的，而不是罕见且戏剧性的。

Spotify的发布火车

Spotify的每个应用程序都有一个定期发布的发布流程。 如果火车离开时某个功能不完整，则使用该功能将其关闭。 该功能切换工作以在测试和生产环境中隐藏代码。 由于始终在一个位置检查代码，因此这也有助于减轻合并代码的问题。

发布火车按可靠的时间表工作-类似于真实火车-提供固定的节奏和可预测的计划。 多个开发团队可以将功能和代码推送到火车上。 一个小组致力于火车，其成员来自不同的背景。 日期和质量是固定的，其中范围是系统中的变量。 每个团队都有相似的迭代长度和速度来支持计划。

发布培训具有一组角色来管理它，从发布培训工程师（我们是否比喻这个培训隐喻？）开始，他类似于Scrum管理员。 他们使过程继续进行。 版本管理将决定范围和计划版本。 产品经理有权对内容进行设置，以与Scrum团队中的产品所有者一起设置产品积压。

如何设置自己的发行火车

想在自己的团队中尝试吗？ 设置发布培训的第一步是确定发布培训的域或谁将从事哪些工作。 例如，在Web应用程序上，自然故障可能是前端和后端服务。 您将有两个团队将代码提供给发布培训。

在确定了应用程序的功能，产品和组件之后，确定团队的迭代和发布计划很重要。 基础架构，通用组件和用户界面设计的支持工作需要在开发团队之前进行。

完全整合应定期进行，例如两周。 与工作的完全整合一起，向利益相关者的演示有助于报告进度并征求反馈。

Context Matters的合伙人Em Campbell-Pretty建议，已经熟悉敏捷的团队将使过渡更快地发布。 她描述了他们在最初的发布训练中如何尝试的方式：“我们决定将五个最成熟的敏捷团队转变为EDW敏捷发布训练，并且我们将努力将其他团队逐步转变为训练。 ”

如何设置功能切换

功能切换是一种根据环境或用户打开或关闭代码或功能的方法。 例如，假设我们要在屏幕上添加电子邮件按钮。 我们可以将其关闭，直到我们对该功能进行了完整的编码和测试为止。 这将是用户功能切换； 代码功能切换将是另一个版本。 代码功能切换将在基础应用程序中关闭和打开代码。 马丁·福勒 （ Martin Fowler）和其他人已经写了一段时间关于这个话题的文章，但是在许多组织中它已经很流行。

Rally Development的开发人员Ryan Scott概述了使用功能切换的三个好处 ：

• 分枝少。 使用功能切换签入代码时，可以关闭不完整的部分。 我知道合并问题已经处理了不止一次，这从来都不是一件好事。
• 分阶段推出。 您不必一次发布所有更改。 在不得不回滚整个发行版并希望我们不会错过任何内容之后，我真的很喜欢这样做。
• 安全失败。 这对许多经理很重要。 您可以简单地关闭会导致问题的事物。

您可以进一步将功能切换分为发布切换，开发团队可以使用这些切换来推出功能。 因此，如果您发布的功能不完整，只需关闭该功能即可。 完成后，在下一个版本中将其打开。 当然，完全释放功能开关很重要！

另一种功能切换分类适用于业务切换。 也许您想为您的付费订阅会员添加新选项。 可以关闭和打开业务切换以测试响应或更改营销。

您可以在应用程序属性文件中设置任何这些功能切换。 例如，在.net应用程序中，您可以在app.config或web.config中设置这些切换。 下次您要更改这些功能切换之一时，请勿发布新代码-只需更改app.config。 如果功能存在问题，则无需再回滚代码。

为失败留有余地

Spotify的创始人Daniel Ek说： “我们的目标是比任何人都更快地犯错。” 他们想快速失败以快速学习并快速改进。 Spotify试图营造一种故障友好的氛围，在这种氛围中，他们将重点放在故障恢复而不是避免故障上。 通过在每次失败后进行验尸，他们试图捕获所有汲取的教训。

Spotify应用程序采用分离的组件进行架构，以使用“受限爆炸半径”方法。 如果发生故障，则不会影响其他组件。 他们还使用逐步推出的功能，仅允许少数人看到新功能。 这样可以控制，监视和衡量故障。 每个小组都会不断进行小型实验并对其做出反应。

在Spotify团队构建新功能之前，他们会围绕该想法进行叙述。 他们问诸如“有人要这个吗？”之类的问题。 和“这是否有价值？” 使用精益启动原则，他们构建了最低限度的可行产品。 他们通过将其发布给少数人来对其进行测试。 通过分析数据并调整原型，他们最终可能会完全推出该功能。

在Spotify整个开发过程中显而易见的一个原则是，该公司似乎重视创新而非可预测性。 他们很少进行计划以允许更多的实验和创新。 这样，他们的团队就拥有更大的自由来实现总体目标并创造新的价值。

在Assembla上测量连续敏捷模型

Assembla的首席执行官Andy Singleton写了一本名为《 Unblock》的书，其中详细介绍了如何使用连续敏捷模型更快地开发新产品。 更快发布的团队会更频繁地进行创新，并更快地进行改进。

像Spotify一样，Assembla最初在开发过程中使用Scrum。 随着公司的发展，他们看到了Scrum如何无法有效地扩展到较大的团队和快速发布。 他们开始分解内容并消除大量发布，目的是更频繁地发布。 他们创造了持续敏捷和无阻碍发展的过程。

使用精益原则，Assembla开始一次专注于一件事。 他们创建了一个自动化的环境，在人工命令中什么都没有隐藏。 所有内容对整个团队都是可见的，并且具有可重复的脚本。 这使人们能够提取已准备好的功能。

监视，自动化和测试分层有助于频繁发布

Assembla会不断评估其用法。 因此，它们将仅对正在使用的功能起作用，而不会花时间在未使用的部分上起作用。 如果不使用某些内容，则将其删除。

一旦完成测量，就可以发布频繁的版本并收集测量数据以指导您的未来。 频繁发布的原则对于Assembla获得竞争优势很重要。 在此变化之前，他们落后于竞争对手。

Assembla还在构建，测试和部署周期中利用自动化，以使这些频繁发布成为可能。 他们问类似的问题，“我们在哪里可以使用更多机器？” 和“我们可以实现什么自动化？” 安迪指出，您可以添加测试层以提高发行版的质量。 或者，您可以删除图层以加快发布频率。 他分享了测试层中的一些示例，其中包括单元测试，代码审查和人员质量保证。

如何设置测试分层

测试分层可以从使用模拟对象的单元测试开始。 这些单元测试可以在将代码检入到存储库之前从开发人员的计算机上运行。 可以通过设置一个连续集成机器来自动执行此操作，该机器可以在签入任何代码后运行所有测试。

通过在虚拟机上进行集成测试以模拟生产环境，在此基础上增加另一层。 确保您的虚拟机具有与生产或您要测试的环境类似的数据库； 该层有助于测试开发人员在编写解决方案时所做的任何假设。

与最后一层类似，您将需要集成测试以及将在共享环境（通常是连续集成系统）中运行的系统测试。 该层测试了最近的代码更改，这些更改可能会阻止团队前进。 它还可以检查源代码管理问题，合并问题或批处理更改。

倒数第二层应该是负载测试，灾难恢复测试和性能测试的组合，可以在暂存或预生产环境中执行。 确保此环境尽可能接近生产环境。 这些测试应按团队确定的频率定期运行。

测试的最后一层应集中在生产系统上。 这些检查系统是否存在局部中断，并监视如何处理它们。 这一层是一种测试风格，Netflix的开发团队为此而声名狼藉： 混乱的猴子 。

将发布与发布分开

与Spotify的功能切换类似，Assembla使用功能开关使他们能够隐藏功能，直到准备好显示为止。

Andy谈论将发布与发布分离。 当您使用一项新功能时，它会随着时间的推移而隐藏在众多版本中。 结果，发布的交付过程从大批量发布变为连续且频繁的小更改发布。 进行增强措施并进行衡量，以查看它们带来的价值以及根据指标而改变或去除的价值。

有趣的是，最后，Assembla开发人员对质量负责。 他们决定何时准备发布功能。 这使开发人员有责任产生高质量的代码，并使他们更多地参与代码审查和测试。 质量保证人员将更多地充当协助测试策略的顾问。

超越敏捷：总结

如果我们研究来自Spotify和Assembla的这些不同方法，我们可以开始看到我们可以使用的各种方法来应对技术团队在尝试超越敏捷开发时所面临的挑战。

将来，许多此类“超越敏捷”的实践将变得司空见惯，但请记住，在您的公司中发展团队的第一步是让团队中的所有角色一起工作。 与以前的“丢墙”方法相比，协作是一个很大的变化。 与业务部门紧密合作，与所有技术人员一起了解优先级并交付价值是开发人员的关键部分。

翻译自: https://www.javacodegeeks.com/2015/09/going-beyond-agile-like-spotify-and-assembla.html