Рабочие истории. Системное проектирование с Картой реализации историй

2.4. Зона уверенного применения лаконичной записи

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

Вот пример подобной формы записи историй. Перед нами карта историй для пользовательской роли «Слушатель» и разрабатываемой системы онлайн-радио. Карта устроена так, что на самом верхнем уровне слева направо идут карточки крупных потребностей, группирующие истории-шаги по смыслу: Выяснить, что за радио; Слушать музыку. Сразу под ними слева направо идёт слой из последовательности карточек основных «историй»: Послушать эфир, Список возможностей, Сколько слушателей и так далее. Снизу под каждой карточкой с историей расположено её детальное описание. Например, под карточкой «Список передач» в качестве деталей записано: Инф. о передаче, Рейтинг передач.

Посмотрим на основные «истории» в примере и попробуем восстановить их контекст и смысл. Вот, что у нас получается:

Что за радио:

– Послушать эфир

– Список возможностей

– Сколько слушателей

– Какие исполнители

– Список передач

Слушать музыку:

– Управлять звуком (нарисованы пиктограммы паузы, зачёркнутого динамика, ползунка-фейдера и английское слово «bitrate»)

– Узнать, что за песня играет

– Отложить в закладки

– Поделиться песней

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

В первом блоке историй – «Что за радио» – пользователю предлагается ознакомиться с сервисом для принятия первого решения: стоит ли задержаться и уделить чуть больше времени. Все перечисленные здесь средства направлены на создание первого впечатления у посетителя и помощь в принятии решения о том, подходит ли ему инструмент.

Второй блок – «Слушать музыку» – описывает основные органы управления радиопроигрывателем: остановку проигрывания, изменение громкости или полное отключение звука, смена качества потока вещания. Мы можем представить себе как их действие, так и примерный внешний вид. И всё потому, что уже многократно сталкивались с подобным, будь то обычный радиоприёмник или музыкальный плеер.

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

Даже несмотря на то, что шаблон Коннекстры «роль – функциональность – основание» не соблюдён, опущены основания и мотивы, мы можем восстановить понимание, так как хорошо знакомы с предметом. Но что делать, когда такого знакомства нет?

2.5. Трудности в сложных предметных областях

Рассмотрим на контрасте лаконичную запись историй для инструмента раскроя в сфере производства металлоконструкций. Вот перечень записанных историй:

Оптимизация материалов:

– Пользователь видит оптимизацию как таблицу;

– Пользователь видит полный объём материалов, общую длину, общее количество и так далее;

– Пользователь хочет видеть в колонке тип материала;

– Пользователь хочет видеть в колонке тип по каталогу профилей.

Получение данных:

– Загрузка данных в оптимизацию согласно выбранным пользователем маркам;

– BOM изменился. Пользователь хочет видеть изменения с уже имеющимися материалами в оптимизации материалов.

Замена материала:

– Пользователь хочет заменять марки материала;

– Пользователь хочет заменять профили материала;

– Пользователь хочет видеть список возможных замен материала.

Отчёты:

– Пользователь хочет отправить данные в отдел снабжения;

– Получать отчёты по заменам от отдела снабжения;

– После получения отчёта, формировать его и отправлять заказчику.

Давайте попробуем понять, что же здесь имелось в виду. Если читатель не является специалистом в области металлоконструкций, то скорее всего ему трудно будет восстановить смысл происходящего в этих историях. Время от времени автор историй пытается применить куски шаблона: пользователь хочет. Но это не помогает, потому что «пользователь» в сравнении с кем-то из «отдела снабжения» выглядит абстрактно, и из такой записи невозможно понять, кто с кем имеет дело в реальной жизни и по какому поводу. То тут, то там появляются понятия-«чёрные ящики»: BOM, оптимизация, материал. Часть из них являются объектами, с которыми важно работать пользователю системы, а часть – элементы плохо выявленной терминологии. Видны осколки конкретных решений: отчёт, таблица. Вместе с тем совершенно неясно, какие именно данные и почему должны туда попасть.

Это типичный пример неудачи из-за краткой формы записи историй.

2.6. Восстанавливаемость содержания истории

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

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

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

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

Практические напутствия главы

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

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

Глава 3. Вспомогательные практики

Приёмочные тесты как средство восстановления контекста и определения критериев готовности · Шаблон изменений · Шаблон работной истории, Job Story · Шаблон вопросов · Шаблон утверждений · Заужение естественного языка

