УПРАВЛЕНИЕ ПРОЕКТАМИ ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: СОВЕТЫ ПО РЕШЕНИЮ ПРИЛОЖЕНИЙ

dis.agency
Опубликовано :2021-10-18 | Блог
УПРАВЛЕНИЕ ПРОЕКТАМИ ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ: СОВЕТЫ ПО РЕШЕНИЮ ПРИЛОЖЕНИЙ

  При выборе команды разработчиков для вашего проекта, на что следует обратить внимание? 

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

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

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

Управление проектами по разработке программного обеспечения в компании The APP Solutions

Мы применяем SDLC (Software Development Life Cycle) в качестве методологии для проектов, которые мы разрабатываем с нуля, а также для существующих проектов, требующих модернизации функций, обновления программного обеспечения и рефакторинга кода. 

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

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

  • Анализ требований 
  • Процесс планирования
  • Проектирование программного обеспечения 
  • Архитектурное проектирование 
  • Разработка программного обеспечения 
  • Процесс тестирования
  • Процесс развертывания

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

  • Зарождение 
  • Инициация проекта 
  • Разработка проекта и обеспечение качества 
  • Заключительная демонстрационная сессия проекта
  • Техническая поддержка

Каждый из этих этапов требует сотрудничества заинтересованных сторон с различными членами команды. Давайте рассмотрим каждый этап разработки программного обеспечения в The APP Solutions более подробно.

Фаза 1. Вовлечение 

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

Каждая неделя фазы взаимодействия имеет свои цели и результаты:

Неделя 1. Понимание

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

Мы достигаем этих целей путем:

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

Неделя 2. Определение

Мы формируем видение проекта и создаем список функций для первой версии проекта с базовыми возможностями, т.е. MVP (Minimum Viable Product) проекта и функциями для полноценной версии продукта.  

В течение второй недели этапа вовлечения разработчики The APP Solutions посвящают себя следующему 

  • Установление границ объема работ
  • Проведение приоритезации объема работ
  • Опредeление объема MVP
  • Создание архитектурного видения

Неделя 3. Портрет

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

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

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

Задачи на третью неделю включают: 

  • Проведение сессии технической оценки
  • Организация сессии по выяснению требований 
  • Изменение визуального стиля проекта 

Неделя 4. Результат

Мы разрабатываем реалистичную дорожную карту продукта, которая поддерживает вашу коммерческую дорожную карту.

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

В течение последней недели этапа вовлечения мы занимаемся:

  • сбором объема проекта для релиза 0.1
  • Написанием плана ресурсов для объема проекта для релиза 0.1 
  • Завершением описания требований 

Основные результаты начальной фазы

По истечении четырехнедельного периода наша команда подготовила следующие результаты фазы вовлечения: 

  • Техническая документация 
  • Архитектура системы 
  • План ресурсов 
  • Видение UI/UX

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

Фаза 2. Инициация проекта

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

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

Основными результатами фазы инициации проекта являются:

   План коммуникаций

Коммуникационный план - это документ, в котором указаны все сообщения, которые делает наша команда на этапе разработки проекта.

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

Коммуникационный план включает в себя расписание:

  • Ежедневные Scrum-собрания. Их цель - каждый день синхронизировать менеджера проекта с командой о прогрессе/блокировках/плане на следующий день. 
  • Еженедельные встречи по планированию. Раз в неделю менеджер проекта встречается с командой разработчиков для определения приоритетности задач на следующую неделю и улучшения обзора журнала. Менеджер проекта записывает поступающую информацию из записей встреч команды, чтобы не упустить важные детали. 
  • Финaнсовые отчеты. Менеджер проекта создает финансовые отчеты в формате PDF со списком всех потраченных часов и разбивкой задач для заказчика, чтобы обеспечить прозрачность ежемесячных расходов и затраченного времени. Заказчик получает финансовый отчет в первый день месяца.  
  • Ежемесячные отчеты. Менеджер проекта просматривает созданные задачи на основе запросов и составляет ежемесячный отчет с входящими запросами от клиента и запросами, которые мы выполнили. 
  • Встречи по доставке. Директор по доставке и клиент обсуждают процессы на более высоком уровне и записывают результаты встреч. 

   Стартовая встреча

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

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

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

