Жизненный цикл проекта по созданию мобильного приложения

Опубликовано

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

Но как бы не так. Всё заметно сложнее. Постараемся навести порядок в этом многообразии.

Подходы к планированию циклов разработки мобильных приложений

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

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

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

Итак, начнём с лидеров IT-рынка.

Как видят жизненный цикл проекта по созданию мобильного приложения в компании Microsoft

К слову, Microsoft владеет крупнейшими IDE-системами для кроссплатформенной разработки, среди которых: Visual Studio (целая плеяда программных решений – редактор кода, IDE, среда для тестирования и среда для виртуализации), Xamarin (специализированная платформа для создания мобильных приложений под Android, iOS и Windows), язык программирования .NET (со связанным с ним фреймворком .NET Framework) и прочие.

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

  1. Зарождение – формирование основной идеи или концепции. На этом этапе разработчикам нужно определить, в чём будет заключаться ценность приложения как для конечных потребителей, так и для самих создателей. Необходимо также выяснить, с какими мобильными устройствами будет совместим софт, какие конкурентные преимущества он предложит (существуют ли аналоги, в чем их сильные стороны, чем ваше приложение сможет их превзойти и прочее), а также какие требования будут предъявлены к инфраструктуре (если таковые имеются). По сути, уже здесь команде нужно определить, кто будет субъектами взаимодействия и какими будут варианты использования.
  2. Проектирование – на этом шаге нужно детально описать и продумать модель взаимодействия с пользователями. Так как оно происходит непосредственно с графическим интерфейсом, то именно на нём и нужно сконцентрировать свои усилия. Но тут необходимо учесть особенности платформ и требования их вендоров. Например, есть официальные гайдлайны для Android, iOS и для Windows. В обязательном порядке должны быть продуманы элементы ввода и вывода, навигации, размещение основного содержимого, переходы между основными экранами и многое другое. Почти все вендоры предлагают типовые макеты интерфейсов в своих IDE-системах. Кроме того, можно подсмотреть варианты реализации у конкурентов (никто не осудит, если вы возьмёте лучшие идеи и примените в своём проекте). Обратите внимание на расположение элементов интерфейса в разных разрешениях экрана (планшеты, смартфоны) и положениях (вертикальное и горизонтальное), на наличие и размещение блоков камер и датчиков на фронтальной части устройства, на систему уведомлений и виджетов. Всё это тоже элементы взаимодействия с приложением. Макет приложения можно сначала набросать схематично, протестировать его, и только потом переходить к большей детализации.
  3. Разработка – этап написания бэкенда и недостающих частей фронтенда, то есть всего того кода, который выполняется после взаимодействия пользователя с приложением. Часть функций и основные концепции можно писать параллельно работе с макетом интерфейса (опытные разработчики с большой вероятностью могут определить парадигмы, которые будут присутствовать в конкретном проекте приложения).
  4. Стабилизация – фактически это этап тестирования и полировки всех созданных ранее элементов: бэкенда и фронтенда. Опять-таки часть элементов тестирования может писаться параллельно с основным кодом. Это сэкономит время и силы в последующем. Чтобы сузить диапазон поиска потенциальных проблем, релизы стоит разделить как минимум на альфа-версию, бету и окончательный релиз. В реальности каждая новая сборка может иметь новые проблемы и доработки, поэтому циклы последующих релизов могут быть бесконечными.
  5. Развёртывание – это этап выпуска публичной версии приложения, в которой стабилизированы все основные функции и элементы интерфейса. На этом этапе предполагается подписание приложения и выгрузка его в маркетплейсы соответствующих сервисов (вендоров). У каждой платформы могут быть свои нюансы и требования к оформлению кода, предоставлению данных для регистрации, оплате взносов и не только.

На какие особенности Microsoft советует обратить внимание:

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

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

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

Итак, у рядовых программистов есть только путь…

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

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

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

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

Каждое из таких состояний – это свой код и определённые запросы к API операционной системы. Плавные и правильные переходы без потери данных – это залог успеха.

Подсмотреть жизненные циклы приложений можно в технической документации к выбранным платформам – Android и iOS.

Как видят жизненный цикл проекта по созданию мобильных приложений управленцы (проджект-менеджеры)

Классическая теория управления признаёт линейный подход. Но если перевести вопрос в плоскость методологий управления, то мы получаем знакомую многим каскадную модель (Waterfall):

  1. Формирование требований к проекту (приложению).
  2. Анализ и планирование.
  3. Разработка интерфейса.
  4. Написание кода (реализация).
  5. Тестирование.
  6. Внедрение и поддержка.

Последний этап может быть бесконечным по времени.

Как рекомендуют выстраивать цикл жизни приложений опытные проджект-менеджеры:

  1. Формирование основной идеи, концепции. Это своего рода абстрактный уровень планирования.
  2. Построение и согласование каркаса проекта. На этом этапе также улучшается общее понимание конечного функционала приложения.
  3. Выбор технологии (фреймворки, серверная реализация и другие рабочие инструменты).
  4. Проработка дизайна и внешнего вида.
  5. Непосредственно разработка (бэкенд + настройка взаимодействия с фронтендом).
  6. Тестирование.
  7. Запуск (выгрузка в маркетплейсы и т.п.).
  8. Поддержка.

Некоторые руководители проектов и опытные заказчики советуют добавить следующие этапы:

  • Аналитика — здесь происходит обоснования и проверки идей.
  • Составления технических заданий (поскольку разработкой зачастую занимаются посторонние агентства или команды).

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

  • Формирование пула задач.
  • Планирование рисков.
  • Управление ожиданиями стейкхолдеров.
  • Составление списка юзер-сторис.
  • Выбор целей на ближайший спринт.
  • И прочее.

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

  • прототипирование,
  • тестирование концепций,
  • отрисовка макетов,
  • верстка (преобразование макетов в реальный код),
  • снова тестирование,
  • настройка взаимодействия с бэкендом.

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

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

Вместо выводов

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

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

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

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