Переход от громоздкого тестирования к Agile

Работая по принципам Agile рано или поздно сталкиваешься с тем, что существующий инструментарий слишком много требует к себе внимания и сил для его администрирования или управления. Это самое время подумать об отказе от него и высвободить ресурсы не на обслуживание инструмента, а на выполнение полезной для проекта работы.

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

Ключевым моментом здесь является возможность построить процесс тестирования, автоматизируемый на всех уровнях за счет максимально простых инструментов.

Управление требованиями в Agile

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

Рекомендую командам из обоих лагерей (формалистов и "упрощенцев") следующие посты, в которых даются практические советы как поступать с требованиями в том или ином случае:

Сбор требований в Agile проектах
Постановка процесса анализа требований

Проектирование архитектуры системы

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

Ясное дело, вы используете Agile, но что оно говорит об архитекторе? Ведь в основном процессе взаимодействия с заказкиком (владельцем продукта) нет места архитектору. В вашей команде может быть выделена роль архитектора, который будет принимать участие в обсуждении и приоретизации пожеланий. Казалось бы проблема решена, однако, чаще всего подобной выделенной роли нет, а разрабатываемое приложение необходимо интегрировать с массой сервисов и других внешних приложений, уже используемых у заказчика.

Привожу ссылку на интересное выступление о роли архитектора в Agile команде. Надеюсь предложенные решения помогут вам направить работу команды в нужное русло и в итоге добиться желаемого результата.

Много проектов

Если вам приходится вести несколько проектов, разделять участников команды между ними и уметь за всем этим следить, чтобы еще прогнозировать наличие ресурсов для следующих проектов, то вот интересная заметка: http://devprom.ru/news/Управление-портфелем-проектов

Риски нефункциональных требований

Обычно считается, что управление рисками очень хорошо известная область, которой все хорошо владеют и постоянно применяют на практике, хотя на самом деле ни в одном инструменте управления процессом разработки нет явно выделенного подобного функционала. Однако, есть описание вариантов того, как это можно сделать подручными средствами при помощи любимого инструмента. В общем рекомендуют почитать: http://devprom.ru/news/Оценка-рисков-нефункциональных-требований

Проектирование архитектуры в Agile

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

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

Главное не уйти сильно в сторону: документируйте и погружайтесь в обсуждение архитектуры на столько, на сколько это необходимо. Формализацию и спецификации можно опустить, не тратьте на это время.

Вот интересная заметка по поводу описания атрибутов качестваразрабатываемого приложения: http://devprom.ru/news/Определение-нефункциональных-требований

Интересные практики описания архитектуры в Agile проектах: http://agileconsulting.ru/

Гибгкий подход к документированию

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

Это может быть подробное текстовое описание, либо большое количество моделей, по которым должен быть сгенерирован программный код. Но чаще всего, достаточно лишь заметок на клочках бумаги, фотографий досок с изображениями или простенькие макеты, разработанные за 5 минут.