目录:
作为一个敏捷的软件开发团队，对于不同的人当然意味着不同的事情。广泛采用的程度各不相同，显然很少有组织认为他们做得很好。根据VersionOne的《敏捷状态调查》（2017年4月发布），有80％的受访者表示他们“处于或低于成熟水平”。不幸的是，开发团队通常不会在迭代的“学习”部分投入很多精力。我们想快点完成Scrum仪式，这样我们就可以重新开始编写代码了。毕竟，还有很多工作要做！但是编码时间不足真的是问题吗？
对于我们中的许多人而言，在我们的职位描述中也可能会专门列出消防措施。我们每天上班，要知道我们需要随时准备从滑杆上滑下来，戴上帽子，跳上卡车。我们以事物的现状接受它，并且我们假设对此无能为力。但是，如果我们奋斗的根本原因是严重缺乏效率该怎么办？每个人都知道做得比那家其他公司更好的重要性。我们似乎无法到达那里-我们似乎没有带宽。经理增加了更多的人，扩大了组织的规模，但仍然面临同样的困难。您似乎无法克服困难，因为您的团队没有有效地开发软件（而且您并不孤单）。
高效发展原则
Pixabay
那么，是什么导致我们效率低下呢？对于我们大多数人来说，首先想到的是缺乏自动化（自动化的构建，部署，测试）。 “一旦我们有了足够的自动化，生活就会变得更好。”不幸的是，这只是解决方案的一部分。考虑返工对项目的影响。构建功能的最有效方法是正确构建一次，永远不要回头再触摸它。从患者离开手术室之后，错误，重构和其他类似的活动实质上重新打开了患者的视线，并且存在与之相关的固有风险。我们不能消除返工，但是我们一定要努力减少返工。
“但是敏捷不拥抱返工（例如重构）吗？”实际上，这样做确实是有原因的，因为敏捷的创造者理解返工的两个关键原因是无法预料的情况和不断变化的业务需求。事实证明，人类对未来的预测很糟糕。敏捷的创造者还理解到，效率低下的一个巨大原因就是开发人员所说的“镀金”。我们认为，即使最终用户从未真正要求使用这些功能，我们还是会使用某些功能。这就像为您的软件产品使用猪肉一样-完全浪费时间。 “当他们要求的只是沃尔沃时，不要建造空间站。”因此，公司明智地开始抛弃猪肉，转而接受重构，只在有明确需求时才添加功能。但是生活的不可预测性不是重做的唯一动力，不是吗？
在功能开发的任何阶段丢失细节都会最终浪费时间和金钱。随着时间的流逝，有效的前期协作将为您节省大量的返工（应付遗漏的需求，短视的设计等）。我们都有盲区，我们都需要额外的眼睛。许多开发团队在代码审查过程中都将其包含在后端，但是在可以廉价地解决问题并且仅需最少的投资后，早期就投入了更少的精力进行协作。
您实施了多少次功能，并在需求/设计讨论期间发现应该在末尾发现的重大缺陷？这就像试图从亚特兰大开车到蒙哥马利，并意识到旅途中要花几个小时不小心开车去伯明翰。由于错过了重要的要求，花了多少时间试图使代码正确，以便稍后再次打开患者的门？利用集体智能绝对可以节省时间和金钱，但是开发人员经常孤立地处理功能。
传统群居
Pixabay
传统的群体化意味着团队需要由几个人同时处理一个小功能来共同处理故事，从而缩短了反馈循环并减少了该功能的整体完成时间（即分而治之）。实际上，这在每个学科（后端开发人员，UI开发人员等）中都蜂拥而至。在开发开始之前，UI开发人员会努力确定可以同时执行的独立任务。他们讨论界面点，以便每个人都知道自己的作品如何融入整体。然后，团队成员可以完成分配的任务，并在集成过程中将所有内容整合在一起。频繁的提交和定期的代码审查有助于确保一切都保持正常。这种方法需要开发人员之间的协作，无论如何，这有助于产生更好的最终结果。我们通常会优先考虑花费在编写代码（任何代码）上的时间而不是花费在代码上的时间，以确保我们不会编写错误的代码。当您考虑可能节省的时间时，该值将变得清晰。
畅通无阻
Pixabay
群集的另一种有价值的方法是使团队专注于尽早缓解依赖关系，以促进跨学科的并行开发。考虑UI功能的自然开发流程。自动化测试器（SDET）依赖于工作的UI进行测试，UI开发人员依赖于工作的后端API，后端开发人员依赖于配置，数据库更新和自动化的构建/部署。因此，UI开发人员可能要在完成API之后才能开始工作，而SDET可能要等到功能完成才开始工作。每个学科都是孤立工作的，这会阻碍协作，因为您需要与之交互的人员正忙于其他事情。但是，如果您可以更早地减轻依赖性，并允许这些学科同时使用同一功能，该怎么办？
这里有些例子：
1.带有存根的已部署功能UI
为了解除对SDET的阻止，UI开发人员可以为他们提供一个运行良好的UI，该UI足以使他们编写测试。后端API集成和CSS样式仍可能待定，因为Selenium之类的自动化测试框架不会在乎这些事情是否还没有完成。可能都是烟和镜子。尽管可能发生更改而导致某些返工，但尽早开始测试的好处远大于这种风险。
2.部署的后端API（存根，硬编码数据）
提供UI开发人员可以测试的后端API，可以及早发现前端和API之间的集成问题。有时您会发现提供的API不能满足前端开发人员的需求。可能缺少整个调用，签名可能错误，或者数据结构可能有问题。如果存在断开连接，您最好在任何问题变硬之前及早发现它。
3.创建新应用程序和服务的HelloWorld版本。
如果需要新服务（例如微服务），请创建存储库并构建服务的“ hello world”版本。这使dev-ops资源可以在Jenkins作业和部署脚本上实际开发之前就启动。
这些优化促进了早期反馈循环，在此循环中，有人可以说“我需要有所不同”，然后在需要更改的组件上完成开发。
包起来
非常重要的是，我们要弄清楚如何缩短我们正在开发的功能的上市时间。拥有一系列正在开发的功能对企业毫无价值，开发人员迫切需要快速实现功能，以便可以在尽可能接近注入点的位置解决缺陷。即使开发人员真正想做的只是编写代码，他们也迫切需要彼此交互。对于所有相关人员，包括只希望有更好产品的最终用户，它都更好。如果您不给他们，他们会去别的地方找到它。
如果人们花时间学习如何做到这一点，则编组是组织工具箱中非常有价值的工具。它不是框架，甚至不是活动，而是一种思维定势。对于每个用户故事，团队成员都会问自己两个问题：
- 我们如何组织这个故事的任务，以使几个人同时做出贡献？
- 为了解除阻止正在等待我的人，我需要执行的最低要求是什么？
如果您的团队快速地一起构建功能而不是慢慢地独立构建一堆功能怎么办？他们实际上可以响应不断变化的业务需求，并在业务需要满足它们时满足业务的需求。竞争对手会害怕您-客户会爱您。那是成功事业的秘诀。
分级为4 +©2017 Mike Shoemake