Devprom ALM: Руководство пользователя

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

Существует множество подходов в управлении проектами и активностями. Необходимо понять, каким образом Devprom ALM поддержит ваш стиль управления.

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

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

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

Проектом является деятельность команды нацеленная на определенный результат. Когда результат (цели проекта) достигается, то проект считается завершенным. Есть некоторые виды деятельности, которые не являются проектами, например, поддержка пользователей или сопровождение продукта. Такие виды деятельности мы называем "Активности".

В Devprom ALM вы можете управлять как проектами, так и активностями на основе встроенных или ваших собственных процессов. Каждый проект или активность характеризуются:

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

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

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

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

Когда мы говорим об управлении чем-то, мы представляем цели, связанные с ними цепочки работ или дерево задач, своевременное выполнение которых приводит нас к нужному результату. В традиционном управлении проектами это называется структура декомпозиции работ (СДР или WBS). С этой точки зрения Devprom ALM предоставляет следующие возможности по структурированию деятельности:

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

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

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

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

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

Создание портфелей осуществляется вручную, однако, в системе предусмотрено два встроенных портфеля: Мои проекты и Все проекты.

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

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

Создание и настройка

Для создания портфеля перейдите по ссылке "+Портфель"

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

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

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

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

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

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

Программа проектов применяется при кастомизации типового решения, на проектах внедрения, для организации поддержки и сопровождения программных продуктов и т.п.

Создание и настройка

Для создания программы проектов вы можете создать проект, который будет являться программой, а затем добавить в него подпроекты при помощи кнопки "+Подпроект":

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

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

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

Проектная конфигурация выглядит следующим образом:

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

Проектная конфигурация выглядит следующим образом:

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

Проектная конфигурация выглядит следующим образом:

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

Проектная конфигурация выглядит следующим образом:

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

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

Проектная конфигурация выглядит следующим образом:

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

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

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

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

Процесс управления разработкой может быть построен на базе Scrum или Kanban. Devprom автоматически подсчитает метрики, которые вы сможете использовать для контроля за ходом разработки продукта. Сохраняйте в базе знаний планы на спринты, результаты ретроспектив, важные технические решения.

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

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

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

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

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

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

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

Чтобы выстроить эффективный процесс качественной доработки типовых решений, используйте Kanban, который состоит из нескольких простых шагов.

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

Далее необходимо визуализировать процесс разработки на Kanban доске, то есть сделать прозрачными все этапы работ, включая сведения о том, кто чем занят. Это позволит понять на какой стадии находится требование, куда уходит время.

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

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

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

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

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

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

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

В задачи вашей команды входят:

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

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

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

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

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

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

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

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

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

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

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

Матрицы трассировки помогут проконтролировать и поддержать целостность реализуемой функциональности в ядре и кастомизированной версии.