Waterfall, Agile, Scrumban — плюсы и минусы, или Что не так с эталонными подходами к разработке11.01.2024 12:31

Сегодня в методах разработки ПО исключения не подтверждают, а скорее заменяют правила. Чистокровный Аgile днем с огнем не сыщешь ни в одной компании.Зато плодятся разные гибридные методологии. Некоторые проджекты задаются совсем уж крамольным вопросом: зачем нужны эталонные системы, если на практике все работают по-разному?

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

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

Ни Waterfall, ни Agile, ни любая другая существующая методология разработки ПО — не истина в последней инстанции, а всего лишь отправная точка. Это как Open Source: каждый берет нужное и допиливает под свои задачи. И не важно, что порой методологии работают не совсем правильно или вовсе используются не по назначению. Периодически в таких экспериментах даже рождаются удачные гибридные подходы. Однако если не знаешь, что именно менять и дорабатывать, — велик риск сделать еще хуже и сломать рабочие механизмы. Так что взглянем на сильные и слабые стороны распространенных методологий разработки.

Критиковать классику — это классика. Waterfall

Традиционный Waterfall не пнул разве что ленивый, но за годы существования водопадная модель стала основой многих жизненных циклов разработки программного обеспечения. У нее есть сильные стороны.

Достоинства Waterfall

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

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

Во-вторых, водопад подталкивает тщательно оценивать и прорабатывать риски прямо «на берегу». Можно сказать, что у Waterfall девиз чеховского человека в футляре: как бы чего не вышло. Зачастую госкомпании и консервативные организации признают только такую методологию, а сами слова «Аgile», «Scrum» или «Kanban» для многих под строжайшим запретом. Так что хотите побеждать в тендерах и получать госконтракты — готовьтесь к «прыжкам в водопад».

Недостатки Waterfall

Главная претензия большинства специалистов к водопадной модели — заложенное в ее дизайн неприятие изменений и корректив «на лету». Работа по Waterfall означает нудное проектирование толстого ТЗ, которое потом все проклинают, растянутая на месяцы, а иногда и годы (бывает и такое) реализация. Этапы работы выполняются строго поочередно — их нельзя менять местами. Если команда следует Waterfall, то она не может вернуться назад и внести корректировки на ходу — ей придется мириться с допущенными ошибками до конца шестой фазы и лишь затем планировать исправления. 

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

Agile — когда одного манифеста мало

Не удивительно, что так много разработчиков предпочитают различные Agile-методологии, но у них свои фичи и баги.

Достоинства Agile-методологий

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

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

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

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

Недостатки Agile в целом  

Особенность Agile-методологий в том, что с ними уже нельзя спрятаться в футляре из формально зафиксированных требований. Как правило, нет четкого ТЗ и оценки рисков на старте: нужно быстрее «ввязаться в драку», и только затем проясняются перспективы проекта.

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

Даже если разработчики прониклись гибкостью Agile, не факт, что их поймут в других подразделениях. Например, отдел кадров крупной компании может по-прежнему требовать строгого соблюдения штатного расписания и четкого следования определенным ролям.

Препятствием к внедрению Agile становятся и чисто методологические трудности. Манифест Agile на то и манифест: использовать его как пошаговую инструкцию проблематично. Закреплены лишь основные постулаты, но не способы их реализации. 

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

Играет злую шутку и дробление процесса на короткие итерации. Бывает, что руководители используют терминологию Scrum, но в действительности просто заставляют команды брать на себя неоправданные объемы задач в сжатые сроки. Разработка становится настоящим бегом в колесе, а сотрудники выгорают. 

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

Другая слабая сторона Agile — отсутствие адекватных способов оценки результативности отдельных специалистов. В итоге вклад каждого разработчика либо никак не измеряется, либо рассчитывается, исходя из субъективных и оторванных от реальности KPI. Это снижает мотивацию исполнителей и качество работы.

Еще один существенный минус — в наиболее распространенных Agile-подходах, например, Scrum и Kanban, нет высокоуровневого управления требованиями. Заказчики или инвесторы постоянно дают фидбек, корректируют пожелания к ПО. Но в масштабных проектах такие запросы могут выдвигать сразу несколько заинтересованных сторон. Кроме того, менеджерам часто бывает сложно разбить высокоуровневые требования до размеров, позволяющих адекватно оценить трудозатраты. В таких условиях необходимы связующее звено и процессы, которые позволят оценить и «подружить» требования между собой, отсеять лишнее, выстроить коммуникацию со всеми ЛПР-ами. 

