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

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

Встроенные шаблоны

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

• Управление жизненным циклом разработки
• В этом шаблоне максимально используются все возможности DEVPROM: управление пожеланиями, версиями, релизами, планирование итераций и задач, разработка требований, тестовой и справочной документации, выполнение тестирования, трассировка проектных артефактов. Структура требований и тестовой документации содержит типовые разделы. Доступны следующие шаблоны артефактов: вариант использования, тестовый случай.
• Этот шаблон подойдет командам, использующим свой собственный полноценный процесс разработки программных продуктов.
• Разработка по процессу OpenUP
• В этом шаблоне содержатся все типовые документы и структура документации для организации процесса разработки по OpenUP. В проекте, созданном по этому шаблону, вы найдете соответствующие названия ролей участников проекта, описание стадий процесса, соответствующие типы активностей, шаблоны для статусных встреч и ретроспектив.
• Данный шаблон подойдет тем командам, которые хотят использовать принципы и практики Agile, но дополнительно хотят иметь формализованное описание процесса разработки, в котором сосредоточены советы, описаны контрольные проверки и распределены зоны ответственности между всеми участниками проекта, а также шаблоны артефактов (статус-репорты, варианты использования, тестовые сценарии и т.п.), продробнее
• Управление задачами
• В этом шаблоне отключена функциональность, связанная с подготовкой артефактов проекта, например, требований или тестовой документации. Команда проекта управляет пожеланиями, формирует планы работ, детализирует задачи по реализации пожеланий.
• Этот шаблон подойдет для упрощенного процесса разработки ПО, в который вовлечено несколько участников, и при этом не требуется создавать какой-либо проектной документации. Используйте шаблон для организации поддержки программных продуктов.
• Управление ошибками и пожеланиями
• По сравнению с шаблоном "Управление задачами" в данном шаблоне отключено планирование задач на участников проекта. Используйте этот шаблон для исследовательских проектов, разработки небольших приложений, поддержки программных продуктов, когда количество участников не превышает 2-3 человек, когда не требуется детальное планирование их деятельности.
• Обработка заявок
• Этот шаблон предназначен для отслеживания выполнения каких-либо заявок, например, проект по администрированию DEVPROM как раз организуется по процессу, описанному в этом шаблоне.

Вы конечно же можете произвольным образом комбинировать эти шаблоны, создавая свои собственные, соответствующими специфике вашей команды, заказчиков, уровню зрелости процессов и т.п. Для этого необходимо создать проект с использованием готового шаблона и перейти к настройкам проекта, где вы можете подключить те или иные функциональные возможности DEVPROM, выбрать используемые опции методологии, настроить справочники. Вы можете посмотреть на особенности каждого шаблона на примере демонстрационной версии: http://demo.pmcloud.ru

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

Система управления проектами DEVPROM позволяет разработчикам ПО готовить справочную документацию к программным продуктам без использования дополнительных инструментов, например, Author-It или RoboHelp, предоставляя следующие ключевые возможности:

• Создание любого количества справочных документов произвольной вложенности при помощи Wiki.
• Экспорт документации в различные форматы: RTF (MS Word), HTML, CHM (Microsoft Help).
• Автоматическое связывание разделов справочной документации с исходными требованиями к продукту.
• Отслеживание актуальности покрытия разделами документации исходных требований, трассировка требований в разделы справочной документации.
• Планирование задач по подготовке справочной документации, интегрированное в общий процесс разработки ПО.
• Списание времени, затраченного на подготовку или исправление справочной документации.
• Рецензирование справочной документации путем вовлечения всей команды проекта.

Возможности экспорта

Если вам важно подготовить документацию, но не важно ее оформление, то используйте простые возможности экспорта: HTML и RTF. При этом используются стандартные стили для каждого формата экспорта.

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

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

Примерно год назад мы открыли для себя mindmaps в качестве очень удобного дополнительного инструмента в работе над проектами.

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

• Фиксирование результатов митингов
• Формирование состава работ для мини-проектов
• Координирование оперативной работы при выкате сборки на продакнш

Фиксирование результатов митингов

Можно писать meeting minutes в виде письма, можно оформлять в виде документа Word, а можно вести минутки митингов в виде mindmaps.

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

Просто и наглядно. Скорость восприятия информации - невероятная.

Но есть один минус, специально его не буду указывать - скажете, какой?

Мини-проекты

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

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

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

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

Единственное неудобство - невозможность положить mindmap в быстром и редактируемом виде в вики проекта, приходится вставлять как картинку.

Но тем не менее, даже такой способ крайне удобен для совместной работы команды:

• каждый может посмотреть текущее состояние дел и последние результаты на проектном портале
• даже после долгого перерыва, один взгляд на mindmap позволяет, что называется, "вспомнить все".

Координирование оперативной работы

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

В качестве примера:

А вы используете карты памяти на своих проектах?

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

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

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

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

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