fbpx

Agile: 5 плюсов и 5 минусов

Agile – это гибкий подход к разработке, методика, которую применяют в менеджменте для управления командой. Годом появления считается 2001 год, когда был выпущен «Манифест гибкой разработки программного обеспечения». Однако по существу, Agile является собирательным названием большого количества различных методик и подходов к управлению, в том числе и тех, которые появились задолго до Agile, в XX веке. SCRUM, XP, Crystal Clear и многие другие появились еще в 90-х годах и были основой для создания «Манифеста», который сформулировал 12 базовых принципов Agile.

Присоединяйся к школе HRPR в сетях

Минусы

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

Постоянная коммуникация. Один из подходов в Agile говорит о том, что если работа в команде строится по «маленьким кусочкам», то проект сдается быстрее. Это как работа на конвейере, где собирается продукт: один сделал маленькое дело – передал коллеге – занялся следующим маленьким делом – коллега вернул тебе на доработку – ты отвлекся и вернулся к задаче – отдал задачу и вернулся к следующей – снова получил возврат для доработки… Это может не только раздражать, но и тратить ресурс на постоянное переключение от задачи к задаче. Такой подход требует большого количества коммуникаций между сотрудниками, что некоторых интровертов весьма истощает. Отсюда вытекают и некоторые другие недовольства, связанные с инфраструктурой офиса: офисы открытой планировки, где нельзя уединиться и царит постоянный гул, невозможность уделить продолжительное время и внимание инженерной задаче (не забываем, что написание кода – это инженерная разработка), короткие рабочие итерации, в которых ощущение хаоса каждый день и постоянной сменяемости событий может довести человека до депрессии и понизить мотивацию.

Иллюзия о том, что ты на что-то влияешь. Agile часто хвалят именно за то, что во время еженедельных встреч команда сама решает, что им сделать в первую очередь, а какие «фичи» оставить в бэк-логе. Это выглядит привлекательно по сравнению с традиционными «вертикальными» моделями менеджмента, когда руководитель «спускает» задачи команды, не особо прислушиваясь к мнению более опытных людей. На практике же такие встречи часто называют тратой времени, потому что при выстраивании горизонтальных связей много времени тратится на разговоры, а не на дело. И при этом не позволяет инженерам никак влиять на происходящее событие. Побеждают те, у кого лучше всего развиты softskills, а большинство инженеров либо говорит недостаточно убедительно, либо предпочитают отмолчаться. Такие встречи носят, скорее психотерапевтический эффект: мол, мы же все решили, что будем делать вот это и в таком порядке. Возмутиться уже не получится. А выход за пределы установленных сроком по скорости готовности и фичам будет считаться нарушением данного обещания (ведь в конце митинга все высказывают согласие с установленным регламентом работы). В этом плане многие инженеры-соотечественники со светлой надеждой смотрят на Кремниеву долину в ожидании, когда до нас дойдут их методология построения инженерной компании, которая гласит: оставьте разработку инженерам, а сами занимайтесь бизнесом. Грядет тренд к выводу разработки максимально на аутсорс, мы его еще прочувствуем.

Пилим «фичи» или развиваем продукт? В Agile эти две установки считаются идентичными. Но многие инженеры уже почувствовали, что это несправедливо. Scrum и SPRINT как самые популярные подходы к управлению команды регламентируют развитие продукта как постоянное совершенствование. Это значит, что раз в итерацию на базе пользовательских интервью составляется список «фич», т.е. доработок, которые нужно внести в продукт, чтобы он стал лучше. Однако развитие продукта должно фокусироваться не только на интересах пользовательской аудитории. Существует множество других подходов к развитию продукта, которые в Agile-управлении игнорируют. Происходит это скорее по незнанию, чем специально. И хотя методология руководствуется принципом сужать продукт до интересов отдельной касты пользователей, время от времени стоит обращаться к другим методикам развития продукта. Это очень оздоровит и команду (смена образа мышления, восприятия продукта и деятельности в принципе), и бизнес-показатели.

Фокус на мелком – слепота в глобальных проблемах. Вы уже читали выше про принцип работы по конвейеру и фокусировку на мелких задачах. Такой подход вызывает «тоннельное» восприятие горизонта событий и снижает творческую активность команды. Простыми словами: делаем А, В и С, а что там будет дальше – никто не знает и стимула думать про это нет. Возможно, кому-то даже нравилось бы работать в таких условиях, однако в глобальном плане это вызывает трудности, которые в режиме Agile воспринимаются как сильный стрессовый фактор. Мелкие проблемы и нерешенные задачи (см. первый пункт) накапливаются, как снежный ком. Внимание получают мелкие и старые задачи, а объемные и новые откладываются под предлогом: сделаю сначала то, что нужно доделать, а потом уже возьмусь за большое. Это вызывает не только стопор в общем развитии продукта, но и быструю утомляемость команды, снижение мотивации, нежелание браться за новые задачи и принимать творческие вызовы.

Повышенная тревога и психологическая уязвимость команды. Вынести психологический дискомфорт в отдельный пункт стоит уже потому, что мы много говорили об этом в пунктах выше и приводили частные примеры ситуаций. Добавим здесь еще несколько принципов Agile, из-за которых команда разработки может чувствовать себя уязвимо. Многие инженеры жалуются на то, что за ними постоянно следят. Большое количество тикетов, трекеров, запись рабочего времени и прочее – это по сути постоянная слежка, под которой находятся сотрудники. Проблема даже не в жесткой самодисциплине, которую приходится развивать (это мы не относим к негативным факторам), но в перманентном чувстве тревоги, которое нельзя контролировать, ведь оно относится к непроизвольным реакциям организма. Тревога – это стресс, а стресс – это выброс гормонов. Постоянный стресс может привести к гормональному дисбалансу и, банально, к физическому истощению и болезням. Это относится только к наиболее восприимчивым людям, психологически чувствительным к стрессу и эмоциональным типам характера. Однако исключать этот фактор было бы безответственно.

Плюсы

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

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

Высокая скорость реагирования на мелкие проблемы. Имея большой и красивый план на будущее, легко впадаешь во фрустрацию из-за мелких и неприятных трудностей. Кажется, что проект готов к сдаче, и вдруг оказывается, что заказчик хочет что-то «мелкое» поменять, а инженеру приходится переписывать из-за этого половину кода. Благодаря большому количеству командных встреч, постоянному обновлению рабочей доски (Jira наиболее распространена), поддержке и контролю друг за другом, команда успевает выявить мелкие проблемы и отреагировать на них почти моментально. Это тормозит проект в целом, но все же не так сильно, так если бы работа всей команды встала, если бы где-то в первой трети полотна кода пришлось последовательно изменять команды.

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

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

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

В школе HRPR мы готовим вас к поиску самых необычных айтишников

Вы узнаете и про то как искать питонщиков, на которых сейчас ажиотаж, и c++, которых найти практически невозможно

07

СЕНТЯБРЯ 2021

Стартует группа HRPR. 125 часов занятий и подготовка вашего резюме для поиска работы в IT

Последнее из блога

Где вам удобнее общаться?

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

Телефон: +375 29 706 35 79, почта: hi@skademy.by

Или выберите удобный мессенджер: