Комментарии 7
Команда очень слабо работала с Jira. Всегда приходилось двигать таски и актуализировать доску насильственно…
Никто под сомнения сам факт необходимости доски в этом случае не ставил, и продолжали есть кактус?
Так это, самое интересное не рассказали, вот вы пришли "был хаос", сейчас везде "порядок", результаты-то лучше стали?
Сейчас все привыкли работать с доской и это стало гораздо удобнее по сравнение с началом, когда всем приходилось держать все возможные задачи в голове, постоянно что-то забывали, потому не выкатывали вовремя, выкатывали неважные фичи, а важные оставляли на потом и т.д.
Доска помогла исправить эту ситуацию и нормально приоритезировать, описать и распланировать задачи, а также помогла команде держать фокус. Но процесс привыкания был болезненный.
Сейчас же да, результаты стали лучше, скорость и качество выпуска фич возрасло, процесс максимально понятен и прозрачен для всех, команда стала фокусироваться на самом важном и нам удается планировать разработку на основе анализа продолжительности цикла выполнения задач, как минимум.
Круто, а можно пояснить что вы подразумеваете "фичами", просто в моем мире "фича" почти равно новая моделька, либо какой-то достаточно трудоемкий процесс (хорошо если пару недель, а то и месяцы), не совсем понимаю как их можно забыть. Я это к тому, что у меня в разных местах доска была нужна только ради доски и спокойствия менеджера, пользы от нее если DS более-менее изолирован от разработки не много, вреда же прилично.
Может, проблема более глубокая, вроде "перемешанная ответственность", а agile - костыль? Просто DS это ресерч, оценки времени и уж тем более гарантии какого-то результата тут очень условны. Тут скорее работает история целей, а не задач, и с сильно большим горизонтом, чем пара недель.
Да, по большому счету я говорю о фичах как о готовых модельках, но кроме этого у нас были более мелкие требования, которые касались бэкенда или визуализации данных, их анализа и т.д. И моделей как минимум 5 разрабатывалось параллельно, причем данные для них находились в невероятном хаосе) Поэтому что-то забывалось, что-то делалось на скорую руку и т.д. Процесс постановки задач как минимум поспособствовал упорядочить все это.
Судя по тому, что вы описали, вы просто использовали доску для отображения задач, но не использовали kanban или другой фреймворк в полном смысле. Например, используя Kanban мы с командой разделили ответственность, запараллелили разные части работы, поставили ограничения по количеству одновременной работы и это позволило придти к состоянию, когда один член команды работает над одной задачей в одну единицу времени. Также правильная постановка задачи и сроки ее постановки позволили не делать лишней работы, а достигать тех результатов, которые приемлены для заказчика + команда понимает конечный результат который нужно получить. Этому очень хорошо помогают приемочные критерии, кстати: https://prnt.sc/1bfixn8
В плане работы над моделями важно также правильно декомпозировать задачи. Например, у вас есть задача от заказчика: он хочет, чтобы личные данные с фото паспорта автоматически заносились в БД и отображались в карточке пользователя в личном кабинете на каком-то сайте. Вы можете сказать ему: ну мне надо или 1 неделя или 4 месяца. Он ждет и получает версию с точностью 70% через 3 месяца. Он же думает, что получит уже готовый вариант и больше никогда вы не станете лезть в эту модель, займетесь другой задачей. В итоге конфликт и срыв сроков, так как нужно еще 2 месяца переобучать модель и т.д.
Но можно разбить эту же задачу на несколько параллельных гипотез:
1. Попробовать предобученную модель
2. Собрать датасет и добавить аугументаций (я фантазирую)
3. Собрать числые данные и сделать свою модельку
4. Использовать обучение только на латинских буквах и посмотреть как будет работать с другими языками
Гипотеза сработала и будет использоваться, если модель сможет работать с Европейскими языками и точность оказалась не ниже 80%
И вы можете:
* Проверять подходы параллельно
* Выдавать заказчику результаты быстрее (промежуточные)
* Разбить требование на части и сделать отдельно, выкатывая частями сразу в прод (например, сперва английский язык, потом японский и др.)
Используя доску вы можете определить время начал и конца работы над каждой гипотезой, оценить их вес и определить среднюю продолжительность цикла проверки гипотезы как минимум. На основе этого спланировать хотя бы как-то (с учетом рисков) как вы будете выкатывать фичу.
А теперь представьте, что у вас распределены обязанности и есть, например, отдельная группа подготовки данных и тестирования моделей, которая всегда поставляет вам данные и сама проверяет модельку. А также вы всегда видите загрузку этих ресурсов и можете добавить, скажем обязанностей той или иной группе или переключить человека из одной группы в другую и т.д.
Также вы всегда понимаете что вам предстоит сделать в следующую очередь, и вы всегда занимаетесь одной конкретной задачей.
Не имея доски у вас как минимум не будет информации для анализа, которую можно использовать для улучшения процесса и планирования
Очень здорово звучит, надеюсь, когда-нибудь весь DS будет в таких рамках, сейчас я мысленно пытаюсь натянуть такую сову на свой глобус и понимаю, что она развалится через неделю.
Например:
определить среднюю продолжительность цикла проверки гипотезы как минимум
это скорее задачка на поразвлекаться, это почти никак не помогает оценить время проверки будущих гипотез, кроме каких-то шаблонных задач
Не имея доски у вас как минимум не будет информации для анализа
Здесь есть неявное предположение, что доска является единственных трекером, что совсем не так, у нас более-менее прижилась модель "статусы и планы", то есть когда вы скорее синхронизируетесь и примерно накидываете вектор развития.
Главная претензия у меня к доска-лайк подходам - статусы вроде "to do, in progress" и тд, это хорошо работает когда ты в день закрываешь пару задач, а не когда одну в пару недель - это просто становится абузой.
UPD: ссылка https://prnt.sc/1bfixn8 не открывается(
Главная претензия у меня к доска-лайк подходам — статусы вроде "to do, in progress" и тд, это хорошо работает когда ты в день закрываешь пару задач, а не когда одну в пару недель — это просто становится абузой.
Я бы сказал ещё проще: пока вы можете без проблем держать все свои таски в голове, то доска лично вам и не нужна.
Правда возможно она будет нужна вашему тимлиду/менеджеру так как он не сможет держать в голове таски всех подчинённых :)
И важно понимать, что вы можете хоть на листике в блокноте записывать ваши задачи. Ваша доска - инструмент, который помогает вам управлять потоком задач и делает это удобным (для всей команды). Сам подход к разработке не привязан к доске: вы можете и со списком в блокноте выкатывать релизы каждые 2 недели, а можете по мере готовности, можете ставить себе ограничения на объем одновременно выполняемых задач и уточнять что-то лично у других участников команды через, скажем Slack, но грамотно используя доску вы сможете избежать очень многих лишних вопросов, обсуждений, собраний, сможете грамотнее распределять ресурсы и т.д. + будете понимать загрузку коллег, помогать им по необходимости, понимать общий прогресс команды на проекте и т.д.
Внедрение Agile в Data Science и Computer Vision проекте. Управление командой Data Science