Новости

• Вышло обновление 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 мы постарались решить эту проблему. Что за проблема и откуда она взялась? Попробую пояснить. Подробнее: Объединение данных из нескольких проектов

Иерархия проектов

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

• Программа проектов. Обычно под программой проектов понимают набор из нескольких проектов, объединенных общими целями, иногда, общим интересом со стороны одного заказчика. В каждом из проектов программы могут разрабатываться независимые приложения или решения, либо частично пересекающиеся и интегрируемые.
• Поддержка продуктов для одного заказчика. Цель проекта поддержки заключается в организации единой точки управления ожиданиями заказчика. Все пожелания внутри проекта поддержки дублируются в проектах соответствующих продуктов и тем самым отслеживается и контролируется решение запросов заказчика.
• Единая служба поддержки. При передаче реализованного продукта в поддержку, заказчику сообщается адрес единой службы поддержки, через которую осуществляется взаимодействие пользователей с разработчиками. Часть проблем могут решать специалисты службы поддержки, используя базу знаний или пользовательскую документацию дочерних проектов. Другую часть проблем они передают на анализ и решение непосредственно в дочерние проекты.
• Модульная разработка. Крупное решение часто делится на несколько относительно независимых модулей, либо компоненты, отличающиеся по технологии разработки: сервер приложения и база данных. В каждом модуле происходит уточнение исходных требований под специфику данного модуля.

Звезда (кастомизация решения)

В этой схеме один (центральный) проект связывается с несколькими другими (независимыми) проектами, которые базируются на артефактах и результатах центрального проекта. Центральный проект экспортирует свою базу знаний, требования, тестовую и пользовательскую документацию, бинарный и исходный код. Таким образом, проекты наращивают или адаптируют функционал центрального проекта под нужды своих пользователей или заказчиков. Проекты инициируют необходимые им изменения в центральном проекте путем создания дубликатов пожеланий и отслеживают статус этих зависимостей в соответствии со своими сроками. Характерной чертой такой схемы является экспорт практически всех артефактов из центрального проекта во внешние проекты.

Сеть (технологический актив)

Практически любая команда разработчиков имеет свой набор библиотек или технологий, которые она повторно использует в очередном проекте. Таким образом, проекты собираются из некоторых общих технологических элементов, на базе которых реализуется требуемая функциональность. Таким компонентом может быть и некая стандартная библиотека или framework, с которыми команда познакомилась достаточно хорошо и собрала массу полезной и уникальной информации. Поскольку к технологическому компоненту постоянно предъявляются новые требования, область его применения расширяется и изменяется, то разумно выполнять доработку и поддержку компонента в рамках проекта, для которого есть своя база знаний, набор требований, тестовая и пользовательская документация, бинарные или исходные коды. Проект по поддержке технологического компонента включается (связывается) со всеми проектами, в которых используются его результаты. В настройках связи с технологическим проектом вы указываете экспорт базы знаний, блога проекта, пользовательской документации и файлов.

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

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

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

Измерение прогресса по выполненным пожеланиям

Суть данного подхода заключается в оценке частей работы (пожеланий) в удобных для вас единицах измерения. Это могут быть астрономические часы, идеальные часы, некоторые весовые параметры (например, story points) или же, как в известном мультике, обычные попугаи. Завершив реализацию очередного пожелания, вы просто переводите его в состояние "Выполнено". При этом DEVPROM вычисляет скорость работы вашей команды путем деления суммарной оценки выполненных пожеланий на продолжительности этапа работ (релиза). Исходя из этого параметра оценивается продолжительность оставшейся части работ, и, как следствие, прогнозируются сроки завершения очередного этапа работ или всего проекта.

Низкая степень детализации задач

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

Высокая степень детализации задач

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

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

Проект поддержки

Проектный портал

• в гибких методологиях, например, Scrum - это использование коротких итераций, по результатам которых выпускается работающий продукт с требуемым качеством, то есть в котором нет значимых дефектов.
• в экстремальном программировании - это практика TDD, суть которой заключается в создании тестов перед тем, как будет осуществляться проектирование и реализация.
• в бережливом программировании (lean software development) - это повсеместное внедрение контролирующих механизмов на всех стадиях разработки, призванных выявить дефекты в понимании, артефактах и реализации и сразу же приступить к их устранению, не откладывая, например, редизайн архитектуры на фазу стабилизации или вообще сопровождения выпущенного продукта.
• в более формализованных практиках (MSF Agile, Agile RUP) - это верификация требований, дизайна, исходного кода и других артефактов путем применения более-менее формального метода, например, ревью или восстановления предыдущего артефакта на основе последующих.

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

