敏捷数据科学的宣言

作者：车品觉

十年来，我个人一直从事敏捷数据科学（分析应用的迭代和进化式开发），起初我还不知道该怎么称呼它。作为一名工程师独自工作的时候，迭代和进化我打造的分析软件是再自然不过的事。加入一支团队后，我原以为也是这样。但实际上并非如此。

我还是网站开发人员的时候，就接触过敏捷方法，所以走上作为数据科学家的第一个工作岗位时，我吃惊地发现，数据科学并不敏捷。上任后的最初几周里，我拟定了一个预测系统的规格说明，然后交给其他人，后者需要六个月时间进行开发，然后交付使用。这违背了我对软件开发过程所知的一切，但鉴于那个系统的规模和大数据工具的状况，这个过程是必要的。该项目差点失败，在最后时刻才化险为夷。那段时间，我睡眠严重不足，学到了一些重要的教训。

我不想再经历一次。于是，我试图让数据科学变得敏捷，取得了不同程度的成功。当我开始把敏捷软件开发的方法应用于数据科学时，我发现了一个模式。困难之处不在于具体实现，而在于处理数据（不止是软件）时思考敏捷机会。

在多家公司工作的经历使我的想法逐渐成形，“敏捷数据科学宣言”就此诞生。宣言专注于如何思考，而不是该做什么。看板或Scrum的特性也适用于数据科学，前提是开发团队动态地思考数据探索过程中出现的机会。约翰·阿克雷德（John Akred）在敏捷数据科学的具体实现方面做了很有意义的研究，但就如何追踪工作而言，我有自己的一些看法。关键是要以积极和动态的方式看待数据科学。

敏捷数据科学宣言

迭代，迭代，迭代

经过连续几十次的查询才会得出见解，别指望一上手就能有所发现。数据表必须经过分析、格式化、分类、集合和总结，才能被理解。通常要到第三次或者第四次尝试才能得出具有深刻见解的图表，而不会是第一次。建立准确的预测模型需要经过特征工程和超参数调节的很多次迭代。在数据科学中，迭代是洞见获取、可视化和产品化的基本要素。要构建产品就必须进行迭代。

交付中间产品

迭代是创造分析应用的必要之举，这意味着我们在最后的冲刺阶段常常发现东西还不够完善。如果我们到了这个阶段还没有交付过半成品或中间产品，最后常常就会没有任何东西可交付。这不是敏捷，我称之为“死循环”，浪费无数的时间用于完善没人想要的东西。

好的系统是自文档化的，用敏捷数据科学的话说，我们记录和分享我们创造的不完整资产。我们完全致力于源代码管理。我们跟同事并尽可能快地跟终端用户分享这一成果。这个原则并不是对所有人都显而易见。很多数据科学家拥有学术背景，多年的努力研究最终变成一篇学位论文。

开展实验，而不是执行任务

在软件工程中，产品经理在冲刺期间把一张图表交给一位开发人员去实现。这位开发人员把任务转换成一个SQL GROUP BY，并制作出一个网页。任务完成了？错。以这种方式拟定的图表不可能有价值。数据科学不同于软件工程，因为它是科学和工程兼而有之。

在任何特定的任务中，我们必须通过迭代以获得洞见，实验是对这些迭代的最好诠释。管理一支数据科学团队相当于管理多个同时发生的实验，而不是分派任务。好的资产（图表，报告，预测）是探索性数据分析的产物，因此我们必须从实验而不是任务的角度来思考。

倾听数据的声音

可能性与目标性一样重要。知道什么容易什么困难与期望一样重要。在软件应用开发中，有三个视角需要考虑：客户的视角，开发人员的视角，企业的视角。在分析应用开发中，还有另一个视角：数据的视角。如果不了解数据对特征的“看法”，产品拥有者就无法有良好的表现。数据的意见必须始终囊括进产品讨论中，这意味着产品讨论必须根植于在成为我们努力焦点的内部应用中通过探索性数据分析实现的可视化。

尊重数据价值金字塔

数据价值金字塔（下图）是一个基于马斯洛需求层次理论的五级金字塔。它描述了把原始数据精炼成图表、报告和预测时创造出来的价值增量。不管是记录还是预测，都是为了促成新的行动，或者改善现有的行动：

数据价值金字塔使我们的工作有了结构。这个金字塔是我们应该记住的东西，但不是严格遵循的原则。有时可以跳过一级，有时可以后退一级。如果你把一个新的数据集直接放入预测模型作为一个特征，但没有添加进更低层级的应用数据模型中，未能使这个数据集透明和可访问，那么你就会欠下技术债。你应该牢记这一点，一有机会就还债。

找到关键路径

为了尽量提高成功几率，我们应该把大多数时间用于对成功最重要的方面。但哪些方面对成功最重要？这必须通过实验来发现。开发分析产品是对移动目标的搜索和追求。

一旦确定目标，比如要作出一个预测，我们就必须找到实现的关键路径，如果证明是有价值的，还必须找到改善的关键路径。在从一个任务流向另一个任务的过程中，数据被一步步精炼。分析产品常常需要多个阶段的精炼，并运用ETL（提取，转换，加载）过程、统计技巧、信息访问，机器学习，人工智能和图形分析。

这些阶段的相互联系构成了复杂的依赖网。团队领袖要把这个网放在心上，他的职责就是确保团队发现关键路径，然后组织团队落实这条路径。产品经理无法自上而下地管理这个过程，而是必须由产品科学家自下而上地发现它。

获得元

如果不能像开发普通的应用那样，轻松地按时交付好的产品，那我们交付什么？如果什么也交付不了，就不能号称敏捷。为了解决这个问题，在敏捷数据科学中，我们应该“获得元”。重点是记录分析过程，而不是我们寻求的最终状态或者产品。这可以让我们在反复攀爬数据价值金字塔，寻找杀手级产品的关键路径时，变得更加敏捷，可以交付中间产品。那么，产品从哪里来？来自面板。我们通过记录探索性数据分析，创造了这个面板。

总结

上述七条原则共同驱动了敏捷数据科学方法，构成和记录了探索性数据分析过程，将之转变成分析应用。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。