Начать проект
Процесс поддержки и развития
Описание процесса поддержки и развития it-решений в нашей компании
13 августа 2020
6 минут на чтение
Обслуживание включает в себя работы по поддержанию работоспособности системы (мониторинг, реакция на инциденты, обслуживание ПО и инфраструктуры) и работы по развитию функциональных и нефункциональных характеристик системы (новые функции, изменение существующих, нефункциональные изменения и др.).
В отличие от первичной разработки, на этапе поддержки присутствует сильная приоритизация задач и требования к оперативности выполнения и внедрения изменений. Это создает постоянный поток внутренних задач и необходимость часто обновлять используемый продукт, что может привести к рискам сбоев и ошибок.
Чтобы систематизировать этот процесс, мы применяем простую методологию, похожую на Scrum, в основе которой спринты и регулярные релизы.
Если коротко, поступающие задачи (запросы на изменения, ошибки, и др.) планируются по фиксированным отрезкам времени (спринтам), по завершению которых осуществляется тестирование и публикация новой версии системы. Большие задачи могут быть разделены на несколько спринтов. В зависимости от специфики проекта, в спринтах закладывается заранее определяемый буфер на срочные работы.
Запрос на изменение (change request)
В большинстве проектов после первого релиза в процессе эксплуатации возникают потребности в новых функциях или изменении существующих. Такие задачи мы называем «Запрос на изменения» от англ. Change request). Для владельца системы запрос изменений — это просто общее описание того, что нужно сделать.
Запросы на изменения могут быть и в процессе первичной разработки. В этом случае оценивается их влияние на план разработки, и по результатам оценки либо учитываются в первом релизе, либо планируются на первый спринт в рамках поддержки.
Перед планированием работ запросы анализируются. По результатам формируются новые требования и/или изменения/дополнения к существующим. Иногда запрос может быть достаточно общим и включать сразу несколько изменений/дополнений требований.
Далее осуществляется анализ требований, также называемый «трассировка требований». Трассировка требований — это отслеживание влияния изменений на логические и физические элементы системы (программные элементы, экраны, инфраструктурные элементы и др.).
По результатам трассировки мы получаем информацию о том, какие элементы нужно изменить или создать, и насколько объемные работы необходимы по каждому элементу. Это позволяет получить плановую оценку времени для каждой задачи.
Полученные задачи планируются внутри спринта. Для крупных изменений задачи могут быть распланированы на несколько спринтов (при необходимости, для избежания конфликтов перед релизом ближайшего спринта, изменения осуществляются в отдельной «ветке» в системе контроля версий, которая по завершению объединяется с основной версией).
Спринт
Спринт — это фиксированный отрезок времени (обычно от 1 до 4-х недель).
Размер спринта определяется заранее и зависит от интенсивности планируемых работ и их объема (это обычно зависит от характеристик проекта). По завершению спринта осуществляется обновление эксплуатируемой системы (production-версии).
При формировании спринта применяются следующие правила:
- Задачи в спринт добавляются до его начала
- В спринте закладывается небольшой буфер для срочных неотложных задач
- Задачи приоритизируются (если фактическое время оказывается существенно выше планового, задачи в низким приоритетом могут быть перенесены в следующий спринт)
- Добавлять задачи в спринт в процессе выполнения спринта нельзя (за исключением небольших критичных задач, для которых предусмотрен буфер)
Процессы производства
Работы, необходимые для постановки задачи, оценки объема и формирования подробного видения продукта при первом релизе и на ближайшее будущее.
Задачи
- Сбор и анализ требований
- Формулирование функциональных требований и критериев приемки
- Формулирование нефункциональных требований
- Формулирование интеграционных требований
- Формирование модели данных
- Прототипирование пользовательских интерфейсов
Артефакты
- Спецификация требований к ПО (wiki-сайт)
- Функциональные требования
- Модель данных
- Интеграционные требования
- Нефункциональные требования
- Прототипы пользовательских интерфейсов
Формирование технического проекта, включающего описание программной логики, элементов и компонентов (сервисы, репозитории, модели, контроллеры и т.д.), принципов межсистемного взаимодействия, серверной архитектуры (инфраструктуры) и т.д.
Основная задача технического проектирования — сформировать модель системы на уровне программных единиц и формализовать их взаимодействия. Для удобства дальнейшей поддержки и обслуживания модель должна позволять отслеживать связь требований с программными элементами, задействованными в ее реализации.
Артефакты
- Технический проект
- Структура базы данных
Разработка дизайн-концепции пользовательского интерфейса и разработка полного комплекта макетов для экранов в соответствии с прототипами.
Артефакты
- Дизайн-концепция
- Комплект дизайн-макетов
Процесс разработки кода включает широкий спектр работ, результатом которых является работающее ПО. Разработка кода осуществляется на основе следующих артефактов:
- Спецификация требований к ПО
- Прототипы пользовательского интерфейса
- Технический проект
- Комплект дизайн-макетов (процессы верстки и front-end разработки)
При разработке внутри команды осуществляется интенсивная коммуникация, что позволяет сэкономить время.
В зависимости от типа проекта, разработка может вестись параллельно для разных систем разными по специализации разработчиками.
Этап стабилизации и тестирования, фактически является продолжением этапа разработки, но с введением в работе QA-специалистов. Обычно этап стабилизации начинается за 1-2 месяца до завершения проекта, когда есть готовность порядка 80% работ по разработке кода.
На этапе тестирования и стабилизации осуществляется ручное и автоматизированное функциональное тестирование, тестирование API и другие процессы проверки результатов. Также готовятся инструменты для формализации тестирования: тест-кейсы, чек-листы и т.д.
QA-специалисты и далее продолжают работать с проектом.
На этапе развертывания и внедрения осуществляется работа публикации и финальной подготовке эксплуатационной и тестовых версий. Если в проекте есть мобильные приложения, на этом этапе осуществляется их публикация в маркетах.
В зависимости от масштабов и сложности проекта, работы по обеспечению серверной инфраструктуры могут занимать от нескольких человеко-дней до нескольких человеко-месяцев.
Для MVP версии эти работы обычно минимальны, т.к. нет требований по обеспечению высоких нагрузок и отказоустойчивости. После релиза, по мере роста проекта эти требования могут появиться и это повлечет рост объема работ по серверной инфраструктуре.
Административное управление проектом:
- Подготовка проектной среды
- Формирование команды
- Планирование и контроль задач
- Административные задачи (выставление счетов, актов и т.д.)
Управление и контроль концептуальной и смысловой части разрабатываемого продукта, поддержка требований и модели разрабатываемого ПО. Это множество различных задач, у которых есть две ключевые цели:
- Сохранить фокус на бизнес-задачах клиента в процессе всей разработки от старта до внедрения
- Внести дополнительную ценность в продукт за счет опыта компании, современных решений и т.д.
