В этой статье я расскажу о своем опыте внедрения Agile на проекте DS с нуля.
Я расскажу вам шаг за шагом, что мы с командой пытались использовать, к чему это привело, какие ошибки мы допустили и как в итоге пришли к стабильному, простому и понятному процессу разработки.
Контекст проекта и некоторое введение
Проект, с которым мне пришлось работать, был связан с идентификацией объектов по камерам наблюдения на физических объектах (ресторанах).Нашей основной задачей было создание системы идентификации объектов и отображения необходимой информации на дашборде, а также мы развернули систему на объектах (более 1500) и поддержали пользователей.
Наша команда состояла из специалистов по Data Science и Computer Vision, было несколько QA, один Frontend Developer и один Backend Developer. Я выступал в роли менеджера проекта.
Когда я только начинал работать над проектом, не было документации, плана, отчетности и т. д. Все делалось на словах, некоторые вещи немного отслеживались в Trello, был хаос.
В этой статье я расскажу подробнее о процессе разработки.
Проект также имел очень сложный процесс развертывания и поддержки пользователей.
В этой статье я не буду касаться этих процессов.
ЭШаг 1. Начало внедрения Agile.
В самом начале моей главной целью было понять, что нужно сделать, когда, кто чем занимается и что вообще сейчас существует. В Интернете я наткнулся на целую кучу разных статей о том, как строить процессы в DS, но мнения у всех были разные: кто-то советовал Канбан, кто-то Скрам, кто-то описывал свои методы, но ничего общего я не нашел, тут не было ничего, что можно было бы применить к какому-либо проекту такого рода.Однако самым ценным было знакомство с концепцией CRISP-DM. КРИСП-ДМ .
Идея легко гуглится, но основная идея понятна из графической схемы: 
Как видите, из-за возможности возврата к предыдущим этапам, а также из-за того, что конечный результат все равно может оказаться недостаточно хорошим, мы не можем назвать заказчику точные сроки, что крайне затрудняет любое планирование.
Вот задачи, которые я поставил перед собой на самом первом этапе:
- Определение всех требований проекта
- Определение текущего результата
- Постановка конкретных задач команде
- Оценка задач и формирование плана
- Выбор процесса разработки
- Мы начали использовать Jira. Нам пришлось обучать команду, так как раньше с этой системой никто не работал
- Мы создали канбан-доску со стандартными этапами: «Сделать», «В процессе», «Тестировать», «Готово».
- Я описал все требования к команде и вместе с командой мы поставили первые задачи и сформировали бэклог продукта.
Пришлось все уточнять с командой, так как было совершенно непонятно, что уже реализовано и как именно реализовано то или иное требование с помощью инструментов DS и CV.
- За дни вместе с командой оценили задачи и согласовали сроки со заинтересованными сторонами
- Мы создали совместные чаты и т. д., чтобы общение наконец было централизовано.
- Мы начали проводить общие собрания каждый понедельник и синхронизироваться.
- Все-таки мы решили попробовать использовать Scrum, после чего я пошел настраивать доску и готовить обучение для команды.
- Постановка задачи в виде User Story или просто описание бизнес-требования плохо понимается командой, вызывает неправильные ожидания у заказчика, а в рамках задачи сложно учесть любую сопутствующую работу, например: сбор и маркировка данных и т. д.
- Команда очень плохо работала с Jira. Мне всегда приходилось перемещать задачи и обновлять доску принудительно.
- Цикл выполнения задачи был очень длинным из-за очень общей задачи и мог занять до 3 месяцев.
- После месяца работы над задачей команда могла понять, что она не уложится в срок, потому что модель была плохо обучена или данные были неверными и т. д. и нам всегда приходилось сильно сдвигать сроки, так как очередная итерация могла занять до 2 месяцев
- Развертывание проекта на объектах было крайне хаотичным, делалось по требованию и постоянно возникали проблемы.
Этап 2. Скрам
Прежде чем приступить к Scrum-разработке, я тщательно собрал общий бэклог проекта, описал его в формате обычных Заданий и пользовательских историй и расставил приоритеты.В самом начале на нашей Scrum-доске были одни и те же колонки «Сделать», «В процессе», «Тестировать», «Готово».
Мы с командой провели первое планирование, в ходе которого обсудили бэклог и еще раз обсудили принцип работы по Scrum. В ходе планирования мы пришли к следующему:
- Мы обсудили процесс CI/CD и решили добавить среду UAT.
- Добавлен соответствующий статус на табло - UAT
- Оцениваются задания в сюжетных баллах
- Ставьте задачи на спринт
- Обсудили правила работы и обязанности.
После этого мы провели еще один спринт 3. Мы попытались по-другому сформулировать эти задачи, разбить их на связанные задачи и т. д. В результате нам удалось добиться какой-то стабильности, но выполненные задачи не несли никакой конечной ценности и по итогам спринта мы не получили релиз, мы просто получили набор выполненных задач.
Мы решили сделать еще одну попытку и просто увеличить продолжительность спринта до 1 месяца, но ситуация особо не изменилась + стали приходить срочные задачи, которые не могли ждать 1 месяц и нам пришлось нарушить план.
И мы собрались для полного анализа ситуации в ожидании найти какое-то радикальное решение, которое нам поможет. Мы увидели, что нам в принципе невозможно выполнять задачи в спринтах, так как работа, например, над новой моделью определения того, заплатил ли клиент, может занять до 3 месяцев, а потом нам все равно придется вернуться к этой задаче.
, переобучить модель и т.д. Невозможно втиснуть это в спринт. В результате мы решили перейти на Канбан и попробовать эту практику.
3. Канбан
Итак, Канбан! Мы взяли LeanDS за основу построения процесса разработки Ссылку на книгу вы можете найти в Интернете.
Я сделал новую плату и указал там следующие шаги: 
Сделать, Анализ, Подготовка данных, Экспериментирование, Разработка, Готово к оценке, Оценка, PR-обзор, Испытание, Готово На каждом этапе я устанавливаю лимиты (WIS), которые указываю в соответствии с количеством участников команды, участвующих в конкретном этапе.
Я также просмотрел отставание и разделил работу над моделями на гипотезы; остальные задачи остались по-прежнему в Пользовательских историях.
Отставание снова было расставлено по приоритетам.
Пример гипотезы: Мы верим, что решим проблему появления автомобилей-призраков на всех объектах.
Для этого определим местоположение каждой реальной машины в текущий момент времени.
Мы будем правы, если в ситуациях, вызывающих появление госавтомобилей сейчас, они не появятся и если количество обращений от ресторанов по этой проблеме уменьшится хотя бы на 50% После всех приготовлений мы с командой провели планирование Канбана и договорились работать в соответствии с правилами и идеологией Канбана.
Выбрал первые задачи и начал работать Результат сильно отличался от того, что было раньше, и стал выглядеть многообещающе:
- Мы могли бы взять на себя сверхсрочные задачи и сразу же выполнить их.
- Мы смогли сразу увидеть, на каком этапе застряли наши задачи
- Мы начали понимать, как лучше распределять ресурсы
- Задачи стали активнее двигаться по воронке, так как команда смогла лучше сконцентрироваться на конкретных задачах и стала больше помогать друг другу.
- Мы начали выпускать фичи сразу после их готовности, и это еще больше удовлетворило заказчика, а также позволило упростить развертывание (по крайней мере, процесс утверждения) и проанализировать влияние тех или иных фич независимо друг от друга.
Мы начали применять решения и постепенно еще больше ускорять разработку.
Например, мы решили централизовать сбор данных, выделить для этого отдельную группу и готовить определенные типы данных на постоянной основе, чтобы всегда были свежие наборы данных для переобучения старых или обучения новых моделей.
Таким образом, мы пришли к идеальному формату работы для нашей команды.
Я постарался кратко изложить суть, не описывая лишних подробностей и чепухи, а также показать, почему мы приняли те или иные решения и к чему это привело.
Надеюсь, эта статья окажется для вас полезной и полезной в вашей практике.
P.S. Я настоятельно рекомендую прочитать книгу LeanDS менеджерам и инженерам по науке о данных, поскольку она значительно улучшит хотя бы некоторые аспекты ваших процессов.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Какой метод вы используете? 15,38% Скрам 2 38,46% Канбан 5 7,69% Водопад 1 38,46% Другое 5 Проголосовали 13 пользователей.
2 пользователя воздержались.
Теги: #Управление разработкой #Управление проектами #Управление персоналом #Управление продуктом #наука о данных #DS #менеджмент #agile #kanban #компьютерное зрение #аутсорсинг разработки #проекты по созданию новых продуктов #проекты и стартапы
-
Углекислый Газ На Мкс
19 Oct, 24 -
Mysqldump В Формате Csv
19 Oct, 24 -
Unity3D Для Начинающих — Урок 1
19 Oct, 24 -
Женское Тело Как Инструмент Btl-Рекламы
19 Oct, 24
