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, тем самым вы обеспечите быструю обратную связь от разработчиков и возможность быстро адаптировать приложение под изменяющиеся бизнес-требования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наши типовые процессы делятся на две основные категории:

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

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

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

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

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

За технологию реализации первичных требований - этапы производства ПО - отвечают статусы требований и задачи.

В отличии от универсальных инструментов управления проектами или задачами, при управлении разработкой ПО мы управляем не только задачами, но и требованиями. Это принципиальное отличие является основной для автоматизации процессов разработки в Devprom ALM.

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

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

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

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

Управление проектом на стадии поиска и создания продукта осуществляется на основе Scrum.

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

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

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

Пользовательские требования будущего релиза управляются процессом на основе Scrum. Здесь, как и в процессе "Поиск и создание продукта", осуществляется планирование спринтов, декомпозиция требований на задачи, демонстрация и приемка реализованной функциональности. Из-за того, что часть усилий команды будет оттягивать текущий релиз, требования к срокам (или составу) спринтов смягчаются.

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

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

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

С точки зрения управления проектом, в данном процессе используется подход Software Kanban. Это простой процесс из бережливого производства (Lean Management). Есть суть заключается в следующем:

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

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

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

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

На этапе проектирования участвуют:

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

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

На этапе разработки участвуют:

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

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

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

Процесс используется при контрактной разработке.

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

Детальные требования могут быть предварительно оценены на основе экспертного мнения участников команды. Результаты оценки можно зафиксировать для каждого требования в поле "Оценка, ч." Суммарная оценка для всего ТЗ может использоваться для оценки объема и стоимости работ по ТЗ.

При необходимости получить более детальную оценку, с учетом различных затрат на разного вида работы, для каждого раздела ТЗ создается набор задач, выполнение которых приводит к реализации данного требования. Это могут быть задачи связанные с проектированием интерфейсов, разработкой, тестированием и документированием. Модуль "Трудозатраты по ТЗ" позволяет увидеть подробную смету работ по данному ТЗ. Смету можно выгрузить в Excel для передачи заказчику. При использовании бюджетирования каждому исполнителю можно задать рейт (стоимость часа работы), тогда при помощи модуля "Расходы по требованиям" вы сможете получить детальную смету на проект в деньгах.

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

Управление сроками выполнения ТЗ осуществляется в модуле План. Выполнение ТЗ лучше организовать итерационно - создать итерации, распланировать работы по ним, с использованием модуля "Оперативный план". При помощи настройки группировки доску задач можно разделить по исполнителям или по требованиям.

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

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

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

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

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

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

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

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

План реализации требований можно представить в виде релизов или итераций.

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

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

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

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

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

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

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

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

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

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

Для автоматизации процессов поддержки и разработки создайте два проекта: проект по поддержке создайте на основе шаблона "Поддержка", а проект по разработке - на основе шаблона "Баг-трекинг", например.

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

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

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

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

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

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