Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.
Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее. Часто те, кто так поступали, брали на себя ненужный риск.
Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».
Скрам — это уже не совсем «гибкая методология разработки»
Я пришёл к выводу о том, что в скрам слишком большое внимание уделяется процессу работы. Или, как минимум, люди обращают на это слишком много внимания, что выражается в следующем:
- Завершение работы над пользовательской историей в последний день спринта — это нормально. Но завершение работы в следующий понедельник — это уже «перенос задачи».
- Если нужно сделать что-то незапланированное (исправить ошибку, решить проблему в продакшне и так далее), это повлияет на заранее расписанное время разработчика, и, как следствие, приведёт к тому, что на очередном совещании он не сможет сообщить об успешном исполнении взятых на себя обязательств.
- Для оценки успешности разработчика чаще всего применяют такую метрику, как соотношение обязательств, которые он на себя взял, к объёму выполненных задач. Сравниваются пользовательские истории, которые обработчик обязался выполнить в начале спринта, с историями, завершёнными в конце (я даже не пытаюсь говорить о том, какие проблемы может принести такой подход).
В результате оказалось, что скрам больше не помогал нам идти к цели. Этот метод управления проектами теперь нас ограничивал.
Учитывая всё вышесказанное, я могу отметить, что члены моей команды начали чувствовать недовольство от происходящего. Это повлияло на качество того, что мы создавали. Программисты больше заботились о том, чтобы уложиться в срок, чем о том, чтобы достичь нужного уровня качества.
В этот момент мы начали поиск других возможностей организации работы, поиск другого agile-фреймворка, который лучше подошёл бы к используемым нами методам работы.
Тогда мы нашли Kanban (канбан).
Что такое канбан?
Канбан — это метод управления производством, который появился в компании Toyota в 1950-х годах. В то время в Toyota использовали доску с тремя колонками: «Запланировано», «В работе», «Завершено». Данный фреймворк позволял Toyota более эффективно выделять ресурсы в ситуациях, когда где-то на производственной линии возникали узкие места.
Затем, когда стало ясно, что применение канбан способно повысить скорость разработки ПО, канбан перенесли и в сферу технологий.
Сравнение фреймворков скрам и канбан
В последние годы скрам и канбан сражаются за место ведущего agile-фреймворка. Несмотря на то, что скрам занимает первое место, канбан постепенно распространяется всё сильнее. А что если их сравнить?
Если взять за основу скрам и сравнить его с канбан, то получится следующее:
- В канбан нет итераций, ограниченных по времени (спринтов).
- Канбан не требует оценки сроков выполнения работ по пользовательским историям.
- В канбан нет концепции «обязательств». К выполнению задач приступают тогда, когда это нужно.
- В канбан имеется несколько метрик, которые позволяют оценивать на доске время, необходимое на выполнение работ по пользовательской истории.
- В канбан (очевидно) не нужен скрам-мастер.
Более подробное сравнение скрам и канбан можно найти здесь.
Канбан даёт команде разработчиков достаточно высокий уровень гибкости. Пользовательские истории, в сравнении со скрам, выполняются в более свободной манере. Но свобода — это ответственность. Несмотря на то, что канбан не требует того, что разработчики каждые две недели берут на себя какие-то обязательства, применение этого метода управления разработкой предусматривает собственные средства контроля за работой. Это, например, такие метрики, как время цикла и пропускная способность системы.
Всё дело в метриках
Нельзя оценить эффективность (или неэффективность) работы, не имея специализированных метрик. Рассмотрим метрики, применяемые в скрам и в канбан.
▍Метрики скрам
При применении скрам используются следующие метрики и графики:
- Скорость команды (velocity). Количество этапов пользовательской истории, завершённых во время каждого спринта.
- Соотношение обязательств, которые взял на себя разработчик, к объёму выполненных задач (commitment vs. done). Процент пользовательских историй, по которым были взяты обязательства, и работы по которым были успешно завершены.
- Диаграмма сгорания задач (Burndown Chart). Диаграмма, которая визуализирует ход работ по пользовательским историям во время конкретного спринта.
Эти метрики вряд ли помогут вам улучшить рабочий процесс.
«Скорость» не измеряет скорость выпуска готовых подсистем продукта. Эта метрика оценивает лишь количество выполненных этапов работы, имеющих отношение к некоей пользовательской истории. Если на работу над историей уходит больше времени, чем было запланировано, эта метрика оказывается бессмысленной.
«Соотношение обязательств, которые взял на себя разработчик, к объёму выполненных задач» вообще не должно рассматриваться как метрика. Эта «метрика» сопоставляет обязательства с результатами. Не стоит и говорить о том, что это может привести к тому, что люди будут закрывать и повторно открывать задачи только для того, чтобы они были бы «выполнены».
«Диаграмма сгорания задач» — это то, на что лично я никогда не обращал особого внимания. В основном это так из-за того, что подобные диаграммы часто выглядят примерно так, как показано ниже.
Диаграмма сгорания задач
Почему это так? Предположим, вы начинаете с пустой доски, и приступаете к параллельной работе, например, с тремя пользовательскими историями. Работы по этим историям, вероятно, будут вестись с одинаковой скоростью — именно поэтому на диаграмме сгорания задач можно видеть такие мощные нисходящие движения. Более того, если в команде имеется всего один тестировщик, который должен тестировать результаты выполнения работ по всем задачам, то он окажется узким местом команды.
▍Метрики канбан
Я полагаю, что метрики — это самая важная из сильных сторон канбан. В канбан имеется множество различных метрик, которые помогают лучше понять то, что происходит с командой. Например:
- Пропускная способность команды (throughput). Количество пользовательских историй, работы по которым завершены в заданный промежуток времени.
- Время цикла (cycle time). Число дней, которое уходит на завершение работ по истории с момента начала работы. Здесь используются такие показатели, как уровни доверия. Чаще всего применяют уровень доверия 85%.
- Кумулятивная диаграмма потока (cumulative flow diagram). Такая диаграмма позволяет визуализировать процесс решения задач по пользовательским историям. Выглядеть эта диаграмма должна примерно так, как показано ниже.
Кумулятивная диаграмма потока
Существует плагин для Jira, который позволяет пользоваться всеми этими метриками. Это — ActionableAgile for Jira — Agile Metrics. Он помогает исследовать метрики, имеющие отношение к деятельности команды, используя ту же платформу, что используется для управления работой.
Адаптация канбан
Применение «чистого» канбан не предусматривает выполнение некоторых операций, обязательных при применении скрам. Но этот метод управления проектами достаточно гибок и позволяет, если подобные действия кажутся полезными, добавлять их в рабочий процесс.
Ретроспективные совещания — это один из самых важных видов совещаний. Именно на таких совещаниях члены команды могут поговорить о том, чего удалось достичь, о том, что прошло не совсем удачно, о том, что можно улучшить. Ретроспективное совещание — это спокойное мероприятие, на котором можно рассказать о своих проблемах и поздравить с успехом тех, кто отлично справился со своими задачами.
Несмотря на то, что ретроспективные совещания не являются необходимыми в канбан (в скрам они проводятся в конце каждого спринта), мы сочли их ценными мероприятиями и не стали от них отказываться. На самом деле, мы даже начали проводить их еженедельно, а не каждые две недели, как раньше. Это позволило нам быстрее реагировать на возникновение каких-либо проблем. Мы, кроме того, используем эти совещания для того чтобы анализировать метрики команды и проверять рабочие процессы на наличие проблем и узких мест.
Мы сохранили и ещё один элемент из наших скрам-времён, который необязательно применять при использовании канбан. Речь идёт об оценке времени, необходимого для работы над пользовательской историей. Это делается в ходе уточнения задач, которые входят в историю. В скрам подобные оценки используются для того чтобы лучше понять то, что «поместится» в спринт. Можно подумать, что, так как в канбан нет спринтов, то оценка историй тут не нужна. Но, на самом деле, это не так.
Оценка сроков, необходимых на выполнение пользовательской истории помогает обеспечить то, что все члены команды одинаково видят объём задач, который необходимо решить в ходе работы над историей. Если кто-то даёт истории оценку в 8 баллов, а кто-то — в 3, очевидно то, что нужно продолжить обсуждение этого вопроса. Кто-то может, оценивая сроки, учитывать какие-то проблемы, о которых другие не знают. В чьём-то понимании в объём работ по пользовательской истории должно входить что-то такое, что другие в таком качестве не рассматривают.
Собственно говоря, всё это подталкивает членов команды к дискуссиям.
Когда происходит нечто подобное, становится очевидным то, что не у всех есть чёткое понимание того, какой объём работ нужно выполнить по некоей пользовательской истории.
Ещё один часто встречающийся сценарий выглядит так: вся команда даёт трудоёмкости истории довольно высокую оценку (обычно это — всё, что больше 8 баллов). Это говорит о неуверенности. Это значит, что либо речь идёт о большом объёме работы, либо — о решении очень сложных задач, что вызывает у членов команды неприятные ощущения. В подобном случае лучше всего будет разделить пользовательскую историю на несколько более мелких историй и чётче определить цели работ.
Итоги
Скрам навсегда останется в наших сердцах как первая широко распространившаяся agile-методология. Но по мере того, как компании переходят к схемам непрерывного развёртывания решений, использование спринтов, ограниченных по времени, больше не имеет смысла.
Всегда будут существовать особые проекты, в которых скрам способен отлично себя показать. Правда, учитывая то, что в компаниях всё чаще пользуются agile-методологиями, канбан постепенно выйдет на первое место, сместив с него скрам.
Что больше подходит вам? Скрам или канбан?
Автор: ru_vds
