Как создаётся мобильное приложение

Loading
loading..

Как создаётся мобильное приложение

29 июня, 2015 в 16:56
Олег Вергуленко

User Story

Прежде всего, необходимо определить, что и для кого мы пишем. Ответы на эти вопросы оформляются в User Story. На этом этапе важно проработать все возможные сценарии, чтобы не было неприятных сюрпризов на более поздних этапах разработки. 

Важно, чтобы заказчик понимал, что за каждым пунктом в to-do листе скрывается огромный айсберг функционала. Поэтому на этом этапе необходимо фрагментировать и конкретизировать задачи. Крупные хотелки лучше всего делить на несколько этапов (релизов в стор).

 

Проектирование и дизайн

После составления User Story начинается проектирование и разработка дизайна.

На этом этапе обычно используются прототипы, которые развешаны на доске и стрелочками показано, как будет происходит навигация.

При разработке дизайна обязательно используются гайдлайны.

Гайдлайн в общем понимании – это документ, который выпускает компания, и по которому дизайнеры и разработчики понимают принцип построения взаимодействия приложения с пользователем. Условно говоря, для iOS кнопки надо делать круглыми, а для Windows Phone – квадратными. Таким образом результат работы дизайнера чаще всего состоит из макетов, гайдлайнов и нарезки графики.

Макеты, в идеале, подаются «перелинкованными», чтобы была понятна логика переходов. Гайдлайны содержат в себе информацию об отступах, размерах, визуальных эффектах, механике анимации и пр. Третья часть результата — нарезка графики — должна содержать минимум необходимых графических ресурсов (забота о весе приложения), иметь версии для разных разрешений экранов.

 

Передача в разработку. Обсуждение и необходимые правки описания

После получения макетов, гайдлайна и нарезки, начинается работа разработчика. Мы передаем в разработку все то, что придумали, и ожидаем ранний результат. Это не значит, что работа над архитектурой и пользовательским интерфейсом закончена. Иногда у разработчиков появляются интересные идеи, которые вносят коррективы в изначальный план. Однако, изменение или добавление задач, которые могут частично либо полностью могут изменить вектор процесса разработки, со стороны заказчика воспринимается с некоторой опаской. Естественно, мы примем всё это к сведению и, конечно же, в конечном счёте, реализуем каждое пожелание заказчика, но в таком случае, следует делать поправки и в требованиях к срокам. Этот момент заказчиками часто упускается из виду, отсюда и конфликт.

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

Когда разработка завершена, наступает стадия тестирования.

 

Тестирование

Существует немалое количество способов протестировать приложение.

В мобильной разработке тестировщик – это человек, вокруг которого одни телефоны. Внутри мы стараемся тестировать по тест-кейсам. Если внедряется новая фича, по ее описанию составляется тест-план.

Также, существуют сервисы, помогающие в тестировании.

 

Bugfixing

Исправление ошибок, как правило, производится параллельно с тестированием и занимает не так много времени. Но необходимо различать ошибки и доработки, где ошибка - это несоответствие оговоренному ТЗ, а доработка - неоговоренное ранее пожелание клиента.

 

 

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

Также, для более продуктивного взаимодействия на пути к созданию одного из топовых мобильных приложений, и сторона заказчика и сторона исполнителя должны с пониманием относиться друг к другу. Так, мы, со своей стороны, прекрасно понимаем, что клиент хочет получить высококлассный продукт, быстро и дёшево. Однако, не стоит забывать о том, что совмещение этих трёх понятий с каждым неоговореным нововведением в ТЗ проекта становится всё более недостижимым.