суббота, 30 октября 2010 г.
четверг, 29 апреля 2010 г.
Участие архитектора
При разработке архитектуры приложений или сервисов перед вами часто встает выбор: когда пригласить на эту должность, как человек будет взаимодействовать с разработчиками и будут ли они корректно воспринимать принимаемые решения. Интересная дискуссия завязалась здесь: Архитектор в команде - лидерство или полномочия?
среда, 7 апреля 2010 г.
Оценка качества процесса
В связи с появлением термина "типа Agile", характеризующего проекты, в которых люди очень хотят, но не хватает силы воли, чтобы следовать необходимым принципам, обязательным для выполнения истинным Agile командам, появляются различные способы проверки на соответствие вашего процесса "правильному" Agile.
Один из таких способов позволяет пройтись по чеклисту и отметить галочками те пункты, которые действительно соблюдаются. Получив общую картину вы поймете, где необходимо подтянуть процесс.
Но, что интересно, ведь многие команды используют инструменты, которые предназначены для автоматизации процессов и помощи командам, а значит, эти интрументы также должны соответствовать основным требованиям правильного Scrum. Замечательно, что разработчики DEVPROM одними из первых пошли честным путем и не стали сравнивать себя с другими инструментами, а сравнили себя с тем, как должно быть на самом деле, вот интересные результаты.
Один из таких способов позволяет пройтись по чеклисту и отметить галочками те пункты, которые действительно соблюдаются. Получив общую картину вы поймете, где необходимо подтянуть процесс.
Но, что интересно, ведь многие команды используют инструменты, которые предназначены для автоматизации процессов и помощи командам, а значит, эти интрументы также должны соответствовать основным требованиям правильного Scrum. Замечательно, что разработчики DEVPROM одними из первых пошли честным путем и не стали сравнивать себя с другими инструментами, а сравнили себя с тем, как должно быть на самом деле, вот интересные результаты.
Словарь терминов
Если кто-то искал словарь терминов по Agile, чтобы лучше понимать язык, на котором говорит его Scrum-мастер, то вот список определений основных терминов:
История пользователя
Журнал продукта
Спринт
Рефакторинг
Диаграмма сжигания
Парное программирование
История пользователя
Журнал продукта
Спринт
Рефакторинг
Диаграмма сжигания
Парное программирование
Модели ведения требований в проекте
Если все еще думаете по поводу того, как же построить процесс сбора и анализа требований в вашем проекте, и, при этом, не хотите лишней формализации, использования дорогих инструментов и бардака, которые при этом получается, то вот вам полезная заметка: Варианты сбора требований
понедельник, 29 марта 2010 г.
Управление жизненным циклом проекта
Если вы являетесь приверженцем принципов и методик Agile, а также видите значимость в автоматизации большей части процесса по управлению жизненным циклом приложения или продукта, то вам будет интересно почитать про возможности одного из самых многообещающих инструментов, доступных командам разработчиков ПО: Построение ALM решения
Если вашей команде, пока не требуется всех "плюшек", которые предоставляет ALM-решение, то этот же инструмент позволяет практически полностью удовлетворить потребности вашей команды: Ведение Agile проектов
Если вашей команде, пока не требуется всех "плюшек", которые предоставляет ALM-решение, то этот же инструмент позволяет практически полностью удовлетворить потребности вашей команды: Ведение Agile проектов
пятница, 12 марта 2010 г.
Переход от громоздкого тестирования к Agile
Работая по принципам Agile рано или поздно сталкиваешься с тем, что существующий инструментарий слишком много требует к себе внимания и сил для его администрирования или управления. Это самое время подумать об отказе от него и высвободить ресурсы не на обслуживание инструмента, а на выполнение полезной для проекта работы.
В тестировании это бывает особенно актуально, поскольку оно является самым последним и важным механизмом для измерения готовности продукта. Автоматизация тестирования - это первый шаг, который позволит существенно сэкономить время и ресурсы проекта, при этом не ухудшив отдачу от самого механизма тестирования.
Ключевым моментом здесь является возможность построить процесс тестирования, автоматизируемый на всех уровнях за счет максимально простых инструментов.
В тестировании это бывает особенно актуально, поскольку оно является самым последним и важным механизмом для измерения готовности продукта. Автоматизация тестирования - это первый шаг, который позволит существенно сэкономить время и ресурсы проекта, при этом не ухудшив отдачу от самого механизма тестирования.
Ключевым моментом здесь является возможность построить процесс тестирования, автоматизируемый на всех уровнях за счет максимально простых инструментов.
пятница, 19 февраля 2010 г.
Управление требованиями в Agile
Участвовал в большом количество споров вокруг, казалось бы, простой темы, такой как требования в Agile процессах. Поскольку гибкие практики сами по себе поощряют уход от формализации, то многие команды ломают голову, как же им быть с требованиями, ведь без четкого описания сложно хорошо сделать работу в команде, где ответственность и обязанности распределены между участниками, где нет универсальных специалистов, а ведь это частый случай.
Рекомендую командам из обоих лагерей (формалистов и "упрощенцев") следующие посты, в которых даются практические советы как поступать с требованиями в том или ином случае:
Сбор требований в Agile проектах
Постановка процесса анализа требований
Рекомендую командам из обоих лагерей (формалистов и "упрощенцев") следующие посты, в которых даются практические советы как поступать с требованиями в том или ином случае:
Сбор требований в Agile проектах
Постановка процесса анализа требований
вторник, 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 минут.
Подписаться на:
Сообщения (Atom)