虽然软件工程实践规定，需要创建问题以适应不断变化的需求，但我们需要能够适应由我们自己的研究决定的不断变化的需求的实践。
目录
-
你可能已经尝试过敏捷…
-
为什么敏捷方法不适合数据科学…
-
数据科学生命周期过程 (DSLP)
-
DSLP 的五步法
-
示例项目：检测信用卡欺诈
-
新项目 – 创建一个询问问题
-
探索数据——数据问题
-
这种布局导致传统的敏捷项目
-
适合数据科学的看板
-
结论
你可能已经尝试过敏捷…
坦白说，我们都在某个时候尝试过使用敏捷方法来管理我们的数据科学项目。
我相信你和你的团队一定已经看到它慢慢地崩溃——每个人都说了他们在之前站立会议中说过的话，项目看板板从未得到维护，冲刺变得毫无意义。
你最终会感觉整个事情毫无意义，但你无法确切地指出为什么它不起作用。
由于这个原因，你不知道如何改进它或需要改变什么。
为什么敏捷方法不适合数据科学…
敏捷框架是为软件工程构建的，其中有一个产品需要在结束时交付。
基于这个最终目标，敏捷框架试图保持项目与最终用户需求的一致性，这些需求可能会随时间而变化。它旨在保持开发者和最终用户之间的反馈循环紧密，以便项目能够保持“敏捷”以适应变化。
同时，开发者之间保持高水平的沟通，以便快速识别变化的需求，识别阻碍因素，并转移知识。
这就是为什么你在使用看板板跟踪你的工作时会进行冲刺和站立（或冲刺）。
然而，这个框架很快就会在数据科学项目中崩溃。
为什么？
因为，数据科学本质上是一个研发项目，所以没有你试图在开始时构建的最终产品概念。需要研究来确定最终产品可能的样子。
只有当研发完成，你知道你需要什么数据，需要哪些预处理/特征工程，以及你打算使用什么模型时，你才最终知道你将要构建什么。
这意味着敏捷框架只有在您尝试将模型投入生产时才适用，对于数据科学项目来说，这是项目的最后一步。
那么，替代方案是什么呢？
Buddha Elemental 3D在Unsplash上的照片
数据科学生命周期过程（DSLP）
在研究数据科学项目管理领域后，我发现了**数据科学生命周期过程**，这似乎将其他资源提供的关键见解纳入了一个可以直接集成到 GitHub 项目或任何其他基于 Kanban 的项目管理工具的框架中。
GitHub – dslp/dslp: The Data Science Lifecycle Process is a process for taking data science teams…
我已经用这个方法管理我的数据科学团队的项目，并且它已经证明是我们迄今为止工作流程的最佳改进。
我们看到了哪些好处？仅举几个例子，
-
在整个项目生命周期中改进项目文档，其中每个设计选择和研究成果都记录在同一个地方，
-
这促进了知识的无缝转移，并在交接过程中完全消除了摩擦，
-
并且改善了数据科学家之间的研究协作。
-
更好的项目优先级排序和减少在定义不明确的项目上的浪费时间，
-
鼓励基于任务的流程，该流程与现有的 Kanban 板工作流程无缝结合，所需更改最少，
-
这最终促进了敏捷所追求的迭代方法，但对于数据科学来说，不是软件工程。
上述内容并非详尽无遗，只是我能想到的一些直接要点。听起来好得令人难以置信，但请继续阅读以下内容，以了解上述所有（以及更多）内容是如何实现的。
DSLP 的 5 个步骤
我们将以我的模板 GitHub 项目为例，说明如何使用 DSLP。这个链接在这里：
您可以通过上述链接找到的 DSLP 示例项目模板。
从现在起，我提到的任何相关代码或内容都将包含在这个项目模板中。
本文使用的所有图片都是由作者生成的。
DSLP 由五个项目生命周期步骤组成，包括询问（Ask）、数据（Data）、探索（Explore）、实验（Experiment）和模型（Model）。在每一步骤中，你都会期望在GitHub 项目中为你的数据科学团队创建一个GitHub 问题。
DSLP 的结构
下面是 DSLP 对每个步骤及其相应问题的概述，这些概述由 DSLP 提供。我们将在下一节中深入探讨它们实际工作的情况，包括我团队使用的基于 GitHub 的问题模板和工作流程，以及一个现实生活中的例子。
询问
询问问题用于捕捉、界定和细化团队试图解决的基于价值的问题。它们作为项目的实时工作定义，并将成为协调你做的其余工作的锚点。它提供了已完成工作的总结和正在进行的工作。
这个问题成为你自己或任何需要了解项目信息的人的第一站，在其他步骤中创建的问题应链接到这个问题（我们将在示例中稍后看到这是多么简单)。
数据
数据问题用于协作收集和创建解决该问题所需的数据集。
这个问题与获取你的数据和创建你的输入数据集相关。
探索
探索性问题为我们提供了提供快速总结和 TLDR（Too Long; Didn’t Read）的方式。探索性问题的目标是增加我们对数据的理解，并与他人分享这些见解。
这种问题类型类似于在数据科学项目开始时进行的探索性数据分析，并有助于良好地记录所探索的内容以及与其他数据科学家的协作。
实验
实验性问题用于跟踪和协作解决该问题的各种方法，以及捕捉结果。
一旦你对数据及其与问题的关系有了理解，实验性问题就用于你将进行的建模。P
也许你将你的问题框架为异常检测模型？也许你考虑了不同类型的模型？或者你可能尝试了不同的超参数？
根据你的工作方式，这些可以是一个单独的实验性问题，或者是一个大问题的一部分。
模型
模型问题是为了将成功的实验投入生产，以便你可以部署它们。这通常涉及编写测试、创建管道、参数化运行，以及添加额外的监控和日志记录。
如 DSLP 所述，一旦实验阶段完成，你知道你想要投入生产的内容，那么任何用于生产化模型的努力都应该作为模型问题的一部分。
每个步骤的更多详细信息可以在 DSLP 仓库中找到。
但现在，让我们通过一个虚构的例子来深入了解我是如何通过 GitHub Projects 使我的数据科学团队使用 DSLP 的。
示例项目：检测信用卡欺诈
假设你是一名在银行工作的数据科学家，你被来自信用卡欺诈运营团队的一名 SME（领域专家）约翰·多伊（John Doe）找到。
他们告诉你，信用卡欺诈已经成为银行的一个业务重点，银行需要改进其检测此类案件的过程。这是在监管反馈之后，该反馈指出与其他银行相比，银行在信用卡欺诈检测方面表现不佳。
由LinkedIn Sales Solutions在Unsplash上的照片
他们向你咨询，根据银行在先前模型应用于其他领域所取得的近期成功，数据科学团队能否使用模型提高银行的欺诈检测率。
显然，一开始你并不知道能否构建一个模型——你不知道有哪些数据可用，以及标签的质量是否足够好（或者它们甚至是否存在）。
但是，你知道你的团队能够启动一个新项目并研究这个问题。因此，你安排与 SME 和一些信用卡欺诈预防团队的成员进行后续通话，了解他们面临的问题，并了解项目将涉及的内容。
新项目 - 创建一个询问问题
你带着新项目回到办公桌前。你应该做的第一件事是创建一个新的询问问题，使用询问问题模板（可在此处找到）。关于此模板中每个部分的更多信息可以在 Markdown 模板中的注释中找到）。
问题有不同的部分，各自有不同的用途。每个部分的作用描述可以在 Markdown 代码中的注释中找到。
问题请求用于捕捉、界定和细化团队试图解决的基于价值的难题。它们作为你项目的工作的实时定义，并将成为协调你做的其他工作的基石。
通过将工作定义放在问题中，数据科学团队能够与他们的商业伙伴和领域专家合作，随着对问题的了解更多，对问题进行细化和重新界定。
你应该在问题请求中链接到其他问题。这将给人们提供关于为什么特定问题正在被解决的原因。
随着你对问题的理解不断演变，你应该相应地更新你的问题请求。为了创造清晰度，你应该尽可能具体，并通过更新问题请求来解决歧义。
因此，我们处于项目的非常初期，几乎没有信息。但是，我们可以根据我们的知识更新问题陈述。
问题陈述是对你试图解决的问题及其原因的高层次描述。它应该清楚地说明解决这个问题的价值，并应明确界定哪些内容包含在问题中，哪些不包含。
我们这样更新问题陈述：
"商业优先级已经发生了变化，信用卡欺诈预防已成为优先事项。”
与 John Doe 讨论这个问题后，我们发现我们需要比我们传统上实施的更好的控制措施。”
在这个阶段，我们还没有从之前的简短聊天中确定具体的问题来着手解决，所以现在我们将保持现状。但是为了使这个项目可行，我们需要跟进 John 和其他领域专家，以更好地了解他们的要求以及在他们眼中成功的成果可能是什么样子。
因此，你需要在你的问题请求的评论部分写下下一步你需要采取的行动，以推动这个项目的进展。
在评论部分创建任何项目所需行动点的日志。
整个评论部分的目的就是记录所有行动点和为你的项目所做的设计选择。
它充当一个审计日志，你自己和其他人可以参考以获取关于项目每个步骤的详细信息，而顶部的模板化问题请求则作为你项目重要点的概述，成为任何与项目相关的查询或问题的首要参考。
因此，一旦你安排了会议，与 John 和他的同事讨论了这个行动计划，然后你可以更新评论或添加新的评论，附上会议笔记。
现已填充会议结果的评论
这次会议为我们提供了足够的信息来填写剩余的子部分（预期结果、当前状态、成功标准）。
如何填充预期结果和当前状态字段的示例。有关本节目的更多详细信息，请参阅问题模板
如何填充成功标准字段的示例。有关本节目的更多详细信息，请参阅问题模板
请记住，随着项目的进展和对你能做什么、不能做什么的更清晰的认识，上述部分以及模板中的任何其他部分都应更改，以反映对项目最新的理解。
探索数据 – 数据问题
因此，在与约翰和同事们的会议之后，我们有一个行动计划：
数据科学团队将开始对可用数据进行检查，以验证是否可能建立模型。
第一步将是寻找任何可以作为信用卡欺诈检测任务标签的真实数据。
从评论部分的日志中，我们从这个行动计划创建一个问题：
点击右上角的 (…) 按钮，点击‘在新问题中引用’
然后填写一个新问题的详细信息，如下所示：
填写问题标题（红色），并在你的项目中引用该问题（黄色）。
现在这个问题将出现在你的项目板上。将其拖放到“数据”列，你的板子应该看起来如下所示：
因此，你创建的这个“数据”问题将是你记录与获取真实数据相关的一切的地方，包括你做出的任何设计选择和数据的任何限制。
你编写的任何用于获取数据的代码都应该通过此问题创建，直接从问题创建分支：
创建一个与该问题关联的分支（黄色），并选择该分支应属于的仓库（红色）
最好的是，你创建的分支可以与任何启用了 Issues 的仓库相关联。如果你有用于数据科学堆栈不同部分的单独仓库，这很有用，因为你可以将与你的项目相关的所有内容都放在一个看板上。
与此数据问题相关的任何 PR 都进行了链接。
最后，一旦你完成编码并提交一个 PR，它将自动链接到你的Data问题。
我们目前所拥有的…
所有与 Ask 相关的开发工作如何通过问题和 PR 链接在一起的概述。
通过这种方式工作，我们实现了两件事：
-
所有设计选择和实现细节都链接到相关的 Ask 问题，这样就可以通过一个地方找到与项目相关的所有内容。
-
信息丢失的可能性为零，同时信息以分层格式总结——Ask 问题中的高级细节，数据问题中的低级细节，Pull Requests 中的实现细节，这使得协作或交接更容易。
以这种方式，我们可以继续构建我们的项目：
相同的 ask 问题，链接到后续的 DSLP 问题，如探索、实验、模型…
我们已经涵盖了数据和探索问题，它们相当于数据科学中的数据获取和 EDA 部分。
实验是实际建模，这会涉及到你创建的 Jupyter Notebooks，用于尝试不同的方法和不同的模型。
模型是所有与生产化相关工作的最后一步——单元测试、代码重构、模型监控等。
它们的工作方式与我们上面提到的相同。有关这些步骤的更多详细信息，请查看 DSLP 页面或示例项目看板。但现在，我们将跳到下一节。
这种布局导致传统的敏捷项目
因此，让我们跳到未来，可能是我们示例项目的两周后。
到目前为止，你已经完成了获取所需数据的必要工作，并对数据进行了一些探索，以及尝试构建一个第一迭代模型。
多个问题同时为一个 Ask 问题打开的示例。
项目很可能同时打开多个问题。
-
探索问题或实验问题可能因数据问题而受阻，因为你意识到在继续之前需要提供一些不同的数据。
-
一些其他问题可能需要代码审查，你需要追逐审查者为你做这件事。
-
一些你可能已经忘记的问题，甚至还没有开始。
我们需要一种方法来跟踪所有这些问题，一些熟悉的东西……
由 Tingey Injury Law Firm 在 Unsplash 上的照片
适合数据科学项目的看板
我们现在要进入项目设置，创建一个可以分配给问题的 Progress 字段。
通过点击右上角的 (…) 按钮可以找到设置。
就像下面这样，我使用了 Single select 字段类型创建了四个标签：To Do、In Progress、Blocked 和 Waiting for Review。当然，这是针对我个人的，你可以决定你想要什么。
使用单选字段类型创建的四个进度字段。
现在，回到项目看板，我可以创建一个名为 Kanban Board 的新视图，并使用下拉按钮，根据我们刚刚创建的 Progress 字段（高亮显示为红色）来配置列。
将进度字段分配给项目中的每个问题，
创建一个新视图，并通过字段配置列到进度，高亮显示为红色。
哇！
你现在有一个看板，可以用于会议来组织和跟踪你的数据科学项目的进度！
你现在有一个易于使用的看板。
为什么看板工作得很好，而传统的看板却失败了？
因此，我们又回到了使用看板。你可能正在想：
等等，如果我们已经在使用看板的话，这篇文章的整个重点是什么？
嗯，我们的看板起源的谱系是不同的。
数据科学项目本质上属于研发工作。它需要与软件工程项目的严谨性不同的风味。
数据科学问题是由研究决定的，而不是由客户/最终用户决定的。
虽然软件工程实践规定问题是为了适应不断变化的需求而创建的，但我们需要能够适应由我们自己的研究指定的不断变化的需求的实践！
那就是为什么我们有两个不同的看板：
-
一个看板（项目看板或 Ask 看板），突出显示单个项目（或 Ask）进行的不同的研发工作，
-
另一个看板（看板看板）用于跟踪与 Ask 相关的研发任务的进度。
这就是这个框架与众不同的地方，也是这个框架实际上对数据科学有效的原因。
通过使用这两个不同的看板，你能够实现以下目标：
-
在一个 Ask 问题上有一个关于一个项目所采取的所有研发步骤的完整总结，它将所有相关的问题和 PR 链接到一起。这使得文档、审计日志和知识共享变得轻而易举。这对于像医疗保健或金融这样高风险的行业尤为重要。
-
使用看板（Kanban board）来维护每个 Ask 的进度，这是一种大多数人已经习惯的工作方式。这允许你将其他敏捷方法，如站立会议和冲刺，围绕数据科学方向的看板进行整合。
结论
希望你觉得这篇文章有用。
这个框架可以被任何级别的数据科学家使用：
-
不论是试图找到一种适合他们团队的工作方式的管理者，
-
或者是一名初级数据科学家，正在寻找一种组织他们工作的方法。
这也不一定非得是 Github 项目。任何支持基于看板工作流程的项目都是兼容的，而且如今大多数工具都允许与 Github 集成，所以一切都可以集成在一起。
我没有涵盖 DSLP 框架的每一个细节，只是你需要开始使用它的重要事项。
我鼓励你自己阅读这个框架，因为其中还有一些其他的小建议我没有采用，但也许对你有用——请在评论中告诉我。
最后关于为什么这样一个框架正变得越来越重要的评论。
我提到数据科学是一个基于研发的职业，但事实是，整个行业正迅速达到一个纯研究已经不够用的点，我们需要能够提供具体的价值。
同时，随着机器学习模型在各个行业，尤其是金融和医疗保健这样高风险的行业中普及，监管审查只会随着时间的推移而增加。这一趋势表明，我们需要更好地管理、文档化和审计我们实施的模型。
在评论中告诉我你的想法，如果你觉得这篇文章有用，请给我点赞（每人最多 50 次！），并且随意与你的同事分享。
关注我，获取更多实用的数据科学内容。
扫一扫
857
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
