Как работает система аналитики для управления разработкой и тестированием ПО?
Изображение: Gorodenkoff/shutterstock.com
Аналитика, доступная каждому
Традиционно управление разработкой считается прерогативой руководителя проекта, который разрабатывает планы, определяет сроки этапов и фиксирует достижение целей на каждом из них, рассчитывает инвестиции и т. д. Но зачастую доступ к аналитике, позволяющей объективно оценить качество разрабатываемого продукта на том или ином этапе, необходим и другим участникам процесса – от рядового специалиста до владельца бизнеса, причем без обращения к профессиональному аналитику и ожидания. Иными словами, нужен инструмент, который помог бы стандартизировать и обрабатывать разрозненные параметры разработки и тестирования, визуализируя результаты в формате отчетов, как это делает BI в других сферах.
Такой инструмент решал бы сразу несколько задач: давал общую картину состояния продукта, отслеживал количество дефектов и способствовал выявлению их причин, мог бы сигнализировать о готовности перехода на следующие этапы проекта, гарантировал объективность управления качеством разработки.
Актуальность аналитики разработки и тестирования обусловлена несколькими причинами. Во-первых, многие вендоры сегодня выпускают и поддерживают большое количество продуктов силами множества распределенных команд. Управление этим процессом усложняется, а тенденция к сокращению time to market побуждает искать наиболее оптимальные способы взаимодействия в команде и минимизировать риски, связанные, например, с накоплением багов в коде продукта.
Во-вторых, представители крупного бизнеса наращивают количество внутренних разработок, для которых привлекаются аутсорсинговые команды или формируются собственные ИТ-подразделения. Поскольку ИТ-бизнес не является для таких компаний профильным, в них могут быть недостаточно четко отлажены процессы создания продукта, отсутствовать специализированные инструменты, методология разработки ПО и анализа качества.
На рынке, конечно, существуют необходимые разработчикам инструменты: например, аналитические плагины в Jira позволяют оценивать скорость закрытия спринтов и итераций, вести учет дефектов. Но в данном случае они настроены исключительно под agile-методологию. В российских системах управления проектами применяется базовая аналитика, но хотелось бы сделать ее более универсальной. Для этого нужен максимально гибкий продукт, который, с одной стороны, решал бы все описанные выше задачи, а с другой – подходил бы для любых методологий разработки, в том числе классического каскадного подхода (waterfall). Расскажу о том, как, по нашему представлению, должен работать комплексный аналитический модуль для разработчиков.
Аналитика в разработке: принципы работы
Разработка любого программного продукта подразделяется на этапы и циклы – например, спринты и итерации. На каждом из них важно отслеживать качество продукта, чтобы своевременно исправлять баги и не переносить их на следующий этап (бывает, что о не закрытых вовремя багах вспоминают в тот момент, когда их количество достигает критического объема и проект рискует быть свернутым). Важно также соблюдать сроки этапов, поскольку от этого зависят динамика проекта, потенциальные инвестиции и, как итог, скорость выхода решения в продуктив.
Аналитический инструмент, во-первых, помогает отслеживать количество итераций разработки и оценивать полноту выполнения задач исходя из заданного плана: подсчитать, сколько задач было выполнено точно, сколько просрочено, по каким причинам. Это происходит на основе предварительно настроенных метрик приемки и позволяет более грамотно управлять задачами, при необходимости принимая меры для корректировки процесса.
Во-вторых, благодаря аналитике можно объективно оценить, насколько все задачи «покрыты» тестами. Некоторые задачи, например, по ряду причин не могут быть подвергнуты классическому тестированию, когда специалист проверяет функциональность, пишет по ней test case и выполняет его. Такие моменты необходимо оперативно фиксировать.
В-третьих, такой инструмент дает возможность оценить количество выявленных багов в каждой из итераций, их исполнителя и возможные причины, своевременно реагировать на них. Так, если тестировщики обнаруживают, что задача не проходит тестирование, в системе заводится баг. Его корневые причины могут быть разные: бизнес-аналитик не учел какие-то функциональные или нефункциональные требования, разработчик не реализовал какие-то требования технического задания, и т. д.
Может случиться, что продукт успешно прошел тестирование, но уже из продуктива поступают множественные заявки от пользователей по данной реализации: вероятно, DevOps некорректно выложили в продуктив разработку, реализованную на предпродуктовом стенде, и часть функциональности пропала. Все эти данные могут аккумулироваться в аналитическом модуле и визуализироваться в отчетах. Классификатор проблем при обнаружении дефектов поможет быстро понять их категорию, найти и устранить причину.
Таким образом, аналитический модуль дает возможность владельцу бизнеса целиком контролировать процесс разрабатываемого продукта, оценивать качество разработки и готовность продукта к развитию, масштабированию, выходу в продуктив и внедрению у заказчиков. Происходит стандартизация подходов к разработке и метрик эффективности, что позволяет исполнителю легче взаимодействовать с заказчиком и согласовывать и защищать бюджеты на проект, повышать зрелость и улучшать слаженность работы проектных команд.
Для руководителя проекта аналитика – это способ отслеживать процессы изменения продукта: что команда успела или не успела сделать, кто из исполнителей допускает больше всего дефектов, какие решения следует принять для корректировки работы и устранения недостатков.
Для рядового разработчика или тестировщика аналитика тоже важна. Например, если он видит в отчете, что задачи в его сфере ответственности выполняются качественно, значит, стоит продолжать так же. Если же качество на каком-то уровне теряется, – нужно искать причину, не дожидаясь команды сверху.
Резюме
На качество разработки положительно влияют грамотное следование выбранной методологии и применение специальных инструментов – например, плагина для тестировщиков Zephyr for Jira для покрытия задач тест-кейсам. Таким образом можно наладить контроль разработки на проекте или Postman для проверки интеграций посредством REST API.. С помощью таких программ команда может выстроить систему аналитики, связанной с быстрым обнаружением, классификацией, приоритизацией и устранением дефектов. При этом важно генерировать дашборды для всех участников команды разработки, чтобы найденные баги можно было наиболее оперативно устранять.
С появлением на российском рынке полноценного аналитического модуля, который возможно будет интегрировать в системы управления проектами, уже существующие у вендора или непрофильной компании, занимающейся внутренней разработкой, этот процесс станет гораздо проще.
Опубликовано 22.07.2024
