Как вывести ИТ-продукт на рынок. Часть 3: Проверка на прочность (архитектура, компетенции, качество)

Выбор архитектурного решения: компетенции архитектора

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

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

Важно проверить:

• Насколько гибкой является система по отношению к новым системным требованиям (исходя из того, что ее ждет развитие).
• Насколько масштабируема система, чтобы выдержать возрастание нагрузки.
• Какими могут быть пиковые нагрузки на систему в целом и на каждую подсистему, если речь о комплексной структуре.
• Что случится в непредвиденных ситуациях (отказ системы), приведет ли это к повреждению данных или их потере.
• Произведена ли оценка количества одновременных подключений к серверу(ам): веб-пользователи, подключения к БД (базам данных).
• Произведена ли оценка среднего времени отклика при работе пользователя с системой, соответствует ли это время установленным требованиям.
• Произведена ли оценка стратегий кэширования данных на каждом слое, включая БД, бекенд- и фронтенд-сервисы.
• Если говорить о внесении изменений в уже доступную пользователям версию ПО, планируются ли значительные, затратные по времени задачи по обновлению данных и сервисов. Если да, то нужно ли при этом сохранить доступ пользователей к системе и как.
  
  

Проверка компетенций: как оценить разработчиков

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

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

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

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

Команда тестирования: проверка качества ПО

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

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

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

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

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

Фото на обложке: Shutterstock/Aksonsat Uanthoeng