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

Question

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

V - Ценный

E - оценочный

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

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

Answer 2

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

Answer 3

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

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

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

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

Обновить:

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

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

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

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

1. Создавайте большие истории и разбивайте их на необычайно большое количество подшагов

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