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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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