Менеджер проекта и бизнес-аналитик создают бэклог проекта с задачами.

  • Меджер проекта и владелец продукта определяют приоритетность задач в бэклоге.
  • Менеджер проекта, владелец продукта и остальные члены команды разработчиков оценивают первый спринт, т.е. количество времени, необходимое для реализации требуемой функциональности.
  • Технический руководитель создает общую архитектуру проекта.
  • Менеджер по обеспечению качества создает контрольный список для функциональности проекта, который он будет использовать, чтобы убедиться, что функции проекта работают так, как должны.
  • Системный администратор создает CI/CD-репозиторий GitLab, в котором команда будет развертывать и хранить различные версии кода проекта. 
  • Системный администратор настраивает среды Development и Stage. Среда разработки - это среда для кодирования. Среда Stage (staging или pre-production) - это среда для тестирования, напоминающая производственную среду.

Фаза 3. Разработка проекта и контроль качества

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

  • Планирование спринта 

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

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

На этом этапе руководитель проекта и команда разработчиков

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

Определение выполненной работы 

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

Команда разработчиков определяет определение done для каждой функции проекта во время весеннего планирования: 

Разработчик оценивает время, необходимое для выполнения конкретной задачи.

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

Окончание спринта 

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

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

Улучшение проекта 

Улучшение проекта - это объем работ, которые разработчики должны выполнить, чтобы функции проекта соответствовали определению "сделано":

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

Резервные копии

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

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

Команда создает резервные копии репозиториев GitHub с критическими активами проекта, включая:

Кодовая база                        

  • Инфраструктура и конфигурация                         
  • Базы данных .                        
  • Затем менеджеры QA тестируют каждую резервную копию проекта.

Итерация за итерацией команда разработчиков APP Solutions проводит весеннее планирование, кодирование, исправление ошибок, создание резервных копий и тестирование до финальной демонстрации проекта.

Фаза 4. Окончательная демонстрация

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

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

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

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

Этап 5. Техническая поддержка 

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

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

Команда технической поддержки 

Типичная команда технической поддержки включает в себя: 

  • Инженер DevOps поддерживает работоспособность сети и исправляет ошибки на сервере 
  • Менеджер поддержки (или оператор обратной связи) собирает запросы пользователей (инструктаж, прием жалоб, обработка заявок и предложений)
  • Разработчик поддержки вносит любые срочные изменения в проект для обеспечения оперативного устранения критических проблем, минуя бэклог улучшений проекта

Техническая поддержка на 3 уровнях 

В компании The APP Solutions существует три различных уровня технической поддержки, которые зависят от сложности проекта, потребностей заинтересованных сторон и зрелости бизнеса клиента: 

Уровень 1. Служба технической поддержки

На уровне службы технической поддержки команда The APP Solutions обеспечивает: 

  • Обработку инцидентов и запросов 
  • Решение общих, типичных и ранее задокументированных проблем
  • эскалация проблем
  • Сбор статистики

Уровень 2. Управление вопросами/проблемами

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

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

Уровень 3. Разработка продукта

В рамках третьего уровня технической поддержки компания The APP Solutions предоставляет специальную команду, которая занимается

  • Разработкой постоянных решений для проблем, возникающих в результате редкого устранения
  • Выпуском и развертыванием управления для согласования изменений в системе с меняющимися потребностями бизнеса

Модели кооперации

Модель сотрудничества определяет количество обязанностей, с которыми сталкивается команда разработчиков при создании проекта. Существует три основных модели сотрудничества - Managed Services, Dedicated team и Extended team. Давайте объясним их по порядку.

 

Managed Services - это модель сотрудничества, при которой команда The APP Solutions управляет всеми процессами разработки продукта, а вы получаете свободу и время для развития своего бизнеса. Эта модель сотрудничества лучше всего подходит для создания сложных продуктов, таких как веб- или мобильные приложения, с нуля и предоставления услуг технической поддержки. 

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

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

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

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

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

Управление проектами для разработки программного обеспечения: Советы APP Solutions

У команды APP Solutions есть шесть главных ценностей, которые отличают нас от других компаний, занимающихся разработкой программного обеспечения: 

Счастье как KPI. Мы фокусируемся на вещах, которые имеют значение. Мы знаем, как позаботиться о проблемах вашего бизнеса и превратить их в решения. 

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

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

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

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

Проверка состояния проекта. Мы гарантируем, что проект идет правильно, применяя лучшие практики Project Health Check для сравнения характеристик и качеств проекта с отраслевыми стандартами.

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

Работаем вместе?

Свяжитесь с нами +373 69 423 639
+373 68 057 085
Не можете сделать выбор? Задайте вопрос эксперту!