Что интересно, ведь многие команды понимают и часто принимают эти идеи подсознательно, но не спешат внедрять в своих процессах раннее тестирование, может быть потому, что боятся некоторой неопределенности. Возникают следующие вопросы: Каким образом выполнять раннее тестирование? Например, как можно проверить что-то, если еще нет продукта, который можно пощупать? Ответов может быть много: делайте прототипы, используйте методы верификации артефактов, например, дизайна. Однако, на мой взгляд, правильный ответ: это зависит и никто толком не знает как, исследуйте и придумывайте. Это тот самый случай, где нужно применить всю вашу фантазию и творчество. Как встроить эту практику в процесс создания программных продуктов? Конечно, нужна определенная дисциплина и соблюдение правил игры. И в этом вам может помочь DEVPROM, в котором фокус смещен с простого учета артефактов (дефектов) на вовлечение всей команды в полноценную работу над продуктом. При планировании пожеланий в итерации система автоматически предлагает создавать задачи по всем используемым фазам разработки. Таким образом, планируя пожелание по сбору требований или проектированию архитектуры приложения, вы не забудете о необходимости тестирования подготовленных артефактов. То есть, DEVPROM дисциплинирует команду с тем, чтобы тестирование разрабатываемого продукта выполнялось на всех этапах его развития.

Основные изменения в 2.7.4

1. Создание пожеланий по email
2. Дублирование пожеланий между проектами
3. Подписка на изменения объектов (watching)
4. Генерация справочной документации в формате .chm
5. Удобное вертикальное меню на основных вкладках
6. Новые возможности конфигурации системы
7. Запрос пользователя на получение прав доступа к закрытым объектам (Enterprise Edition)
8. Возможность полноценной работы отдела SD (Enterprise Edition)
9. Отчет по загрузке ресурсов (Enterprise Edition)

1. Создание пожеланий по email

В настройках системы появилась возможность подключать автоматически отслеживаемые электронные почтовые ящики (exchange или pop3). При отправке письма на заданный email, в связанном с этим адресом проекте будет создано новое пожелание.



Теперь вы можете создать отдельный проект поддержки (или использовать для этих целей основной проект разработки), назначить ему email, например productsupport@company.ru и пользователи вашего продукта смогут отправлять вам баг-репорты и другую необходимую информацию.

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

2. Дублирование пожеланий между проектами

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



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

3. Подписка на изменения объектов (watching)

Часто бывает, что какое-то пожелание или требование нужно "поставить на контроль" - то есть быть в курсе всех изменений, а так же отсутствия изменений по этому объекту.



Вы можете установить наблюдение (watching) за нужным пожеланием или артефактом (требованием, тестовым сценарием), при этом при любом его изменении вам будет приходить почтовое уведомление.

Вы так же сможете просматривать список наблюдаемых объектов, чтобы в случае отсутствия активности по ним вовремя ее инициировать.

4. Генерация справочной документации в формате .chm

Помимо возможности экспорта документации в HTML по выбранному шаблону стилей, в новой версии системы появилась возможность экспорта справочной (или пользовательской) документации в формате .chm (Microsoft Help).



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

5. Удобное вертикальное меню на основных вкладках

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



Теперь меню представляет собой вертикальный список, который позволяет быстро и легко перейти к нужному объекту системы.

6. Новые возможности конфигурации системы

В настройках методологии проекта добавились новые опции: использовать релизы и управление версиями.

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

Вторая опция (управление версиями) позволяет не использовать нумерацию версий создаваемого продукта, что может пригодиться, например, если вы ведете исследовательский проект, в котором нет версионности продукта.

7. Запрос пользователя на получение прав доступа к закрытым объектам (Enterprise Edition)

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



Теперь в случае, если у кого-то из получателей одной из ваших ссылок нет прав на просмотр информации по ней в DEVPROM, этот человек сможет запросить доступ к ссылке у администраторов системы.
Все такие запросы попадают в отдельный проект, Администрирование DEVPROM, и могут отслеживаться сотрудниками SD.

8. Возможность полноценной работы отдела SD (Enterprise Edition)

При использовании DEVPROM в крупных компаниях, появилась необходимость обеспечить полное администрирование системы отделом Service Desk (SD) компании.



Для этого в панель администрирования мы добавили возможность создать новый проект (по запросу менеджера, например), добавить в проект участников и указать им необходимые права доступа.

