Начать проект

Проконсультируем и сориентируем по необходимому бюджету и срокам разработки. Заполните форму или отправьте нам письмо.

Процесс поддержки и развития

Описание процесса поддержки и развития it-решений в нашей компании

Дмитрий Юркин
13 августа 2020
6 минут на чтение

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

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

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

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

  • Основные процессы
  • Управление требованиями
  • Техническое проектирование
  • Интерфейс (UI/UX)
  • Программирование
  • Стабилизация и тестирование
  • Развертывание и внедрение
  • Инфраструктура
  • Поддерживающие процессы
  • Управление проектом
  • Управление продуктом

Запрос на изменение (change request)

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

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

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

Далее осуществляется анализ требований, также называемый «трассировка требований». Трассировка требований — это отслеживание влияния изменений на логические и физические элементы системы (программные элементы, экраны, инфраструктурные элементы и др.).

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

1
Запрос на изменения
Получение запроса на доработки или изменения в свободной форме.
2
Требования
Определение необходимых изменений в требованиях к системе.
3
Задачи
На основе требований формируются задачи для разработчиков.
Выполнение
Задачи планируются в спринт, выполняются и внедряются с новой версией системы.

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

Спринт

Спринт — это фиксированный отрезок времени (обычно от 1 до 4-х недель).

Размер спринта определяется заранее и зависит от интенсивности планируемых работ и их объема (это обычно зависит от характеристик проекта). По завершению спринта осуществляется обновление эксплуатируемой системы (production-версии).

При формировании спринта применяются следующие правила:

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

Процессы производства

Основные процессы
Управление требованиями

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

Задачи

  • Сбор и анализ требований
  • Формулирование функциональных требований и критериев приемки
  • Формулирование нефункциональных требований
  • Формулирование интеграционных требований
  • Формирование модели данных
  • Прототипирование пользовательских интерфейсов

Артефакты

  • Спецификация требований к ПО (wiki-сайт)
  • Функциональные требования
  • Модель данных
  • Интеграционные требования
  • Нефункциональные требования
  • Прототипы пользовательских интерфейсов

Подробнее о проектировании и требованиях.

Техническое проектирование

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

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

Артефакты

  • Технический проект
  • Структура базы данных
UI/UX

Разработка дизайн-концепции пользовательского интерфейса и разработка полного комплекта макетов для экранов в соответствии с прототипами.

Артефакты

  • Дизайн-концепция
  • Комплект дизайн-макетов
Программирование

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

  • Спецификация требований к ПО
  • Прототипы пользовательского интерфейса
  • Технический проект
  • Комплект дизайн-макетов (процессы верстки и front-end разработки)

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

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

Стабилизация и тестирование

Этап стабилизации и тестирования, фактически является продолжением этапа разработки, но с введением в работе QA-специалистов. Обычно этап стабилизации начинается за 1-2 месяца до завершения проекта, когда есть готовность порядка 80% работ по разработке кода.

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

QA-специалисты и далее продолжают работать с проектом.

Развертывание и внедрение

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

Обеспечение серверной инфраструктуры

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

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

Поддерживающие процессы
Управление проектом

Административное управление проектом:

  • Подготовка проектной среды
  • Формирование команды
  • Планирование и контроль задач
  • Административные задачи (выставление счетов, актов и т.д.)

Управление продуктом

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

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

Проектируем. Разрабатываем. Внедряем.