User Story
Прежде всего, необходимо определить, что и для кого мы пишем. Ответы на эти вопросы оформляются в User Story. На этом этапе важно проработать все возможные сценарии, чтобы не было неприятных сюрпризов на более поздних этапах разработки.
Важно, чтобы заказчик понимал, что за каждым пунктом в to-do листе скрывается огромный айсберг функционала. Поэтому на этом этапе необходимо фрагментировать и конкретизировать задачи. Крупные хотелки лучше всего делить на несколько этапов (релизов в стор).
Проектирование и дизайн
После составления User Story начинается проектирование и разработка дизайна.
На этом этапе обычно используются прототипы, которые развешаны на доске и стрелочками показано, как будет происходит навигация.
При разработке дизайна обязательно используются гайдлайны.
Гайдлайн в общем понимании – это документ, который выпускает компания, и по которому дизайнеры и разработчики понимают принцип построения взаимодействия приложения с пользователем. Условно говоря, для iOS кнопки надо делать круглыми, а для Windows Phone – квадратными. Таким образом результат работы дизайнера чаще всего состоит из макетов, гайдлайнов и нарезки графики.
Макеты, в идеале, подаются «перелинкованными», чтобы была понятна логика переходов. Гайдлайны содержат в себе информацию об отступах, размерах, визуальных эффектах, механике анимации и пр. Третья часть результата — нарезка графики — должна содержать минимум необходимых графических ресурсов (забота о весе приложения), иметь версии для разных разрешений экранов.
Передача в разработку. Обсуждение и необходимые правки описания
После получения макетов, гайдлайна и нарезки, начинается работа разработчика. Мы передаем в разработку все то, что придумали, и ожидаем ранний результат. Это не значит, что работа над архитектурой и пользовательским интерфейсом закончена. Иногда у разработчиков появляются интересные идеи, которые вносят коррективы в изначальный план. Однако, изменение или добавление задач, которые могут частично либо полностью могут изменить вектор процесса разработки, со стороны заказчика воспринимается с некоторой опаской. Естественно, мы примем всё это к сведению и, конечно же, в конечном счёте, реализуем каждое пожелание заказчика, но в таком случае, следует делать поправки и в требованиях к срокам. Этот момент заказчиками часто упускается из виду, отсюда и конфликт.
А потому, прежде, чем передавать приложение в разработку, мы стараемся убедиться, что учли все пожелания заказчика. Если же новые, порой противоречивые, пожелания неизбежны - заказчик должен понимать, что ранее оговоренные сроки сдачи готового приложения, теряют свою актуальность с момента принятия в работу ранее неоговоренных задч.
Когда разработка завершена, наступает стадия тестирования.
Тестирование
Существует немалое количество способов протестировать приложение.
В мобильной разработке тестировщик – это человек, вокруг которого одни телефоны. Внутри мы стараемся тестировать по тест-кейсам. Если внедряется новая фича, по ее описанию составляется тест-план.
Также, существуют сервисы, помогающие в тестировании.
Bugfixing
Исправление ошибок, как правило, производится параллельно с тестированием и занимает не так много времени. Но необходимо различать ошибки и доработки, где ошибка - это несоответствие оговоренному ТЗ, а доработка - неоговоренное ранее пожелание клиента.
Важным моментом в разработке любого продукта является осознание важности этапа проектирования, потратив на который несколько лишних дней, можно сэкономить недели и месяцы работы программистов и тонны нервных клеток менеджеров, как со стороны заказчика, так и со стороны исполнителя.
Также, для более продуктивного взаимодействия на пути к созданию одного из топовых мобильных приложений, и сторона заказчика и сторона исполнителя должны с пониманием относиться друг к другу. Так, мы, со своей стороны, прекрасно понимаем, что клиент хочет получить высококлассный продукт, быстро и дёшево. Однако, не стоит забывать о том, что совмещение этих трёх понятий с каждым неоговореным нововведением в ТЗ проекта становится всё более недостижимым.
