{"id":13506,"url":"\/distributions\/13506\/click?bit=1&hash=27fcb5113e18b33c3be66ae079d9d20078d1c30f1b468cdc86ecaeefa18446c2","title":"\u0415\u0441\u0442\u044c \u043b\u0438 \u0442\u0432\u043e\u0440\u0447\u0435\u0441\u0442\u0432\u043e \u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438? \u0410 \u0435\u0441\u043b\u0438 \u043d\u0430\u0439\u0434\u0451\u043c?","buttonText":"\u0423\u0436\u0435 \u043d\u0430\u0448\u043b\u0438","imageUuid":"2c16a631-a285-56a4-9535-74c65fc29189","isPaidAndBannersEnabled":false}
IW Group

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

Есть такое выражение – «не нужно натягивать сову на глобус». Не помню уже, откуда оно появилось, но суть его в том, что оппонент в споре делает совсем неочевидные выводы из очевидных фактов.

В роли «совы» у нас сегодня выступают проворные методологии. Само слово «Agile» переводится как «проворный». А в роли глобуса, соответственно – разработка мобильных приложений. Но сначала вспомним сам манифест:

  • Люди и взаимодействие важнее процессов и инструментов

  • Работающий продукт важнее исчерпывающей документации
  • Сотрудничество с заказчиком важнее согласования условий контракта

  • Готовность к изменениям важнее следования первоначальному плану

Если совсем по-простому – то разработчики должны собраться обсудить задачу с заказчиком и всё сделать. Звучит как план! Казалось бы, что может пойти не так?

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

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

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

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

Так как проекты по мобильной разработке существуют достаточно давно, уже предложены хорошо продуманные пути выхода из таких ситуаций - корпоративные Agile-фреймворки:

  • Large Scaled Scrum
  • Disciplined Agile DeliveryScaled Agile Framework

У всех есть свои плюсы и минусы. Главное чтобы такая организация процесса подошла людям которые будут этот процесс выстраивать. Мы же предлагаем наш опыт. Он не заменит полноценного фреймворка, но упростит интеграцию того, что вы выберете.
1. Чётко определиться, следуем ли паттернам дизайна платформы!
Можно разрабатывать чётко следуя UI/UX гайдлайнам каждой из платформ, можно договориться о каком-то усреднённом стиле. Но, главное, не менять своего решения в процессе разработки.
2. Разделить треки аналитики/дизайна, бекенда и мобильных платформ!
Как показала практика, подход из старого доброго регулярного менеджмента – в начале документация, даёт гораздо больше шансов на успешную синхронизацию 3-х групп людей.
3. Поддерживать хорошую документацию на проекте, как бизнес, так и техническую.
Без этого в принципе невозможно удерживать заданный уровень качества в проектах длительностью от полугода и больше.
4. Больше общаться между собой
Это последнее, но возможно самое ценное – никогда не ленитесь узнать дополнительную информацию, поделиться результатами с заказчиком, держите в курсе своих активностей ваших коллег по команде. Общение - это в принципе один из «столпов» проворной разработки программного обеспечения.

0
Комментарии
Читать все 0 комментариев
null