По мере того, как мир становился все более быстрым, клиенты стали требовать быстрой разработки программных продуктов для удовлетворения меняющихся потребностей их бизнеса. Именно тогда методы разработки ПО RUP и Waterfall были признаны недостаточными и была внедрена методология Agile. Гибкая разработка программного обеспечения фокусируется на производстве качественных программных продуктов с использованием итеративной разработки и доставки.
Scrum — один из наиболее широко используемых фреймворков в Agile-разработке. Цель Scrum — как можно быстрее предоставить готовые к рынку продукты. Scrum определяет приоритеты функций продукта и предоставляет их сверху вниз в каждой последующей итерации. Рассмотрим процесс подробно.
Как работает скрам?
У Scrum-команды есть три категории; Скрам-мастер, разработчики и владелец продукта (или заказчик). Скрам-мастер отвечает за управление командами и их работу, чтобы убедиться, что процесс идет гладко. Разработчики работают над продуктом, а владелец продукта должен предоставлять требования, расставлять приоритеты функций и координировать усилия команды.
Характеристики продукта, называемые бэклогом продукта, указываются до начала процесса Scrum. В процессе разработки используется Sprints, концепция гибкой разработки программного обеспечения. Спринты — это периоды времени, отведенные на одну итерацию, после которой продаваемый продукт доставляется на рынок.
Скрам-мастер и команда обсуждают и принимают решение о невыполненной работе спринта, т. е. о том, что необходимо сделать в этом конкретном спринте, и о выделенном времени (варьируется от одной недели до одного месяца в зависимости от невыполненной работы). Затем команды начинают проект разработки, задачи распределяются между разными участниками. Все члены команды встречаются с Мастером каждый день; эти ежедневные встречи называются ежедневными скрамами. Прогресс, проблемы и ежедневные цели обсуждаются на ежедневных скрамах.
Спринт заканчивается обзором спринта, владелец продукта проверяет разработанные функции, после чего они выпускаются. Команда выбирает следующую часть бэклога продукта, которая запускает следующий спринт.
Проблемы подхода Scrum
Метод Scrum, как и все в этом мире, не идеален. Он доказал свою эффективность для быстрого развития и удовлетворения клиентов, но сталкивается с некоторыми проблемами. Эти проблемы влияют на эффективность методологии Scrum в долгосрочной перспективе. Здесь мы обсуждаем основные из них.
Неопытные и несколько команд
Переход от методологий разработки старой школы к методу разработки Agile, такому как Scrum, сложен для компаний, которые веками следовали старому подходу. Менеджеры и опытные люди, берущие на себя роль Scrum Master, продолжают донимать разработчиков, как они привыкли. Микроуправление отрицательно сказывается на производительности команды в Scrum.
Скрам стал подходящим для опытных разработчиков, которые знают и любят работать быстро. Это не оставляет места для неопытных. Кроме того, люди, которые лучше всего работают в одиночку, обычно лучше подходят для Scrum. Конечно, на ежедневных скрамах обсуждаются проблемы, но задача должна быть выполнена в заданное ограниченное время самим человеком.
Скрам-мастеру довольно сложно управлять несколькими распределенными командами. Поскольку это требует большой работы и координации между всеми командами. Scrum обычно полезен для небольших команд. Что также вызывает проблемы с масштабированием для компаний, использующих Scrum для целей разработки.
Непрактичный бэклог спринта и разделение времени
Вся ответственность за управление и надзор за разработкой продукта лежит исключительно на скрам-мастере. Естественно, он должен быть очень опытным и полностью осведомленным о проекте и правилах Scrum. Команды с неопытным скрам-мастером с меньшей вероятностью добьются успеха благодаря методу скрама.
Разделение бэклога может стать проблемой для скрам-мастера и команды, если владелец продолжает добавлять функциональность в спринт или проект. Существует опасность того, что процесс Scrum затянется, что может привести к сокращению ресурсов. Это также может еще больше снизить качество программного обеспечения, как обсуждается в следующем пункте. Поэтому необходимо собрать все требования в начале процесса. К сожалению, у Scrum нет определенной политики в отношении этого.
Время, отведенное на спринт, играет очень важную роль в производительности команды. Скрам-мастеру необходимо хорошо знать разработку, чтобы он знал, какие функции потребуют больше времени, чем другие, и поэтому мог правильно распределять время.
Снижение качества кода и программного обеспечения
Процесс Scrum фокусируется на разработке, и, несмотря на наличие правил, касающихся ясности и оптимизации кода, разработчики склонны игнорировать качество кода. Изменение кода и методов для добавления новых функций в следующих инкрементах еще больше снижает ясность кода.
Вот почему способность программного обеспечения вносить изменения и обрабатывать ошибки уменьшается с каждым новым выпуском. Увольнение члена команды в какой-то момент разработки может еще больше ухудшить ситуацию. Если процесс будет продолжаться слишком долго, программный продукт может стать практически неизменяемым. Затем требуется много усилий, чтобы сначала упростить и оптимизировать существующий код, что также может быть невозможно на данном этапе.
Отсутствие отладки и тестирования
Из-за необходимости быстрой доставки продукта на рынок больше всего страдает надежность продукта, которая также является наиболее важным фактором его успеха. Тщательное тестирование должно проводиться после каждого спринта, чтобы гарантировать качество продукта.
В методологии Scrum отсутствуют фиксированные правила и политики в отношении управления рисками и обеспечения качества. Организации не утруждают себя наймом отдельной группы тестирования, а разработчики часто игнорируют этот важный шаг. Даже когда тестирование завершено, оно остается на последний день, и изменить код в это время становится довольно сложно.
Хотя в Scrum вводятся различные схемы для правильной отладки, такие как парное программирование. Это может помочь не только в отладке, но и в повышении качества кода. Но разработчики Scrum все еще должны внедрить строгие правила, прежде чем Scrum можно будет использовать для крупномасштабных продуктов.
Причины этих проблем
Видно, что эти проблемы возникают из-за самого метода Scrum, а не последователей Scrum. Ниже приведены две основные причины:
Идеалистический подход
Методология Scrum вообще непрактична. Предполагается, что команды самоуправляются, а все разработчики очень опытны. Многие реальные проблемы не учитываются при использовании этого фреймворка. Небольшое препятствие может сильно помешать продвижению продукта. На самом деле Scrum нужно еще многому научиться, чтобы гарантировать качество продукции.
Неясная методология
Скрам практически ничего не говорит о многих проблемах, возникающих при разработке в реальном мире. Процесс слишком динамичный и был разработан для быстрой разработки, а не для качественной разработки.
По моему скромному мнению, пришло время, когда Agile-процессы разработки, включая Scrum, созреют. Однако Scrum нужно правильно регулировать и нужно учитывать уже возникшие проблемы. Четкие правила и шаги должны быть записаны, чтобы метод Scrum стал по-настоящему практичным.
автор Техрим Фаруки из bktronics.com