В случае необходимости, сотрудники SD могут удалить любого участника из нужного проекта, или вообще заблокировать его вход в систему.

9. Отчет по загрузке ресурсов (Enterprise Edition)

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

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



Отчет показывает два состояния занятости - ресурс включен в проект (с указанной загрузкой более 0) и на ресурс назначены проектные задачи.

Отчет по загрузке ресурсов доступен как внутри одного проекта, на закладке Участники, так и для всех проектов компании, на закладке Загрузка ресурсов.

10. Прочие улучшения и исправления ошибок

• [I-1324] Версионность должна отключаться. Работу с версиями продукта необходимо отключать...
• [I-1803] Реализовать возможность попросить у администратора доступ - например, при перехо...
• [I-1877] Возможность подписки на изменения по определенным пожеланиям, требованиям и тест...
• [I-2820] Подменю в закладках нужно переделать в вертикальное, иначе с ним трудно работать
• [I-2822] Для организации поддержки необходима возможность создания пожелания по email
• [I-2823] У администраторов системы должна быть возможность добавить участника в любой проект
• [I-2827] На закладку Лицензии добавить ссылку Получить еще лицензий
• [I-2830] Продублировать пожелание в проекте - организация поддержки продукта
• [I-2879] Вики - шаблоны страниц не должны участвовать...
• [I-2979] Необходимо убрать почтовую нотификацию о действиях...
• [I-3982] Позволять отключать работу с релизами в проекте
• [I-3983] Сделать отдельную страницу с не найденным URL
• [I-4086] Добавить в статусную строку системы ссылку Сообщить о проблеме - ведет на сайт...
• [I-4087] При открытии журнала пожеланий релиза нужно по-умолчанию ставить фильтр Невыполненные, как...
• [I-4116] Реорганизовать обработку и настройку периодически выполняемых заданий
• [I-4173] Экпорт документации для компиляции в chm. Нужно иметь возможность на странице экпорта...
• [I-4202] При клике на журнал пожеланий релиза необходимо показывать только невыполненные пожелания, так...
• [I-4203] Если задаче назначается статус "Отклонена", то она оказывается на доске в колонке...
• [I-4205] Некорректно отображаются ссылки на выполнение теста
• [I-4206] Если сегодня еще идет последний день итерации, а я переключился на следующую,...
• [I-2852] Ваша система при установке запаролила мне...
• [I-2980] В экспорт вики в HTML попадают...
• [I-2981] При экспорте в RTF раздела, имеющего...
• [I-4001] Пишем сообщение блога, не указываем тему, нажимаем Сохранить - страница перезагружается, показывает сообщение...
• [I-4005] При создании тестового набора есть возможность сохранить его как шаблон, при этом...
• [I-4017] Здравствуйте! Есть небольшой косяк во вкладочке SVN при выводе содержимого репозитория. При...
• [I-4025] Создал пожелание, проставил ответственного и трудоемкость в 2 часа потом запланировал в...
• [I-4054] При создании задачи в итерации можно указать ее состояние. Если указать Выполнена,...
• [I-4088] При отключенном планировании задач, если планировать пожелание в релиз, создается невидимая задача...
• [I-4102] Не появляется ссылка на журнал пожеланий: создал релиз, добавил в него пожелания,...
• [I-4103] В инсталляторе на линукс нужно первым делом проверять версию установленного Php, и...
• [I-4104] Архив в документации не работает. Берем страницу из середины иерархии, отправляем в...
• [I-4177] Версия 2.7.3 При создании нового...
• [I-4186] Не могу создать задачу. Сообщает об отсутствии обязательного поля (которого вообще в...
• [I-4200] Версия 2.7.3 Не показываются добавленные...
• [I-4218] Итерация не переключилась на следующую. Итерация 0.1 заканчивалась 21.05.2010. Следующая 0.2 началась...
• [I-4249] У нас в проекте 3 человека, но реально на странице итерация отображается...
• [I-4255] После создания задачи номер итерации некорректно отображается. Подробности на скриншотах.
• [I-4265] Обеспечить поддержку php больше 5.2.9

Благодарности

Еще раз хочется сказать спасибо всем, кто принимал активное участие (прямое или косвенное) в подготовке этой версии DEVPROM.

И отдельное спасибо одному из самых активных пользователей DEVPROM, помогающих улучшить систему - Андрею за его ценные баг-репорты и комментарии.
]]>

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

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