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

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

Если обратиться к документации крупнейших 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.