Комментарии 21
"Ситуация: есть 14 конкурирующих стандартов..."
Скажите, а задачи между досками как-то связаны?
Только в головах
Да. При переходе Требования в финальный статус предлагается создать задачу на доске разработки на основе выкладок из родителя.
И есть специфические кейсы. Например, баги, связанные с разметкой (веб-аналитика) попадают на доску Requirements.
Самая большая интеграция с досками цеха, куда сливаются все задачи из всех проектов по определенным типам и подтипам. Наверно эта тема отдельной заметки достойна.
Не стал про это подробно писать, кажется это особенности наших процессов.
Не хватает сравнения со Сбергилом.
Не знаю деталей, как в Сбере применяется Agile. Так как это большая продуктовая компания, наверняка там адаптация какого-то масштабируемого фреймворка: Less/Safe/Nexus. Мы сервисная компания, поэтому нам лучше подходит Канбан-метод. С помощью которого мы работаем с тем же Сбером.
Если действительно интересно, могу разузнать у коллег из Сбера детали и написать отдельную статью на эту тему.
Сбер большой. Команд много. Кто то канбанит, кто то скрамит, кто то свое придумывает. У каждой команды свои практики.
Нормальная схема. Пришёл к очень похожей системе, правда, на роли продакта со внешней студией в качестве исполнителя - поэтому в основу всё же фиксированные спринты положил. А тут все те же задумки до логического завершения доведены.
Хороший подход, отдельный респект, что все задокументировали и описали (особенно чек-листы)
Как совет: попробуйте соединить 2-ю и 3-ю доску. Видится, что это один поток задач у вас, который переходит с одной доски на другую - да, доска станет длиннее (купите ребятам широкоформатные мониторы), но процесс будет прозрачнее. Разрабы будут видеть заранее задачи, которые к ним идут. Так кажется со стороны.
Спасибо.
Для больших команд тако вариант не очень подходит, если очень много работы собрано на каждой из досок.
Но для средних и небольших — может быть нормальной практикой. Запишу себе идею подумать над Агимабан_лайт)
Некоторые таск-трекеры, Jira, например, позволяют отображать одну и ту же задачу на разных досках или, если посмотреть с другой стороны -- разбить доску на несколько частей.
В таком случае и двойного ввода не будет, и широкоформатный монитор покупать не надо будет: при достижении задачей финального статуса на одной доске она автоматически появится на другой доске.
Кстати, еще специфика в том, что готовое Требование обычно декомпозируется на ряд задач в разработку, которые попадают в бэклог.
Т. е. после разработки дизайн-макета, например, в бэклог может попасть 3 задачи, которые пока делать не нужно и они должны ждать своей очереди.
В таком кейсе сквозная визуализация скорее повредит.
У нас происходило это следующим образом:
Если требование заказчика изначально включало в себя несколько требований, то бизнес-аналитик сразу их разбивал на несколько на своей борде и дальше работа по ним велась отдельно.
Если же требование по факту было одно, но для его реализации требовалось несколько задач (банльный пример: дизайн, клиент и сервер), то задача декомпозировалась уже на борде разработки в процессе планирования.
И суть тут не в визуализации, а в непрерывности жизненого цикла задачи: всегда можно посмотреть что там с ней происходило на этапе проработки требования. Ну и плюс экономия времени: не нужно копипастить всю информацию из требования в задачу.
Если это работает также хорошо как выглядит в тексте - это прекрасно, но лично я больший сторонник традиционного Agile + scrumban, а как выглядит доска - это совсем дело 10-е.
Чек-листы - тема здравая, тоже пришли к ним, только к таскам не привязываем жёстко.
Доски 2 и 3 у нас объединены, раздергивать - создавать хаос в головах у менеджеров, контролировать процессы в двух местах, у нас - одна, просто разрабы смотрят на правую её часть.
С первой вообще не понятно. Как правило эти задачи сложные, не прогнозируемые по структуре и составу. И на доске могут висеть в одном статусе долго. И тут противоречие - по сути процесс такой не визуализируется, задача просто прыгает в колонку Выполнено. Сомнительное решение.
Про "задачу на доработке не возвращаем" - тоже вопрос. Опять же, противоречие в визуализации. Не понятно, почему при её переносе назад херится история. Кто мешает сохранить артефакты?
С первой вообще не понятно. Как правило эти задачи сложные, не прогнозируемые по структуре и составу. И на доске могут висеть в одном статусе долго. И тут противоречие - по сути процесс такой не визуализируется, задача просто прыгает в колонку Выполнено. Сомнительное решение.
В этом и идея, что задачи, которые должны помогать развивать систему не должны быть невыполняемыми абстрактными идеями, которые никто и делать на самом деле не собирается. Задачи смартуем, приоритизируем, декомпозируем и пускаем в работу. Слева-направо отслеживая зрелость и поддерживая фокус на регулярных встречах.
Про "задачу на доработке не возвращаем" - тоже вопрос. Опять же, противоречие в визуализации. Не понятно, почему при её переносе назад херится история. Кто мешает сохранить артефакты?
История не «херится». Движение по доске справа-налево портит аналитику для Cumulitive Flow Diagram и Lead Time. Для дефектов лучше создавать новые задачи на исправление или доработку (это проводить через бэклог).
Мы придумали удобную систему управления разработкой. Объясняем, как она работает