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

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

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

Таким образом, вполне обоснованным является желание использовать нечто среднее: некоторый формальный процесс, описанный и проверенный опытом индустрии, с готовыми шаблонами артефактов, но не обремененный всевозможными деталями и в большей степени опирающийся на Agile-принципы. Встречайте: Open Unified Process (OpenUP).

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

В плане "легкости" OpenUP предлагает командам использовать следующие практики:

• измерение скорости работы команды, предварительную оценку пожеланий в story points
• проведение ежедневных митингов и ретроспектив по окончании каждой итерации
• концепцию микро-шагов, повторяющую принцип непрерывного создания работающего продукта
• концепцию раннего тестирования с использованием проверочных листов (checklists)
• методику гибкого моделирования (AMDD), направленную на быстрое создание только той документации, которая потребуется в ближайшем будущем.

В плане "тяжести" OpenUP предлагает:

• Готовые шаблоны для
• Описания видения продукта
• Проведения ретроспектив и измерения состояния проекта
• Создания требований, архитектуры, дизайна и тестовой документации
• Контрольные списки (checklists), по которым проверяется корректность и полнота создаваемых артефактов
• Формализованный, но упрощенный с точки зрения RUP, процесс, в котором описано какие активности и в какой последовательности должна выполнять команда, какие цели должна перед собой ставить
• Перечисление ролей, описание зон их ответственности, артефакты, которые они создают и потребляют.

В Devprom ALM вы найдете готовый шаблон проекта, настроенный под использование процесса OpenUP, с предустановленными проектными ролями, стадиями процесса, типами задач, шаблонами для ретроспектив, <a href="http://devprom.ru/features/Система-управления-требованиями-Devprom-Requirements">анализа требований</a> и дизайна программного решения, тестовой документации, а также с типовой структурой требований и тестовой документации.

Таким образом, вам не нужно пытаться притянуть ваш инструмент управления проектом под процесс OpenUP, также вам не нужно что-то самим настраивать. Достаточно просто установить Devprom ALM и создать проект по шаблону OpenUP - у вас будет инструмент, в полной мере автоматизирующий разработку ПО по процессу OpenUP.

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

Новости

• Вышло обновление DEVPROM, в этой версии мы добавили ряд долгожданных возможностей, таких как подписка на обновления (watching) и создание пожеланий по email, а так же несколько новых фич в Enterprise версию системы, подробнее...
• Для живой демонстрации возможностей DEVPROM мы подготовили несколько проектов, расположенных по адресу http://demo.pmcloud.ru вы также можете создавать свои проекты и оценивать возможности enterprise версии системы.
• Напоминаем, что есть такой вариант использования DEVPROM как Enterprise Edition SaaS - очень дешевый способ обзавестись собственным экземпляром DEVPROM без каких-либо ограничений, включающим Enterprise фичи и Subversion-репозиторий, без необходимости где-то искать хостинг, что-то устанавливать и администрировать. Просто напишите нам.

Публикации

• Примерно год назад мы открыли для себя mindmaps в качестве очень удобного дополнительного инструмента в работе над проектами. Хочется рассказать про два кейса, которые мы наиболее часто применяем в работе, на примере проекта построения достаточно большого хранилища данных. Подробнее: Примеры использования MindMaps в проектной работе
• Специалисты, задействованные в разработке программного обеспечения, являются довольно дорогостоящим ресурсом, а проекты, в которых они участвуют сильно отличаются друг от друга по плотности задач. Из-за этого часто одни и те же люди участвуют в одновременно в нескольких проектах, например, в новом и предыдущем (с целью его поддержки), либо выделяются на некоторый процент времени в случае с матричной системой управления проектами. Подробнее: Анализ загрузки ресурсов
• Система управления проектами DEVPROM позволяет разработчикам ПО готовить справочную документацию к программным продуктам без использования дополнительных инструментов, например, Author-It или RoboHelp, предоставляя следующие ключевые возможности. Подробнее: Создание справочной документации к продукту
• В компаниях и распределенных командах, занимающихся разработкой программного обеспечения, часто возникают рутинные задачи по организации и обеспечению поддержки процесса разработки, которыми кому-то нужно заниматься, но нет возможности это делать в те моменты, когда это нужно. Вот только небольшой список подобных задач. Подробнее: Ежемесячный дайджест
• При работе над проектом, особенно, если не все члены команды размещаются в одной комнате, просто необходимо получать свежую информацию об изменениях в проекте (нотификаций), например, при помощи уведомлений по электронной почте, через RSS-канал или другими способами. В DEVPROM существует несколько вариантов нотификаций. Подробнее: Возможные варианты нотификаций
• В последнее время различные методологи все чаще обращаются к вопросу качества разрабатываемых продуктов, при этом не прибегая к использованию сложных и долгих формальных методов верификации, поскольку современные практики разработки ПО позволяют дать дешевый и достойный ответ. Подробнее: Раннее тестирование (early testing)
• Поддержка разработанных или еще разрабатываемых программных продуктов часто применяется при заказной или продуктовой разработке, причем, из-за размеров и количества частей, составляющих программный продукт, в этот процесс могут быть вовлечены отдел поддержки и несколько проектных команд, разработавших свои части продукта. Подробнее: Организация поддержки продуктов
• Любую крупную задачу, а именно такой и является разработка программного продукта, эффективно разбить на множество небольших, относительно независимых подзадач. Именно данный принцип позволяет измерять прогресс выполнения исходной задачи, вычислять текущий статус проекта. В зависимости от количества участников проекта, сроков его завершения, уровня зрелости команды, финансовой модели, по которой выполняется проект, необходимо применять соответствующие методики измерения хода проекта. Подробнее: Варианты оценки производительности команды
• По сравнению с вовлечением пользователя в процесс разработки или предоставления пользователям портала проектов, вариант с почтовым ящиком, конечно существенно проигрывает, однако, из-за различного рода ограничений все же остается востребованным вариантом. Подробнее: Поддержка продуктов по email
• Если вы чувствовали недостаток обмена информацией между проектами, то в корпоративной версии DEVPROM мы постарались решить эту проблему. Что за проблема и откуда она взялась? Попробую пояснить. Подробнее: Объединение данных из нескольких проектов

С уважением, команда DEVPROM.

Если вы чувствовали недостаток обмена информацией между проектами, то в корпоративной версии DEVPROM мы постарались решить эту проблему. Что за проблема и откуда она взялась? Попробую пояснить.

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

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

Для системы управления проектами DEVPROM появилась подобная функциональность, которая позволяет реализовать этот вариант взаимодействия с пользователями:

1. Вам необходимо выделить почтовый ящик для приема сообщений от пользователей.
2. В разделе администрирования DEVPROM, на закладке "Обработка почты" необходимо добавить почтовый ящик и указать параметры подключения к почтовому серверу.
3. Необходимо сопоставить почтовый ящик проекту, в котором будут создаваться пожелания на основе сообщений, находящихся в этом почтовом ящике.

Данная функциональность состоит из следующих моментов:

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

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

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