Шаблоны проектов
Когда мы говорим о шаблоне, то подразумеваем некое обобщенное, типовое представление информации. Шаблон проекта позволяет описать его типовые настройки, типовую иерархию требований, тестовой документации, часто используемые шаблоны документов и многое другое. |
OpenUP: исследуем процесс
Наличием большого количества традиционных "тяжелых" процессов или методологий в области разработки программного обеспечения никого не удивишь. Среди них можно найти варианты на любой вкус: водопадные, итерационные, спиральные и любые другие их комбинации.
Всевозможные следствия от их тяжеловесности при внедрения и использования в проектах вызывают отторжение этих процессов у многих проектных команд. На этой почве созревают методологии семейства Agile, с крайне облегченными или отсутствующими процессами, ориентированными на зрелость и взаимозаменяемость участников проектной команды.
Очевидно, что в реальных условиях разработки ПО "тяжелые" и "легкие" методологии представляются противоположными крайностями. Эксперты с 20-ти летним опытом участия в разработке - большая редкость. Наличие необходимых представлений о процессе разработки, о создаваемых артефактах - чаще иллюзия, никто особенно этому не учит. Зрелость большинства проектных команд недостаточна для того, чтобы заказчик не беспокоился о процессе, по которому работает исполнитель.
Таким образом, вполне обоснованным является желание использовать нечто среднее: некоторый формальный процесс, описанный и проверенный опытом индустрии, с готовыми шаблонами артефактов, но не обремененный всевозможными деталями и в большей степени опирающийся на Agile-принципы. Встречайте: Open Unified Process (OpenUP).
"OpenUP - это экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла. OpenUP использует прагматичную философию гибкой разработки, которая имеет в своей основе коллективный подход к разработке программного обеспечения. Это независимый от инструментов, мало регламентированный процесс, который можно расширить для адаптации к широкому диапазону типов проектов."
В плане "легкости" OpenUP предлагает командам использовать следующие практики:
В плане "тяжести" OpenUP предлагает:
В Devprom ALM вы найдете готовый шаблон проекта, настроенный под использование процесса OpenUP, с предустановленными проектными ролями, стадиями процесса, типами задач, шаблонами для ретроспектив, <a href="http://devprom.ru/features/Система-управления-требованиями-Devprom-Requirements">анализа требований</a> и дизайна программного решения, тестовой документации, а также с типовой структурой требований и тестовой документации.
Таким образом, вам не нужно пытаться притянуть ваш инструмент управления проектом под процесс OpenUP, также вам не нужно что-то самим настраивать. Достаточно просто установить Devprom ALM и создать проект по шаблону OpenUP - у вас будет инструмент, в полной мере автоматизирующий разработку ПО по процессу OpenUP.
|
Объединение данных из нескольких проектов
Если вы чувствовали недостаток обмена информацией между проектами, то в корпоративной версии DEVPROM мы постарались решить эту проблему. Что за проблема и откуда она взялась? Попробую пояснить. |
Поддержка продуктов по email
Традиционно организация обратной связи с пользователями продуктов, например, представителями заказчика, осуществляется посредством обмена почтовыми сообщениями. Типичный пример: заказчику сообщается некоторый почтовый ящик разработчика, на который он может отправлять вопросы, сообщения об ошибках и т.д.
По сравнению с вовлечением пользователя в процесс разработки или предоставления пользователям портала проектов, вариант с почтовым ящиком, конечно существенно проигрывает, однако, из-за различного рода ограничений все же остается востребованным вариантом.
Для системы управления проектами DEVPROM появилась подобная функциональность, которая позволяет реализовать этот вариант взаимодействия с пользователями:
Данная функциональность состоит из следующих моментов:
Самый простой вариант поддержки пользователей ваших продуктов, максимально тесно интегрированный с инструментом разработки этих продуктов заключается в следующем. Вы сообщаете пользователям почтовый адрес, на который они отправляют сообщения, которые попадают в проект поддержки пользователей в виде пожеланий. Участники проекта поддержки переносят или дублируют пожелания в соответствующих проектах и могут сообщать пользователям о ходе выполнения их пожеланий, задавать уточняющие вопросы. |
Организация поддержки продуктов
Поддержка разработанных или еще разрабатываемых программных продуктов часто применяется при заказной или продуктовой разработке, причем, из-за размеров и количества частей, составляющих программный продукт, в этот процесс могут быть вовлечены отдел поддержки и несколько проектных команд, разработавших свои части продукта. В системе управления проектами DEVPROM возможны различные варианты организации поддержки пользователей или заказчиков:
Проект поддержкиВ этом варианте вам необходимо создать отдельный проект, участниками которого могут стать сотрудники отдела поддержки или, как вариант, продуктовый менеджер. В этом проекте будет аккумулироваться вся общая информация по продукту: высокоуровневое описание функциональности, обнаруженные пользователями ошибки, результаты обсуждения с пользователями и т.п.
Участники проекта поддержки обрабатывают поступающие от пользователей пожелания и, либо самостоятельно решают проблемы (первый эшелон сервиса поддержки), либо дублируют пожелания к функциональности в конкретный проект, в рамках которого должна реализовываться эта функциональность. При этом между исходными пожеланиями и продублированными пожеланиями в проекте автоматически создается связь, которая позволяет отслеживать состояние реализации исходных пожеланий во всех проектах, куда они были переданы для реализации.
Отслеживая журналы пожеланий проекта поддержки участники проекта находятся в курсе состояния реализации пожеланий пользователей и могут влиять на приоритеты, сроки реализации исходных пожеланий в рамках конкретных проектов, куда они переданы для реализации.
В случае, когда дополнительный контроль за пожеланием со стороны проекта поддержки не требуется, то участники проекта могут просто перенести пожелание в тот проект, где его необходимо реализовать.
Ограничения данного варианта: для организации доступа пользователей к проектам поддержки и разработки продуктов необходимо создавать для них аккаунты в системе и выполнять настройку прав доступа. Если доступ пользователям предоставить нет возможности, то необходимо настроить автоматическое создание пожеланий по факту получения письма от пользователя на предустановленный почтовый ящик. Проектный порталПо сравнению с предыдущим вариантом снимаются описанные ограничения, поскольку вы предоставляете пользователям доступ к порталу, на котором они могут регистрироваться самостоятельно либо использовать свои существующие аккаунты в других сервисах (с использованием OpenID).
Таким образом, пользователи самостоятельно могут добавлять пожелания, задавать вопросы, загружать файлы, выложенные участниками проектов, и многое другое. В качестве примера такого портала посмотрите на сервис "Облако проектов", который реализован в виде плагина для DEVPROM.
Дополнительным преимуществом такого варианта является реализация полноценной ALM, построенной на базе DEVPROM. Продуктовые менеджеры получают эффективный инструмент коммуникации с пользователями, построения каналов обратной связи с ними, маркетирования и управления инициативами пользователей и сотрудников компании. |