敏捷:机器学习项目的用户故事？

Question

我刚刚完成了一个监督学习算法的原型实现,自动为我们公司数据库中的所有项目分配分类标签(大约500万个项目).

结果看起来不错,我已经获得了计划生产实施项目的批准.

我以前做过这种工作,所以我知道软件的功能组件如何.我需要一组网络抓取工具来获取数据.我需要从已爬网文档中提取功能.需要将这些文档分成"训练集"和"分类集",并且需要从每个文档中提取特征向量.这些特征向量自组织成簇,并且簇通过一系列重新平衡操作.等等等

因此,我制定了一个计划,其中包含大约30个独特的开发/部署任务,每个任务都有时间估算.第一阶段的发展 - 忽略了我们希望长期拥有的一些先进功能,但尚不足以将其纳入开发计划中 - 预计将进行大约两个月的工作.(请记住,我已经有了一个工作原型,所以最终的实现比项目从头开始要简单得多.)

我的经理说这个计划看起来不错,但他问我是否可以将任务重新组织成用户故事,原因如下:(1)我们的项目管理软件完全是围绕用户故事组织的; (2)我们的所有调度都是基于将整个用户故事编入sprint,而不是单独调度任务; (3)其他团队 - 比如Web开发人员 - 已经充分利用了敏捷方法,并且他们从将所有软件功能建模为用户故事中受益.

所以我在项目的顶层创建了一个用户故事:

作为系统的用户,我想按类别搜索项目,这样我就可以在庞大而复杂的数据库中轻松找到最相关的项目.

或者这个功能的更好的顶级故事可能是:

作为内容编辑器,我想自动为数据库中的项目创建分类标识,以便客户可以在我们庞大而复杂的数据库中轻松找到高价值数据.

但这不是真正的问题.

对我来说,棘手的部分是弄清楚如何为机器学习架构的其余部分创建从属用户故事.

举个例子......我知道该算法需要两个主要的架构细分:(A)训练和(B)分类.我知道架构的培训部分需要构建一个集群空间.

我读过的所有敏捷开发文献似乎都表明用户故事应该是"提供任何商业价值的最小可能实现".在设计一个最终用户软件时,这很有意义.从小处开始,然后在用户需要其他功能时逐步增加值.

但是,集群空间本身就是零业务价值.爬虫或特征提取器也不是.在部分系统中没有商业价值(不适用于最终用户,也不适用于公司内部的任何角色).只有爬虫和特征提取器才能使用经过训练的集群空间,并且只有在我们开发了附带的分类器时才能使用.

我想可以创建用户故事,其中系统的从属组件充当故事中的用户:

作为一个监督学习的集群空间构建例程,我想要使用特征提取器中的数据,以便我可以存在.

但这似乎很奇怪.作为开发人员(或我们的用户,或任何其他利益相关者),我为这样的用户故事建模有什么好处？

虽然主要故事可以很容易地沿着架构组件边界(爬行器,训练器,分类器等)划分,但我不能从用户的角度考虑任何有用的分解.

你们有什么感想？您如何为复杂,不可分割,非面向用户的组件规划敏捷用户故事？

Answer 1

任何故事都有角色、行动和目标。因此，考虑写一个故事，其中指定一个角色（又名演员）做某事来实现目标。

你所写下的内容应该有一个明显的测试，即定义成功和失败的有效决策程序。

我认为，你在这里遇到麻烦的地方是陷入了“商业价值”。首先从总体上定义您如何知道何时成功完成任务。那么，“实现商业价值”就是朝着目标取得一些进展。

对于敏捷中的某些事情，您必须具有一点点创造力，因为它们通常面向业务流程。

更新：

这里有几点。

1. 一个定理是，如果您无法从系统外部观察到某个组件的任何影响，那么该组件可以在观察等价的意义上被删除而不会产生任何影响。

2. 定义了一个事物，通常称为任务，它是小于用户故事的程序员分配。如果你有一些看起来像故事一样大的事情，请将其分解为一项任务。但是，请以具有明确定义的外部行为的方式执行此操作，或者在可以观察其行为的上下文中构建它。

因此，有几种可能的方法向我推荐：

1. 设置大故事并将其分解为数量异常多的子步骤

2. 或许可以通过对数据集进行分区来分解故事。因此，例如要分解“用户请求标签已更新”，请分解您的测试数据，以便您只有接收标签 α 的数据并制作一个故事“用户请求更新为 α 的标签”。因为您知道一切都将是 α，所以您构建了始终分配 alpha 的最简单的代码，并担心选择的代码。