Что такое гибкая методология
Agile помогает командам разработчиков программного обеспечения быстрее и с меньшими трудностями приносить пользу своим клиентам благодаря поэтапному подходу к разработке проектов и проектированию систем. Agile-команда производит работу управляемыми небольшими шагами, а не ставит все на план запуска «все или ничего».
Внедрение практик Agile в вашей компании дает бесчисленное множество преимуществ. Тот факт, что Agile-методологии имеют высокий уровень внедрения в компаниях, свидетельствует о том, насколько они могут улучшить работу команды при работе над проектом. Несмотря на этот факт, Agile-разработка не лишена своих недостатков, и командам необходимо проявлять осторожность при работе с этой структурой, поскольку это может привести к потере времени и снижению производительности разработчиков.
В этой статье вы узнаете о некоторых недостатках работы в среде разработки Agile и о том, как это может негативно сказаться на способности команды своевременно выполнять Agile-спринты.
1: Ограничения по времени
Управление временем должно быть одним из самых больших недостатков при работе со структурой разработки Agile. Общеизвестно, что если бы у нас было больше времени в жизни, мы могли бы достичь гораздо большего, а время — это единственная вещь в жизни, которую мы обычно никогда не вернем. Это может быть довольно серьезной проблемой для Agile-команд.
Члены команды должны посещать ежедневные стендап-совещания, что может затруднить их рабочий процесс. Кроме того, мышление Agile требует постоянного сотрудничества между разработчиками, тестировщиками, клиентами и другими заинтересованными сторонами. Такой интенсивный уровень взаимодействия может существенно повлиять на навыки тайм-менеджмента членов команды Agile-разработчиков. На протяжении Agile-спринта члены команды должны будут посещать множество других церемоний, которые по сути являются разными встречами.
Эти встречи могут включать планирование спринта, уточнение, ретроспективу, ежедневные скрамы и даже демонстрацию клиента. Не исключено, что церемонии могут занимать полдня, и я сталкивался с этим раньше, работая в различных компаниях. Это полдня встреч, которые, по сути, мешают вам работать над задачами на этот день. Не поймите меня неправильно, встречи могут быть чрезвычайно важными, однако они должны проходить гладко и не занимать слишком много времени в течение дня.
Встречи могут отвлекать, и разработчику очень трудно сосредоточиться на выполнении задачи, когда его постоянно отвлекают и ему приходится переключаться между несколькими делами, происходящими одновременно. Предположительно, в ходе нескольких исследований они обнаружили, что в среднем может потребоваться 23 минуты 15 секунд, чтобы вернуться к задаче, над которой вы работали после того, как отвлеклись.
2: Неясные сводки задач
Еще один важный фактор, который следует учитывать, заключается в том, что иногда описания задач могут быть довольно запутанными и трудными для понимания с первого взгляда. Agile-команды сжимают огромные объемы данных в более короткие пользовательские истории с минимально подробной информацией. Эти пользовательские истории, как правило, используют следующую структуру:
Как (описание пользователя),
Я хочу (функциональность),
Так что (выгоды)
Это может затруднить программисту понимание точных потребностей клиента. Проходя этапы проекта без четко сформулированной стратегии или установленного метода, члены команды могут легко потеряться. Неадекватная документация может привести к тому, что разработчик запутается из-за отсутствия пояснений. В большинстве случаев им потребуется получить дополнительную информацию от человека, написавшего пользовательские истории, потому что именно он напрямую контактирует с клиентами.
Лучшим решением было бы иметь вики или место для документации, связанной с пользовательскими историями, чтобы разработчики, работающие над заявками, имели всю информацию, необходимую им для работы над заданием. Последнее, что кому-то нужно, — это работа, которая была сделана неправильно, что может привести к блокировкам и задержкам во время спринта. Или, в худшем случае, два разработчика работают над разными историями для заявки, которая требует создания одной и той же функциональности, что может привести к дублированию. Каким бы редким это ни казалось, я видел, как это происходит из первых рук.
3. Постоянно меняющиеся требования
Это область, которая может привести к значительному увеличению рабочей нагрузки на команду, что может привести к выгоранию, и члены команды будут перегружены всей дополнительной работой, которую им приходится выполнять. Клиенты часто меняют свое мнение, потому что нет ограничений на количество идей и запросов функций, которые они могут захотеть реализовать. В отрасли это называется «расширением объема», «расширением функций» и «расширением требований».
По сути, он описывает, как проект может меняться на протяжении своего жизненного цикла по мере того, как заказчику требуется все больше и больше функций. Недостатком этого является то, что это может привести к задержкам проекта, препятствиям или перерасходу бюджета, что нежелательно. Команды могут оказаться перегруженными и упустить из виду, какими должны быть их цели, потому что они не уверены, каким из них расставить приоритеты.
То, что начиналось как одиночный выпуск, может стать семью или восемью, отягощая портфель продуктов. Или, в другом случае, скажем, у вас был продукт, который начинался с двух важных функций, а теперь должен иметь семь. Потребности клиента могут измениться в процессе выполнения проекта, что потребует переоценки требований к проекту, что может привести к гибким спринтам, которые могут разорить их бюджет в виде назначенных баллов. Очки историй в сочетании со скоростью спринта служат ориентиром для историй, которые должны быть завершены в предстоящих спринтах. В начале предоставляется оценка, и мастер схватки старается не превышать назначенное общее количество.
4. Долгосрочные проекты плохо работают с Agile
Попытки заставить Agile-разработку работать с долгосрочными проектами обычно заканчиваются неудачей или нежелательными результатами. Весь смысл Agile заключается в создании небольших частей продукта с помощью agile-спринтов. Изменения, скорее всего, произойдут на протяжении Agile-спринта, что хорошо для краткосрочных проектов. Для сравнения, и давайте возьмем в качестве примера производство, если вы строите автомобиль, окончательный дизайн является фиксированным, и изменения не подходят.
Agile-разработка построена на концепции, согласно которой команды вряд ли знают, как будет выглядеть их конечный результат. Или как будет выглядеть следующий этап результатов, становится невозможно точно предвидеть финансовый аспект, временные ресурсы или спецификации, необходимые для начала проекта.
5. Трудно поддерживать максимальную эффективность
Работая в Agile-разработке, команда должна поддерживать высокую производительность, а также сотрудничать с другими членами команды и дополнительными командами, работающими над одними и теми же продуктами. Этого не всегда легко достичь, потому что другие члены команды часто имеют другие обязательства внутри других команд, которые могут истощить ресурсы, доступные для работы над задачами. Таким образом, важно обеспечить, чтобы ваши команды реализовывали кросс-функциональное сотрудничество и общение.
При правильном использовании методология Agile может стать захватывающей и трансформирующей системой. Однако успех требует значительных инвестиций практически от всех, кто связан с проектом, включая ваших клиентов. В одном примере от разработчика может потребоваться работать в других командах над более приоритетными областями, что может сократить ресурсы, доступные другому отряду. Это проблема, потому что разработчики должны быть доступны для утверждения и подготовки продукта к производству. Могут возникать блокираторы, которые могут замедлить спринт, вынуждая переносить билеты на следующий спринт, что может рассматриваться клиентом как задержка.
Последние мысли
Сегодня вы узнали об Agile-разработке и 5 ошибках, которых следует избегать при ее использовании. Agile-разработка действительно может привести ваш бизнес к успеху при правильном использовании. Просто убедитесь, что вы предпринимаете необходимые шаги, чтобы получить максимальную отдачу от Agile-разработки, и ваша команда разработчиков сможет работать на хорошем уровне.
