По данным
17-го ежегодного отчета о статусе Agile за 2023 год от компании digital.ai, 71% проектов используются Agile-методологии. И это неудивительно, ведь применение технологии Agile позволяет сократить стоимость продукта и выпускать функциональность, соответствующую требованиям рынка.
Самый популярный Agile-фреймворк для команд среднего размера (7-9 человек) – это Scrum.
Этот фреймворк имеет подробное «Руководство по Скраму», но на практике некоторые компании внедряют его с ошибками. Сегодня поговорим о самых распространенных ошибках в процессах, устранение которых поможет команде работать более эффективно и улучшит качество продукта.
Недостаточная вовлеченность scrum-мастера
Задача Scrum-мастера на проекте часто заключается в ведении Scrum-митингов и контроле за закрытием спринтов.
Если же следовать Scrum-руководству, роль Scrum-мастера гораздо шире. Он отвечает за то, чтобы команда понимала свои задачи, была эффективной и самоорганизованной.
Но самое главное – Scrum-мастер устраняет проблемы, которые мешают команде разработки делать свою работу.
Если этого не происходит, разработчики отвлекаются на поиск дизайнера или бизнес-аналитика, чтобы уточнить требования, а тестировщики идут к DevOps-команде для возобновления работы тестового окружения. Время, которое могло уйти на задачи из спринта, уходит на дополнительное общение. Из-за этого команда может или не закрыть спринт вовремя, или закрыть его без должного тестирования, с плохо поддерживающимся кодом.
Чтобы решить эту проблему, важно понимать роль Scrum-мастера в команде, искать на эту должность человека, способного эффективно решать поставленные задачи, а также собирать обратную связь от команды по его работе.
Фокус на спринтах и стори-поинтах вместо продукта и его качества
Главный результат, который предоставляет команда разработки и тестирования, – это стабильный продукт, выпущенный вовремя. Если с качества продукта фокус сместится на закрытие стори-поинтов и спринта, разработчики под давлением сроков могут начать спешить, что может привести к ухудшению качества кода. А тестировщикам может не хватить времени, чтобы внимательно протестировать новую функциональность. В таком случае в релиз попадет продукт с дефектами, код которого будет сложно поддерживать, а команда будет находиться в стрессе.
Чтобы этого избежать, надо донести до всех участников процесса ожидаемый результат.
Команда должна думать не только о закрытии спринта и стори-поинтов, но и о выполнении цели спринта – вовремя выпустить функциональность, которая соответствует требованиям и стандартам качества.
Отсутствие тесного взаимодействия с владельцем продукта
Основная роль владельца продукта в Scrum-процессах – постановка задач и их приоритизация. На многих проектах владелец продукта занимается только этим, что отдаляет его от команды. Невовлеченность в жизнь команды ведет к недопониманию, отсутствию дополнительных вопросов – и результату, отличному от ожидаемого.
Если вовлекать владельца продукта в ежедневные Scrum-митинги, команда разработки и тестирования сможет вовремя решать вопросы вместе с ним, а сам владелец продукта лучше поймет статус проекта и раньше отследит недопонимание в требованиях.
Неэффективные ретроспективы или их отсутствие
Ретроспектива – важная часть Scrum-процесса, позволяющая команде поднять проблемы в работе и найти для них решения. Эта встреча инициируется Scrum-мастером в конце спринта. На встрече каждый участник команды рассказывает о проблемах, с которыми он столкнулся, а после команда составляет план действий, как эти проблемы решить и не допустить их появления в будущем.
Случается, что ретроспективу недооценивают и не проводят вообще или проводят неправильно. Например, команда определяет проблемы, но не находит решения или не реализует их. Из-за этого страдает качество продукта, поскольку проблемы команды мешают ей работать с максимальной пользой.
Когда проблемы подняты, но не решены, падает мотивация команды участвовать в этой встрече – появляется ощущение, что ретроспектива бесполезна.
Чтобы этого избежать, составляйте обязательный план по решению всех проблем – от плохого интернета до неполных требований.
Фиксируйте его в доступном для команды месте и отмечайте, какие проблемы были решены и как.
Отсутствие широкого понимания продукта
Частой проблемой Scrum является узкое видение задач. Например, у команды разработки в представлении есть только 2-недельный спринт и задачи в нем, но нет глобального понимания продукта и направления его развития. С одной стороны, это хорошо и помогает фокусироваться на текущих задачах, но с другой – мешает выбирать верные подходы к своей работе.
Рассмотрим еще пример. В текущем спринте разрабатывается форма регистрации в одном сервисе, но в будущем планируется запустить еще 10 сервисов с похожим интерфейсом.
Если разработчик знает, что количество сервисов будет расти, он создаст универсальную форму, принимающую в качестве параметров поля и типы данных, и сэкономит время в будущем. Если же перед ним стоит задача только из текущего спринта, он создаст обычную страницу, которую потом придется дублировать и расширять.
Чтобы вся команда понимала продукт более широко, проводите такие встречи, как уточнение бэклога продукта.
Уточнение бэклога (backlog refinement) – встреча, на которой Scrum-команда удаляет неактуальные пользовательские истории и добавляет новые, переоценивает приоритеты задач.
Во-первых, уточнение бэклога помогает сохранять требования актуальными, а во-вторых, дает команде возможность еще раз взглянуть на планы по развитию продукта и задать возникшие вопросы.
Как улучшить качество продукта в рамках Agile
Улучшить Scrum можно с помощью
команды тестирования. Тестировщики тесно общаются с разработчиками на ежедневной основе и могут решить непонятные вопросы в требованиях. Также команда тестирования оценивает продукт с точки зрения качества. QA-специалисты могут выявить проблемы в обеспечении качества и предложить их решение на ретроспективе.
Несколько советов, чтобы тестирование в сочетании с Agile было более эффективным:
- Добавьте в проект тестирование требований. Команда по тестированию найдет несоответствия в требованиях или недостаточно детальное описание пользовательских историй до того, как начнется разработка. Исправление несоответствий и уточнение деталей на ранних этапах поможет избежать лишних затрат времени в спринте и работы, которую придется переделывать.
- Отдавайте продукт на тестирование несколько раз за время спринта. Тестировщики найдут ошибки в реализации до того, как они распространятся на другие части продукта. Кроме того, команда разработки не будет получать на исправление большое количество дефектов в последний день спринта. Если это не предотвратить, исправление ошибок в коде будет поспешным, и возникнут новые дефекты.
Подведем итог
Мы рассмотрели основные ошибки в использовании Scrum, устранив которые вы сможете добиться более быстрого и качественного результата.
Чтобы получить максимальную выгоду от использования Scrum при разработке ПО, необходимо обеспечить тесное взаимодействие внутри команды, понимание важности Scrum-активностей и направленность усилий всей команды на достижение главной цели — выпустить стабильный и качественный продукт в срок.
