敏捷群集的魔力

作者:

Mike Shoemake已经是一个成功的软件开发人员20年了，建立了高质量的应用程序和高效的开发团队。

对于不同的人来说，成为一个敏捷的软件开发团队当然意味着不同的事情。采用的程度在非常广泛的范围内，显然很少有组织认为他们做得很好。根据VersionOne的敏捷状态调查(2017年4月发布)，80%的受访者表示他们“处于或低于仍在成熟的水平”。不幸的是，开发团队通常不会在迭代的“学习”部分投入很多精力。我们想快点结束Scrum仪式，这样我们就可以回去写代码了。毕竟，有这么多工作要做!但编码时间不足真的是问题所在吗?

对于我们中的许多人来说，灭火或许还可以在我们的工作描述中特别列出。我们每天去上班时都知道，我们需要随时准备好从杆子上滑下来，抓起帽子，跳上卡车。我们接受了事物本来的样子，并认为我们对此无能为力。但是，如果我们挣扎的根本原因是严重缺乏效率呢?每个人都知道比其他公司做得更好有多重要。我们似乎无法到达那里——我们似乎没有带宽。管理者增加更多的人员，扩大组织规模，但仍然面临同样的困境。您似乎无法克服这个难关，因为您的团队没有有效地开发软件(而且您并不孤单)。

高效发展的原则

那么是什么导致我们效率低下呢?对于我们大多数人来说，首先想到的是缺乏自动化(自动化构建、部署、测试)。“一旦我们有足够的自动化，生活就会变得更好。”不幸的是，这只是解决方案的一部分。考虑返工对项目的影响。构建一个特性最有效的方法是正确地构建它一次，永不回头再碰它。bug、重构和其他类似的活动本质上是在病人离开手术室后让他重新进入手术室，这有与之相关的固有风险。我们不能消除返工，但我们当然应该努力将其最小化。

“但是敏捷不包括返工(例如重构)吗?”实际上在某种程度上是这样的，因为敏捷的创造者明白返工的两个主要原因是不可预见的环境和不断变化的业务需求。事实证明，人类在预测未来方面很糟糕。敏捷的创造者也明白，导致效率低下的一个重要因素是开发人员所说的“镀金”——把我们认为有人会使用的功能包装起来，尽管最终用户从未真正要求使用它。这就像你的软件产品的猪肉——完全是浪费时间。“如果他们想要的只是一辆沃尔沃，那就别建空间站了。”因此，公司明智地开始放弃猪肉，转而拥抱重构，只在明确需要时添加功能。但生活的不可预测性并不是返工的唯一驱动因素，不是吗?

在功能开发的任何阶段错过细节最终都会浪费时间和金钱。随着时间的推移，有效的前期合作将为您节省大量的返工(处理遗漏的需求、短视的设计等)。我们都有盲点，我们都需要一双额外的眼睛。许多开发团队在后端在代码评审过程中采用了这种方法，但是在早期的协作中投入的精力要少得多，因为在这个时候问题可以以较低的成本解决，投入也最少。

有多少次你实现了一个特性，在接近尾声时发现了应该在需求/设计讨论中发现的重大缺陷?这就像从亚特兰大开车去蒙哥马利，几个小时后才发现自己不小心开到了伯明翰。花了多少时间试图让代码刚刚好，只是为了稍后再次打开病人，因为遗漏了重要的需求?利用集体智慧绝对可以节省时间和金钱，但相反，开发人员通常是孤立地开发功能。

传统的群集

传统的蜂群工作是指团队中有几个人同时在一个小功能上进行协作，缩短反馈循环，减少功能的总体完成时间。分而治之。这实际上是在每个规程(后端开发人员、UI开发人员等)中聚集。在开发开始之前，UI开发人员要确定可以并发执行的独立任务。他们讨论接口点，以便每个人都知道自己的部分如何融入整体。然后，团队成员可以继续完成分配给他们的任务，并在集成过程中将所有内容整合到一起。频繁的提交和定期的代码检查有助于确保一切正常进行。这种方法需要开发人员之间的协作，这有助于产生更好的最终结果。我们经常优先考虑花在写代码(任何代码)上的时间，而不是花在确保不写错误代码上的时间。当您考虑到可能节省的时间时，其价值就变得清楚了。

得到疏通

另一种有价值的蜂群方法是，在早期将团队的重点放在减少依赖性上，以促进跨规程的并发开发。考虑一个UI特性的自然开发流程。自动化测试人员依赖于一个工作的UI进行测试，UI开发人员依赖于一个工作的后端API，后端开发人员依赖于配置、数据库更新和自动化构建/部署。因此，UI开发人员可能要等到api完成后才开始工作，而sdet可能要等到特性完成后才开始工作。每个规程都是独立工作的，这妨碍了协作，因为您需要与之交互的人都忙于其他事情。但是，如果您能够更早地减少依赖性，并允许规程在相同的特性上并发地工作呢?

下面是一些例子:

1.部署了带存根的功能UI

为了解除阻塞sdet, UI开发人员可以为它们提供一个功能UI，让它们能够编写测试。后端API集成和CSS样式仍然可以等待，因为像Selenium这样的自动化测试框架不会关心这些事情是否未完成。一切都可能是假象。虽然可能会发生导致一些返工的更改，但尽早开始测试的好处超过了风险。

2.已部署的后端api(存根、硬编码数据)

提供UI开发人员可以测试的后端API，允许早期检测前端和API之间的集成问题。有时您会发现所提供的API不能满足前端开发人员的需求。整个调用可能丢失，签名可能错误，或者数据结构可能有问题。如果存在脱节，您最好在任何东西变硬之前尽早发现它。

3.创建新的应用程序和服务的HelloWorld版本。

如果需要一个新的服务(例如一个微服务)，创建repo并构建服务的“hello world”版本。这允许在实际开发服务之前在Jenkins作业和部署脚本上启动开发-ops资源。

这些优化促进了早期反馈循环，在需要更改的组件的开发完成之前，有人可能会说“我需要一些不同的东西”。

包装起来

我们必须清楚如何缩短我们所致力于的功能的上市时间。业务从一堆正在进行的特性中得不到任何价值，开发人员迫切需要快速实现特性，以便在尽可能接近注入点的时候解决缺陷。开发人员也迫切需要彼此交互，即使他们真正想做的只是写代码。这对所有相关的人都有好处，包括只想要更好产品的最终用户。如果你不给他们，他们就会去别的地方找。