Эксперименты с Kanban, визуализацией и потоком создания ценности

У тренеров Cleverics есть замечательная возможность ставить эксперименты на людях изучать интересные штуки, наблюдая за слушателями. Разумеется, полезность наблюдений чуть более, чем полностью определяется именно слушателями. Неделю назад мне повезло: на открытую деловую игру "Проект Феникс" собралась исключительная команда. Интеллектуалы с богатым опытом, открытые всему новому — о такой группе тренер может только мечтать.

Помимо мечтаний удалось проследить эволюцию визуализации. Сейчас поясню.

Игра — про DevOps. А эксперты этого модного направления вовсю советуют обязательно проработать как минимум следующие ключевые вещи:

  • поток создания ценности (Value Stream)
  • определение завершения (Definition of Done)
  • ограничение числа задач в работе (WIP Limit)
  • ясную картину загрузки ресурсов и ограничений

Для всего этого очень рекомендуется изобрести некую визуализацию. Далее без лишних слов, но с небольшими комментариями, посмотрим на возможное развитие этого направления.

Итак, для начала набросаем простейший поток создания ценности:

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

Отлично. Однако через некоторое время становится понятно, что релиз — это здорово, но бизнес-пользователи тоже должны что-то поделать (обучить персонал, проверить готовность, поменять свои процедуры, ещё что-то...). Добавляем:

Наверняка можно детализировать и далее, но пока остановимся. Излишне усложнять нам не требуется — задача ровно обратная, чтобы всё было понятно.

Как такой поток наполнить задачами, чтобы было куда их складывать, было видно что сейчас в работе, и что уже завершено? Конечно же, нам нужен канбан. Набросаем минимальный вариант:

У нас появился вход и выход, это классно. Но та часть в середине не очень похожа на нарисованный ранее поток. Совмещаем одно с другим:

Можно начать заполнять задачами, но как понять кто сколько их сможет взять? Необходимо где-то указать ресурсные ограничения:

Уже можно работать. Собственно, работать можно было и раньше, но теперь как-то стало краше и нагляднее.

Однако, стоп! У нас ведь задумана вытягивающая система (Pull System), а это означает, что каждый следующий шаг в потоке сам забирает себе задачи. Откуда же он будет их забирать, если непонятно что на предыдущем этапе завершено, а что нет? Надо добавить ясности:

Можно на этом закончить? Безусловно. Вот только жизнь показывает (и в игре это ощущается достаточно явно), что только часть ресурса мы можем выделить на плановую работу над известными заранее задачами. Мы же не в Agile играем, где главное — выдать продукт поскорее. У нас тут DevOps, нам этот вот "Ops" очень даже важен. Потому неплохо бы понимать есть ли ресурс на неплановые задачи (инциденты, исправление дефектов и подобное), и есть ли эти задачи, и у кого они есть, и успеваем ли решить:

Вроде бы всё. Ан нет! Тестирование в конце работ — это анахронизм, нынче не модно. Качество должно быть встроено (тот самый четырнадцатый принцип Деминга), а обратная связь должна появляться как можно скорее, да при том реализовываться на любом этапе. Потому от блока единого тестирования в середине лучше отказаться, организовав соответствующие области внутри каждого из этапов:

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

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

Очевидно, что рассмотренный вариант — не единственно возможный. Так я ровно с того и начал: у тренеров есть уникальная возможность посмотреть на реальных примерах как и что сделают другие команды, решая аналогичную задачу и осваивая те же приёмы, техники и рекомендации DevOps.

На фото: реальная доска Kanban той самой игры в один из моментов своей эволюции.

 

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

The Phoenix Project Основы DevOps

Новый учебный курс 2017
 

Проект Феникс — DevOps на практике

Новая деловая игра от GamingWorks
 

DevOps: погружение

Новый корпоративный семинар
 

Комментарии и мнения

  1. Андрей

    Спасибо за интересную статью!

    Здесь имеются в виду человеко-часы? - "Можно начать заполнять задачами, но как понять кто сколько их сможет взять" 

    1. Олег Скрынник Автор

      Андрей, хороший вопрос.

      Мне известно два подхода к оценке трудозатрат на задачу и доступного объёма ресурса (это ведь две стороны одной медали, верно?).

      Первый подход — мы стараемся рассчитать доступный ресурс в человеко-часах, затем учесть все дополнительные временные затраты, действуя минимум по двум направлениям:

      1. неизбежное время на планирование, совещания, ретроспективы и прочее

      2. учёт фактической утилизации персонала, которая редко бывает 100%

      Затем в те же единицах, человеко-часах, пытаемся оценить каждую "прилетающую" задачу. Математика поможет сделать остальное, иногда получается хороший результат.

      Второй подход подсказывает Agile. Вводится понятие условной единицы объёма (story point), и все задачи оцениваются относительно друг друга в этих единицах. Заранее определяется шкала, апологеты любят слегка модифицированный ряд Фибоначи (1, 2, 3, 5, 8, 13, 20, 40, 100). Важно, чтобы самая мелкая задача была оценена именно в единицу. Затем задачи распределяются и выполняются, что таким образом даёт нам оценку реальной скорости работы конкретной команды в тех же условных единицах (они называют это velocity). Через несколько итераций и планирование, и оценка доступного ресурса будут точнее. Но всё в тех же попугаях.

       

      1. Владимир Калёнов

        Немного дополню. При наличии данных — уже сделанных задач, принято проводить "калибровку" т.е. оценивать несколько уже сделаных задач в тех же числах Фибоначи. В при оценке не сделаных задач они оцениваются относительно "калибровочной". Практика показывает, что планирование проходит точнее, если за точку привязки мы берем не самую мелкую "задачу на 1", а "среднюю задачу". Такой подход позволяет в дальнейшем, тем же методом "выравнивать попугаи" при наличии нескольких команд. Если концепция "StoryPoint попугаев" смущает, то можно попробовать аналогичный по механике "идеальный час" http://agile.by/2009/03/05/ocenka-chast-1

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28