Оценка эффективности процесса с помощью карт потока значений
При создании карты потока значенийили VSM она помогает анализировать текущий процесс выпуска. Цель VSM — визуально показать, где в процессе команда создает значение и где есть отходы. Цель состоит в том, чтобы прийти к процессу, который обеспечивает максимальное значение клиенту с минимальными отходами. VSM может помочь определить те области, которые либо не вносят никакого значения, либо фактически сокращают значение продукта.
Давайте посмотрим, как Tailspin показывает себя.
Мара, которая является новой для команды, собирается создать VSM, чтобы помочь ей понять существующий процесс. С помощью VSM она получит представление о том, где команда вписывается в модель зрелости DevOps. Как оказалось, более зрелые команды обычно выпускаются быстрее, с большей уверенностью и с меньшим количеством ошибок, чем менее зрелые команды.
Мара знает, что она еще не понимает все, так что она собирается создать быструю VSM на доске в комнате собраний. Там будут некоторые пробелы и неотвеченные вопросы, но это нормально. Это начало. Когда она сделает всё, что в её силах, она поделится этим с командой. VSM дает всем общий отправной пункт для выявления первых шагов по улучшению того, как Tailspin разрабатывает и освобождает свои веб-сайты.
Давайте рассмотрим ее карту.
Общие сведения о текущем процессе
Мара собирает команду в комнате для совещаний, чтобы представить свой VSM.
Мара: VSM помогает нам измерять, где процесс приносит пользу клиенту и где он только тратит время, не создавая никакой ценности. Наша карта начинается в левом верхнем углу с функциональной спецификацией программного обеспечения. Давайте рассмотрим только одну функцию, чтобы узнать, как она перемещается через текущий цикл выпуска.
Некоторые люди закатывают глаза, но Мара продолжает.
Процессы разработки
Создание новой функции в настоящее время начинается с создания метки в системе контроля версий 
. У нас есть один человек, который может создавать метки, и это Энди. Мы запрашиваем метку по электронной почте. Мы используем централизованную систему управления версиями, поэтому Энди ожидает, пока все существующие коды не будут проверены и стабильны, прежде чем он создает метку. После создания метки мы получаем сообщение электронной почты о том, что мы можем начать работу. Этот процесс занимает до трех дней и не имеет значения для клиента. Вещи без значения для клиента должны занять как можно меньше времени.
Кодирование функции занимает около четырех дней для одного человека после получения доступа ко всем файлам, которые нам нужны 
. Мы должны находиться в корпоративной сети, чтобы получить доступ к системе управления версиями. Это время имеет значение для клиента. Они хотят эту функцию.
Тестовые процессы
После принятия решения о том, что у нас стабильная сборка, мы обновим электронную таблицу, чтобы сообщить Амите, что сборка готова к тестированию и где найти ее 
. Она узнает об этом через два дня.
Амита вручную проверяет сборку 
. Этот процесс становится дольше по мере роста базы кода. На данный момент, скажем, три дня. Затем она отправляет сообщения Энди с отчетами об ошибках. Тестирование не добавляет значение, но необходимо.
Затем Энди должен уделить время, чтобы разобрать ошибки и назначить задачи . Энди потребуется еще три дня, чтобы разобраться в проблемах и передать их нужным разработчикам.
Процессы операций
Когда Амита утверждает сборку, она передает её Тиму. Тиму необходимо развернуть эту сборку на предварительно созданных серверах для более подробного тестирования. Часто предварительные серверы не синхронизируются с последними исправлениями и обновлениями, необходимыми для запуска веб-сайта. Тиму требуется около двух дней, чтобы развернуть приложение на предпроизводственную среду и провести некоторые тесты. Опять же, хотя развертывание в предпроизводственную среду не добавляет ценности, оно необходимо 
.
После того, как сборка готова для производства, руководство должно одобрить выпуск, прежде чем его можно будет развернуть. Утверждение происходит на собрании. На согласование встречи руководства и рассмотрение релиза требуется четыре дня.
В конечном итоге Тим развертывает функцию, и функция доходит до клиента в правом верхнем углу VSM. Если конфигурация рабочего сервера перемещена таким образом, что она не синхронизирована с предварительной версией, Тим сначала должен обновить его, что занимает один день 
.
Вычисление метрик ценности клиента
Теперь мы можем посмотреть на ключевые метрики производительности и оценить, как мы справляемся.
Общее время выполнения — это время, необходимое для того, чтобы функция дошла до клиента. Здесь общее время составляет 22 дня. время обработки — это время, затраченное на функцию, которая имеет значение для клиента. Здесь время процесса включает четыре дня для написания кода плюс один день для развертывания функции, что дает в общей сложности пять дней.
Коэффициент активности — это время процесса, разделенное на общее время выполнения:
$${Коэффициент\ активности\ =\ }{\dfrac{Время\ обработки}{Общее\ время\ выполнения}}$$
Это наша эффективность . Умножайте эффективность на 100, чтобы получить процент. Результат превышает 0% и обычно меньше 100%. Более высокий процент указывает на более высокую эффективность.
Замените наши номера, и мы получаем:
$${Коэффициент\ активности\ =\ }{\dfrac{5\ дней}{22\ дней}}{\ =\ .23}$$
Умножьте результат на 100, и вы получаете 23%.
Как видите, у нас много места для улучшения. Затрачивание 22 дней на разработку одной функции — это слишком долго.
Тим: Так как это помогает нам?
Куда мы идем отсюда?
Мара: Это помогает увидеть, где мы сейчас, чтобы определить области, где есть отходы. Мы хотим свести к минимуму время, которое мы тратим, что не имеет значения для клиента. Я считаю, что мы действительно можем повысить нашу эффективность, приняв подход DevOps. Во-первых, мы можем автоматизировать многие из этих шагов, что определенно сокращает время на выполнение.
Я не предлагаю нам отказаться от наших текущих процессов, но я думаю, что мы можем работать над более эффективным процессом по небольшим шагам, не нарушая то, что у нас уже существует.
Давайте рассмотрим лишь несколько областей, где мы можем улучшить.
Энди: Мы можем также начать в начале. Мне потребуется много времени, чтобы получить метку в коде, чтобы мы могли начать новую функцию. Я должен обойти разработчиков и попросить их загрузить свои изменения, чтобы мы могли создать и протестировать. Если вы сможете понять, как это ускорить, я буду внимательно слушать.
Кроме того, я заметил, что у вас нет времени, выделенного непосредственно на сборку. Это занимает полдня прямо сейчас. Было бы приятно увидеть, что время улучшается.
Амита: И разработчики не всегда обновляют электронную таблицу, чтобы сообщить мне, что есть новая сборка, которая нуждается в тестировании. Это позволит сэкономить время, если был какой-то способ убедиться, что часть будет выполнена.
Мара: Отлично! Я думаю, Что DevOps может помочь нам со всеми этими проблемами.
Энди: у нас нет времени на изменение процесса. Ты слышала Ирвина? / Ты слышал Ирвина? Мы здесь в кризисном режиме!
Мара: Я понимаю. На данный момент давайте делаем то, что мы всегда делаем. Но мы все можем подумать о нашей части процесса и о том, как мы можем улучшить. Мы можем начать вносить небольшие изменения параллельно с текущими процессами. Мы можем увидеть, помогает ли DevOps нам, не нарушая то, что у нас есть. Я сохраню эту карту и показатели производительности. Если мы все же внедрим методики Azure DevOps, то сможем пересмотреть цифры. Может быть, мы можем обновить VSM в какой-то момент.