Гибкие методологии критикуют и за низкий уровень долгосрочного планирования. Типичные бэклоги в рамках Agile описывают лишь небольшие временные отрезки, например, двухнедельные спринты. Зачастую Agile-методологии не охватывают цели и ориентиры проекта, и об этом стоит подробно поговорить в отдельной статье.

Недостатки Kanban 

Простота изменений — это, конечно, хорошо, но до некого предела. Иногда Kanban все же не хватает ограничителей. Скажем, заказчик ПО только заикнулся, что ему нужна та или иная дополнительная функциональность, и на доске мгновенно появляется новая карточка. Задача в работе, и вот уже специалисты бьются над тем, как «изобразить каменный цветок». А уже через неделю выясняется, что заказчик передумал…

Вспоминается давний случай из практики. Однажды разрабатывали мобильное приложение — криптовалютный кошелек. У заказчика было несколько ключевых требований к функциональности: чат для пользователей, система обработки ERC20-транзакций.

Первым делом реализовали прием и отправку BTC и ETH, потом занялись чатом… Должны были доделать его примерно через полтора месяца, но спустя три недели заказчик поменял приоритеты в пользу обработки платежей и функции обмена. Наработки по чату отправились в морозильник, где лежат до сих пор. Время по большому счету было потрачено впустую.

Помимо фальстартов, Kanban плох тем, что рассеивает внимание и подталкивает разработчиков перескакивать между задачами.  

Недостатки Scrum 

Scrum часто критикуют за перекос в сторону руководителей и менеджеров, которые держат в своих руках все рычаги воздействия на ход проекта. Конечно, грамотный PM или тимлид должен прислушиваться к команде, но на деле так происходит не всегда. При неумелом руководстве спринты превращаются в формальность и обязанность «штамповать» определенный объем работы каждую неделю-две даже тогда, когда спешить некуда.

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

Многие scrum-команды из мира заказной разработки грешат частой ротацией составов: далеко не все участники проходят проект «от и до». Следовательно, разработчики не видят результатов и не делают выводов. Порой анализировать ошибки, вскрывшиеся на поздних этапах проекта, просто некому, так как виновники уже работают над чем-то другим.

Продолжая командную тематику, отмечу, что Scrum ориентирован на работу группами по 6 — 9 специалистов. Если участников существенно больше, методология начинает сбоить

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

Вызывают проблемы и ограничения ролевой модели Scrum. Владелец продукта, скрам-мастер и разработчик — вот и все доступные роли. Абстрактные «разработчики»‎ сливаются в единую массу и методологически не привязаны к задачам или областям. Это может вызывать путаницу, когда непонятны степень вовлеченности и сфера ответственности конкретного специалиста.

Упрекают Scrum и за перебор с совещаниями и установочными мероприятиями. Стендапы, спринт-ревью, сторипоинты и другие активности могут отнимать столько времени, что непосредственно разработкой заниматься некогда.

Направо пойдешь… или Как выбрать подходящую базовую методологию

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

Предпосылки к применению WaterFall

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

Вторая предпосылка — низкая динамичность и консервативность рынка, для которого создается продукт. Наглядный пример — бухгалтерия с ее учетными системами, такими же классическими, как симфоническая музыка или костюм-тройка. Большая часть подобного ПО разработана еще при царе Горохе, и заменяют его крайне медленно и аккуратно. Вот где можно и даже нужно перестраховаться по полной программе, на старте просчитать все риски и четко следовать ТЗ.

Предпосылки к применению Agile

Гибкие методологии, напротив, подходят для динамичных отраслей, в которых технический прогресс мчится, как скоростной поезд. Удачный пример — машинное обучение, где идут постоянные исследования. 

Отраслевой фактор актуален для всех гибких подходов, но как выбрать между Kanban и Scrum?

Когда подходит Kanban