—

«Передача знания» – это оксюморон: передавать знания непосредственно как нечто разом данное и очевидное невозможно. «Сейчас я прочту энное количество книг и стану взрослым». Так не бывает. Нужны многообразные усилия, чтобы сформировать свои знания…

Тагир Сафаев, типограф

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

3.1. Практика записи приёмочных тестов

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

Языковая проблема всегда была и остаётся актуальной. Участники команды чаще всего мыслят в волнующих их категориях, употребляют разные языковые конструкции для описания одного и того же и не узнают в описаниях оппонентов того, о чём те рассказывают. Разработчики говорят на своём техническом языке в силу того, что они чаще и больше думают о будущей реализации задачи. Заказчик мыслит и говорит на языке бизнеса. Пользователи объясняются на языке своей специализации в деятельности. Трудно себе представить ситуацию, когда кто-то из них будет подстраиваться под язык другой группы, мастерски следить за разницей терминологий, отмечать разницу в картинах мира участников.

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

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

Эта техника перенесена из разработки через тестирование TDD (test-driven development), одной из практик «Экстремального программирования». До этого подобная техника использовалась в электронике: создавался макет с ожидаемым поведением, в него периодически ставилось «решение», то есть прототип создаваемого элемента, и наблюдалось, что уже срабатывает в схеме, а что ещё нет. Принцип техники предлагает «разматывать» решение задач задом наперёд. Если мы хотим, чтобы такие-то типы банковских карт обрабатывались приложением, то мы сначала напишем на это тест, убедимся в том, что сейчас приложение проваливает этот тест, потому что функциональность отсутствует или деградировала, а затем перейдём к решению конкретной задачи, приводящей к тому, чтобы тест проходил успешно. Эта же практика была перенесена на работу с пользовательскими историями как текстовыми моделями будущей функциональности.

Рассмотрим пример истории и приёмочных тестов на ней:

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

Приёмочные тесты:

– После повторного входа в том же браузере видны схемы, созданные в этом браузере.

– Переход по сгенерированной заранее ссылке возвращает к конкретной схеме. В ссылке содержится всё необходимое, на сервере ничего не хранится.

– После авторизации в сервисе на любом компьютере видны схемы, созданные ранее пользователем.

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

3.2. Практика использования шаблонов

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

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

Помимо классического шаблона Коннекстры Ш-1, сообществом методологий гибкой разработки накоплено несколько других интересных форм. Рассмотрим их ниже вместе с примерами.

3.2.1. Шаблон изменений

Вместо того, чтобы <старый способ действия>,

<новый способ действия> – Ш-2

<Новый способ действия>,

тогда как сейчас <старый способ действия> – Ш-2.1

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

Легко заметить, что в самом формате истории отсутствует явное описание ценности. Это не составляет проблемы, когда из описания нового способа действия очевидно его превосходство над предыдущим.

Вот типичные истории в формате изменений. Обратите внимание, как история И-12 ниже, про покупку рекламы, записанная в классическом виде, превратилась в историю в формате изменений И-13.

Я, как рекламодатель, хочу размещать рекламу только на сайтах выбранных тематик, чтобы захватить желаемую аудиторию и результативно использовать рекламный бюджет. – И-12, вариант в шаблоне Коннекстры

Вместо бесконтрольных трат бюджета выбирает, на какие тематики его потратить. – И-13, вариант в шаблоне изменений

Примеры других историй в шаблоне изменений.

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

Вместо самостоятельного определения приоритетной задачи из кучи, получает наиболее приоритетную, назначенную системой. – И-15

Вместо перезаказа вручную, устанавливает условия автоперезаказа. – И-16

Клиент сам видит актуальный отчёт в любое время, тогда как сейчас оператор регулярно ошибается при создании и отправке отчёта клиенту вручную. — И-17

3.2.2. Шаблон работных историй, Job Story, из JTBD

Когда <обстоятельства, задающие контекст ситуации>,

Я хочу <мотивация>,

чтобы <ожидаемый результат> – Ш-3

Шаблон работных историй пришёл из практики Jobs To Be Done. Сердцевиной подхода является сосредоточение на выявлении глубинных потребностей и мотивации изучаемой группы людей, в отличие от изучения форм решений, задач и действий этих людей.

