Несколько зарисовок…

В своей статье на Hacker Noon, John Cutler рассказывает о базовых понятиях, без которых Agile не будет работать. Оригинал статьи

Пару лет назад я навещал родственника. Мой несчастный кузен (генеральный директор страховой компании) разочаровался в серебряной пуле под названием «Agile». Он говорил что-то вроде:

Это кошмар! Мы полностью изменили свою политику. Мы пригласили консультантов. Мы наняли руководителей проектов. И ничего не сработало! Не произошло никаких изменений. Никакой ответственности. Все, что я получаю, — это оправдания.

Я не помню, как я ответил тогда, но знаю, что сказал бы сейчас. Я бы нарисовал несколько рисунков, даже не упомянув слово Agile. Есть всего несколько основных понятий, о которых мне нужно было бы ему поведать….

1. Эффективность потока

Во-первых, если мы посмотрим на общее время выполнения заказа — период от возникновения идеи до поступления товара/услуги к клиенту — мы заметим, что большая часть времени тратится на «ожидание». Эффективность потока 15% (отношение времени работы к общему периоду выполнения заказа) считается нормальной. Сумасшествие, не так ли? Тем не менее, сейчас мы концентрируемся на том, что (относительно) заметно… на фактическое выполнение работы тратится очень небольшое количество времени. Лучшие компании достигали показателя в 40%. Одним словом, для того, чтобы выполнять заказы быстрее, вам нужно обратить внимание на время ожидания.

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

Кстати в итоге эта карточка после работы над ней была возвращена обратно в очередь.

2. Внеплановая работа и многозадачность

Нередки случаи, когда команды 75 процентов времени уделяют внеплановой работе и на переключение контекста задач. И часто не успевают закрывать свой основной технический долг. Это дополнительные ресурсозатраты, которые при этом никак не отражаются в системе управления задачами. Скорее всего, компания не в восторге от этого (ситуация очень удручающая). Но если проблему игнорировать достаточно долго, она становится печальной реальностью, что и происходит.

Теперь представьте, если команда одновременно выполняет задачи по развитию (новые проекты) и по поддержанию текущей инфраструктуры. Эта команда сразу же превращается в бутылочное горлышко.

Урок: обратите внимание на такие команды в вашей компании. Скорее всего в общих трудозатратах этих команд, количество добавленной ценности в рамках новых проектов теряется на фоне затрат на незапланированную работу (ошибки, поддержка текущей инфраструктуры, помощь другим).

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

Например, в примере выше отчетливо видно, что ошибки составляют не менее 50% от общего количества задач ежемесячно.

3. S, M, и L

Вот забавный трюк – разделите все задачи проекта на крупные, средние и мелкие задачи. И в большинстве случае вы увидите, что между временем выполнения задачи и ее размером практически отсутствует корреляция. Почему так? Потому что помимо фактического времени на выполнение задачи на сроки ее выполнения влияют другие факторы:

  • разрешение зависимостей от других сотрудников/команд;
  • незапланированная работа;
  • переключение контекста в связи с большим количеством одновременно выполняемой работы.

Примечание. Например, на первый взгляд многим Scrum-командам кажется, что сложность задачи коррелирует со временем выполнения (velocity), но на практике оказывается все наоборот.
Вот распределение времени выполнения задач, которые команда оценивала как 8 SP:

А вот распределение времени выполнения задач, оцененных в 1 SP той же командой.

То есть получается, что 85% простых задач (1 SP) закрывается за 15 дней, а 85% сложных задач (8 SP) за 9. То есть на срок выполнения задачи факторы вроде переключения контекста, внешних зависимостей и т.д. влияют сильно больше, чем сложность задачи.

4. Создание ценности

Многие компании уделяют слишком много времени работе с рисками по срокам поставки. И это имеет смысл, если вы работаете на заказ и клиент платит за готовый продукт. В SaaS (программное обеспечение как услуга) мы не получаем оплату при выполнении заказа. Результат проявляется лишь со временем. Я называю это «риском неполучения прибыли» (риск того, что мы не создали добавленную ценность).

Зачастую крупные организации, которые используют Agile, не замечают от этого каких-либо финансовых выгод. Почему? Да, они начинают шагать быстрее, но при этом они не идут ни к принятию правильных продуктовых решений, ни к созданию ценности. Основная задача Agile заключается в снижении рисков. В проектной работе — это риски «нарушения сроков/объемов». В разработке продукта — риски того, что «эта штука, *, не пашет». Основная ошибка руководителей проектов в этом случае в том, что они принимают задачу за готовую с технической точки зрения, в то время как для потребителя ценность не была доставлена!

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

5. Незакрытый технический долг

И наконец, возьмите какую-то хорошо вам известную задачу в качестве примера и попробуйте мысленно пропустить ее через ваш процесс разработки продукта. Окажется, что если не уделять должного внимания автоматизации, упрощению кодовой базы и снижению объема технического долга, время на выполнение этой задачи с каждым годом будет расти. В первый год работы задача могла занять 3 дня, а через 6 лет – 6 недель.

Agile

Это подводит меня к Agile. Agile бесполезен, если он не служит катализатором непрерывного улучшения. Scrum и SAFe бесполезны, если они не служат катализаторами непрерывного улучшения. Почему? Потому что факторы, которые замедляют ваш рост, лишь частично объясняются тем, что вы бегаете, записывая пожелания заказчиков, и делаете демонстрации каждые две недели. Я бы сказал, что эти вещи являются относительно незначительными (по сравнению с постепенным снижением риска).

Чтобы «быть Agile», вам нужно потратить много денег и энергии на:

  • Выполнение работы, которая действительно имеет значение (ценность), затрачивая меньше времени
  • Автоматизацию, конвейер развертывания, флаги функций и т. д. (DevOps)
  • Изменение вашей культуры управления
  • Корректировку методов финансирования инициатив. Переход на постепенное, социально ответственное финансирование, вместо бюджетирования проектов
  • Распределение ресурсов для управления сложностями (регулярный рефакторинг и пересмотр архитектуры)
  • Сопоставление потоков создания ценностей и обработку вашего бизнеса экологией обслуживания
  • Новый взгляд на совместное обслуживание

Серебряной пули не существует.
Вы должны работать.
Остерегайтесь тех, кто говорит иначе.