Так все же: Scrum или Kanban?
Когда-то в разработке применяли каскадную модель: это когда все этапы расписаны заранее, а каждый новый зависит от результатов предыдущего. Потом случился большой взрыв во вселенной методологий разработки и появилась идеология Agile. А вместе с ней Scrum, Kanban и другие фреймворки.
Как Agile победил каскадную модель
До появления методологии Agile в разработке ПО использовали каскадную модель, или “водопад”. Ее суть заключается в строгой последовательность циклов: определение требований, проектирование, написание кода и так далее. Изначально эту модель применяли в промышленном производстве и строительстве, где внезапное внесение изменений на одном из этапов влекло за собой большие финансовые расходы. Упорядоченность была продиктована рабочим процессом.
Каскадная модель оказалась не лучшим вариантом для IT индустрии. Для создания софта нужен другой подход: готовность к изменениям и умение оперативно переключаться на новые задачи. Разработчики быстро поняли, что нужно избавляться от бюрократии. Так, в 90-х начали появляться легкие методы разработки ПО (RAD, Crystal Clear, XP и другие).
В 2001 году был написан манифест Agile, в котором сформулировано 12 принципов гибкой методологии разработки. Этот документ — не точная инструкция, а идеология, пришедшая на смену старым неповоротливым методикам. Принципы, суть которых это изменения, динамика и гибкость, оказались настолько востребованными, что большинство IT компаний (включая Google и Amazon) перешло на Agile.
Одни из самых популярных Agile-методологий — это Scrum и Kanban. Чем они хороши и в каких проектах будут наиболее уместны?
Scrum
В методологии Scrum работа выполняется во время спринтов — циклов длиной в две или три недели. Разработчики сами ставят себе задачи перед началом спринта: оценивают, сколько времени у них уйдет на каждую и выставляют соответствующее количество “единиц сложности”, story points. Это необходимо, чтобы грамотно спланировать работу на спринт, ведь если он начался, задачи уже не меняют (если что-то не успели — переносят в следующий спринт). В конце каждого спринта — релиз и обсуждение проделанной работы.
Спринты позволяют регулярно выпускать рабочие версии продукта. Каждая версия получает ряд исправлений и улучшений, а пользователи видят, в каком направлении развивается проект. Такой подход к релизам перекликается с концепцией минимально жизнеспособного продукта. Она тесно связана с одним из принципов Agile: “Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.”
Kanban
В Kanban нет спринтов: когда разработчик заканчивает одну задачу, он просто переключается на следующую. Этот процесс визуализирован: на kanban-доске карточка с завершенным заданием перемещается из колонки “в работе” в колонку “выполнено”. Поскольку новые задачи можно добавлять постоянно, Kanban позволяет команде часто менять вектор развития. Если в Scrum корректируют приоритеты при планировании спринта, то в Kanban это можно делать хоть каждый день.
Отсутствие списка задач, которые нужно выполнить до конца спринта, предоставляет больше опций для релиза. Кто-то выпускает новую версию по графику раз в две недели, по аналогии со Scrum. Кто-то готовит релиз, как только наберется достаточное количество карточек в колонке “выполнено”. Иногда приходится релизить продукт под определенное требование клиента, то есть когда завершена нужная задача.
Как выбрать?
И Scrum, и Kanban признают изменчивость продукта, но одна из практик предоставляет больше свободы в плане смены приоритетов. Нужно разобраться, в какой ситуации это будет преимуществом, а в какой — источником неразберихи.
Так, для начальных этапов разработки часто выбирают Scrum, как более структурированный подход к Agile. Перед началом спринта определяются задачи, что позволяет понять, в каком состоянии продукт будет через пару недель. Закончили спринт — выпустили новую версию продукта. Все по графику.
Когда софт уже доступен пользователям и начинает приходить обратная связь, на помощь приходит Kanban. Он заточен на работу с множеством задач, выполнение которых может (и будет) происходить в непредсказуемой последовательности. Клиенту важен определенный функционал? Как только задача реализована, состоится релиз. График — на усмотрение команды. А можно и вовсе без него.
Манифест Agile тогда и сейчас
Важно помнить, что манифест Agile — это не инструкция, где пошагово описано, как следует создавать софт. Это идеология, в основе которой лежат изменения и гибкость, свойственные разработке. Авторы манифеста хотели показать, что можно и нужно уходить от бюрократии.
Со временем принципы были реализованы в методологиях. Появилась упорядоченность и правила, по которым выстраивается работа. Независимо от того, какую практику вы будете применять, помните о первом правиле манифеста: люди и взаимодействие важнее процессов и инструментов.
