6 заметок с тегом

kanban

Про скорость разработки в Канбан

В августе 2016 года на одном из проектов установили ограничение Work In Progress равное количеству девелоперов работающим над проектом. Т. е. если кто-то заболевал или уходил в отпуск, ограничение Work In Progress уменьшалось на единицу. При добавлении разработчиков, увеличивалось на единицу.

На скриншоте Control Chart в Jira и эффект от внедрения данной практики:

Rolling avarage дней между «взято в разработку» и «готово к релизу» (конкретно на этом проекте даже выкачено на продакшен) снизилось с 7.4 дней до 2.7 дней.

То есть бизнес стал получать свою функциональность в два раза быстрее.

Недавно проводил мастер-класс новой проектной команде по Канбану и WIP:

Смысл в том, что бы браться за новые задачи только после того, как уже взятые в работу полностью готовы.

Частая картина в девелоперских командах:

  1. Программист взял Задачу 1 в разработку
  2. Отправил Задачу 1 на тестирование
  3. Тестер приступил к тестированию через 5 часов
  4. Программист пока взял Задачу 2
  5. Задача 1 вернулась с багом
  6. Программист решает закончить Задачу 2
  7. Через 3 часа программист отправляет Задачу 2 на тестирование
  8. Программист возвращается к доработке Задачи 1
  9. Через час исправляет баг и отправляет Задачу 1 на тестирование
  10. Через 2 часа Тестировщик приступает к тестированию Задачи 1
  11. Задача 1 отправляется в релиз

Итого время простоя задачи
на пункте 3: 5 часов
на пункте 7: 3 часа
на пункте 10: 2 часа

Проблемы бесконтрольного набора задач:

  1. Задача долго отлеживается, перед тем как её возьмут на тестирование, потому что тестировщики заняты тестированием других задач
  2. Задача долго отлеживается после возвращения на доработку, потому что программист пока ждет результатов тестирования, взял себе на разработку уже другую задачу, и пока ее не закончит, к доработкам вернувшегося тикета не приступит.

Как итог: куча полуфабрикатов, недоделок, незавершенных задач — одним словом, связанный капитал: время и деньги на разработку потрачены, а результата нет.

Так вот, в моих командах, процесс устроен следующим образом:

  • Ограничение WIP = кол-во девелоперов на проекте
  • Пока программист реализует задачу, тестировщик ждет: читает хабр, доки, занимается планированием собственной работы, какими-то улучшениями, общением с аналитиками по задачам в разработке
  • Как только задача готова, тестировщик принимается за ее тестирование.
  • Программист находится в активном ожидании обратной связи от тестировщика и читает хабр, документацию, занимается самосовершенствованием, помогает тестировать
  • Как только задача возвращается на доработку — берет ее в ту же минуту и быстро исправляет недочеты. Это легко, т. к. программист находится в контексте задачи и прекрасно помнит что именно где править
  • Как только задача завершена, тестировщик в ту же минуту проводит повторное тестирование, и если все ОК, отправляет в релиз.
  • Как результат:

    1. минимальное время на реализацию задач
    2. минимальное количество задач погрязших в болоте доработок
    3. у программистов и тестировщиков есть время на саморазвитие
    4. бизнес подразделение довольно: новая функциональность начинает приносить деньги сразу же, а не «через 2 недели, когда будет релиз»

    + Полезное из переписки на facebook:

    Канбан (Манн-Иванов-Фербер)

    Обнаружил и начал читать свежую книгу про Канбан. Могу сказать, что она совершенно замечательная, полезная и я всем проектным управленцам ее теперь буду яростно рекомендовать.

    Очень легко и понятно сформулированы все вещи, которые мы на своем опыте прошли и сохранили в виде не описанного опыта и ощущений «спинным мозгом» того, что правильно и работает, а что нет.

    http://www.mann-ivanov-ferber.ru/books/kanban/

    2017   kanban   Книги

    Вот такой получился Kanban

    В моей команде мы используем следующий подход к приоритезации задач и процессу разработки.

    У нас определено 5 слоев приоритетности реализации features:

    1. Реализация бизнес-задач, которые приносят выручку/прибыль компании — подключение новых партнеров, типов услуг, ускорение того что должно быть быстрым, снижение лагов.
    2. Реализация задач, которые не дают потерять прибыль компании  — оптимизации, профилактика ошибок, исправление техдолгов, бекапы, резервирование.
    3. То, что влияет на принятие решений — статистика в различных разрезах, отчетность, графики, инструменты аналитики.
    4. Улучшения, которые снижают нагрузку на техническую команду — автоматизация того, что можно, чтобы все кто хочет получить те или иные данные/сборки/отчеты могли их самостоятельно запросить из системы и получить.
    5. Ошибки, улучшения не влияющие на принятие решений — улучшения в веб интерфейсе, скорости работы личного кабинета, добавление мелкой функциональности которая делает работу удобнее.

    Внутри каждого из этих слоев есть определенный набор задач, так же отранжированных по приоритетности. Все пять слоев всегда в разработке параллельно друг другу. Т. е. нет такого что мы сначала делаем только то что дает выручку, потом технические доработки, потом все остальное. Все делается параллельно.

    Термины юзерстори или эпик мы нигде не употребляем. Просто если есть какая-то важная большая задача (Мамонт) она идет в каком-то из этих слоев нарезанная по кусочкам.

    И есть одна «красная линия» с высочайшим приоритетом: для задач асап/ критическим багом в продакшене.

    Процесс один: беклог -> аналитика -> аналитика готова -> разработка -> разработка готова -> тестирование локально -> кодревью -> тестирование на стеджинге -> тестирование завершено -> выкат на прод -> тестирование на проде -> тесткейсы в вики -> автотест на ui -> внесение в регрессионый план -> завершено.

    Процесс непрерывного улучшения

    В общем-то я и прежние годы был под впечатлением и действовал по принципам книги «Цель. Процесс непрерывного совершенствования», которую давно всем рекомендую, но реальный практический тренинг все расставил по полочкам.

    Чем собственно отличается процесс SCRUM от KANBAN.

    Чем меряют сложность задач в Scrum и Kanban

    Три графика, которые помогут измерить эффективность всего процесса (от начала до результата)

    Стоимость задержки поставки. Авария, обычная необходимость, жесткий срок, технический долг

    Звездная карта. Картотека компетенций команды и точек интереса сотрудников. Полезная вещь, сразу же завел такую у себя.

    Бонусом раскрыли тему о том чем коллектив отличается от команды

    А это просто доска с результатами игры. Сначала мы шли медленнее остальных, но за счет того, что автоматизировали многие вещи, ограничили WIP и очередь выиграли.

    Что еще интересно, и игру закончили мы Э-э-э раньше двух других команд. Но это, по словам тренеров, не релевантно :)

    Могу теперь всем говорить, что у нас не чик-чик и в продакшен, а KANBAN. Даже справка есть.