Способы планирования циклов разработки
Среди разработчиков есть несколько точек зрения в зависимости от того, кто именно занимается планированием, на каком уровне принимаются решения. Проджект-менеджеры, дизайнеры, программисты, управленцы, тимлидеры — каждая группа по-своему видит основные задачи работы, предлагает и внедряет свои этапы.
При совместной работе все эти нюансы нужно не только предусмотреть, но и согласовать между собой, чтобы выстроить единую схему. Только в этом случае можно будет говорить о контроле целей, задач, дедлайнов.
Как задачу видят крупные игроки
Гиганты IT-рынка, включая Microsoft, используют следующий вариант цикла разработки мобильного ПО:
Разработка идеи — формирование концепта и общего представления. Разработчики должны ответить на вопрос о ценности продукта для пользователей, а также для самой компании. На этом же этапе решают, как и с какими гаджетами (смартфонами, планшетами) будет работать программа, какие у нее будут преимущества на фоне конкурентов. Для ответа на последний вопрос понадобится изучение существующих аналогов, их сильных и слабых сторон.
Создание проекта — разработка и описание модели взаимодействия человека и приложения. В мобильном ПО обычно пользователи работают с графическим интерфейсом, поэтому на нем и следует сконцентрироваться. Полезно будет использовать гайдлайны для основных ОС: Android, iOS и для Windows. Разработчики должны продумать:способы получения и выведения информации;местоположение контента. Нужно учесть большое разнообразие разрешений экрана у современной техники, а также особенности работы программы при ориентировании экрана по вертикали и горизонтали;смену экранов;элементы управления;систему уведомлений, виджеты;текст. В разных гаджетах одни и те же текстовые сообщения могут выглядеть по-разному. Пользователи не должны с лупой рассматривать, что же хотел сообщить им разработчик.Иногда имеет смысл использовать типовые макеты интерфейсов, а также удачные идеи реализации из приложений конкурентов. Сначала делают схематичный макет, затем его тестируют, после чего исправляют выявленные недочеты и только потом переходят к проработке деталей.
Разработка — собственно, написание программного кода. Внедрение различных вариантов взаимодействия потребителя с приложением.
Стабилизация — тестирование возможностей, отладка функций всех элементов. Для экономии времени релизы делят на отдельные версии, обычно не менее трех — ранний доступ (альфа), ограниченный доступ (бета), окончательный релиз. Это позволяет получить обратную связь и выявить возможные проблемы до момента запуска. В рамках каждой версии отдельные циклы отладки и дорабатывания могут повторяться по несколько раз.
Запуск — выход (публикация) стабильно работающей версии приложения в маркетплейсах в открытом доступе. У каждого из них есть свои требования к ПО, представлению информации, регистрации и пр. Их нужно учитывать, чтобы запуск прошел в штатном режиме. Возможно, для разных платформ потребуется несколько версий исходной программы.
Важные нюансы, на которые стоит обратить внимание разработчикам:
многозадачность;
программные и аппаратные ресурсы. Сейчас есть много устройств с разными техническими возможностями, которые нужно учитывать при адаптации приложения;
ограничения и требования ОС. Работа в фоновом режиме, запрос доступа к файлам, специфика API, запуск специальных служб и пр.
В целом такой жизненный цикл включает все основные этапы разработки и может применяться на практике в разных компаниях. Однако это не единственное решение.
Этапы разработки с точки зрения программистов
Специфика мобильных приложений состоит в том, что они работают внутри определенной среды, которая вносит свои ограничения на использование памяти и заряда батареи, возможности специальных служб, запуск системных функций и пр. Даже на работу с физическим оборудованием — камерой, сенсорным управлением, датчиками — нужно особое разрешение. Но и это не главное. Самое сложное — управление текущими процессами.
Мобильные приложения работают на переднем плане, поэтому при потере этого активного состояния (например, если пользователю позвонили, или он решил переключиться на мессенджер и ответить на сообщение) система запускает определенные процессы, на которые разработчики ПО повлиять не могут. Эти моменты нужно учесть на этапе разработки, продумать для них индивидуальные программные решения.
Именно поэтому цикл работы приложения программисты видят так:
передний план — работа в активном режиме. Кстати, некоторые приложения могут сразу уходить в фон, если работа на переднем плане не предусматривается;
фон — переход в состояние службы или отключение. В последнем случае нужно предусмотреть возможность экстренного сохранения данных, текущих изменений, а также истории действий пользователя;
уведомления — будет ли приложение общаться с пользователем через виджеты и оповещения. Если да, то в каком виде, как часто, какие события будет отражать;
приостановка со стороны ОС, например, для экономии заряда батареи.
Для каждого состояния нужно прописывать свой программный код, запросы к API, обеспечивать сохранность данных при переходе. Согласитесь, будет неприятно, если внезапный звонок станет причиной потери всех введенных данных, игрового прогресса либо иных вариантов взаимодействия пользователя и ПО.
Уточнить, какие циклы разработки приложений существуют, как влияют на работоспособность всей системы и отдельных программ, можно в технических документах к соответствующим платформам — Android и iOS.
Как представляют жизненный цикл мобильного ПО проджект-менеджеры
Классики менеджмента всегда предлагали линейный подход, но если речь заходит о методах управления, то без каскадной модели не обойтись. Она предполагает следующие этапы:
Формулирование требований к проекту. По сути, мы ставим цели и задачи.
Анализ и планирование. Собираем сведения о ресурсах, планируем затраты времени, основные этапы.
Разработка интерфейса. Создаем схему взаимодействия, продумываем разные сценарии работы пользователя.
Написание кода — воплощаем задуманное в жизнь.
Тестирование — проверяем работоспособность всех функций и инструментов. Вносим изменения по мере необходимости.
Внедрение и поддержка — запускаем продукт и оперативно реагируем на вопросы и жалобы пользователей.
Последний этап, кстати, не имеет ограничений по времени — он будет длиться, пока компания-разработчик (или покупатель) заинтересована в продукте.
Исходя из вышеизложенного, опытные проджект-менеджеры выстраивают работу над проектом следующим образом:
Создание концепции. По сути, на этом этапе есть только абстрактные представления о будущем продукте — о чем он, что получит пользователь, какие свои проблемы решит, чем продукт будет ценен и команде разработчиков, и конечному потребителю.
Выстраивание каркаса. Разрабатывают схему, согласовывают все «узлы», шлифуют представления об общей функциональности будущего ПО.
Выбор технологии. Определяют, какие фреймворки, серверные реализации и иные инструменты подходят для воплощения задумки в жизнь.
Дизайн, UI и UX. Придумывают внешний вид продукта, рисуют иконки, фоны, переходные экраны, элементы меню и пр. Продумывают, каким будет пользовательский интерфейс, как люди будут взаимодействовать с функциями приложения, удобно ли им будет нажимать на кнопки, читать текст (особенно если разрешение экрана небольшое).
Программирование — бэкенд и настройка взаимодействия с фронтендом.
Тестирование. Проверяют работоспособность всех функций.
Запуск. Приложение выгружают в маркетплейсы и открывают для скачивания.
Поддержка. Ответы на обращения пользователей. В случае возникновения технических и других проблем — возврат к предыдущим пунктам, чтобы обнаружить источник жалоб пользователей, разработать стратегию исправления, внести правки в код, дизайн, заново все протестировать и выпустить новую версию.
В некоторых ситуациях руководство добавляет дополнительные этапы:
аналитика. Идеи проверяют, изучают, подкрепляют доказательствами. Объясняют, почему нужно сделать так, а не иначе. Обсуждают различные варианты, ищут оптимальные решения;
подготовка технических заданий. Требуется, если часть задач отдают на аутсорс, то есть их выполнением будут заниматься команды или специалисты со стороны. В таких ситуациях сложно объяснить посторонним внутренние стандарты, принятые схемы взаимодействия. Чтобы не тратить время на согласования, обсуждения, правки, нужно составить грамотное ТЗ с четко прописанными требованиями, задачами и другими важными нюансами.
При этом внутри групп, ответственных за определенные шаги жизненного цикла мобильного ПО, могут быть свои этапы, задачи и нюансы. К примеру:
подготовка перечня задач;
прогнозирование рисков;
работа с ожиданиями ключевых пользователей и стейкхолдеров;
постановка задач на ближайшую перспективу;
протопипирование, отрисовка, верстка (у дизайнеров).
Если проектов несколько либо они сложные, то придется выстроить управление целым портфелем задач и подпроектов.
Вместо заключения
Общих решений и универсального метода планирования этапов разработки мобильного приложения не существует. Каждая команда разрабатывает его под себя с учетом точки зрения на основные задачи, уровней планирования, а также банального удобства. Неизменным остаются три этапа — начало, разработка и завершение.
Не стоит забывать, что любой шаг может раскрыться в виде дерева сложных или долгореализуемых подпунктов, например разработка клиентской и серверной частей, настойка нагрузки на серверы и пр.
В одном случае процесс разработки занимает неделю-две, в другом — растягивается на годы. Все зависит от целей, масштабов, опыта команды, а также возможностей по расширению штата, в том числе привлечению сторонних специалистов. Чтобы не запутаться во всех обсуждениях и взаимодействиях, не срывать дедлайны и не бежать вперед паровоза, чтобы наладить контакты между разными группами для своевременного согласования, нужно выстроить грамотную систему контроля за всеми процессами, датами и целями. Как раз для этого существует Projecto: он помогает наладить работу вне зависимости от масштабов проекта.
Начать дискуссию