敏捷的死亡？

在本期的“雷达”专栏中，我们来审视一下围绕敏捷的大图景，看看它意味着什么，它不意味着什么。

我读了一篇关于敏捷之死的文章。这不是我看到的第一篇声称敏捷已经死亡的文章，我相信这也不会是最后一篇。

敏捷“死了”的说法的问题在于，正如Eben Hewitt在一次对话中对我说的那样，“没有一项运动是成功的，除非它变成了对自己的恶搞。”这一点非常适用于敏捷。什么是现代敏捷？恋物单口相声。迷恋成对编程。迷恋单元测试。Scrum迷恋短时间、高强度的工作。(在80年代，我曾为一家公司工作，该公司有很多预期Scrum的实践。我所能说的就是他们非常不健康。给我买瓶啤酒，我可能会告诉你更多。)。这些都不是坏事，但它们都没有抓住要点，特别是当它们成为一种仪式的时候。(超过一个小时的站立会议？是的，我被邀请去参加那些活动。(第一次会议后拒绝出席。)。通常情况下，拜物教的结果是-什么都没有。一些现有的实践被重新命名，一些新的仪式被创建，工作完全像以前一样继续-但是现在它是“敏捷的”。这种敏捷需要消亡。我不会在哀悼者之列。

有一件事我看不到，也是最能体现敏捷价值的一件事，那就是客户(不管是怎么构思的)和开发人员之间正在进行的对话。这事很重要。敏捷不是，也从来不是让开发人员更快地编写软件。(Scrum可能是…)。敏捷就是让开发人员定期、反复地与实际的用户和客户联系，这样项目就不会不可避免地偏离轨道，产生一些东西(用Douglas Adams的话说)“几乎但不完全像茶”。

我不是敏捷原教旨主义者，甚至不是一个严肃的敏捷布道者。但是值得花一些时间思考敏捷宣言和它的含义，也许甚至可以沉思一下。如果你在80年代和90年代参与过专业编程，你可能还记得让软件开发人员与用户和客户接触是多么激进(在许多商店里，现在仍然是如此)。脖子上的胡子？书呆子和书呆子？他们可能会告诉客户，他们想要的某些功能是不可能的！他们可能会说真话！那么销售人员会怎么做呢？

嗯，事实证明，如果你想让软件工作，开发人员必须与需要软件工作的人交谈。你不能把它留给销售人员或营销人员。你不能创建一个“产品所有者”，然后说那是他们的工作--特别是因为，通常情况下，“产品所有者”与客户本身没有什么有意义的联系。(真实故事：在一家前公司，一名销售人员基于一项功能进行了一次重大销售，该功能不仅不可能实现，甚至毫无意义。(我们很幸运没有被起诉。)。当项目因为某些需求没有被正确理解而偏离正轨时，您需要尽快修复它-而不是在长达一年的开发过程之后。如果敏捷的第一个原则是经常与客户交互，那么它的第二个原则(也是一个密切的推论)就是频繁的中途修正。那些中途的修正总是比走到最后发现你构建了错误的东西要轻松得多。这是关于“敏捷”一词含义的一条重要线索。这不是让软件开发人员更快地编写代码。这是关于当你需要改变方向的时候学习，然后去做。它是关于在小错误变成大错误之前纠正它们，在它们被多年、数百万美元的预算放大之前。

所以我真的不想听到敏捷不适用于大项目之类的说法。我不管你怎么称呼它，但是大型项目(A)很少成功，不管采用什么方法，因为它们(B)被许多没人需要但听起来不错的功能超负荷了，(C)忘记了客户或用户真正需要或想要的是什么。大型项目是必要的，但它们的势头往往会驱使它们偏离轨道。一旦一个项目开始朝着错误的方向发展，它往往会继续朝着错误的方向发展。这在敏捷之前是正确的(艾萨克·牛顿不是这么说的吗？)，在敏捷之后也是如此。敏捷提供了使这些项目保持在正轨上的工具；无论这些工具是被使用了，还是只得到了口头上的服务，都不是方法的错。

在“敏捷宣言”发表20年后，敏捷面临着许多挑战。最重要的是发现如何与数据科学和人工智能项目合作。这些项目的开发时间表不像传统软件那样可预测；它们以奇怪的方式扩展了“测试”的含义；它们不是确定性的。软件开发的进展往往是缓慢的、渐进的、

敏捷是否适用于大型团队？大型团队会提出他们自己的问题，但讽刺的是，作家们嘲笑“两个披萨小组”的概念，因为它不可能适用于大型组织。他们知道这个概念是从哪里来的吗？我不知道有多少行代码支持亚马逊的核心业务，也不知道有多少软件开发人员在为这些核心业务工作，但我相信这些都是非常大的数字。但是，再说一遍：价值交互胜过文档。通过划分项目并保持小组规模，使这些交互成为可能。你可以保持与客户不断联系的原则；你只需要小心地理解你的客户是谁，以及他们的意思。(这与域驱动设计(Domain Driven Design)中的有界上下文的概念有关。)。

我不认为敏捷是“完美的”；我甚至不知道在这种情况下“完美”是什么意思。我确实认为，正如“宣言”中所描述的那样，敏捷指出了软件开发中持续存在的许多问题，并提供了看似合理的解决方案。可悲的是，这些解决方案在违背中比在遵守中更受尊敬；埃本说得对，没有一种方法是成功的，除非它成为了对自己的嘲弄。但是，如果Eben是对的，那么解决方案不是着眼于敏捷之外，而是对我们自己的行为变得自我意识和批评。为什么，当事情发生变化时，它们会保持不变吗？新旧方法论背后的权力斗争、奖惩是什么？当流程改变时，谁赢了，谁输了，为什么？在任何组织中，回答这些问题都会很好地说明敏捷是如何变得自我嘲弄的。

但说真的，你知道敏捷成功意味着什么吗？我们就会忘了这件事。我们就这么做了。与客户的频繁联系，团队成员之间良好的面对面交流，以及源代码控制和测试等实践，都会像我们的Wi-Fi网络一样随处可见。我们不会为这些做法而苦恼，也不会围绕它们创造仪式和仪式。他们只会是我们做的事。--迈克·鲁基德斯(Mike Loukeyes)。

在“2020年科技领袖需要关注的5个关键领域”中，我们检查了来自O‘Reilly在线学习平台的搜索和使用数据。这些数据包含有关技术领导者需要关注和探索的趋势、主题和问题的显著信号。

蟒蛇是出类拔萃的。它是O‘Reilly上最流行的编程语言，占所有使用的10%。今年Python使用量的增长得益于它在数据科学家、机器学习(ML)和人工智能(AI)工程师中越来越受欢迎。

软件体系结构、基础设施和运营都在快速变化。向云本地设计的转变正在改变软件架构、基础设施和运营。另外：基础设施和运营呈上升趋势，而DevOps呈下降趋势。巧合？可能不会，但只有时间才能证明这一点。

ML+AI上升了，但热情已经降温。直到2017年，ML+AI话题一直是该平台上增长最快的话题之一。对于如此大的话题来说，增长依然强劲，但使用量在2018年放缓(+13%)，在2019年明显降温，仅增长7%。然而，在数据主题中，ML+AI在所有使用中所占的比例从22%上升到了26%。

仍然是云雾缭绕，但有迁移的可能性。云平台的强劲使用率(+16%)占特定于云的增长的大部分。但对云迁移的持续兴趣-在2018年30%的基础上，2019年使用量增长了近10%-抓住了另一个重要的新兴趋势。

安全措施正在激增。去年总体安全使用率激增26%，原因是两个安全认证的使用率增加：CompTIA Security(+50%)和CompTIA CYSA+(+59%)。业务主管、系统管理员、DBA、开发人员等需要警惕大量的安全风险。

我们最近还进行了一项关于数据质量状况的调查。正如我们所怀疑的那样，这个话题充满了兴趣-我们很快就收到了1900多份对我们调查请求的回复。

首席执行官致力于数据质量。CXO、副总裁和董事占所有调查受访者的20%。数据科学家和分析师、数据工程师和管理他们的人占观众的40%；开发人员和他们的经理约占22%。

数据质量在变好之前可能会变得更差。创建专门的数据质量团队的组织相对较少。只有20%的组织发布数据来源和数据沿袭。大多数人没有说他们没有开始的计划。

采用人工智能可以提高数据质量。近一半(48%)的受访者表示，他们使用数据分析、机器学习或人工智能工具来解决数据质量问题。这些受访者更有可能暴露和解决潜在的数据质量问题。人工智能能否成为提高数据质量的催化剂？

组织正在处理多个同步的数据质量问题。他们有太多不同的数据源和太多不一致的数据。他们没有清理数据质量问题所需的资源。这只是个开始。

组织内部通常缺少数据治理的构建块。这些包括基础知识，如元数据创建和管理、数据来源、数据沿袭和其他基本要素。