当我开始我的数据科学家职业生涯时，我并没有真正的工作流程。在公司、潜在客户和我之间，没有人知道在“现实”世界中实施统计模型或机器学习方法意味着什么。但是每个人都对这个“大数据”感兴趣，
所以我们很快就开始做工作，但没有明确我要做什么。当我们遇到一个看起来像一个项目的东西时，我就投入了进去。为了快速交付结果，我将数据提取加载到 R 中，并开始在其上应用各种不同的模型和算法。结果最终出现在 R 脚本的代码注释中，这些脚本通常会增长到数百甚至数千行。我拥有的唯一系统是按顺序对脚本进行编号。很快，我发现自己置身于数十个脚本和中间结果的数据导出中，这些中间结果不再可重现。我无限期运行的 R 会话有时被错误地关闭，或者它崩溃了（随着使用的内存增加，这必然会发生）。发生这种情况时，我花了数小时甚至数天来重新创建结果。截止日期是一场噩梦；到那时为止我所做的一切都必须在最后一刻加载、加入和比较。通常情况下，模型结果与之前提到的不同，没有任何迹象表明我之前弄错了，我现在使用了错误的数据，或者引入了其他一些错误源。回想起来，我不知道一个好的工作流程对于做更大的数据科学项目的重要性。
敏捷的起源 （The Origins of Agile）
敏捷软件开发不是关于如何完成工作的特定方法、流程或处方。相反，它是一套信念、一种哲学，应该指导软件开发团队做出最佳决策。敏捷当然不是凭空产生的，它是对当时无处不在的称为瀑布（Waterfall）的方法的一种反应。
在 Waterfall 中，大型软件项目被划分为特定的阶段，每个阶段都应该完成，然后才能开始下一阶段。随后的这些阶段是问题分析、设计项目、编写软件、测试，最后是实施和维护。
Waterfall 的目标是提供完整且无故障的软件。Waterfall 项目的重中之重是文档，其中详细记录了软件的每个要求和方面。潜在的信念是，当软件的所有方面都预先决定时，它的编写速度更快，质量更高。
然而，使用瀑布方法完成的项目有一个主要的缺陷。它们可能需要很长时间才能完成。顺序性和完整性的结合可能会导致项目在交付软件之前持续多年。每次在后期阶段中发现错误或不完整时，项目就会返回上一阶段进行修复。由于整个过程持续时间长，经常出现最终结果不再适合不断变化的市场的情况。问题分析可能是几年前完成的，同时问题已经发生了变化。
在九十年代，人们对笨重的瀑布产生了几种反应。软件开发领域的许多有影响力的思想家开始探索编写软件的不同方式。建议采用替代流程，例如 Scrum 和 Xtreme 编程。最终，2001 年，一群 17 人聚集在犹他州，起草了敏捷软件开发宣言。他们简短声明是：
我们正在通过做和帮助他人来发现更好的软件开发方法。通过这项工作，我们开始重视：
个人和交互胜过流程和工具
工作软件优于综合文档
客户协作而非合同谈判
响应变化而不是遵循计划
敏捷思维通过识别瀑布式思维中的许多缺陷，对软件设计采用了截然不同的方法。首先，在开始编写代码之前不可能考虑到复杂设计和架构的所有方面。相反，软件必须有机地增长。其次，客户通常并不真正知道他们想要从产品中得到什么，直到他们开始与之互动。从法律上讲，在上班前检查所有方面可能是个好主意，但这不会让客户满意。最后，如果在交付工作产品之前需要很长时间，客户和利益相关者将失去兴趣并失去项目将完成的信心。
宣言附有源自这些价值观的十二项原则。它们比四个值更适用，因此是做出选择时的主要准则。它们是（编号由我添加）：
我们的首要任务是通过早期和持续交付有价值的软件来满足客户。
欢迎不断变化的需求，即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。
频繁地交付可工作的软件，从几周到几个月不等，优先考虑较短的时间范围。
业务人员和开发人员必须在整个项目中每天一起工作。
围绕积极进取的个人建立项目。为他们提供所需的环境和支持，并相信他们会完成工作。
向开发团队和在开发团队内部传达信息的最有效和最有效的方法是面对面的交谈。
工作软件是进度的主要衡量标准。
敏捷流程促进可持续发展。赞助商、开发商和用户应该能够无限期地保持恒定的步伐。
对卓越技术和良好设计的持续关注可提高敏捷性。
简单性——最大化未完成工作量的艺术——是必不可少的。
最好的架构、需求和设计来自自组织的团队。
团队定期反思如何提高效率，然后相应地调整和调整其行为。
敏捷（Agile）方法
我们了解到，敏捷与其说是一种工作流程或一种方法，不如说是一种在必须做出选择时指导我们的哲学。敏捷提倡严格遵循工作流程至关重要，我们应该持续监控我们的工作方式是否最适合遵循敏捷价值观和原则。如果不是这种情况，则应调整工作流程。这并不意味着没有与敏捷相关的工作流。
Scrum
最著名和应用最多的工作流是 Scrum。它开发于八十年代末和九十年代初，是一种久经考验的方法论。Scrum 与 sprints 一起工作，设置时间单位，在此之后可交付的产品应该准备好。大多数团队使用两周的冲刺，但它们也可以更短或更长时间。团队是完全自组织的，他们决定在下一个冲刺中要做什么以及如何做。要完成的任务都收集在产品日志中，它们的制定方式都清楚地表明它们将如何为产品增加价值。这些用户故事采用“作为角色用户，我想要操作/功能，这样我才能受益”的形式”。假设您运营的网站向所有客户发送时事通讯，但目前还没有选择退出的选项。创建这样一个功能的用户故事可以是“作为订阅用户，我希望能够选择退出时事通讯，这样我只在我想要的时候接收信息”。
Scrum Master的职责是确保团队制定冲刺目标。为此，她必须有一双警惕的眼睛。如果销售经理想要完成某件事并试图说服咖啡机的开发人员之一，他会被亲切地重定向到产品所有者，以将其记入待办事项。如果一些团队成员缺乏一些必要的技能，她会和他们一起制定如何获得这些技能的计划。此外，她将是不同 Scrum 会议（称为仪式）的组织者和协调者。
该产品所有者负责的产品看起来像什么。他监控客户的需求和愿望，因此他的主要职责之一是利益相关者管理。他将功能请求和改进计划转化为用户故事。因此，他维护产品日志，按重要性对故事进行排序。
产品负责人决定应该做什么，开发团队（可能还有其他专家）决定如何做。它是完全自组织的。在每个 sprint 开始时，团队都会评估哪些故事可以在即将到来的 sprint 中完成。团队成员通常有不同的专长，但故事的完成是整个团队的责任。
四个仪式（会议）是 Scrum 循环的一部分。在 sprint 的开始是sprint 计划，其中定义了故事的范围并确定了已完成的定义。在冲刺期间，每天至少有一次站立会议，团队成员在会上快速分享他们正在做的事情以及彼此的需求。冲刺完成后，团队会组织冲刺评审，向团队以外的人员展示已完成的工作。最后是回顾，团队讨论上次冲刺中哪些地方做得好，哪些地方可以改进。
看板 Kanban
板比 Scrum 轻得多，流程也少得多。它不适用于固定的时间单位，但与 Scrum 一样，它旨在实现连续的流程。就像在 Scrum 中一样，要执行的任务在用户故事中制定，但承诺一次只针对一个故事。故事收集在积压日志中，并按重要性不断排序。每次完成一个故事时，下一个最相关或最紧迫的故事就会开始。
中央是看板，可以是物理的，也可以是虚拟的，至少有以下几列：to do、doing和done。这可以根据团队的愿望和需求量身定制。与 Scrum 不同，产品负责人没有正式的角色，尽管让某人处理传入的请求仍然很有用。这可以是指定人员或同时从事开发工作的团队成员。团队不应一次专注于太多任务；所有被拉出来做的事情都应该尽快完成。这确保了重点始终放在前面最重要的任务上，并且将多任务处理降至最低。
团队可以对每列中可以包含的故事数量设置上限。
中心指标是完成一项任务通常需要的时间，即周期时间。有效的看板团队周期时间短，他们能够快速完成任务。较短的周期时间使团队能够自信地估计何时完成工作。就像在 Scrum 中一样，整个团队负责完成一个故事，而不仅仅是“指定”的工作人员。为了尽快完成任务，团队成员可能会不时完成一些超出他们舒适区的任务。
高度结构化的 Scrum 和轻量级看板是两个工作流程，使团队更有可能遵循敏捷原则。他们都旨在持续发布工作软件，而不是致力于一个主要版本。他们还专注于您现在正在处理的部分，Scrum 通过修复在 sprint 中完成的故事，而看板限制了团队正在处理的故事数量。但也有一些显着的差异。在 Scrum 中，团队承诺在此 sprint 中选择要完成的故事，并且建筑物必须先着火，然后才能进行不在 sprint 中的工作。看板只对正在进行的故事数量规定了限制，先完成你开始的事情，然后开始新的事情。然而，为了接下来的故事，一切都可能随时改变。
这两种方法都取得了巨大的成功，重要的是要记住它们是达到目的的手段，而不是宗教。敏捷价值观和原则应该是主要的指导方针，在选择其中一个工作流程时，你这样做是因为这是以敏捷方式工作的最佳方式，因为它最适合给定的情况。团队应该自己决定什么是最好的工作方式，并应该随着情况的发展监控选择是否仍然是最好的。然而，一般来说，当团队正在完成项目时使用 Scrum 更有意义，而看板的灵活性最适合处理大量传入请求的服务团队。
