вторник, 26 января 2010 г.

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

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

пятница, 22 января 2010 г.

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

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

понедельник, 18 января 2010 г.

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

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

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

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

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

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

четверг, 14 января 2010 г.

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

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

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