Я написал о функциональной спецификации интерфейса.

— Это один из артефактов, который полезно создавать при проектировании интерфейсов. Она уточняет показанные в прототипе решения и отвечает на будущие вопросы разработчиков;
— В ней можно описать то, что трудозатратно или невозможно визуализировать в прототипе, и то, что на картинках человек скорее всего не заметит;
— Также она: 1) может стать частью договора, 2) помогает перепроверить и доработать свои решения;
— Во второй половине статьи я рассказал, как её писать: когда приступать, что в неё включать и как это структурировать, что писать об отдельных элементах интерфейса и что уже выходит за рамки подобного документа;
— Это, конечно, не подробное руководство с детальными чеклистами, но неплохой материал для старта.

#docs

Давид Саргсян написал о требованиях к интерфейсу.

— Постулат методологии Agile: «Работающий продукт важнее исчерпывающей документации»;
— Чтобы уложиться в спринт, часто жертвуют документированием: отдают разработчиком тезисные требования, подкреплённые устными объяснениями;
— Они иногда бывают неполными, и разработчики тратят время на уточнения и предположения;
— Потом при доработке или создании смежной фичи приходится тратить время на повторное исследование логики её работы. Можно упустить какие-то нюансы, что ухудшит итоговое качество продукта;
— Из-за пробелов в логике растёт техдолг, на исправление которого со временем требуется всё больше ресурсов;
— Чтобы этого избежать, аналитик должен 1) выделить отдельные элементы интерфейса, 2) задаться рядом вопросов о логике их работы;
— Давид выписал вопросы к 12 самым популярным элементам интерфейса: текстовый элемент для чтения, таблица, поле ввода, раскрывающийся список, поиск, календарь, кнопка, чекбокс, радиокнопка и переключатель, карта, уведомление, загрузчик файлов, индикатор выполнения;
— Например, поле ввода: обязательно ли, ограничение на количество символов, нужны ли подсказка с маской, реакция системы на дубликаты, может ли пользователь редактировать сохранённые данные;
— Раскрывающийся список: можно ли выбрать несколько значений, будет ли поиск по значениям, можно ли добавлять новые значения, как на список значений влияют другие поля.

Перекликается с моей статьёй о функциональной спецификации интерфейса, там тоже фигурировали вопросы к отдельным элементам интерфейса. #docs

Андрей Шапиро написал о слабых местах подхода SDD (Specification-Driven Development) в агентной разработке.

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

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

Решение: когда оператор принимает результат, все удачные решения агента делать частью спецификации. Но всё равно останутся нежелательные феномены.

1) Дрейф — отклонение агента от спецификации.
2) Эрозия — потеря важных деталей при правках. Изменение А приводит к незаметному изменению Б, потому что часть важного для Б контекста исключается как неважная для А.
3) Наплыв — перенос свойств объектов, которые видит агент, без требования о переносе. Пример становится образцом целиком, вместе со случайными чертами вроде оформления.

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

#ai #docs