冲刺的陷阱：不要像斯嘉丽·奥哈拉一样。今天就要思考！

原文：towardsdatascience.com/the-trap-of-sprints-dont-be-like-scarlett-o-hara-think-today-0e08258262f3

数据科学

你一定听说过《飘》及其女主角斯嘉丽·奥哈拉。她的一句著名台词是：“我明天再考虑。明天又是新的一天。”这反映了她推迟处理困难情况的趋势。

如果你是一名数据科学家，不要像斯嘉丽·奥哈拉一样！不要急躁。今天就要思考。

这些天，许多（如果不是大多数）数据科学项目都是使用敏捷方法进行的。有时它们被准确遵循，包括冲刺计划、冲刺、回顾、持续改进、每日站立会议、待办事项整理、用户故事映射和迭代开发。其他时候，敏捷方法被不那么严格地遵循——但即使如此，冲刺仍然是交付产品的主要工具。

如果我们不花更多的时间谈论而不是工作，我对敏捷方法没有任何异议。事实上，冲刺是敏捷项目组织的心脏。如果我们把它们当作工作组织单位而不是目的本身，那就都很好。

我的意思是，不要让冲刺比项目本身更重要，或者让冲刺的目标比项目目标更重要。数据科学项目有其特殊性：在项目过程中可能会发生各种事情，它们可能会改变你的视角。这正是你应该不断思考数据的原因，无论你在做什么。数据一直在和我们交流，所以关闭自己当前任务的泡沫，忽略它们并不是一个好主意。关于数据的好想法可能随时出现——只需倾听。

想象一下，在一个两周冲刺的前几天，你学到了一些新的东西，一些能改变你视角的东西——你意识到你需要改变一些东西。你该怎么办？

你——我指的是你和整个团队——有两个选择。首先，你可以对敏捷方法采取严格的态度，完成冲刺，并在下一次修复这个问题。这样，你的目标就是按计划完成冲刺。你将在下一次冲刺中考虑新想法的后果。

请注意，然而，接下来的冲刺不仅旨在实施这个新概念，还要修复你在当前冲刺中实施的内容。如果你很幸运，你可能只需将代码回滚到当前冲刺开始时的版本。如果不巧，你需要处理更改后的代码，例如，因为其他团队成员，如 DevOps、MLOps 或 UI，也进行了更改，回滚代码意味着代码将停止工作。

其次，你可以改变冲刺的范围，利用团队获得的新知识来追求项目的核心目标，而不是冲刺的目标。这听起来很简单，但并不一定如此，至少不是总是如此。如果团队的其他成员对这次冲刺有自己的目标，你不能只是改变你的工作——他们中的所有或一些人也需要改变。这可能意味着新的冲刺计划和全新的冲刺，这似乎与敏捷哲学不太相符。

一方面，敏捷开发注重有效的沟通。因此，最糟糕的事情就是忽视你刚刚获得的新知识，继续按照原计划进行冲刺，然后在冲刺回顾（在冲刺结束时进行）期间让团队知道问题。这基本上意味着采取上述第一种方法。项目肯定会因此受到影响，并且可能比计划的时间更长。

即使这听起来像是一件奇怪的事情，我也曾与数据科学家合作过，他们选择了（并且在实际项目中确实选择了）这种方法。这导致了上述我所描述的情况：做了一些后来要被丢弃的工作，而且确实被丢弃了。这样做更好吗？更简单吗？是的，更简单。但并不更好，因为在这个过程中，你不需要太担心你工作的质量——你最终会丢弃它，而且你知道这一点。你不需要传达问题，你也不必冒险有人告诉你：“你为什么现在才说，而不是在你提出整个想法的时候？”

这到底有多可能？！

你可能认为我在谈论一个非常罕见的情况：在冲刺开始时找到重要的颠覆性想法的可能性有多大？

好吧，我并不是说这会在每个项目、每次都发生。但这是可能的。在数据科学中，这种情况可能比你想象的更常见，尤其是在项目关键的数据逻辑相关阶段。我在大约 10-15%的数据科学项目中遇到过这种情况。也许 10-15%不是一个很高的数字，但它足够高，以至于可以将这种情况视为一个真实可能性——所以你应该学会如何在这种情况下反应。此外，考虑这类事情将帮助你从更广泛的角度处理你的工作。

假设你在一个使用双周冲刺的项目中工作。如果我们把冲刺开始时定义为前三天，那么有 30%的可能性，如果你在冲刺开始时提出一个颠覆性的想法，你会在冲刺开始时这么做。当然，这是一个非常粗略的估计，但仍然，你应该知道如何行动。

该怎么办？

我不会给出像“忽略它！”或“恐慌并改变一切！”这样的精确答案。但有一种特定的、明确的反应，在我看来，构成了对这种不寻常且压力山大的情况的最佳反应。