Лучше всего он показывает себя для небольших команд и бюджетов. Разбивать на scrum-команды «полтора землекопа» незачем — только запутаете коммуникацию и процессы. Несколько разработчиков, тимлид да проектный менеджер договорятся между собой безо всяких стендапов и спринт-ревью. Кстати, так и получилось в ходе вышеописанной разработки криптокошелька.

Тот пример показателен еще и в плане типа создаваемого ПО. Методики Kanban и Times and Materials оптимальны при реализации небольших разовых проектов для узких сегментов рынка — разработке несложного отраслевого приложения, трекера и т. д. Изменения «на лету» здесь обычное дело, но они не столь глобальные и многочисленные, как при создании корпоративной CRM-системы. Дробить все это на итерации — лишь усложнять себе жизнь. Команде вполне хватит Kanban-доски, чтобы эффективно управлять задачами.

Когда подходит Scrum

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

Допустим, у службы поддержки банковского приложения все время спрашивают, когда появится поддержка новой системы переводов. Становится понятно, что такая фича назрела. Можно смело планировать ее доставку пользователям, назначать дату релиза, делать из этого PR-событие. В таких ситуациях Scrum помогает справиться с растущим объемом изменений на основе фидбека. При помощи спринтов обеспечивается достаточный уровень планирования, чтобы не хвататься за все подряд.

Scrumban: срединный путь

Некоторые управленцы пытаются сгладить шероховатости традиционных методологий при помощи гибридных моделей. Эта тенденция началась с микширования Waterfall и Agile, но потом «селекционеры» отважились на скрещивание гибких подходов. У нас в Magnus Tech довольно высокую эффективность показала система с говорящим названием Scrumban.

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

Таким образом, свобода и гибкость Kanban отчасти уравновешивается правилами Scrum. Разработчики не распыляются между тасками и не берутся за все подряд. При этом в границах спринта можно гибко распределять задачи, корректировать загрузку по ситуации. То, что несложно изменить сразу, тут же идет в графу «открыто» на Kanban-доске и берется в реализацию. Более трудоемкие задачи улетают в следующий спринт. Присутствуют и традиционные стендапы, спринт-ревью и другие установочные встречи, которые помогают лучше координировать действия и дают командообразующий эффект. 

Конечно, здесь свои издержки, ведь, наряду с достоинствами, Scrumban унаследовал и слабые стороны »‎родителей». Поскольку «фривольный» Kanban не заботят такие детали, как размеры команд, участие стейкхолдеров в процессе разработки и распределение ролей, то здесь слово дается Scrum со всеми вышеупомянутыми недостатками. 

К тому же этот гибридный подход крайне чувствителен к любым пробелам  в планировании. Следовательно, PM и аналитикам приходится прикладывать немало усилий по поддержке актуальной roadmap проекта. Только так реально отследить, в какой момент пора браться за ту или иную функциональность в соответствии с заданными стейкхолерами приоритетами. 

Пример roadmap проекта при работе по методологии Scrumban

На всякий случай подчеркну, что «укладывать» функциональности в roadmap следует с осторожностью, учитывая фактическую производительность команд, человеческий фактор (больничные, отпуска и т. п.). Если обратиться к схеме выше, то видно, что иной раз важная функция передается из дизайна в разработку в пределах одного спринта. Но надеяться, что так будет всегда, наивно, ведь обстоятельства могут складываться по-разному.   

Когда подходит Scrumban

Подобный гибридный подход «выстреливает», если у ПО еще немного пользователей, но впереди большой объем работ по функциональности. Другими словами, между MVP и полноценным мажорным релизом — на стадии активной разработки объемного проекта. В начале пути в методологии будет преобладать Kanban, в то время как спринты могут иметь упрощенный вид. Но по мере развития продукта фокус сместится в сторону Scrum, поскольку обратной связи станет больше, а горизонт планирования расширится. Соответственно, гибкость разработки несколько уменьшится, зато появятся гарантии своевременной доставки фич пользователям.

Готовые советы из интернета вам не помогут

Если обобщить вышесказанное, то Kanban лучше подходит для локальных и небольших проектов, Scrum — полноценных продуктов, а Scrumban — проектов, постепенно переходящих в продукты.

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

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

А сейчас давайте обсудим в комментариях, какие методы и подходы вы применяете и что бы в них изменили?

© Habrahabr.ru