«Работа» есть условное обозначение для чего-то, что человек в действительности хочет достичь в определённых обстоятельствах. Эти самые обстоятельства или контекст ситуации гораздо более существенны, чем особенности человека или характеристики используемых продуктов и технологий. При этом «работа» не только относится к какой-то утилитарной функции – она может затрагивать эмоциональные и социальные потребности человека9.

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

Шаблон работных историй хорош тем, что вытаскивает два уровня целевых установок изучаемой группы людей. «Я хочу, чтобы выполнялось одно, чтобы в итоге последовало второе» – есть цепочка из двух последовательно соединённых «ради чего».

В случае простоя между задачами я хочу видеть, как изменилось состояние дел, чтобы при необходимости в качестве следующей задачи выбирать наиболее приоритетную. – И-18

Когда сбоят системы отправки, я хочу быть уверенным, что критически важные уведомления доставлены вовремя, чтобы я мог избежать штрафов и сохранить доверие регулятора. – И-19

«Работы» и работные истории бывают разных масштабов. Одни затрагивают уровень продуктов, другие описывают тот или иной шаг деятельности, третьи указывают на небольшое улучшение на уровне каких-то предпочтений в интерфейсе.

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

3.2.3. Шаблон вопросов

<Вопросительное слово> <объект> <обстоятельство>?

Произошёл ли <факт>? – Ш-4

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

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

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

Мне понадобится сделать небольшое отвлечение, чтобы пояснить особенности предметной области человеко-машинного интерфейса. Большая часть информационных систем работает с концепцией цифрового двойника или цифровой тени. Это когда для реально представленного в физическом мире объекта строится его модель. Модель помогает решить задачу управления объектом.

Например, у такого реального объекта, как троллейбус, с помощью датчиков может сниматься масса показателей: заряд батарей, напряжение на узле двигателя, скорость движения, состояние открытости дверей, факт нажатия педали тормоза и так далее. Все эти данные по каналам связи попадают в модель цифрового двойника. Там они будут преобразованы и визуализированы в понятной человеку форме, так, чтобы он мог эти данные проанализировать и осмыслить. Часть информационных систем создаются как инструменты слежения и управления за подобными объектами.

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

Но как следить за параметрами виртуальных объектов? На вашей банковской карте нет иллюминатора, через который можно было бы заглянуть внутрь вашего счёта. То, что не дано само по себе или скрыто по тем или иным причинам, нужно каким-то образом сделать видимым. Для прямого описания потока данных в сторону потребителя и служит шаблон историй-вопросов.

Можно было бы записать историю о визуализации так:

Предприниматель видит баланс счёта, что даёт ему понимание сколько свободных денежных средств доступно. – И-20

Но лучше подойдёт запись в форме истории-вопроса, лишённая долгих расшаркиваний с излишними подробностями о пользовательской роли и надуманной ценности:

Сколько денежных средств на счёте? – И-21

Другие примеры историй-вопросов:

В какой срок мне нужно организовать поставку и куда? – И-22

Оператор-логист: Файл принят к парcингу? – И-23

Оператор-логист: Какие строки в файле содержат ошибки и что с этим делать? – И-24

Сколько потенциальных наличных заблокировано в проектах? — И-25

Сколько времени и средств уходит на продажу одному клиенту? – И-26

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

Какой объём спроса остаётся неудовлетворённым по причине, что мы не поняли запроса клиента, а какой по причине, что у нас не было для него предложения? – И-27

Каковы аномальные отличия текущих значений на этапах воронок по отношению к предыдущим периодам? – И-28

3.2.4. Шаблон утверждения

<Объекты> – <новый статус>!

Вот <данные> для <объект>! – Ш-5

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

Вот мой номер телефона! – И-29

Эти возвращённые товары я получил! – И-30

Я применяю такие истории на уровне деталей и стараюсь не иметь их на уровне основного сценария в карте историй.

3.3. Практика намеренного зауживания языка

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

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

Жизненный цикл виртуальных объектов и их цифровых двойников

и естественные точки опыта работы с подобными объектами

диктуют способы действия в работе с этими объектами.

Когда вся деятельность и состоит лишь в том, чтобы управлять цифровым объектом, в историях всё чаще появляются глаголы, означающие типичные действия с цифровыми сущностями:

– понять,

– добавить,

– видеть,

– редактировать,

– удалить,

– отменить,

– обнаружить такой-то срез данных.

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

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