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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Обновление:

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

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

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

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

1. Установить большие истории и сломать их в необычно большом количестве субшагов

2. Разложить истории , возможно, путем разбиения набора данных.Например, чтобы разложить «теги пользовательских запросов обновлены», разложите тестовые данные, чтобы у вас были только данные, которые будут получать тег α и сделать историю «Теги запросов пользователей обновлены до α». Поскольку вы знаете, что все будет α, вы создаете простейший код, который всегда присваивает альфу, и беспокоиться о выбранном коде.

Answer 2

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

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

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

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

V - полезный

E - Предполагаемый размер

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

T - Testable

Answer 3

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