Блог a1qa

О тестировании и качестве ПО

5 ошибок при внедрении Agile, которые влияют на качество программного продукта

По данным 13-го ежегодного отчета о статусе Agile за 2019 год от компании CollabNet VersionOne, на 97% проектов используются Agile-методологии.

И это неудивительно, ведь Agile позволяет сократить стоимость продукта и выпускать функциональность, соответствующую требованиям рынка.

Самый популярный Agile-фреймворк для команд среднего размера (7-9 человек) – это Scrum.

Этот фреймворк имеет подробное «Руководство по Скраму», но на практике некоторые компании внедряют его с ошибками. Сегодня поговорим о самых распространенных ошибках в процессах, устранение которых поможет команде работать более эффективно и улучшит качество продукта.

Ошибка 1: Недостаточная вовлеченность Scrum-мастера

Роль Scrum-мастера на проекте часто заключается в ведении Scrum-митингов и контроле за закрытием спринтов.

Если же следовать Scrum-руководству, роль Scrum-мастера гораздо шире. Он отвечает за то, чтобы команда понимала свои задачи, была эффективной и самоорганизованной.

Но самое главное – Scrum-мастер устраняет проблемы, которые мешают команде разработки делать свою работу.

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

Чтобы решить эту проблему, важно понимать роль Scrum-мастера в команде, искать на эту должность человека, способного эффективно решать поставленные задачи, а также собирать обратную связь от команды по его работе.

Ошибка 2: Фокус на спринтах и стори-поинтах вместо продукта и его качества

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

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

Команда должна думать не только о закрытии спринта и стори-поинтов, но и о выполнении цели спринта – вовремя выпустить функциональность, которая соответствует требованиям и стандартам качества.

Ошибка 3: Отсутствие тесного взаимодействия с владельцем продукта

Основная роль владельца продукта в Scrum-процессах – постановка задач и их приоритизация. На многих проектах владелец продукта занимается только этим, что отдаляет его от команды. Невовлеченность в жизнь команды ведет к недопониманию, отсутствию дополнительных вопросов – и результату, отличному от ожидаемого.

Если вовлекать владельца продукта в ежедневные Scrum-митинги, команда разработки и тестирования сможет вовремя решать вопросы вместе с ним, а сам владелец продукта лучше поймет статус проекта и раньше отследит недопонимание в требованиях.

Ошибка 4: Неэффективные ретроспективы или их отсутствие

Ретроспектива – важная часть Scrum-процесса, позволяющая команде поднять проблемы в работе и найти для них решения. Эта встреча инициируется Scrum-мастером в конце спринта. На встрече каждый участник команды рассказывает о проблемах, с которыми он столкнулся, а после команда составляет план действий, как эти проблемы решить и не допустить их появления в будущем.

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

Когда проблемы подняты, но не решены, падает мотивация команды участвовать в этой встрече – появляется ощущение, что ретроспектива бесполезна.

Чтобы этого избежать, составляйте обязательный план по решению всех проблем – от плохого интернета до неполных требований.

Фиксируйте его в доступном для команды месте и отмечайте, какие проблемы были решены и как.

Ошибка 5: Отсутствие широкого понимания продукта

Частой проблемой Scrum является узкое видение задач. Например, у команды разработки в представлении есть только 2-недельный спринт и задачи в нем, но нет глобального понимания продукта и направления его развития. С одной стороны, это хорошо и помогает фокусироваться на текущих задачах, но с другой – мешает выбирать верные подходы к своей работе.

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

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

Чтобы вся команда понимала продукт более широко, проводите такие встречи, как уточнение бэклога продукта.

Уточнение бэклога (backlog refinement) – встреча, на которой Scrum-команда удаляет неактуальные пользовательские истории и добавляет новые, переоценивает приоритеты задач.

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

Как улучшить качество продукта в рамках Agile

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

Несколько советов, чтобы тестирование в сочетании с Agile было более эффективным:

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

Подведем итог

Мы рассмотрели основные ошибки в использовании Scrum, устранив которые вы сможете добиться более быстрого и качественного результата.

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

Заказать консультацию по тестированию можно здесь.

Поделиться статьей: