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

时间:2011-01-11 21:46:54

标签: agile machine-learning scrum task user-stories

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

结果看起来不错,我已经获准计划生产实施项目。

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

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

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

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

  

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

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

  

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

但这不是真正的问题。

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

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

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

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

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

  

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

但这看起来很奇怪。作为开发人员(或我们的用户,或任何其他利益相关者),我为这样的用户故事建模提供了什么好处?

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

你们觉得怎么样?您如何为复杂,不可分割,非面向用户的组件规划敏捷用户故事?

3 个答案:

答案 0 :(得分:1)

利用“垂直切片”概念可能会有所帮助。想象一下简单的3层应用程序(例如UI / Logic / DB)。不是建立一个层,而是另一个层,而是“垂直”切割所有三个层。最初的故事可能是“作为用户,我希望能够登录系统,以便我可以访问它。”完成后,这个故事可能会发布,因为它提供了完整的功能,但极不可能为客户提供足够的价值,使其值得实际发货。垂直切片的一个好处是,您已经学习了所有层的知识,可以在将来的迭代中使用这些知识。

如果您不熟悉它,那么INVEST模型对用户故事非常有用:

我 - 独立

N - 面议

V - 有价值

E - 可估计

S - 适当大小

T - Testable

答案 1 :(得分:0)

任何故事都有角色,动作和目标。所以,考虑写一个故事,命名一个角色(一个/一个/一个演员)做某事来实现目标。

你所说的应该有一个明显的测试,即一个定义成功和失败的有效决策程序。

我认为,你在这里遇到麻烦的地方正陷入“商业价值”。首先定义您在成功完成任务时的总体知识。然后,“实现商业价值”正朝着目标迈进。

你必须对敏捷中的某些东西有点创意,因为它们经常面向业务流程。

更新

这里有几点。

  1. 这是一个定理,如果你不能观察到来自系统外部的任何组件的影响,那么在观察等效的意义上,该组件可以被移除而没有效果。

  2. 定义了一个通常称为任务的东西,它是一个小于用户故事的程序员分配。如果你有一些看起来很重要的故事,那就把它分解为一项任务。但是,这样做的方式是它具有明确定义的外部行为,或者在可以观察其行为的上下文中构建它。

  3. 因此有几种可能的方法向我推荐:

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

    2. 可能通过对数据集进行分区来分解故事。因此,例如,为了分解“更新的用户请求标签”,分解您的测试数据,以便您只有接收标签α的数据并创建一个故事“用户请求标签更新为α”。既然你知道所有东西都是α,你就会构建总是分配alpha的最简单的代码,并担心选择的代码。

答案 2 :(得分:0)

我认为您也可以为部分系统测量正确或不正确的结果。您需要存根其他系统组件。当然可能。此外,在我看来,系统的一部分是其他模块的参与者是有道理的。