Comments 28
"Ситуация: есть 14 конкурирующих стандартов..."
Скажите, а задачи между досками как-то связаны?
Только в головах
Да. При переходе Требования в финальный статус предлагается создать задачу на доске разработки на основе выкладок из родителя.
И есть специфические кейсы. Например, баги, связанные с разметкой (веб-аналитика) попадают на доску Requirements.
Самая большая интеграция с досками цеха, куда сливаются все задачи из всех проектов по определенным типам и подтипам. Наверно эта тема отдельной заметки достойна.
Не стал про это подробно писать, кажется это особенности наших процессов.
Не хватает сравнения со Сбергилом.
Не знаю деталей, как в Сбере применяется Agile. Так как это большая продуктовая компания, наверняка там адаптация какого-то масштабируемого фреймворка: Less/Safe/Nexus. Мы сервисная компания, поэтому нам лучше подходит Канбан-метод. С помощью которого мы работаем с тем же Сбером.
Если действительно интересно, могу разузнать у коллег из Сбера детали и написать отдельную статью на эту тему.
Сбер большой. Команд много. Кто то канбанит, кто то скрамит, кто то свое придумывает. У каждой команды свои практики.
Нормальная схема. Пришёл к очень похожей системе, правда, на роли продакта со внешней студией в качестве исполнителя - поэтому в основу всё же фиксированные спринты положил. А тут все те же задумки до логического завершения доведены.
Хороший подход, отдельный респект, что все задокументировали и описали (особенно чек-листы)
Как совет: попробуйте соединить 2-ю и 3-ю доску. Видится, что это один поток задач у вас, который переходит с одной доски на другую - да, доска станет длиннее (купите ребятам широкоформатные мониторы), но процесс будет прозрачнее. Разрабы будут видеть заранее задачи, которые к ним идут. Так кажется со стороны.
Спасибо.
Для больших команд тако вариант не очень подходит, если очень много работы собрано на каждой из досок.
Но для средних и небольших — может быть нормальной практикой. Запишу себе идею подумать над Агимабан_лайт)
Некоторые таск-трекеры, Jira, например, позволяют отображать одну и ту же задачу на разных досках или, если посмотреть с другой стороны -- разбить доску на несколько частей.
В таком случае и двойного ввода не будет, и широкоформатный монитор покупать не надо будет: при достижении задачей финального статуса на одной доске она автоматически появится на другой доске.
Кстати, еще специфика в том, что готовое Требование обычно декомпозируется на ряд задач в разработку, которые попадают в бэклог.
Т. е. после разработки дизайн-макета, например, в бэклог может попасть 3 задачи, которые пока делать не нужно и они должны ждать своей очереди.
В таком кейсе сквозная визуализация скорее повредит.
У нас происходило это следующим образом:
Если требование заказчика изначально включало в себя несколько требований, то бизнес-аналитик сразу их разбивал на несколько на своей борде и дальше работа по ним велась отдельно.
Если же требование по факту было одно, но для его реализации требовалось несколько задач (банльный пример: дизайн, клиент и сервер), то задача декомпозировалась уже на борде разработки в процессе планирования.
И суть тут не в визуализации, а в непрерывности жизненого цикла задачи: всегда можно посмотреть что там с ней происходило на этапе проработки требования. Ну и плюс экономия времени: не нужно копипастить всю информацию из требования в задачу.
Если это работает также хорошо как выглядит в тексте - это прекрасно, но лично я больший сторонник традиционного Agile + scrumban, а как выглядит доска - это совсем дело 10-е.
Чек-листы - тема здравая, тоже пришли к ним, только к таскам не привязываем жёстко.
Доски 2 и 3 у нас объединены, раздергивать - создавать хаос в головах у менеджеров, контролировать процессы в двух местах, у нас - одна, просто разрабы смотрят на правую её часть.
С первой вообще не понятно. Как правило эти задачи сложные, не прогнозируемые по структуре и составу. И на доске могут висеть в одном статусе долго. И тут противоречие - по сути процесс такой не визуализируется, задача просто прыгает в колонку Выполнено. Сомнительное решение.
Про "задачу на доработке не возвращаем" - тоже вопрос. Опять же, противоречие в визуализации. Не понятно, почему при её переносе назад херится история. Кто мешает сохранить артефакты?
С первой вообще не понятно. Как правило эти задачи сложные, не прогнозируемые по структуре и составу. И на доске могут висеть в одном статусе долго. И тут противоречие - по сути процесс такой не визуализируется, задача просто прыгает в колонку Выполнено. Сомнительное решение.
В этом и идея, что задачи, которые должны помогать развивать систему не должны быть невыполняемыми абстрактными идеями, которые никто и делать на самом деле не собирается. Задачи смартуем, приоритизируем, декомпозируем и пускаем в работу. Слева-направо отслеживая зрелость и поддерживая фокус на регулярных встречах.
Про "задачу на доработке не возвращаем" - тоже вопрос. Опять же, противоречие в визуализации. Не понятно, почему при её переносе назад херится история. Кто мешает сохранить артефакты?
История не «херится». Движение по доске справа-налево портит аналитику для Cumulitive Flow Diagram и Lead Time. Для дефектов лучше создавать новые задачи на исправление или доработку (это проводить через бэклог).
Коллеги, спасибо за статью! Круто, что детализировали этапы аналитики и разработки. Но кажется, что вопрос контроля качества немного не раскрыт. Если вдруг, найдете время, был бы признателен за ответы на эти вопросы:
1. Вы складываете все баги в отдельный таск и отслеживаете динамику багов. Как возможно отслеживать динамику багов, если таск один на все баги?
2. Все ли баги, найденные при внутреннем тестировании QA инженером обязательно фиксятся перед тем, как отдать на приемку клиентом?
3. Как при такой модели реализовать шифт-лефт подход к тестированию? Т.е. когда тестировщик, к примеру пишет тест-кейсы еще на этапе кодинга? Допустим, можно было бы элементом чек-листа или другим свойством задачи. Но тогда мы наглядно не увидим нагрузку на QA и не сможем WIP лимиты настроить и стягивание для таких подзадач на QA.
4. Если QA создает автотесты(или выполняет любые другие задачи отличные от реализации конкретной фичи, но нужные для поддержки качества проекта), то на каком этапе и в рамках какого процесса ставятся такие задачи?
Привет! Сорри за запоздалый ответ.
Нет, баги разбиваем на отдельные задачи. На некоторых проектах баги собираются в небольшие группы примерно одной размерности для упрощения.
Зависит от DoD по задаче. Но в по общему правилу стараемся отдавать клиенту готовое, чтобы не накапливать техдолг и негатив.
У нас такие кейсы пишутся в рамках сервиса Requirements: стараемся на вход разработчику передать тест-кейсы.
Если покрытие автотестами не входит в задачу по разработке функциональности, то смотрим на это, как на отдельное требование. Сбор и описание требований в рамках Requirements → согласование бюджета с клиентом → реализация в рамках Features.
Не раскрыта тема визализации зависимостей задач между собой, или ваши проекты настолько простые, что их просто нет? Но ведь фронт от бекенда зависит, к примеру, тогда как отслеживаются зависимости? депендансями в тикетах? А как это визализировать (то есть Гантт где?)
В целом, если у вас простой комбайн, который фигачит поток входящих небольших (до 2х мес) CRы, они же ЗНИ, то да. Как только вы начинаете работать с проектными зависимостями, канбан не панацея.
Привет!
или ваши проекты настолько простые, что их просто нет
Всё относительно, но проекты непростые и наполнены зависимостями.
А как это визализировать (то есть Гантт где?)
План-график разрабатывается на стадии планирования проекта и детализируется после предпроектного обследования, когда более-менее чётко определены границы проекта. Как основной инструмент, используем Merlin. В этой фазе РП отслеживает отклонения от базового плана, показывает прогресс, блокировки, риски клиенту и управляет его ожиданиями.
Как только вы начинаете работать с проектными зависимостями, канбан не панацея.
Отдельной строкой, как планируется работа в процессе разработки. Если накоплено достаточно готовых Requirements для старта разработки, в рамках Канбан-встречи «Собрание по пополнению» с командой проводится воркшоп User Story Mapping. Там как раз определяются приоритеты по User Story: что стоит взять на ближайшие 2–4 недели в очередь Features/Requirements. Там же визуализируются зависимости между задачами и командами, подсвечиваются блокеры.
Когда план на ближайшую итерацию готов, лиды декомпозируют на задачи и пополняют очередь To Do в соответствии с WIP-лимитом. Сколько задач вышло, столько зашло в новую итерацию.
спасибо. в целом не вижу сильных отличий от стандартной разработки:
вы делаете план работ в Мерлине (а ктото в проджекте). Чем ваш подход лучше общего на рынке?
вы делаете декомпоз работ и осаживаете его на трекер (задачи). Вы делаете в своей системе (как я понял), а большинство - в JIRA (и JIRA гибче вашей системы). Чем ваш подход лучше?
Все остальное - детали и метрики, специфичные для кажой компании.
И кстати, вопрос 3 - вы помянули, что сократили time-to-market. А как считали сокращение, расскАжите?
спасибо. в целом не вижу сильных отличий от стандартной разработки:
Если речь о Канбан-методе, как стандарте — то да, мы его придерживаемся.
вы делаете план работ в Мерлине (а ктото в проджекте). Чем ваш подход лучше общего на рынке?
вы делаете декомпоз работ и осаживаете его на трекер (задачи). Вы делаете в своей системе (как я понял), а большинство - в JIRA (и JIRA гибче вашей системы).
Мерлин, Проджект, Гантпро, Structure и пр. — отличные инструменты для планирования проектов. Я предпочитаю Мерлин за то, что его можно купить из РФ, он десктопный (быстрый), есть удобная выгрузка в HTML и все необходимые функции для планирования ресурсов и связей.
Jira, Kaiten, Yandex и пр. — хорошие Канбан-тулы. Мы не используем самописные инструменты — расширяем существующие под нашу специфику. Jira, увы, ушла из РФ.
Все остальное - детали и метрики, специфичные для кажой компании.
Чем ваш подход лучше?
Я рассказал, как мы на практике применяем разные теоретические знания и подходы. Лучше они или хуже тех, что использует (или планирует) читатель — каждый решит для себя.
А как считали сокращение, расскАжите?
Замеры lead time/cycle time в разрезе разных сервисов и типов работы до и после изменений.
Мы придумали удобную систему управления разработкой. Объясняем, как она работает