Участвовал в большом количество споров вокруг, казалось бы, простой темы, такой как требования в Agile процессах. Поскольку гибкие практики сами по себе поощряют уход от формализации, то многие команды ломают голову, как же им быть с требованиями, ведь без четкого описания сложно хорошо сделать работу в команде, где ответственность и обязанности распределены между участниками, где нет универсальных специалистов, а ведь это частый случай.
Рекомендую командам из обоих лагерей (формалистов и "упрощенцев") следующие посты, в которых даются практические советы как поступать с требованиями в том или ином случае:
Сбор требований в Agile проектах
Постановка процесса анализа требований
пятница, 19 февраля 2010 г.
вторник, 9 февраля 2010 г.
Проектирование архитектуры системы
При разработке относительно сложного приложения рано или поздно встает вопрос по формировании архитектурного описания, понимания зависимостей между компонентами приложения и внедрении всего этого в существующую инфраструктуру компании заказчика или покупателя.
Ясное дело, вы используете Agile, но что оно говорит об архитекторе? Ведь в основном процессе взаимодействия с заказкиком (владельцем продукта) нет места архитектору. В вашей команде может быть выделена роль архитектора, который будет принимать участие в обсуждении и приоретизации пожеланий. Казалось бы проблема решена, однако, чаще всего подобной выделенной роли нет, а разрабатываемое приложение необходимо интегрировать с массой сервисов и других внешних приложений, уже используемых у заказчика.
Привожу ссылку на интересное выступление о роли архитектора в Agile команде. Надеюсь предложенные решения помогут вам направить работу команды в нужное русло и в итоге добиться желаемого результата.
Ясное дело, вы используете Agile, но что оно говорит об архитекторе? Ведь в основном процессе взаимодействия с заказкиком (владельцем продукта) нет места архитектору. В вашей команде может быть выделена роль архитектора, который будет принимать участие в обсуждении и приоретизации пожеланий. Казалось бы проблема решена, однако, чаще всего подобной выделенной роли нет, а разрабатываемое приложение необходимо интегрировать с массой сервисов и других внешних приложений, уже используемых у заказчика.
Привожу ссылку на интересное выступление о роли архитектора в Agile команде. Надеюсь предложенные решения помогут вам направить работу команды в нужное русло и в итоге добиться желаемого результата.
вторник, 26 января 2010 г.
Много проектов
Если вам приходится вести несколько проектов, разделять участников команды между ними и уметь за всем этим следить, чтобы еще прогнозировать наличие ресурсов для следующих проектов, то вот интересная заметка: http://devprom.ru/news/Управление-портфелем-проектов
пятница, 22 января 2010 г.
Риски нефункциональных требований
Обычно считается, что управление рисками очень хорошо известная область, которой все хорошо владеют и постоянно применяют на практике, хотя на самом деле ни в одном инструменте управления процессом разработки нет явно выделенного подобного функционала. Однако, есть описание вариантов того, как это можно сделать подручными средствами при помощи любимого инструмента. В общем рекомендуют почитать: http://devprom.ru/news/Оценка-рисков-нефункциональных-требований
понедельник, 18 января 2010 г.
Проектирование архитектуры в Agile
Поскольку Agile относится к гибким практикам, в некотором смысле отрицающим монолитный, фундаментальный и формальный подход к подготовке проектной документации, то возникает вопрос о том, как и нужно ли обсуждать и документировать архитектуру приложения.
Опыт нашей команды говорит о том, что в каждом проекте нужно самостоятельно принимать решение о необходимости совместного обсуждения архитектуры приложения, где-то это действительно важно, особенно, если технические риски высоки, или планируется использовать новую платформу, которую еще не особенно обкатали.
Главное не уйти сильно в сторону: документируйте и погружайтесь в обсуждение архитектуры на столько, на сколько это необходимо. Формализацию и спецификации можно опустить, не тратьте на это время.
Вот интересная заметка по поводу описания атрибутов качестваразрабатываемого приложения: http://devprom.ru/news/Определение-нефункциональных-требований
Интересные практики описания архитектуры в Agile проектах: http://agileconsulting.ru/
Опыт нашей команды говорит о том, что в каждом проекте нужно самостоятельно принимать решение о необходимости совместного обсуждения архитектуры приложения, где-то это действительно важно, особенно, если технические риски высоки, или планируется использовать новую платформу, которую еще не особенно обкатали.
Главное не уйти сильно в сторону: документируйте и погружайтесь в обсуждение архитектуры на столько, на сколько это необходимо. Формализацию и спецификации можно опустить, не тратьте на это время.
Вот интересная заметка по поводу описания атрибутов качестваразрабатываемого приложения: http://devprom.ru/news/Определение-нефункциональных-требований
Интересные практики описания архитектуры в Agile проектах: http://agileconsulting.ru/
четверг, 14 января 2010 г.
Гибгкий подход к документированию
Не устаю повторять всем, кому приходится рассказывать про Agile, что команда сама для себя решает какой уровень детализации и формализации при подготовке требований ей подходит.
Это может быть подробное текстовое описание, либо большое количество моделей, по которым должен быть сгенерирован программный код. Но чаще всего, достаточно лишь заметок на клочках бумаги, фотографий досок с изображениями или простенькие макеты, разработанные за 5 минут.
Это может быть подробное текстовое описание, либо большое количество моделей, по которым должен быть сгенерирован программный код. Но чаще всего, достаточно лишь заметок на клочках бумаги, фотографий досок с изображениями или простенькие макеты, разработанные за 5 минут.
вторник, 29 декабря 2009 г.
Как не упустить срыв сроков
Частой проблемой при разработке является отставание команды от первоначального графика. Причин тому может быть несколько, например, изменился скоуп, изменилась оценка трудоемкости скоупа или просто темп разработки снизился.
Из-за чего может измениться скоуп? Например, потому что заказчику показалось, что теперь ему нужны не эти фичи, а еще те и те. Это частый кейс и риск, которым необходимо управлять, то есть следить составом скоупа и вашими договоренностями.
Есть и другие причины, например, низкое качество продукта из-за которого постоянно вылезают ошибки предыдущих релизов или вновь созданные в этом. Поскольку ошибки нужно исправлять, то они часто автоматически включаются в скоуп текущего релиза, а следовательно изменяют сроки его выхода.
Мне понравилась методика, которая используется в DEVPROM. Члены команды просто отмечают часы, система автоматически вычисляет текущую скорость команды и прогнозирует срок завершения итерации и релиза. То есть, вся команда всегда в курсе возможного срыва сроков и отсутствия запаса времени. Используйте эти моменты для понимания проблем в процессе, команде и адаптируйтесь вовремя.
Из-за чего может измениться скоуп? Например, потому что заказчику показалось, что теперь ему нужны не эти фичи, а еще те и те. Это частый кейс и риск, которым необходимо управлять, то есть следить составом скоупа и вашими договоренностями.
Есть и другие причины, например, низкое качество продукта из-за которого постоянно вылезают ошибки предыдущих релизов или вновь созданные в этом. Поскольку ошибки нужно исправлять, то они часто автоматически включаются в скоуп текущего релиза, а следовательно изменяют сроки его выхода.
Мне понравилась методика, которая используется в DEVPROM. Члены команды просто отмечают часы, система автоматически вычисляет текущую скорость команды и прогнозирует срок завершения итерации и релиза. То есть, вся команда всегда в курсе возможного срыва сроков и отсутствия запаса времени. Используйте эти моменты для понимания проблем в процессе, команде и адаптируйтесь вовремя.
Подписаться на:
Сообщения (Atom)