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

Закрыт. Этот вопрос не по теме . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос , чтобы он был по теме для Stack Overflow.

Закрыт 6 лет назад .

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

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

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

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

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

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

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

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

Но это не совсем так.

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

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

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

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

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

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

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

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

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

задан benjismith 11 January 2011 в 21:46

0 ответов

Другие вопросы по тегам:

agile machine-learning scrum task user-stories

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

0 ответов

Похожие вопросы: