Specsful: Дайте разработчику, наконец, ТЗ!

«Что …, от меня хотят!», - тихий вопль каждого разработчика. «Когда же мне дадут нормальную спецификацию?!!», - таким вопросом каждый день задавался и я. И я решил с этим покончить. Хочу рассказать о своем стартапе Specsful и его продукте - инструменте для подробной спецификации мобильных и web приложений.

Для того, чтобы мобильные и веб разработчики могли быстро и качественно сделать приложение, важно передать им подробную спецификацию. Без такой спецификации разработчики будут тратить кучу времени на постоянное уточнение деталей, отвлекать друг друга от работы, либо просто сделают приложение «как поняли». Еще эта спецификация удобна для оценки времени разработки.

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

На сегодняшний день популярны несколько инструментов для спецификации. Для описания API используется Swagger. Для описания интерфейса пользователя Zeplin или Figma. Это классные специализированные инструменты, но они решают только свои узкие задачи.

Функционал Specsful в отличие от этих инструментов сфокусирован на логике работы приложения. Это ТЗ для разработчика позволяет ему понять сколько экранов должно быть в приложении, что происходит на этих экранах и как это происходит.

Как может выглядеть подробная спецификация приложения я покажу, рассматривая функционал Specsful. Для работы потребуются макеты или скриншоты экранов приложения.

Экран – основной компонент спецификации и вокруг описания экранов строится работа в Specsful. Понимать сколько всего экранов в приложении или фиче важно разработчикам приложения для того, чтобы точнее оценить время разработки.

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

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

Каждое состояние также содержит краткое описание со ссылками. В ссылки удобно добавить другие источники спецификации. Например, спецификацию UI в Zeplin. Если в приложении много экранов, в Zeplin уходит много времени, чтобы найти нужный – ссылка на конкретную страницу может решить эту проблему.

Фрагменты – это часть экрана, которая может использоваться на одном или нескольких экранах (не путать с фрагментами Android). Например, фрагментом может быть одна запись в списке.

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

На этой иллюстрации фрагмент соответствует элементу списка счетов. К счету может быть привязана карта – это состояние “With card”. Счет может быть накопительным – состояние “Savings”.

Описание источников данных в связке с элементами на экране – очень важный элемент спецификации.

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

Источником данных может быть:

• модель данных, переданных из другой части приложения
  
• API сервера
• статический текст, зашитый в приложение

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

На скриншоте выделено текстовое поле с суммой операции, привязанное к полю c адресом amount / value модели Operation Item.

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

Элементы на экране могут быть связаны с моделями данных, которые приходят от сервера или отправляются на сервер. Для этого в Specsful хранятся сетевые запросы. Запросы могут быть связаны с неограниченным количеством моделей. Модели могут выступать GET параметрами запроса, телом запроса или телом ответа. Запросы также содержат блок с описанием и ссылками, что удобно для связи их с дополнительной документацией (например, Swagger).

Для отражения в спецификации, что данные на экране приходят из точки доступа API, к экрану привязывается сетевой запрос и те его модели данных, с которыми работает экран. Привязка полей работает одинаково со всеми уже привязанными к экрану моделями.

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

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

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

Чтобы попробовать Specsful в деле заходите на сайт specsful.io, создавайте проект и загружайте свои данные! Надеюсь, этот инструмент будет вам полезен. Делитесь своим опытом – оставляйте обратную связь команде Specsful.