Какой ваш язык программирования?

Я использовал Scrum с самого начала своей карьеры. Работе с этим фреймворком я обучился ещё в колледже, где он рассматривался как наилучший вариант для управления разработкой ПО. В самом же начале работы я любил всё, связанное с ним: ежедневные собрания, планирование, ретроспективы, спринты и т.д. В конце концов, я применял то, чему учился.

Спустя несколько лет я начал замечать одну вещь: в последние дни спринта все спешили завершить всё, что наработали за последние две недели, чтобы избежать переносов, которые зачастую несут необоснованные риски.

Почему? Разве некоторые задания не могли подождать ещё недельку? Неужели было так важно отправить все их до выходных? На самом деле нет. Мы делали это, потому что “переносы — это плохо.”

Scrum недостаточно гибок

Я пришёл к заключению, что Scrum делает слишком большое ударение на процессе или просто люди уделяют этому слишком много внимания:

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

Стало очевидно, что Scrum нас уже не направлял, а ограничивал.

Учитывая все перечисленные пункты, команды начали чувствовать негодование, которое сказывалось на качестве работы. Люди больше беспокоились об отправке материала в срок, чем о его надлежащем качестве. В итоге мы начали искать другие гибкие фреймворки, подходящие под наш метод работы. И нашли Kanban.

Что такое Kanban?

Kanban — это фреймворк для управления рабочим процессом, который впервые был представлен компанией Toyota Production System ещё в 40-х годах. На этот раз в Toyota использовали визуальную доску с тремя столбцами: Requested (предложенные), In Progress (в работе), Done (выполнено). Этот фреймворк позволял Toyota более успешно распределять ресурсы, когда в производственной линии возникало узкое место. Когда же люди заметили возможные выгоды от его использования, Kanban был принят на вооружение и в техиндустрии.

Scrum против Kanban

В последние годы между Scrum и Kanban происходит борьба за звание наиболее гибкого фреймворка. Несмотря на то, что в данный момент Scrum является фреймворком №1 в этом отношении, Kanban постепенно становится всё более распространённым. Но как же сравнить эти два фреймворка?

Если взять за основу Scrum:

В Kanban нет повторяющихся временных рамок (спринтов).
Kanban не требует оценки истории.
В Kanban нет принципа обязательств. Задачи добавляются в поток, только когда требуется их выполнение.
Kanban обеспечивает несколько метрик для измерения времени, проводимого историей на доске.
Kanban не требуется Scrum Master (что и так очевидно).

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

Всё дело в метриках

Вы не можете измерить успех (или его недостаток) без метрик для анализа прогресса.

Метрики Scrum

В Scrum используются следующие метрики и графики:

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

На деле же эти метрики не очень-то помогают улучшить рабочий процесс.

Производительность не измеряет скорость выполнения. Она просто подсчитывает количество очков законченных историй. Если на реализацию истории в итоге уйдёт больше времени, чем планировалось, то эта метрика полностью утратит своё значение.

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

Графику выполнения работ лично я никогда не уделял особого внимания главным образом потому, что он зачастую выглядел так:

Почему такое происходит? Предположим, что перед вами пустая доска, и вы начинаете, к примеру, три параллельных истории. Эти истории будут скорее всего двигаться вперёд одновременно, поэтому в итоге вы увидите подобные массивные провалы графика. Более того, если тестированием всех историй будет заниматься один тестировщик, то вы неизбежно получите узкое место в рабочем процессе.

Метрики Kanban

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

Выработка (throughput): число историй, завершённых в течение данного отрезка времени.
Время цикла (cycle time): число дней, требующихся для завершения истории с момента её начала. Здесь используются доверительные интервалы. Наиболее распространённым является доверие на 85%.
Кумулятивная диаграмма потока (Cumulative flow diagram): даёт визуальное представление перемещения историй по доске.

Плагин ActionableAgile для Jira предоставляет все эти метрики “из коробки”. Вы можете изучать метрики вашей команды, используя то же ПО, что и для управления своей работой.

Мы адаптировали его под свою команду

Чистый Kanban не требует выполнения нескольких действий, необходимых в Scrum. Тем не менее эти действия можно включить в процесс в случае объективной пользы для работы.

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

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

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

Оценивание истории помогает убедиться, что у всех сформировано единое понимание того, что в этой истории должно быть сделано. Если кто-либо поставит 8, а другие — 3, станет ясно, что требуется дополнительное обсуждение. Кто-то может высказаться по поводу проблемы, о которой другие не знают или наоборот может оказаться, что кто-то добавляет излишнюю работу, которая в этой истории рассматриваться не должна.

Оценка стимулирует обсуждение. Когда оно происходит, становится понятно, что не у всех есть чёткое понимание необходимых к выполнению задач.

Также часто бывает, что вся команда ставит высокую оценку (как правило, выше 8), что означает неуверенность. Получается, что либо нужно слишком многое проделать, либо задача имеет высокую степень сложности, что вызывает у сотрудников неудобства. В данном случае лучшим вариантом будет разделить историю на более мелкие с более явными заданиями.

Заключение

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

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

Перевод статьи

Поделиться статьей:

Вернуться к статьям