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