也就是说，要参考敏捷哲学的一个基本要素：有效的沟通。换句话说，就是沟通！与团队分享你脑海中出现的概念。然而，在这样做的时候，要具体。向团队解释问题或概念是什么，以及它将如何影响冲刺、项目和他们的工作。说明为什么你认为现在改变工作方向而不是在下个冲刺中改变是好的。要具体。

因此，要做好准备。在没有认真思考之前不要做任何事情。仔细考虑这个问题，两次、三次、四次。与其他数据科学家讨论这个问题（除非你独自一人）。你绝对不能急于处理这类事情。

就这样！你如何做取决于你。你可以在项目通用频道上沟通问题，与 Scrum 大师、产品负责人、技术负责人或团队负责人交谈——或者你认为最适合听取此类信息的人。重要的是，你不要独自做决定，而要涉及团队。因此，重大的决定应该由整个集体或至少是其核心成员做出。

然而，在传达情况时，请记住强调其重要性，并且在你看来，整个团队都应该意识到这一点。如果这个变化不会影响除了数据科学家之外的其他团队成员，那么可能没有必要让每个人都参与——只需要数据科学团队和另一个人，无论是负责人还是技术负责人。

这个建议可能看起来非常简单——也许甚至过于简单？但这是一个理想的解决方案！这里没有普遍的答案，没有普遍的解决方案。行动模式应该取决于整个项目的背景。

接下来是什么？这取决于团队的决定。团队最了解如何处理给定的项目，最重要的是，让关于在这种情况下做什么的决定成为团队的共同决定。

换句话说，不要单方面行动。在没有咨询他人之前不要改变冲刺。（记住，我们谈论的不是一个微小的变化，而是一个导致整个冲刺及其后续内容发生转变的变化）。在没有他们的知情下为他人做决定。他们可能会对在两周（或在这个项目中冲刺持续的时间）内为一个需要重新实现的功能性工作感到不满——所有这一切都因为你没有说出来，不幸的是，结果证明它不能，或者不应该那样工作，或者有一个更好的解决方案。

如果团队决定在当前冲刺中不做任何改变，请接受这一点。这是一个集体决定，所以请做好你的工作。也许你会发现，由于你知道它将被丢弃，你可以花更少的时间在你正在做的事情上？如果是这样，你可以利用这段时间来思考接下来会发生什么。也许你将能够实现一些你将在下一个冲刺中重用的代码，那个新概念将要实施的冲刺？或者，也许，仅仅是也许，完成这个冲刺并将这项工作作为临时或替代解决方案存档可能是个好主意？

结论

敏捷哲学不赞成在冲刺期间出现突然的重大变化。但这并不意味着它们不可能发生。敏捷哲学中最显著的因素之一是沟通。因此，如果你想变得敏捷，请记住要有效地沟通。

我的经验表明，这样的情况可能发生——而且永远不会简单。但嘿，这就是数据科学，这就是生活。生活并不总是简单，数据科学也是如此。有时我们必须做出艰难的决定，在我们讨论的情况下，任何决定都将很困难。所以，向团队传达这个问题，并参与做出最终决定——但这是团队或涉及的团队部分的集体决定。

有效的沟通意味着很多，但绝对不意味着没有沟通。我知道这听起来怎么样，所以让我换一种说法。如果你在一个敏捷项目中工作，沟通很重要。所以请沟通，尤其是在一个问题可能会影响整个团队和项目的时候。

此外，相信我，当你从肩上卸下这个负担时，你会感到极大的解脱。没有人是完美的，没有人是全能的——这就是为什么作为团队而不是个人做出这样的决定更好。这是敏捷哲学的一部分。

你想变得敏捷吗？思考并沟通。你不会后悔的。

你可能会后悔隐藏这样重要的事情不让团队知道。如果他们后来发现你做了什么，其中一些人可能会非常生气——我不会责怪他们。听到我上一个冲刺的工作可能会被丢弃，我不会生气。但听到这本来可以避免，一个团队成员十天前就知道但不想把这个消息告诉团队，我会生气。此外，这样的消息并不是坏消息！但如果结果是我们本可以更早地采取行动，如果那个有想法的团队成员立刻传达了这个信息，它可能会变成坏消息。

所以……也许在冲刺回顾期间简单地说出这一点是最好的，但省略你在冲刺开始时学到所有这些内容的部分？仅仅是一个小谎言……

你可以做到，但记住，这将与敏捷带来的所有东西背道而驰。与它的哲学背道而驰。你真的想成为这样的人吗？一个骗子？这确实是一种破坏行为，所以你真的想成为一个破坏者吗？

作为数据科学家，我们必须是负责任的人，也是负责任的团队成员。没有人应该因为你在解释这样重大的问题时遇到问题。但每个人都会因为你破坏项目而对你产生问题。如果你真的是一名真正的数据科学家——你永远不会做这样的事情，因为这会意味着违反规则。你只是为了给自己提供那一点额外的安慰，就愿意这样做吗？

既然你已经读到这篇文章的这一部分，我相信你绝对不是这样的人。你确实想成为一名专业的数据科学家。如果类似的情况发生在你身上，你现在知道该怎么做。

沟通。