- Гибкая методология для мобильной разработки
- Agile
- Agile для мобильной разработки
- Scrum
- Адаптация методик
- Что насчет Waterfall?
- Кроссплатформенная разработка мобильных приложений в 2020 году
- Выбор пути мобильной разработки
- Отдельные нативные приложения для Android и iOS
- Прогрессивное веб-приложение
- Одно кроссплатформенное приложение для двух систем
- Flutter
- Плюсы
- Минусы
- Польза для бизнеса
- Прогноз, перспективы на ближайшие 5 лет
Гибкая методология для мобильной разработки
Agile development is especially useful for mobile app development. The agile methodology provides our clients with a continuous feedback loop. Sourcebits mobile app design and development clients see milestones every 2-3 weeks. They aren’t left to wait until the very end of the project. Agile development for mobile apps means clients provide feedback every step of the way to ensure the success of the project. – Joe Chen, CTO, Sourcebits
Не секрет, что разработка под мобильные платформы имеет важные отличительные характеристики, относящиеся к большинству фаз жизненного цикла, такие как:
- необходимость короткого времени доставки продукта на динамичный рынок, и дальнейших постоянных обновлений;
- большое количество пользователей со всего мира;
- сложность в выявлении требований к приложению, в том числе по причине трудностей в идентификации стейкхолдеров;
- высокая вероятность изменений потребностей и ожиданий пользователей, и соответственно необходимости вносить изменения по ходу разработки;
- высокий темп технической эволюции – новые устройства, релизы ОС, ЯП, технологии мобильной связи & IoT, и пр.
Для того чтобы соответствовать этим характеристикам, снизить степень риска, и упорядочить процесс мобильной разработки – широко применяется методология Agile с ее адаптивным (допустимость частых изменений), итеративно-инкрементальным (обратная связь с заказчиком на каждой итерации, и множественные релизы), кооперативным (плотное сотрудничество разработчиков, заказчика и конечных пользователей) и простым (легко понять, менять и улучшать) подходом к разработке.
Agile
Agile – это серия подходов к разработке программных продуктов путем непрерывной и быстрой поставки ценного рабочего функционала самоорганизованной командой профессионалов в сотрудничестве с заказчиком.
Agile – это комбинированный вариант итеративной и спиральной моделей жизненного цикла: пошаговая разработка и наличие готовых фрагментов работающего ПО, взятые из итеративной модели + главенствующая роль человеческого фактора и анализ возможных рисков, взятые из спиральной модели.
Преимущества Agile, и причины, по которым ее применяют компании, хорошо были проилюстрированны в ряде известных исследований: State of Agile, CHAOS Report, Agile Quantitative Assessment.
State of Agile: причины, по которым применяют Agile
Основные идеи Agile были изложены в документе, который получил название «Манифест гибкой разработки». В нем же содержатся двенадцать конкретизированных принципов Agile. Полный текст обоих документов (и их переводы) доступны на сайте http://agilemanifesto.org.
Agile для мобильной разработки
Как было отмечено, Agile позволяет адаптировать процессы к неустойчивым потребностям мобильной области. Agile обеспечивает гибкость для понимания рынка, структурирования продукта и его выпуска в короткие сроки.
За последние несколько лет был разработан ряд фрейморков, подходящих для применения в мобильной сфере: Mobile-D, MASAM, Hybrid, Scrum, SLeSS.
Эволюция гибкой методологии разработки для мобильного ПО (Источник изображения)
Scrum и SLeSS являются наиболее современными, при этом в основе SLeSS лежит тот же Scrum. Самая первая попытка адаптировать Agile для мобильной разработки – Mobile-D – также вызывает интерес, в особенности по той причине, что включает в себя элементы инженерных практик XP.
Scrum и XP будут рассмотрены подробнее далее.
Scrum
Scrum – это одна из agile-методик, в которой создание продукта происходит в виде серии итераций фиксированной продолжительности. Методика делает акцент на качественном контроле процесса разработки, на управлении задачами в командной среде разработки.
В общем случае, Scrum предполагает работу над проектом короткими итерациями (обычно 2-4 недели), каждая из которых является уменьшенным вариантом проекта, и включает все задачи, необходимые для выдачи прироста по функциональности.
Каждый день проводится скрам-митинг, на котором команда синхронизирует свою работу и обсуждает проблемы.
Каждый раз когда новая фича, модуль или обновление завершено, осуществляется тестирование. Благодаря тестированию во время разработки, возможные баги исправляются вовремя, что в итоге приводит к гораздо более стабильному продукту.
По окончанию итерации заказчик получает новую версию продукта, и, если требуется, проект или какая-либо его часть пересматривается. Здесь также учитывается обратная связь от конечных пользователей. Кроме того, в процессе ретроспективы команда получает возможность оптимизировать свои рабочие процессы. Затем цикл реализации запускается снова. В итоге создается решение, которое максимально точно соответствует требованиям заказчика и востребовано рынком.
Основные инструменты Scrum:
- Беклог продукта (Product Backlog);
- Пользовательские истории (User Stories);
- Планирование спринта (итерация в Scrum);
- Беклог спринта (Sprint Backlog);
- Доска задач (в виде физической или цифровой, например, внутри JIRA)
Пример доски задач
- Диаграмма сгорания задач (Burndown Chart);
- Быстрые совещания (стендапы / митинги);
- Обзор спринта (демо и ретроспектива).
Agile-методика XP (Extreme Programming) сфокусирована на инженерной стороне развития продукта. Это системный подход к программированию. В то время как Scrum уделяет больше внимания управлению и выпуску, XP сосредоточена на процессе производства. XP включает практики, существенно улучшающие качество конечного продукта:
- Непрерывная интеграция (Continuous Integration (CI))
- Автоматизированное тестирование;
- Рефакторинг;
- Ревью кода;
- Парное программирование;
- Стандарты кодирования, и другие.
Адаптация методик
Довольно часто в мобильной разработке классические методики необходимо адаптировать с учетом особенностей проекта, команды и заказчика. Некоторые варианты такой адаптации:
- модификация временных рамок agile-практик. Например, сокращение времени спринта до 1 недели – как правило, заказчик приложения желает получать новые релизы, а команда получать feedback, как можно чаще. Другой пример: ретроспектива может быть раз в месяц или каждую итерацию, в зависимости от потребностей проекта;
- модификация реализации agile-практик. Например, проведение асинхронных стендапов через Slack/Stride/др. Если команда работает удаленно – это особенно актуально. Другой пример: в связи с зачастую «туманными» требованиями заказчика, и соответствующими трудностями команды при планировании работ, интересным смотрится Dual-Track Scrum;
- модификация набора agile-практик. Очевидно, что не всегда нужно включать в работу сразу все инструменты выбранной методики, особенно в стартапе. Поэтому сначала могут быть выбраны только самые необходимые и «работающие».
Что насчет Waterfall?
Стоит отметить, что нельзя сказать определенно о неприменимости традиционной водопадной методологии с ее последовательными фазами в мобильной разработке. Всё зависит от специфики конкретного проекта. Существуют примеры проектов (например, выполняющие сверх-критические работы; в совершенно новой области, требующей предварительных исследований; c большим размером, сложностью и длительностью срока разработки; государственные контракты), сущность которых противоречит принципам Agile, и тогда водопад – подходящий выбор. Однако таких проектов в коммерческой разработке очень мало.
Мобильный проект часто подвержен внутренним или внешним неопределенностям, таким как нечетко определенные требования или частое изменение потребностей пользователей, поэтому вполне благоразумно будет планировать его жизненный цикл, используя какую-либо agile-методику, или, как это часто бывает на практике, их сочетание. Хорошие результаты показало применение адаптированных версий Scrum и XP.
Источник
Кроссплатформенная разработка мобильных приложений в 2020 году
Я – Сергей Якимов, CTO Omega-R, международной компании по разработке и интеграции IT-решений. На базе многолетнего опыта в сфере информационных технологий и экспертизы компании хочу поделиться своим видением настоящего и ближайшего будущего кроссплатформенной разработки мобильных приложений.
На протяжении многих лет кроссплатформенная мобильная разработка заслужила репутацию одного из самых популярных направлений разработки программного обеспечения. Кроссплатформенный подход позволяет создавать приложения для различных платформ с одной кодовой базой, что экономит время и деньги и избавляет от ненужных усилий.
Согласно исследованию Digital 2020 Reports, подготовленному компаниями We Are Social Inc. и Hootsuite Inc., число пользователей интернета по всему миру увеличивается на 9 человек в секунду. Это означает, что каждый день к мировому онлайн-сообществу присоединяется более 800 тысяч человек, которые пользуются настольными или мобильными устройствами. Интересно, что последний вариант становится все более популярным с каждым месяцем.
Проникновение смартфонов в повседневную жизнь растет во всем мире. Ожидается, что к 2024 году три из четырех используемых телефонов будут смартфонами. Согласно статистике StatCounter, доля пользователей настольных устройств снизилась до 45,66%.
Самым простым объяснением такого состояния событий является изменение нашего образа жизни. Мы проводим в интернете больше времени, чем когда-либо прежде. Почти каждый имеет доступ к смартфону или планшету. Учитывая то, что среднестатистический пользователь в среднем проводит в сети почти 7 часов в день, неудивительно, что более половины этого трафика поступает с мобильных устройств.
Это, в свою очередь, подталкивает к росту рынок мобильных приложений. Результатом предпочтения мобильных приложений являются довольно внушительные цифры. Согласно отчету Statista за прошлый год, мировые доходы от мобильных приложений в 2019 году составили 461 млрд долл., а к 2023 году платные загрузки и реклама в приложениях, как предполагается, принесут более 935 млрд долл. дохода.
Выбор пути мобильной разработки
Приложения популярны не только среди современных пользователей интернета, но и достаточно прибыльны для их владельцев. Если связать эти два фактора воедино, можно сделать вывод, что практически любая стратегия развития бизнеса может включать создание приложения. Дилемма, однако, заключается в выборе правильного пути разработки мобильных приложений.
Одним из первых шагов на пути к цифровому успеху является решение о мобильной операционной системе – это, кстати, было не так просто десять лет назад, когда Android, iOS, Microsoft, RIM и Symbian были вполне жизнеспособными вариантами.
Сегодня выбор гораздо проще, поскольку единственными крупными игроками остаются Android и iOS, которые вместе составляют около 99% от общей доли рынка мобильных операционных систем. Согласно различным статистическим данным, Android выигрывает по количеству пользователей, но нет недостатка и в сторонниках iOS, доля которого на рынке составляет 25,75%. В то время как Google Play Store может похвастаться большим количеством приложений (2,5 млн), Apple App Store содержит более 1.8 млн приложений. Одного этого факта достаточно, чтобы показать, что ни одну из двух платформ не следует упускать из виду.
Поскольку выбор мобильной операционной системы является вопросом личных предпочтений пользователей, а не вопросом производительности или доступности, будет целесообразно в конечном итоге создать мобильное приложение как для Android, так и для iOS – и есть три способа сделать это.
Отдельные нативные приложения для Android и iOS
Нативное решение, как следует из названия, предполагает разработку приложения на родном для данной платформы языке программирования: Java или Kotlin для Android, Objective-C или Swift для iOS. Будучи глубоко ориентированной на операционную систему, разработка нативных приложений имеет свои достоинства и недостатки. С одной стороны, нативное решение обеспечивает доступ ко всем функциям данной ОС, позволяет неограниченно настраивать интерфейс и предотвращает любые проблемы с производительностью. С другой стороны, если вы хотите охватить оба типа пользователей, вам придется создать два отдельных приложения, которые требуют больше времени, денег и усилий.
Прогрессивное веб-приложение
Прогрессивное веб-приложение – технология в веб-разработке, которая добавляет сайтам возможности приложений для мобильных устройств и трансформирует сайт в приложение. На выходе получаем гибрид сайта и приложения для мобильных устройств. Однако, как любой другой вариант, прогрессивные веб-приложения небезупречны, так как они потребляют больше энергии батареи и не могут получить доступ ко всем функциям данного устройства, например, к календарю, камере, контактам и так далее. Кроме этого, теряется возможность перекрестного входа в веб-приложение с помощью приложения Facebook, Инстаграм, Вконтакте или т.д. Несмотря на то что веб-приложение не требует установки из Google Play Store или Apple App Store, последние выполняют функцию крайне удобных библиотек для пользователей.
Одно кроссплатформенное приложение для двух систем
Кроссплатформенность – это способность ПО (в нашем случае мобильных приложений) работать на нескольких платформах.
Кроссплатформенная мобильная разработка позволяет охватить две операционные системы, iOS и Android, одним кодом. Она не предполагает написания кода на родном языке программирования, однако обеспечивает почти нативный опыт благодаря интерфейсу визуализации с использованием собственных элементов управления.
На текущий момент многие компании используют кроссплатформенные решения, кто-то уже всерьез подумывает перейти на них в ближайшем будущем. Это не только вендоры самих решений, как, например, Facebook со своим React Native, на котором работают приложения Facebook и Instagram, но и другие крупные игроки рынка, у которых имеются продукты, например, на Flutter – Alibaba, Philips Hue, Hamilton, Tencent, Grab, Groupon и другие.
Существует множество статей, где подробно анализируются все преимущества кроссплатформенных приложений. Однако плюсы и минусы стоит рассматривать на платформе, которая имеет все шансы стать в 2020 году самой популярной среди разработчиков – Flutter.
Flutter
Flutter – SDK от компании Google с открытым исходным кодом для создания кроссплатформенных мобильных приложений, который предоставляет пользователям как Android, так и iOS по-настоящему нативный дизайн и опыт. Данная платформа разработки уже на старте показала внушительный рост по сравнению с React Native. Анонсированный на конференции Google I/O 2017 и выпущенный в 2018 году, Flutter остается все еще новичком на рынке платформ для создания кроссплатформенных приложений. С более чем 87 700 звездами в GitHub, что выше результата React Native, и подавляющим большинством разработчиков, называющих его одним из трех самых любимых фреймворков в обзоре Stack Overflow’s annual Developer Survey 2019, Flutter, несомненно, является силой, с которой следует считаться.
Рассмотрим плюсы и минусы Flutter как платформы для разработки продукта:
Плюсы
Минусы
- некоторую функциональность необходимо разрабатывать независимо на обеих платформах, если нет кроссплатформенных библиотек;
- один язык разработки – Dart, который необходимо выучить, если компания разрабатывает приложение, не имея необходимой экспертизы. В нашей компании есть разработчики на Flutter, что нейтрализует данный минус и позволяет получить специалистов быстрее поиска на рынке (согласно исследованиям, на найм специалиста тратится не менее двух недель).
Язык программирования Dart, который Google называет “оптимизированным под клиента”, был представлен в 2011 году. Это адаптивный объектно-ориентированный язык, который считается относительно легким для изучения по двум причинам: во-первых, он использует C/C++ и Java; во-вторых, на официальном сайте Dart можно найти обширную и довольно простую документацию. Также стоит отметить, что Dart поставляется с большим хранилищем Flutter-совместимых программных пакетов, позволяющих сделать ваше приложение еще более сложным.
Кроссплатформенные приложения на Flutter разрабатываются аналогично нативным в общепринятых IDE – Android Studio и XCode. Как дополнение, разработчикам доступен hot-reload кода, что ускоряет запуск приложения во время разработки. Кроме этого, процесс публикации ничем не отличается от нативных – собранные дистрибутивы подписываются и загружаются в магазины приложений.
Польза для бизнеса
В бизнесе решающую роль зачастую играет метрика TTM (time-to-market). Быть впереди и внедрять новые функции в свой продукт быстрее конкурентов сразу на обеих платформах – об этом с самого начала задумывается любая компания-лидер. Кроссплатформенные фреймворки позволяют это достигать и, как очевидный бонус, получать снижение затрат на разработку на каждом этапе. По нашим подсчетам – разработка на Flutter позволяет снижать общую стоимость разработки продукта на 25-30%.
Прогноз, перспективы на ближайшие 5 лет
Все, кому важен быстрый выход на рынок со своим продуктом одновременно на обеих платформах мобильной разработки, уже активно разрабатывают с использованием кроссплатформенных решений. В 2020 году тренд не изменится, и все больше компаний будут использовать кроссплатформенные мобильные приложения на Flutter.
Google разрабатывает новую ОС Fuchsia, в том числе для мобильных устройств. Flutter заявлен как UI toolkit в этой ОС. В ближайшем будущем Fuchsia может заменить ОС Android, и, несмотря на то что в Fuchsia в данный момент все же добавляется возможность запускать нативные приложения под Android, стоит учитывать эту тенденцию при планировании разработки и выхода на рынок со своими мобильными приложениями.
Таким образом, одна кодовая база, несомненно, влияет на все аспекты разработки приложения вплоть до снижения количества требуемых разработчиков, позволяя компании сэкономить деньги, которые обычно затрачиваются на исправление и обновление двух отдельных кодовых баз. Сэкономленную значительную часть первоначального бюджета проекта можно затратить на дальнейшее совершенствование приложения в соответствии с отзывами пользователей. В результате кроссплатформенная разработка мобильных приложений сбалансированно достигает своих целей как по критерию цены, так и по критериям времени, сложности и пользовательского опыта.
Источник