спасибо. в целом не вижу сильных отличий от стандартной разработки:
Если речь о Канбан-методе, как стандарте — то да, мы его придерживаемся.
вы делаете план работ в Мерлине (а ктото в проджекте). Чем ваш подход лучше общего на рынке?
вы делаете декомпоз работ и осаживаете его на трекер (задачи). Вы делаете в своей системе (как я понял), а большинство - в JIRA (и JIRA гибче вашей системы).
Мерлин, Проджект, Гантпро, Structure и пр. — отличные инструменты для планирования проектов. Я предпочитаю Мерлин за то, что его можно купить из РФ, он десктопный (быстрый), есть удобная выгрузка в HTML и все необходимые функции для планирования ресурсов и связей.
Jira, Kaiten, Yandex и пр. — хорошие Канбан-тулы. Мы не используем самописные инструменты — расширяем существующие под нашу специфику. Jira, увы, ушла из РФ.
Все остальное - детали и метрики, специфичные для кажой компании.
Чем ваш подход лучше?
Я рассказал, как мы на практике применяем разные теоретические знания и подходы. Лучше они или хуже тех, что использует (или планирует) читатель — каждый решит для себя.
А как считали сокращение, расскАжите?
Замеры lead time/cycle time в разрезе разных сервисов и типов работы до и после изменений.
или ваши проекты настолько простые, что их просто нет
Всё относительно, но проекты непростые и наполнены зависимостями.
А как это визализировать (то есть Гантт где?)
План-график разрабатывается на стадии планирования проекта и детализируется после предпроектного обследования, когда более-менее чётко определены границы проекта. Как основной инструмент, используем Merlin. В этой фазе РП отслеживает отклонения от базового плана, показывает прогресс, блокировки, риски клиенту и управляет его ожиданиями.
Как только вы начинаете работать с проектными зависимостями, канбан не панацея.
Отдельной строкой, как планируется работа в процессе разработки. Если накоплено достаточно готовых Requirements для старта разработки, в рамках Канбан-встречи «Собрание по пополнению» с командой проводится воркшоп User Story Mapping. Там как раз определяются приоритеты по User Story: что стоит взять на ближайшие 2–4 недели в очередь Features/Requirements. Там же визуализируются зависимости между задачами и командами, подсвечиваются блокеры.
Когда план на ближайшую итерацию готов, лиды декомпозируют на задачи и пополняют очередь To Do в соответствии с WIP-лимитом. Сколько задач вышло, столько зашло в новую итерацию.
Нет, баги разбиваем на отдельные задачи. На некоторых проектах баги собираются в небольшие группы примерно одной размерности для упрощения.
Зависит от DoD по задаче. Но в по общему правилу стараемся отдавать клиенту готовое, чтобы не накапливать техдолг и негатив.
У нас такие кейсы пишутся в рамках сервиса Requirements: стараемся на вход разработчику передать тест-кейсы.
Если покрытие автотестами не входит в задачу по разработке функциональности, то смотрим на это, как на отдельное требование. Сбор и описание требований в рамках Requirements → согласование бюджета с клиентом → реализация в рамках Features.
В модели предполагается, что после Предпроектного обследования (ППО) согласовываем итоговый объем проекта и фиксируем стоимость в 5500 часов.
Тут есть пара правил переоценки:
— в первоначальной смете подробно расписать работы и прозрачно указать, что после ППО будет переоценка (~20–30%);
— после финализации ППО (занимает 1 месяц): оценить только новые выявленные пункты, но не переоценивать те, которые были в предыдущей смете;
— пункты в обоих сметах должны «биться» друг с другом;
— обычно появляется много новых пожеланий, поэтому нужно сделать новую приоритизацию с клиентом, чтобы согласовать новый состав проекта, который поместится в бюджет.
По договору:
Договор на ППО;
Договор на все работы после завершения ППО;
Доп. соглашения (по необходимости), если окажется, что ближе к концу проекта нужно еще что-то доделать или от чего-то отказаться.
С первой вообще не понятно. Как правило эти задачи сложные, не прогнозируемые по структуре и составу. И на доске могут висеть в одном статусе долго. И тут противоречие - по сути процесс такой не визуализируется, задача просто прыгает в колонку Выполнено. Сомнительное решение.
В этом и идея, что задачи, которые должны помогать развивать систему не должны быть невыполняемыми абстрактными идеями, которые никто и делать на самом деле не собирается. Задачи смартуем, приоритизируем, декомпозируем и пускаем в работу. Слева-направо отслеживая зрелость и поддерживая фокус на регулярных встречах.
Про "задачу на доработке не возвращаем" - тоже вопрос. Опять же, противоречие в визуализации. Не понятно, почему при её переносе назад херится история. Кто мешает сохранить артефакты?
История не «херится». Движение по доске справа-налево портит аналитику для Cumulitive Flow Diagram и Lead Time. Для дефектов лучше создавать новые задачи на исправление или доработку (это проводить через бэклог).
Не знаю деталей, как в Сбере применяется Agile. Так как это большая продуктовая компания, наверняка там адаптация какого-то масштабируемого фреймворка: Less/Safe/Nexus. Мы сервисная компания, поэтому нам лучше подходит Канбан-метод. С помощью которого мы работаем с тем же Сбером.
Если действительно интересно, могу разузнать у коллег из Сбера детали и написать отдельную статью на эту тему.
Да. При переходе Требования в финальный статус предлагается создать задачу на доске разработки на основе выкладок из родителя.
И есть специфические кейсы. Например, баги, связанные с разметкой (веб-аналитика) попадают на доску Requirements.
Самая большая интеграция с досками цеха, куда сливаются все задачи из всех проектов по определенным типам и подтипам. Наверно эта тема отдельной заметки достойна.
Не стал про это подробно писать, кажется это особенности наших процессов.
Не совсем так. Канбан на заводах Тойоты – это бережливое производство, определяющим принципом которого является понятие “точно в срок”. Канбан, как термин в управлении, действительно пошел от Тойоты. В переводе с японского это слово означает “сигнал” или “карточка”. На автомобильных заводах такие карточки использовались, чтобы передать информацию с одного этапа на следующий о том, сколько и каких деталей потребуется...
...Канбан-метод тоже придерживается понятия “точно в срок”, но в отличие от заводов Тойоты здесь речь идет об интеллектуальном труде. Иными словами, код программиста или идею маркетолога нельзя пощупать и увидеть обычному человеку, пока он(она) не превратится в конечный продукт или сервис. Таким образом, Канбан-метод используется для визуализации потока интеллектуальной работы и сокращения количества этой незавершенной работы. За счёт этого достигается равномерная и предсказуемая скорость оказания услуги конечному потребителю.
WIP-лимиты помогают фокусироваться на доделывании работы в стадиях уборки и проверки. Новая задача берется, когда полностью сделана предыдущая в соответствии с приоритетом. Помогает обуздать хаос, сбалансировать нагрузку и создать ритм. У команды был установлен wip-лимит на сотрудника: не более 1 задачи одновременно в работе.
Когда зависимостей между задачами мало — так легче планировать работу, но wip-лимиты не отменяются.
В этом доме не хранились драгоценности, но многие ценные вещи сгорели или испортились. Если вы имеете в виду, украли ли что-то пока устранялись последствия пожара — то нет.
Если речь о Канбан-методе, как стандарте — то да, мы его придерживаемся.
Мерлин, Проджект, Гантпро, Structure и пр. — отличные инструменты для планирования проектов. Я предпочитаю Мерлин за то, что его можно купить из РФ, он десктопный (быстрый), есть удобная выгрузка в HTML и все необходимые функции для планирования ресурсов и связей.
Jira, Kaiten, Yandex и пр. — хорошие Канбан-тулы. Мы не используем самописные инструменты — расширяем существующие под нашу специфику. Jira, увы, ушла из РФ.
Я рассказал, как мы на практике применяем разные теоретические знания и подходы. Лучше они или хуже тех, что использует (или планирует) читатель — каждый решит для себя.
Замеры lead time/cycle time в разрезе разных сервисов и типов работы до и после изменений.
Привет!
Всё относительно, но проекты непростые и наполнены зависимостями.
План-график разрабатывается на стадии планирования проекта и детализируется после предпроектного обследования, когда более-менее чётко определены границы проекта. Как основной инструмент, используем Merlin. В этой фазе РП отслеживает отклонения от базового плана, показывает прогресс, блокировки, риски клиенту и управляет его ожиданиями.
Отдельной строкой, как планируется работа в процессе разработки. Если накоплено достаточно готовых Requirements для старта разработки, в рамках Канбан-встречи «Собрание по пополнению» с командой проводится воркшоп User Story Mapping. Там как раз определяются приоритеты по User Story: что стоит взять на ближайшие 2–4 недели в очередь Features/Requirements. Там же визуализируются зависимости между задачами и командами, подсвечиваются блокеры.
Когда план на ближайшую итерацию готов, лиды декомпозируют на задачи и пополняют очередь To Do в соответствии с WIP-лимитом. Сколько задач вышло, столько зашло в новую итерацию.
Привет! Сорри за запоздалый ответ.
Нет, баги разбиваем на отдельные задачи. На некоторых проектах баги собираются в небольшие группы примерно одной размерности для упрощения.
Зависит от DoD по задаче. Но в по общему правилу стараемся отдавать клиенту готовое, чтобы не накапливать техдолг и негатив.
У нас такие кейсы пишутся в рамках сервиса Requirements: стараемся на вход разработчику передать тест-кейсы.
Если покрытие автотестами не входит в задачу по разработке функциональности, то смотрим на это, как на отдельное требование. Сбор и описание требований в рамках Requirements → согласование бюджета с клиентом → реализация в рамках Features.
В модели предполагается, что после Предпроектного обследования (ППО) согласовываем итоговый объем проекта и фиксируем стоимость в 5500 часов.
Тут есть пара правил переоценки:
— в первоначальной смете подробно расписать работы и прозрачно указать, что после ППО будет переоценка (~20–30%);
— после финализации ППО (занимает 1 месяц): оценить только новые выявленные пункты, но не переоценивать те, которые были в предыдущей смете;
— пункты в обоих сметах должны «биться» друг с другом;
— обычно появляется много новых пожеланий, поэтому нужно сделать новую приоритизацию с клиентом, чтобы согласовать новый состав проекта, который поместится в бюджет.
По договору:
Договор на ППО;
Договор на все работы после завершения ППО;
Доп. соглашения (по необходимости), если окажется, что ближе к концу проекта нужно еще что-то доделать или от чего-то отказаться.
С первой вообще не понятно. Как правило эти задачи сложные, не прогнозируемые по структуре и составу. И на доске могут висеть в одном статусе долго. И тут противоречие - по сути процесс такой не визуализируется, задача просто прыгает в колонку Выполнено. Сомнительное решение.В этом и идея, что задачи, которые должны помогать развивать систему не должны быть невыполняемыми абстрактными идеями, которые никто и делать на самом деле не собирается. Задачи смартуем, приоритизируем, декомпозируем и пускаем в работу. Слева-направо отслеживая зрелость и поддерживая фокус на регулярных встречах.
Про "задачу на доработке не возвращаем" - тоже вопрос. Опять же, противоречие в визуализации. Не понятно, почему при её переносе назад херится история. Кто мешает сохранить артефакты?История не «херится». Движение по доске справа-налево портит аналитику для Cumulitive Flow Diagram и Lead Time. Для дефектов лучше создавать новые задачи на исправление или доработку (это проводить через бэклог).
Кстати, еще специфика в том, что готовое Требование обычно декомпозируется на ряд задач в разработку, которые попадают в бэклог.
Т. е. после разработки дизайн-макета, например, в бэклог может попасть 3 задачи, которые пока делать не нужно и они должны ждать своей очереди.
В таком кейсе сквозная визуализация скорее повредит.
Хех, это внутреннее название. У нас компания называется Agima, поэтому Agimaban хорошо приживается
Спасибо.
Для больших команд тако вариант не очень подходит, если очень много работы собрано на каждой из досок.
Но для средних и небольших — может быть нормальной практикой. Запишу себе идею подумать над Агимабан_лайт)
Не знаю деталей, как в Сбере применяется Agile. Так как это большая продуктовая компания, наверняка там адаптация какого-то масштабируемого фреймворка: Less/Safe/Nexus. Мы сервисная компания, поэтому нам лучше подходит Канбан-метод. С помощью которого мы работаем с тем же Сбером.
Если действительно интересно, могу разузнать у коллег из Сбера детали и написать отдельную статью на эту тему.
Да. При переходе Требования в финальный статус предлагается создать задачу на доске разработки на основе выкладок из родителя.
И есть специфические кейсы. Например, баги, связанные с разметкой (веб-аналитика) попадают на доску Requirements.
Самая большая интеграция с досками цеха, куда сливаются все задачи из всех проектов по определенным типам и подтипам. Наверно эта тема отдельной заметки достойна.
Не стал про это подробно писать, кажется это особенности наших процессов.
1 стандарт. Канбан-метод
Здравствуйте, спасибо за материал!
А расскажите, как технически вы реализовали интеграцию Jira и Metabase?
Прошу прощения, отвечу цитатой, очень подходит:
https://scrumtrek.ru/blog/kanban/1360/chto-takoe-kanban-metod-maksimalno-korotko/
WIP-лимиты помогают фокусироваться на доделывании работы в стадиях уборки и проверки. Новая задача берется, когда полностью сделана предыдущая в соответствии с приоритетом. Помогает обуздать хаос, сбалансировать нагрузку и создать ритм. У команды был установлен wip-лимит на сотрудника: не более 1 задачи одновременно в работе.
Когда зависимостей между задачами мало — так легче планировать работу, но wip-лимиты не отменяются.
В этом доме не хранились драгоценности, но многие ценные вещи сгорели или испортились. Если вы имеете в виду, украли ли что-то пока устранялись последствия пожара — то нет.
Скажем так, скептиков было больше, чем 2–3 евангелистов, которые были за любую движуху )
Всё было достаточно стремительно. 1 день на первичную подготовку.
Точно уже не помню, но примерно так:
1 день :: 4
2 день :: 8
3 день :: 16
4 день :: 18→20