Самое главное – поток

Самое главное – поток

Главное вовсе не инструменты и процессы. Правильно? Конечно, главное – это люди и взаимодействие. Ну, опять это бла-бла-бла, подумали вы. Что за люди? Какое взаимодействие? Под всеми разговорами, принципами и концепциями в Agile, Scrum, Lean и всех остальных подходах есть какой-то глубокий смысл. Иногда он неявный, иногда явный (Канбан много говорит о нем). Что это?

Самое главное – это поток. Я не говорю о какой-то псевдомистической философии или о новомодной ахинее: я говорю о практической философии. Поток работ, идей, программного обеспечения, ценности, знаний. Люди, которые действительно понимают Lean и Agile, знают, что в основе всего лежит поток. Небольшие размеры партии и малое время цикла обеспечивают хороший поток.

Виктор Вальчук
Критическая цепь. Управление проектами по ТОС

Цель любого проекта: «Завершить проект в срок, в полном объеме и в рамках выделенного бюджета». Для этого необходима методика, умеющая справляться с возникающей неопределенностью. Метод Критической цепи позволяет эффективно управлять неопределенностью. Использование буфера проекта позволяет вовремя получать информацию о задачах, которые ведут к опозданию проекта и ставят под угрозу его бюджет.

Тренеры: В.В. Вальчук, В.Е. Краснов. Старт: 3 июня 2024.

ПОДРОБНЕЕ

Большинство людей фокусируются на скорости

Типичный «мастер» Agile или Scrum в наши дни обычно сфокусирован на скорости. Но часто скорость не очень хороший показатель. Скорость не поощряет поток, она поощряет его противоположность: захватывающие истории и героизм. Команды решают заняться одной большой историей в 13 «стори пойнтов» вместо трех «3-пойнтовых», потому что так их объем работы выглядит намного лучше. И это может затянуть команды в опасную спираль завышения оценок.

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

Вместо скорости мы должны сфокусироваться на времени цикла и проходе

Время цикла и проход являются более ценными показателями, чем скорость. Время цикла показывает, насколько быстро работа проходит через вашу систему. Часы начинают тикать, когда элемент работы (задача) впервые переходит в состояние «В работе». Они перестают тикать, когда элемент переходит в состояние «Готово».

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

Наилучшие способы сократить время цикла – это использовать небольшие партии, устранить потери, использовать принципы Simple Design и YAGNI (Вам Это Никогда Не Понадобится). Это все хорошие идеи Lean, которые каждый должен использовать повсюду.

Большинство людей фокусируются на разделах «Бэклог» и «В работе»

Многим людям, особенно бизнес-аналитикам и владельцам продуктов, нравится видеть большие бэклоги. Они думают, что большой бэклог является признаком здорового продукта. Им нравится помещать истории в бэклог продукта, им нравится перемещать истории внутри бэклога, и им нравятся встречи и дискуссии о содержании бэклога. Проблема в том, что это неправильно.

Бэклог продукта представляет собой вид запасов, а запасы – один из видов потерь. Я не думаю, что мы обязательно должны впасть в другую крайность и не иметь вообще никакого бэклога (хотя, по-видимому, теперь это «История»). Подход «точно в срок» предпочтительнее: достаточно такого бэклога, чтобы обеспечить вашей команде следующий транш работы.

Другие люди, особенно разработчики и тестировщики, любят фокусироваться на разделе «В работе». Им нравится видеть большие колонки под названием «В разработке» или «В тестировании» и т.п., битком набитых жирными задачами для работы. Они видят в этом признак здоровой системы. Проблема в том, что это не так.

Незавершенная работа (WIP) технически не является одной из страшных потерь Lean (и Lean разработки программного обеспечения), но мы должны попытаться свести ее к минимуму.

В этом и заключается суть Канбана: не выстраивать на доске ряды стикеров и не размещать на них милые аватарки, а минимизировать WIP. Больше WIP означает – больше время цикла, меньше проход и меньше ценность поставки. Кажется, что незавершенная работа выглядит как прогресс в доставке ценности, но это не так. Единственный способ предоставить ценность – переместить все в «Завершено».

Вместо этого мы должны сфокусироваться на разделе «Завершено»

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

Святой Грааль Lean – непрерывный поток единичных изделий. Это состояние, в котором работа разбита на минимально возможные партии, и все движется через систему как можно быстрее. Это полная противоположность традиционному подходу «Водопада» с большими партиями, где работа продвигается медленно, большими партиями, с большим количеством остановок и этапов.

Так как же улучшить поток?

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

Прекратите стартовать и начните финишировать

Лучший способ улучшить поток – это сфокусироваться на завершении активных задач, прежде чем запускать новые. Я отчаиваюсь, когда вижу, что команды постоянно берутся за новую работу до того, как существующие задачи будут закончены. Озвучиваются обычные оправдания: «Мы должны подождать, пока они не исправят программу, и тогда мы сможем все это закрыть». «Я жду ответа от тестеров по этой истории». «UX все еще дорабатывается, поэтому я начну делать что-то еще вместо ожидания».

Это звучит вроде бы разумно, но это не так. Как насчет: «Что я могу сделать, чтобы помочь исправить программу?», «Могу ли я помочь с тестированием этой истории?», «Давайте разобьем эту историю, чтобы я мог работать над задачами, которые не зависят от UX».

Минимальное количество передач

Сокращение количества передач друг другу работ, необходимых данных и числа переключений чрезвычайно важно. В противном случае работа будет регулярно зависать и блокироваться. Это главная причина, по которой Scrum и особенно Scale Scrum рекомендует кросс-функциональные команды: работу не нужно никому передавать.

Параллельная работа

Вместо того, чтобы переносить пользовательские истории через фазы мини-водопада, такие как «Анализ», «Разработка», «Тестирование», попытайтесь распараллелить как можно большую часть работы.

Парное программирование, роение (swarm) и моббинг (mob)

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

Маленький размер партии

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

Встроенное качество

Качество должно быть встроено в процесс, а не пристраиваться в конце как большой этап. Если вы используете разработку через тестирование (TDD – Test Drive Development), вы начинаете тестирование еще до того, как начнете кодировать. Разработка через тестирование, безжалостный рефакторинг (реорганизация и перепроектирование кода), разработка, управляемая поведением, исполняемые спецификации и автоматизированное тестирование – это инструменты и методы, которые можно использовать для повышения качества процесса разработки. Уровень дефектов со временем должен стремительно снижаться до очень небольшого количества.

Резюме

Agile Software Development в значительной степени заимствована из Lean Manufacturing (работы Тома и Мэри Поппендик по Lean Software Development делают это наследие более явным). И на это есть веская причина: Lean фокусируется на сокращении потерь, улучшении и максимизации потока и прохода.

Agile – это путь к истинной гибкости бизнеса и экспоненциальному росту. Не проталкивайте большие тяжелые истории в работу, чтобы хорошо выглядели случайные показатели, а быстро вытягивайте мелкие задачи через простую Lean систему. В этом заключается сила потока.

Блог Leon Tranter

Прорыв

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!


Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.

Давайте обсудим...