Согласно данным отчета the State of Software Testing 2018 Industry, в прошлом году 26% команд выпускали новые версии продукта хотя бы раз в день. При этом 89% из них вели разработку по гибкой методологии.
Почему Agile-подход так популярен? Отличие Agile в том, что он позволяет быстро адаптировать продукт к меняющимся требованиям рынка, повысить мотивацию команды и ответственность за общий результат. А значит, выпустить более качественное ПО.
Как при этом правильно организовать процесс тестирования, особенно если речь идет о больших командах? Как оценить эффективность процессов?
Давайте разбираться.
Для продуктов какой вертикали лучше всего подойдет agile?
Подобная методология Agile может успешно использоваться для программных продуктов любой вертикали, от банкинга до электронной торговли. Однако степень детализации документации будет напрямую зависеть от сферы использования ПО.
Решения из банковской сферы, как правило, характеризуются сложной бизнес-логикой, и цена ошибки может быть очень высока. Поэтому чем детальнее описана документация, тем меньше вероятность возникновения любых проблем с логикой и функциональностью ПО.
Еще один момент связан с тем, что часто документация, описывающая функциональность сложных продуктов, к примеру, из медицинской сферы, должна быть предварительно согласована. Однако не всегда можно полностью согласовать весь документ.
Agile-подход — отличное решение для подобных случаев, ведь он позволяет готовить документацию постепенно и вносить в нее изменения по мере необходимости.
Кроме того, вы сможете быстро подстроиться под любые тенденции рынка. Желая добавить новую функциональность или заменить текущую на более актуальную, вам не придется переписывать всю документацию, а лишь добавить/заменить необходимые части.
Какие разновидности методологии встречаются чаще всего?
Agile – это свод принципов, задающий уникальное идейное направление работы для каждого проекта.
Отсюда и такое разнообразие возможных методов. Однако во многом они похожи и направлены на синхронизацию работы команды и ускорение доставки конечного продукта.
Инженеры компании «Точка качества» в основном задействованы на проектах, где разработка продуктов идет по Scrum/Kanban.
Как определиться с выбором?
Scrum подойдет, если:
- вы можете спланировать работу на определенный промежуток времени;
- у вас есть набор требований хотя бы на два спринта вперед;
- во время спринта вам не придется внезапно выполнять незапланированные задачи.
Что касается Kanban, главное отличие Kanban от Scrum связано с необходимостью оперативно переключиться на задачу, которая не входит в обозначенный заранее план, что приводит к нарушению продолжительности спринтов.
Однако при этом важно, чтобы текущая работа все равно была выполнена. Иначе может появиться дополнительный риск опоздать с выпуском очередной версии ПО из-за переключения на другие задачи и снижения качества кода.
Kanban также отлично подойдет для работы по поддержке уже выпущенного продукта, когда можно быстро устранять появляющиеся проблемы в работе решения с учетом их приоритета.
Но есть и третий вариант – комбинация двух методологий – Scrum-ban. Как он применяется на практике?
Для обеспечения высокого качества ПО можно разрабатывать его по Scrum, а поддержку осуществлять через Kanban, предварительно закладывая на это время для каждой из команд.
Есть ли разница между внедрением agile на проекте с маленькими и большими командами?
Если речь идет о небольшой команде из 3-4 специалистов, то планировать работу в ней можно и не используя подобную методологию.
При среднем размере команды (7-9 человек) Scrum – один из оптимальных вариантов организации работы
выделенной команды на проекте.
Совсем другое дело – планирование для больших команд. Здесь важно продумать действия всех участников спринта так, чтобы каждый специалист на протяжении всего промежутка времени мог выполнять свою работу, а не ждать нужного момента.
Как построить процессы работы для большой команды?
Главное – разумно подойти к организации работы на проекте и сразу начать масштабирование.
Мы рекомендуем обратить внимание на SAFe – фреймворк, помогающий успешно внедрить гибкую методологию для крупных команд (вплоть до 150 человек).
Чтобы эффективно вести такой проект, лучше разбить команду на небольшие группы и регулярно синхронизировать их работу (после каждого спринта).
Такой подход сильно упростит ход проекта. Масштабирование с помощью SAFe-фреймворка поможет вовремя выполнять все задачи каждого спринта.
У компании «Точка качества» подобный опыт есть. В компании работают сертифицированные инженеры, за плечами которых не один год тестирования на проектах с использованием Scrum, Kanban и SAFe.
Специалисты компании «Точка качества» регулярно проходят внутреннее и внешнее практическое обучение в рамках использования гибких методологий на проекте.
Как понять, что выбранный подход работает эффективно?
В подобном вопросе важно отталкиваться как от ожиданий клиента, так и от выбранного метода. Рассмотрим несколько примеров.
Если заказчик уже разрабатывает продукт по Scrum, то для проекта будет характерно частое обновление версий продукта. И здесь за метрику эффективности можно взять частоту выхода новых версий с учетом выбранных критериев качества. Они будут служить маркерами готовности к выпуску этих самых версий.
Если клиент только начинает переходить на Scrum, команде потребуется время, чтобы сработаться по новой модели. Как в этом случае измерить прогресс? Ориентироваться на пропускную способность команды в спринт. При успешно выстроенном процессе она будет расти.
Еще одна метрика для оценки качества разрабатываемого продукта – количество дефектов, найденных в спринте по задачам самого спринта.
Она очень эффективна, когда в создании продукта задействовано сразу несколько команд. При общей сборке этой метрики каждая команда стремится показать лучший результат в спринте.
Также можно выделить метрику, показывающую количество дефектов в уже выпущенном на рынок программном продукте. Это важнейший показатель его качества и эффективности самого процесса тестирования. При этом данная метрика хороша тем, что ее можно использовать независимо от вида методологии разработки на проекте.
Главное при выборе метрики – определиться с параметром, который мы хотим измерить, будь то скорость разработки или качество устранения дефектов, и отслеживать его в динамике.
Как гибкая методология влияет на качество r&d?
Мы с уверенностью можем утверждать, что разработка лишь выигрывает от внедрения гибкой методологии.
Если мы рассмотрим Scrum, то ближе к окончанию спринта QA-команда проводит финальные тесты, чтобы убедиться в том, что новая версия продукта готова к выпуску на рынок. Что в это время делает Dev-команда? Помимо устранения технического долга (накопленных проблем в коде за счет жестких сроков выпуска новой версии), разработчики ищут новые, эффективные решения создания кода продукта.
Если же речь идет про SAFe-подход, то в данном случае каждый пятый спринт, пока QA-команда завершает процесс тестирования, Dev-специалисты на протяжении всего хода спринта работают над новыми техническими решениями (поиск эффективных способов оптимизации работы, модернизация инфраструктуры, внедрение новых практик/инструментов, участие в хакатоне, обмен знаниями между подкомандами и многое другое).
