Agile: Истории пользователей для машинного обучения?

Я только что закончил прототип реализации управляемого алгоритма обучения, автоматически присваивая категориальные теги всем элементам нашей базы данных нашей компании (примерно 5 миллионов элементов).

Результаты выглядят хорошо, и мне было дано право планировать проект по реализации продукции.

Я уже делал такую ​​работу, поэтому я знаю, как функциональные компоненты программного обеспечения. Мне нужна коллекция веб-сканеров для извлечения данных. Мне нужно извлечь функции из обходных документов. Эти документы должны быть разделены на "набор учебных материалов" и "набор классификации", а функциональные векторы должны быть извлечены из каждого документа. Эти векторы признаков самоорганизуются в кластеры, а кластеры проходят через ряд операций по балансировке. Etc и т.д. И т.д. и т.д.

Итак, я собрал план с примерно 30 уникальными задачами разработки/развертывания, каждый из которых имеет временные оценки. Первый этап разработки - игнорирование некоторых продвинутых функций, которые мы хотели бы иметь в долгосрочной перспективе, но не достаточно высокоприоритетных, чтобы сделать это в графике разработки еще - запланировано на двухмесячную работу, (Имейте в виду, что у меня уже есть рабочий прототип, поэтому окончательная реализация значительно проще, чем если бы проект начинался с нуля.)

Мой менеджер сказал, что план выглядит хорошо для него, но он спросил, могу ли я реорганизовать задачи в истории пользователей по нескольким причинам: (1) наше программное обеспечение для управления проектами полностью организовано вокруг пользовательских историй; (2) все наше планирование основано на подгонке целых рассказов пользователей в спринты, а не в индивидуальном планировании задач; (3) другие команды, как и веб-разработчики, отлично использовали гибкие методологии, и им удалось моделировать все функции программного обеспечения в качестве пользовательских историй.

Итак, я создал историю пользователей на верхнем уровне проекта:

Как пользователь системы, я хочу искать элементы по категориям, чтобы я мог легко находить наиболее релевантные элементы в огромной, сложной базе данных.

Или, может быть, лучшая история верхнего уровня для этой функции:

Как редактор контента, я хочу автоматически создавать категориальные обозначения для элементов нашей базы данных, чтобы клиенты могли легко находить высокоценные данные в нашей огромной, сложной базе данных.

Но это не настоящая проблема.

Сложная часть, для меня, заключается в том, как создавать подчиненные истории пользователей для остальной архитектуры машинного обучения.

Случай в точке... Я знаю, что алгоритм требует двух основных архитектурных подразделений: (A) обучения и (B) классификации. И я знаю, что учебная часть архитектуры требует построения кластерного пространства.

Вся литература Agile Development, прочитанная мной, кажется, указывает, что история пользователей должна быть "наименьшей возможной реализацией, которая обеспечивает любую ценность для бизнеса". И это имеет большое значение при разработке части программного обеспечения конечного пользователя. Начните с малого, а затем постепенно добавляйте значение, когда пользователи требуют дополнительных функций.

Но кластерное пространство само по себе обеспечивает нулевое значение для бизнеса. Также не работает сканер или экстрактор. В частичной системе нет коммерческой ценности (а не для конечного пользователя или для любой из ролей, внутренних для компании). Обученное кластерное пространство возможно только с помощью искателя и экстрактора объектов, и только релевантно, если мы также разработаем сопроводительный классификатор.

Я предполагаю, что можно было бы создавать истории пользователей, где подчиненные компоненты системы действуют как пользователи в рассказах:

В качестве процедуры построения кластерного пространства с контролируемым обучением я хочу использовать данные из экстрактора функций, чтобы я мог существовать.

Но это кажется действительно странным. Какую пользу он дает мне, как разработчику (или нашим пользователям, или любым другим заинтересованным сторонам, если на то пошло) моделировать мои истории пользователей, как это?

Хотя основную историю можно легко разделить по границам архитектурных компонентов (искатель, тренер, классификатор и т.д.), я не могу придумать какую-либо полезную декомпозицию с точки зрения пользователя.

Что вы, ребята, думаете? Как вы планируете рассказы пользователей Agile для сложных, неделимых компонентов, не относящихся к пользователю?

ОТВЕТЫ

Ответ 1

Возможно, было бы полезно использовать концепцию "вертикальных срезов". Представьте себе простое трехслойное приложение (например, UI/Logic/DB). Вместо того, чтобы строить один слой, затем другой, вы "срезаете" вертикально через все три. Первоначальная история может быть "Как пользователь, я хочу иметь возможность войти в систему, чтобы я мог получить к ней доступ". Когда это будет сделано, эта история потенциально возможна, поскольку она обеспечивает полную функциональность, но вряд ли обеспечит достаточную ценность для клиента, чтобы сделать ее действительно реальной. Одним из преимуществ вертикальных срезов является то, что вы узнали что-то обо всех слоях, знания, которые могут быть использованы в будущих итерациях.

Если вы не знакомы с ним, модель INVEST очень полезна для пользовательских историй:

I - независимый

N - Договорная

V - Ценность

E - Оценочный

S - Соответствующий размер

T - тестируемый

Ответ 2

Любая история имеет роль, действие и цель. Итак, подумайте о написании истории, которая называет роль (a/k/a Actor), что-то делает для достижения цели.

То, что вы указали, должно иметь очевидный тест, то есть эффективную процедуру принятия решений, которая определяет успех и неудачу.

Где вы столкнулись с проблемами здесь, я думаю, попадает в "деловую ценность". Начните с определения того, как вы узнаете, когда вы успешно выполнили свою задачу. Затем "достижение деловой ценности" продвигается к цели.

Вы должны быть небольшим креативным с некоторыми вещами в Agile, потому что они так часто ориентированы на бизнес-процессы.

Update:

Несколько пунктов здесь.

  • это теорема, что если вы не можете наблюдать какие-либо эффекты компонента извне системы, то этот компонент может быть удален без эффекта в смысле наблюдательной эквивалентности.

  • Определяется вещь, обычно называемая задачей, которая представляет собой назначение программиста, меньшее, чем история пользователя. Если у вас есть что-то, что кажется большим, как история, разобьем его как задачу. ОДНАКО, сделайте это так, чтобы у него было четко определенное внешнее поведение, ИЛИ создайте его в контексте, в котором вы можете наблюдать его поведение.

Итак, есть несколько возможных подходов, которые рекомендуют мне:

  • Настройте большие истории и разделите их на необычно большое количество подэтапов

  • Разложите истории, возможно, разбив набор данных. Так, например, чтобы разложить "теги пользовательского запроса обновлены", разложите тестовые данные, чтобы у вас были только данные, которые будут получать тег & alpha; и сделать рассказ "Теги запросов пользователей обновлены до & alpha;". Поскольку вы знаете, что все будет & alpha;, вы создадите простейший код, который всегда присваивает альфу, и беспокоиться о выбранном коде.

Ответ 3

Я думаю, что вы можете измерить правильные или неправильные результаты для частичной системы. Вам нужно заглушить другие компоненты системы. Это, безусловно, возможно. Кроме того, на мой взгляд, имеет смысл, что одна часть системы является актером для других модулей.