Снова 🤦 про Agile: 5 скрытых угроз

Если кратно, то Agile ("гибкий" англ.) - это методология разработки.

Спринт — это короткий временной интервал, в течение которого команда выполняет заданный объем работы. Рабочая единица Agile.

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

Методология разработки Agile помогает командам разработчиков программного обеспечения быстрее и с меньшими трудностями доставлять продукт клиентам благодаря поэтапному подходу к разработке проектов и проектированию систем. Функционал доставляется часто "малыми, но рабочими" порциями (фичами), вместо того, чтобы доставлять "все и сразу".

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

Ниже рассмотрим 5 основных ограничений, на которые стоит обратить внимание.

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

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

Совещания могут отвлекать, а разработчику очень трудно сосредоточиться на выполнении задачи, когда его постоянно прерывают и приходится переключать внимание между несколькими вещами, происходящими одновременно. В ходе замеров, ученые выяснили что может потребоваться в среднем 23 минуты и 15 секунд, чтобы вернуться к задаче, от которой вас отвлекли!

Еще одним важным фактором, который следует принять во внимание, является то, что иногда описание задач может быть довольно запутанным и трудным для понимания. Product Manager сжимают огромные объемы бизнес-задач в более короткие истории пользователей (User Story) с минимально подробной информацией. Эти пользовательские истории, как правило, используют следующую структуру:

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

Лучшим решением было бы создать wiki или место для документации, связанное с пользовательскими историями, чтобы разработчики, работающие над тикетами, имели всю необходимую информацию. Последнее, что кому-либо нужно, - это работа, которая была выполнена неправильно. Это может привести к блокировкам и задержкам во время спринта. Или, в худшем случае, два разработчика работают над разными историями для тикета, который требует создания одинаковой функциональности, что может привести к дублированию

Точнее сказать, постоянно меняющиеся требования.

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

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

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

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

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

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

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

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

🖤 Подписывайтесь на мою телегу. Больше кода 🐍 - меньше багов 🪲!

#agile #development #it