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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы