Айтишник из Британии с 20-летним опытом работы написал на Medium, что в последнее время методология Agile стала настолько популярной, что начала противоречить сама себе. По его мнению, многие команды разработчиков утверждают, что работают по Agile, но на деле отказываются от его основных принципов. Bubble спросил у project менеджеров, действительно ли это так.
Разработчик из Британии Бен Хоскин в IT уже двадцать два года. Он начинал с техподдержки и Java-разработки, а последние семь лет занимает позицию Solution Architect. В своем блоге на Medium он поделился наблюдением: Agile-проекты превратились в проекты Waterfall со спринтами и потеряли всю гибкость. Вот основные поинты его текста:
- Agile завоевал мир и стал настолько популярным, что клиенты требуют вести проекты по Agile независимо от того, подходит ли методология проекту — получается «Agile ради Agile».
- При этом из проектов ушли ретроспективы и гибкость, они не попадают в производство быстро, но ожидается, что все будет согласно дедлайнам. Автономии у команд нет.
- Поэтому теперешний Agile больше похож на Waterfall-проекты с предварительными требованиями, фиксированными сроками, спринтами и двумя демоверсиями в неделю.
- Этот дополнительный уровень управления и совещаний замедляет разработку, потому что у команд остается на нее меньше времени. А сохраненное, благодаря удаленной работе время, тратится на собраниях.
Bubble спросил у РМов и разработчика, прав ли Хоскин.
Виктория Пивоварчик, project manager WannaPlay
— Как подход Agile никогда не работал у меня идеально, но отдельные практики приживаются прекрасно, отменять их не собираюсь, это приносит профит текущему проекту. Я работаю в продуктовой компании по разработке игр и я миксую подходы, потому что именно это приносит мне результат. Где-то Agile может не работать — не нужно насильно его использовать, чтобы быть в тренде.
Не нужно привязываться и говорить модные слова: «Мы работаем по Agile, вчера рефлексировали на ретро, завтра пойдем планить в попугаях». Лучше говорить: «Наша команда работает в отличном темпе, мы поставляем результат, наши коммуникации налажены, процессы прозрачны, никто не выгорает, заказчик доволен».
«Дополнительный уровень управления и совещаний замедляет разработку» — это не всегда так. Пример из моей практики: общий проект с единой целью, команда из семнадцати человек — тут не обойтись без обсуждений. Мы как-то взяли крупную задачу в работу, но не обсудили ее. В итоге потратили очень много времени на решение конфликтов, когда смержили все вместе.
У меня gamedev, в котором люди горят идеей конкретной игры, так что без митингов и play сессий никак: нужно давать людям возможность предлагать продуктовые решения. Возможно, в аутсорс проектах обсуждения и планерки можно минимизировать, так как там решения по продукту принимает все равно заказчик, и вы на это меньше влияете.
Agile-практики настроены на ценность людей и командные мероприятия (ретро, планинг, дейлики). Это все про прозрачность, а прозрачность уменьшает шанс фейла проекта.
Алексей Мурзич, project manager
— Действительно есть такая ситуация: ряд компаний внедряют в Waterfall спринты и дейлики и утверждают, что у них Agile. Особенно иронично, когда некоторые компании с подобными гибридами пользуются спринтами как инструментом для уменьшения гибкости на уровне «Извините, баг пофиксим через три недели, у нас уже есть план на этот спринт». Но дело не в командах, в первую очередь гибкий подход должен быть интересен заказчику. Если нужно дать четкое ТЗ и получить результат, внедрение Agile не имеет смысла.
Чтобы Agile был эффективен, заказчик должен не только постоянно участвовать в проекте, но ещё и на постоянной основе грузить свой штат аналитиков и отслеживать все интересующие его изменения на рынке.
Каждая компания и команда сама решает, какие конкретно церемонии и совещания от Agile ей внедрить в Waterfall. Дейлики, например, прекрасно работают с каскадной методологией, в то же время использование ретро, если заказчик не принимает активного участия в проекте, по меньшей мере бесполезно.
Артем, senior frontend engineer, работал с 2018 до 2021 в Wargaming
— Ну ерунда [на Meduim] написана, это зависит от проекта. В аутсорс компаниях зачастую пихают Agile, потому что это удобно, в маленьких конторах и геймдеве тоже, потому нужна гибкость. [Agile не противоречит сам себе], потому что может включать в себя любые практики, так как это гибкая разработка. Из плюсов: быстрая разработка, быстрая доставка, легко подстраиваться под требования, customer first, высокая связность команды. Минусы: собрания, каша, когда в один спринт пихают все подряд (к примеру, элементы из противоречащих друг другу методологий), плохие процессы, когда спринт затягивается, плохая работа менеджеров.
Waterfall используется в основном в проектах с высоким риском — это медицина, военная инженерия, космо-штуки. Либо же на legacy-проектах. В простом коммерческом программировании [Waterfall] обычно не встречается из-за невозможности подстроиться под моментально меняющийся рынок.
Елизавета Шошина, Scrum Master SoftSwiss
— Я думаю, что гибрид — это естественный этап проектов, который приходит при масштабировании.
Цитатой: Это не плохо, так как беспрерывно делать ценные инкременты и быть постоянно в контакте с клиентом затратно, это требует большого труда обеих сторон. Однако важно оставлять основные традиции, такие как — ретро, гибкость, быстрота поставки и атомарность команд.
Удаленная работа усложняет один из основных принципов Agile — постоянное взаимодействие (внутри команды и между командой и клиентом), и здесь появляются миты. Изначально в них нет ничего плохого, если они не занимают половину рабочего времени команды. Если их становится много — скорее всего, это сигнал, что команда слишком большая и ее пора разделить на более мелкие. Предварительные требования не противоречат Agile, но дают больше понимания, что предстоит делать. Такую работу легче планировать. Сроки — это логичное ожидание от клиента, так как разработка продукта зачастую включает еще работу маркетинга и продвижения, которые тоже занимают время, и срок «когда получится, тогда и будет» уже не работает. Плана на спринт или на релиз (зависит от выбора фреймворка) достаточно, если клиент и команда кооперируются в соблюдении целей. Ретро дает возможность организовать обратную связь в нужное русло, оценить состояние команды, проекта, увидеть, где есть узкие места, поэтому оно нужно.
Agile (и любого фреймворка в рамках него) часто недостаточно для проектов outsource и добавляется Waterfall. Это не критично, нужно корректировать процессы на проекте, выбирать принципы, которые будут отзываться команде и клиенту и работать основываясь на этом.
Agile не противоречит своим принципам, обычно им противоречит управление. Нельзя одновременно бежать во всех направлениях, собираться на совещания по паре раз на дню, планировать много фич на краткосрок и при этом иметь эффективную команду. Agile выстраивается на людях, на крутых специалистах, которые получают идею или концепцию и могут сделать классный продукт. Но если начнется микроменеджмент — весь их креатив и гибкость уйдут, и это будет просто аутсорсинг, работающий по конкретному списку задач с конкретными результатами.
Я предпочитаю гибрид, но исходя из проекта. Чаще всего работаю с Scrum+Kanban, Waterfall+Scrum. Клиенты чаще просят Agile или Scrum, однако за пару спринтов большинство клиентов устает от необходимости определять бэклог будущего спринта, непонимания сроков релиза и вилки бюджета, и это превращается в Waterfall+Scrum.
Илья Федотенко, project manager 7tech
— Я думаю, что проблема повсеместной популярности Agile действительно имеет место. Поднимать знамя гибкого подхода к проектам — сейчас тренд, и многие компании пытаются внедрять некоторые артефакты Scrum, Kanban или Lean без изменения общей парадигмы работы компании. Например, продолжают заключать контракты с фиксированной стоимостью и функционалом, с обязательствами по объему документации, обязательным роадмэпом и т. д.
Многие компании используют гибридную методологию, которая развернута классической стороной (контракт, план-график, документация) к заказчику и гибкой стороной (спринты, канбан-доски, ретро) к команде разработки.
Естественно, такую систему нельзя назвать работающей по Agile, т. к., напомню, базовые принципы этого подхода:
- люди важнее процессов,
- продукт важнее документации,
- отношения с заказчиком важнее контрактов,
- готовность к изменениям важнее плана.
То есть, многие компании не внедряют Agile, а пользуются только некоторыми его атрибутами. Таким образом, я бы не говорил, что гибкие методологии противоречат сами себе. Просто в реальности их используют только частично, хоть и провозглашают обратное.
Очевидно, что полноценный Agile возможен, наверное, только в продуктовой разработке с не очень большой численностью сотрудников и маленькой текучкой.
В такой конфигурации он может работать максимально эффективно, и явно более предпочтителен, чем классика. Тут его плюсы (способность к быстрым изменениям, скорость, восприимчивость к обратной связи) выходят на первый план, а минусы («размытость» результата, низкая предсказуемость срока) не критичны.
В традиционной заказной разработке же, более важны плюсы waterfall-подхода (четкий результат в предсказуемый срок, зафиксированный бюджет), а минусы (неповоротливость, долгий цикл доставки) вторичны.
В своей карьере PM я сталкивался с разными проектами — в некоторых была возможность применить полноценный Agile, во многих был более уместен Waterfall. Но чаще всего, было удобнее использовать тот самый гибрид, пользоваться инструментами из разных методологий в рамках одного проекта. Считаю, что хороший PM должен уметь грамотно управлять стандартами, и не позволять стандартам управлять собой.
