Один из наших пользователей недавно задал вопрос - как в системе управления проектами DEVPROM назначать задачи при использовании командой парного программирования, то есть одну задачу сразу на двух разработчиков?

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

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

Одно из преимуществ DEVPROM как в раз в том, чтобы максимально облегчить ежедневную работу участников проекта. Так, например, добавление новой задачи при планировании пожелания в итерацию делается всего одним кликом по ссылке "Добавить задачу" на форме планирования. Остается только указать нужного исполнителя задачи.

pptask

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

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

Я хочу привести пример того, как можно выполнить эту задачу с использованием возможностей DEVPROM. И для начала нужно выбрать подходящее приложение, нефункциональные требования которого я хочу проанализировать. Например, это будет простое графическое приложение для ведения личной бухгалтерии.

В предыдущем посте "Описание архитектуры приложения" я приводил вариант описания архитектуры приложения, а теперь хочу дать чуть более подробное описание методики составления архитектурного описания приложения или проекта. Эта методика является неким адаптированным вариантом стандарта IEEE 1471 и не претендует на полноту. Основная цель - помочь командам выбрать направление для документирования архитектуры их проектов.

Часто инструменты для поддержки процессов разработки программного обеспечения воспринимаются как примитивные тикет-системы (баг-трекеры), позволяющая создать тикет, назначить ответственного и ждать, когда он будет выполнен, либо как примитивное управление задачами, что вообще-то свойственно любому процессу, где задействованы люди. Из вида упускаются крайне важные этапы и элементы процесса разработки:

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

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

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