Есть такое выражение – «не нужно натягивать сову на глобус». Не помню уже, откуда оно появилось, но суть его в том, что оппонент в споре делает совсем неочевидные выводы из очевидных фактов.
В роли «совы» у нас сегодня выступают проворные методологии. Само слово «Agile» переводится как «проворный». А в роли глобуса, соответственно – разработка мобильных приложений. Но сначала вспомним сам манифест:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
Если совсем по-простому – то разработчики должны собраться обсудить задачу с заказчиком и всё сделать. Звучит как план! Казалось бы, что может пойти не так?
Вот тут и нужно сделать ремарку – практически все проворные методологии были сформулированы тогда, когда не существовало мобильной разработки. Т.е. разработчики в команде были взаимозаменяемы, да и в целом сложность разрабатываемых систем была не такой высокой. Что же принесла с собой массовая разработка мобильных приложений?
Во-первых, проект разрабатывается сразу под несколько платформ (разработка под iOS и Android одновременно - это уже сложившийся стандарт). Что влечёт сложности с согласованием различий в версиях под разные платформы, например, различия в интерфейсе – на платформе Android до сих пор есть кнопка «назад». Или таким фактором может выступать наличие оптимизации и узкий модельный ряд iOS устройств.
Во-вторых, для мобильных приложений необходимо выстраивать жёсткий релизный цикл, так как разработчик не может контролировать скачает ли пользователь новую версию приложения или нет.
Самый простой выход из ситуации - разделить разработку на три проекта. Одна команда будет заниматься серверной частью, а две другие реализацией только мобильной части, каждая под свою платформу. Релизный цикл здесь состоит в том, что «мобильные» команды берут задачу в работу только после того, как команда, отвечающая за серверную часть, эту задачу полностью закончила. Но таким подходом не снимается проблема разной реализации в зависимости от мобильной платформы. А скорее всего эти расхождения только увеличатся.
Так как проекты по мобильной разработке существуют достаточно давно, уже предложены хорошо продуманные пути выхода из таких ситуаций - корпоративные Agile-фреймворки:
- Large Scaled Scrum
- Disciplined Agile Delivery
- Scaled Agile Framework
У всех есть свои плюсы и минусы. Главное чтобы такая организация процесса подошла людям которые будут этот процесс выстраивать. Мы же предлагаем наш опыт. Он не заменит полноценного фреймворка, но упростит интеграцию того, что вы выберете.
- Чётко определиться, следуем ли паттернам дизайна платформы! Можно разрабатывать чётко следуя UI/UX гайдлайнам каждой из платформ, можно договориться о каком-то усреднённом стиле. Но, главное, не менять своего решения в процессе разработки.
- Разделить треки аналитики/дизайна, бекенда и мобильных платформ! Как показала практика, подход из старого доброго регулярного менеджмента – в начале документация, даёт гораздо больше шансов на успешную синхронизацию 3-х групп людей.
- Поддерживать хорошую документацию на проекте, как бизнес, так и техническую. Без этого в принципе невозможно удерживать заданный уровень качества в проектах длительностью от полугода и больше.
- Больше общаться между собой
Это последнее, но возможно самое ценное – никогда не ленитесь узнать дополнительную информацию, поделиться результатами с заказчиком, держите в курсе своих активностей ваших коллег по команде. Общение - это в принципе один из «столпов» проворной разработки программного обеспечения.