我刚刚完成了一个监督学习算法的原型实施,自动把分类标签分配给我们公司数据库的所有项目(约500万件)。
成果看好,我早上去计划生产实施项目。
我以前曾做过这种工作,因此我知道软件的功能组成部分如何。 我需要收集网络拖网器,以收集数据。 我需要从拖网文件中提取内容。 这些文件需要分为“培训组”和“分类组”,专题主持人需要从每份文件中提取。 这些特点媒介是自成组的,通过一系列重新平衡的行动通过分组。 等等。
So I put together a plan, with about 30 unique development/deployment tasks, each with time estimates. The first stage of development -- ignoring some advanced features that we d like to have in the long-term, but aren t high enough priority to make it into the development schedule yet -- is slated for about two months worth of work. (Keep in mind that I already have a working prototype, so the final implementation is significantly simpler than if the project was starting from scratch.)
我的经理说,该计划对他非常好,但他询问,我是否可以将任务重新整理成用户故事,原因有几个:(1)我们的项目管理软件完全围绕用户故事编排;(2) 我们的所有时间安排都基于将整个用户故事纳入印刷,而不是单独安排任务;(3) 其他小组——如网络开发商——已经充分利用了一种灵活的方法,并且它们将所有软件特征作为用户故事加以建模。
因此,我在项目顶级制作了一个用户故事:
作为该系统的用户,我希望按类别搜寻物品,以便我能够很容易地在一个庞大、复杂的数据库中找到最相关的物品。
或者说,这一特征的最好高层故事是:
作为内容编辑,我想自动为我们数据库中的项目确定分类,以便客户能够很容易地在我们庞大、复杂的数据库中找到高价值数据。
但这不是真正的问题。
The tricky part, for me, is figuring out how to create subordinate user stories for the rest of the machine learning architecture.
案例...... 我知道,算法需要两个主要建筑司:(A)培训,(B)分类。 我知道,建筑结构的培训部分需要建造一个集群空间。
我所读到的所有阿吉略发展文献似乎都表明,用户故事应该是“提供任何商业价值的尽可能少的执行”。 在设计一个终端用户软件时,这一点具有许多意义。 如果用户需要额外功能,则开始小,然后逐步增加价值。
但是,一个集群空间本身就提供了零商业价值。 也没有拖网者,也没有主角。 在
我相信,如果该系统的下属部门在报道中充当用户,就有可能制作用户故事:
作为一项监督学习的集群-空间建设的例行做法,我希望从一个特选中提取数据,以便我能够生存。
但是,这似乎确实令人不安。 作为开发者(或我们用户,或其它任何利益攸关者)效仿我的用户故事会有什么好处?
虽然主要故事可以很容易地按照建筑工程的毗连边界(拖网、培训员、班级人员等)区分开来,但从用户的角度来看,我可以不考虑任何有益的分歧。
你认为什么? 你们如何为老化、不可分割、非用户的复杂部件规划用户故事?