{"id":13579,"url":"\/distributions\/13579\/click?bit=1&hash=fac1e262bacedc292bce698ad3ca818a77bd592caa4fdfa917a7de6d9e68f657","title":"\u0420\u0435\u043a\u043b\u0430\u043c\u043d\u044b\u0439 \u0431\u044e\u0434\u0436\u0435\u0442 \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u043b\u0438, \u0430 \u0442\u043e\u043b\u043a\u0443 \u043d\u0435\u0442","buttonText":"\u041a\u0430\u043a \u0443 \u043c\u0435\u043d\u044f!","imageUuid":"7b040e27-87ca-5e31-ad48-6ae8b0b1ebed","isPaidAndBannersEnabled":false}
Трибуна
Oleg Koltunov

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

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

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

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

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

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

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

Экраны приложения

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

Список экранов

Состояния экранов

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

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

​Состояния экранов в Specsful

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

Фрагменты экранов

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

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

Фрагмент с различным состоянием​

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

Источники данных

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

На выяснение вопроса – «Откуда брать данные на экране?» – разработчики тратят кучу времени.

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

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

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

Модель данных

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

Привязка данных

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

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

API сервера

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

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

Запросы к серверу в Specsful​

Статический текст

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

Локализации

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

ID разметки

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

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

0
6 комментариев
Написать комментарий...
Vladimir Chernatkin

Аджайл уже не в моде? Заклеймили же ТЗ

Ответить
Развернуть ветку
Oleg Koltunov
Автор

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

Ответить
Развернуть ветку
Oleg Koltunov
Автор

Всем привет! Очень надеюсь получить объективную критику или любую обратную связь

Ответить
Развернуть ветку
Victor Chernogorov

Будет или может есть, но я не вижу, возможность выгрузить потом все экраны с описанием того, какие данные/методы и т.д. там есть? Чтобы собрать ТЗ для клиента?

Ответить
Развернуть ветку
Oleg Koltunov
Автор

Поясните, пожалуйста,  кто в данном случае клиент? Если клиент - Front-end разработчик, то его можно пригласить в проект с правами на редактирование или с правами только на чтение.

Ответить
Развернуть ветку
Victor Chernogorov

Заказчик приходит в студию , чтобы получить сайт или мобильное приложение, обычно он перед разработкой хочет получить ТЗ. Обычно студии делают "сочинение на тему проекта" вместо ТЗ, а реально важные вещи обсуждают в живую/чатиках + какие-то мелкие артефакты создаются, которые заказчику не интересны. 

Было бы круто иметь возможность экспортировать это в документ. 
В котором: 
– Название экрана
– Картинка
– Описание (кнопка такая-то вызывает такой-то метод, по клику переходишь на экран такой-то)

Таким образом у нас и документ для клиента и для разработчика, а если поддерживать в актуальном состоянии, то и документация :)

(да, скорее всего что-то руками в док надо будет заносить)

Ответить
Развернуть ветку
Читать все 6 комментариев
null