kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Декомпозиция
Техники декомпозиции
В предыдущих уроках вы познакомились с концепцией пользовательских историй и правилами их оформления. В этом уроке вы узнаете, как можно разделить большие пользовательские требования на мелкие истории, которые удобнее брать в работу. Также вы научитесь использовать техники разбиения полученных пользовательских историй на ещё более детальные и точные.
Что такое декомпозиция
Декомпозиция — это разделение целого объекта на составные части.
Предположим, к вам обращается друг и говорит:
«Как именинник, я хочу получить в подарок десерт, который ты приготовишь дома, чтобы мы приятно провели время за чаем».
Вы очень хотите порадовать именинника, но никогда не готовили десерты. Как это сделать?
Если времени достаточно, вы можете приготовить торт своей бабули, которым она любила угощать гостей. Это огромный и невероятно вкусный торт, но над ним предстоит как следует потрудиться.
Но если вечеринка в честь дня рождения начинается совсем скоро и вы не уверены, что успеете приготовить бабулин торт, то хорошей альтернативой будет сделать «торты в чашке» — капкейки.
Капкейк — полноценный десерт, для которого требуется меньше ингредиентов и значительно меньше времени. Поэтому вы наверняка успеете приготовить хотя бы несколько штук к приходу гостей. Ведь несколько готовых капкейков лучше, чем не до конца приготовленный торт.
Задачи, которые нужно выполнить для приготовления торта и капкейков, практически идентичны:
- Найти рецепт.
- Отмерить нужное количество ингредиентов.
- Смешать их: отдельно тесто, отдельно крем.
- Разлить в несколько форм для выпечки.
- Разогреть духовку.
- Испечь.
- Украсить.
Имея такой наглядный план действий, вы можете попросить кого-то из друзей вам помочь. Например, ваш друг будет готовить крем, пока вы замешиваете тесто.
По аналогии с приготовлением десерта, декомпозиция истории большого размера на несколько историй поменьше помогает команде разработки удостовериться, что она сможет реализовать хотя бы часть этих историй. Команда покажет эту часть заказчикам или даже передаст её пользователям и таким образом быстрее получит обратную связь или позволит клиентам быстрее получить пользу от работы с ПО (даже если остались доработки). Такая декомпозиция называется вертикальной.
Вертикальная декомпозиция — это разделение одной функции (или элемента бэклога из другой категории) на несколько элементов.
Истории, получившиеся в результате вертикальной декомпозиции другой истории, тоже должны соответствовать INVEST-критериям.
Задачи, на которые команда разработки может декомпозировать истории, представляют собой план действий по её реализации. Такими задачами могут быть проектирование, реализация, тестирование и другие. Декомпозиция на задачи позволит команде разработки распределить их по членам команды. Такая декомпозиция называется горизонтальной.
Горизонтальная декомпозиция — это разделение одной функции (или элемента бэклога из другой категории) на несколько задач, необходимых для её реализации.
Каждый элемент бэклога продукта, получившийся в результате вертикальной декомпозиции, команда декомпозирует горизонтально во время итерации.
Определите, какие функции были декомпозированы горизонтально, а какие — вертикально.
В рамках перевода двух систем по выдаче микрозаймов на одну общую клиентскую базу команда определила следующие задачи: спроектировать архитектуру, написать программный код, разработать прототип договора о передаче данных в общую базу обеих систем и протестировать результат реализации.
Горизонтальная
Разделение функции на несколько задач, необходимых для её реализации, — это пример горизонтальной декомпозиции.
Приложение для чтения книг должно предоставлять пользователям возможность делать заметки. Команда разработки добавила в бэклог продукта следующие функции: создание заметок, удаление заметок, редактирование заметок, скачивание всех заметок файлом в формате PDF.
Вертикальная
Разделение большой функции на несколько поменьше — это пример вертикальной декомпозиции. Реализуя эти функции по очереди, команда разработки уже с первой итерации может предоставить пользователю возможность работать с заметками.
Команда разработки должна реализовать функцию отмены брони авиабилетов на разных платформах продукта: в мобильном приложении и на сайте. Команда добавила в бэклог продукта отдельные функции: отмены бронирования на сайте и в приложении.
Вертикальная
Разделение функции на платформы — это вертикальная декомпозиция. Уже после первой итерации разработки любой пользователь сможет отменить бронирование.
Команда разработки должна добавить в мессенджер новый стикерпак в честь Нового года. Времени достаточно, поэтому команда разработки разделила функцию и добавила в бэклог итерации разработку прототипов стикеров, написание программного кода стикеров и их тестирование. Затем команда распределила задачи между участниками.
Горизонтальная
Команда приняла решение реализовывать весь стикерпак целиком. Она горизонтально декомпозировала функцию на задачи и приступила к работе.
Если после декомпозиции команда готова чётко оценить задачу и взять её в работу — это отличный результат. Но бывает и так, что команда всё равно не может подступиться к получившейся после декомпозиции истории. Причин может быть множество: в истории есть неизвестные переменные или скрытые подпроцессы, компания базирует свой продукт на нескольких платформах или команда оценивает реализацию функциональности в неприемлемые для заказчика сроки.
В таких случаях нужно проанализировать полученную историю и определить возможности для ещё более детальной декомпозиции. В этом системному аналитику поможет группа техник под названием «спайдер» — SPIDR.
SPIDR
SPIDR — группа техник вертикальной декомпозиции. Название образовано из первых букв входящих в неё техник:
- Spikes — спайки.
- Paths — пути.
- Interfaces — интерфейсы.
- Data — данные.
- Rules — правила.
Акроним SPIDR придумал Майк Кон (Mike Cohn), который является одним из основателей Scrum Alliance.
Представьте, что команда разработки реализует приложение, которое сравнивает цены на авиабилеты от компаний по всему миру и предоставляет пользователям возможность их бронировать. Системный аналитик написал историю:
«Как пассажир, я хочу изменить условия бронирования, чтобы не потерять деньги за билеты».
Рассмотрим каждую SPIDR-технику на примере этой истории.
Спайки
Команда разработки пока не знает, позволяют ли правила авиакомпаний и технические возможности их систем изменять условия бронирования. Она может получить необходимые знания, выполнив исследование в спайке.
Спайк — это элемент бэклога продукта, предназначенный для получения знаний о том, как реализовать функцию.
Чтобы провести исследование, команда разделяет основную историю на два элемента бэклога продукта:
- Спайк.
- Формулировка истории по результатам спайка.
При добавлении спайка в бэклог продукта следует придерживаться следующих правил:
- Записывать ожидаемые от спайка результаты.
- Ограничивать выделяемое на него время.
- Выполнять спайк как минимум на одну итерацию раньше реализации истории.
Правило 1: записывать ожидаемые результаты
Выполняя исследование в спайке, команда разработки выдвигает несколько гипотез и критериев проверки — ещё их называют метриками. Результаты исследования помогут команде выбрать подходящее техническое решение для реализации истории.
Как формулировать гипотезу
Хорошая гипотеза изначально содержит в себе ожидаемый результат исследования, который нужно проверить и доказать. Чтобы грамотно сформулировать гипотезу, следует придерживаться нескольких рекомендаций:
- Гипотеза не должна быть общеизвестным фактом. Иначе такую гипотезу нет необходимости доказывать.
- В гипотезе не должно быть неопределённостей, которые придётся дополнительно исследовать, прежде чем приступить к проверке самой гипотезы.
- В гипотезе должен быть заложен только один вопрос. Если команда разработки исследует несколько вопросов, она формулирует для каждого вопроса отдельную гипотезу.
- Гипотеза должна быть проверяемой. Команда знает, как именно проверить гипотезу, и может это сделать. Например, у команды есть для этого все технические возможности.
- Гипотеза должна быть связана с историей, в рамках которой эта гипотеза выдвигается. Она позволяет команде определить, как реализовать историю и помочь пользователю решить его задачи.
После выдвижения гипотезы нужно обозначить критерии, по которым можно будет понять, подтвердилась гипотеза или нет.
Как формулировать критерии проверки
Критерии проверки должны быть:
- Реалистичными — то есть достижимыми с учётом возможностей команды и системы.
Изменить бронирование силой мысли — это, конечно, невероятно круто, но пока что из области фантастики. А вот найти перечень авиакомпаний, где есть минимум один способ изменения брони, вполне реально.
- Конкретными — без туманных и двусмысленных фраз, которые можно понять по-разному.
«Хорошая продажа» — расплывчатое понятие, которое каждый может трактовать по-своему. Для одного это семь проданных билетов в день, для другого — отсутствие возвратов за покупки. Участники исследования должны одинаково понимать термины, которые содержатся в описании метрики.
- Измеримыми — то есть поддающимися количественной оценке.
Увеличить количество покупок можно на одну единицу продажи (один билет), но удовлетворит ли заказчиков такой результат, учитывая, что проектирование функциональности вышло значительно дороже? Чтобы подтвердить или опровергнуть гипотезу, нужно обозначить, к какому конкретно результату стремится компания.
Правило 2: ограничивать время
Исследовать информацию можно бесконечно, поэтому важно чётко обозначить временные границы. Команде стоит выделить для спайка столько времени, сколько предположительно потребуется для выполнения исследования при умеренном темпе работы.
И здесь может быть два сценария развития событий:
- У истории уже есть один или несколько вариантов решения и без исследования.
В этом случае команде следует оценить время, необходимое для:
- проведения исследования,
- реализации истории без исследования в рамках имеющихся решений.
Если исследование займёт больше времени, чем реализация истории без него, то стоит либо уменьшить объём исследования, либо отказаться от него.
- Команда разработки не знает, как реализовать историю.
В этом случае исследования не избежать, но оно может затянуться и тем самым отодвинуть реализацию истории ещё дальше. Поэтому основная задача — провести его в максимально короткий срок. Команда может дать приблизительную оценку времени на исследование и постараться уложиться в эти даты.
Правило 3: выполнять спайк на одну итерацию раньше реализации истории
Нельзя просто так взять и запланировать историю в работу, пока команда не поймёт, как именно эту историю реализовывать. Когда у команды недостаточно информации, есть риск не успеть к дедлайну и не выполнить обещания.
Невыполнение обещаний не только влияет на лояльность пользователей, но и блокирует работу других структурных подразделений. Например, заказчиков, которые планируют кампании на основе обещанной функциональности, или сотрудников службы поддержки, которые готовят новые скрипты для взаимодействия с пользователями приложения.
Избежать этого можно, заранее спланировав спайк. Но почему спайк лучше ставить как минимум на одну итерацию раньше реализации истории?
Если поместить спайк в одну итерацию с реализацией, то можно существенно снизить качество полученных результатов, если один из этапов затянется:
- Потратить слишком много времени на исследование, но не оставить времени на реализацию, то есть сделать на скорую руку функцию, которая не работает.
- Провести слабое исследование и ошибиться с выбором решения, но долго реализовывать функцию, которая не решает задачу пользователя или делает это частично.
Оба результата, скорее всего, разочаруют и заказчика, и пользователей, а также демотивируют команду разработки. Чтобы избежать подобных ситуаций и грамотно спланировать работу, команде следует придерживаться следующего алгоритма:
Вернёмся к истории про пассажира, который хочет изменить бронь авиабилета в приложении.
По результатам анализа верхнеуровневого требования команда разработки запланировала такие спайки:
- Проверить возможность изменения брони билета в топ-3 авиакомпаниях — партнёрах приложения.
- Выбрать самый быстрый для реализации вариант изменения брони пользователем в приложении.
Команда взяла спайки в текущую итерацию, а история осталась в бэклоге продукта. После выполнения спайков команда сможет принять решение о реализации истории и приступит к ней в следующих итерациях.
Итак, команда разработки проанализировала историю пассажира, который хочет изменить бронирование авиабилета, провела исследование в спайке и предложила следующие решения:
- реализовать функциональность по авиакомпаниям (вертикальные столбцы);
- реализовать функциональность по способам (горизонтальные столбцы).
Каждое решение уже можно оценить и взять в работу. Но будет лучше, если после спайка команда использует следующую технику, которая декомпозирует задачу изменения бронирования на ещё более детальные подзадачи.
Пути
Пути — это техника декомпозиции истории, которая позволяет определить способы и результаты достижения цели истории.
Способы достижения цели истории
Изменить бронирование авиабилета можно разными способами, например:
- перенести даты бронирования;
- отменить бронирование;
- изменить место отправления;
- изменить место прибытия;
- изменить данные пассажира.
Каждый из этих путей можно оценить и приоритизировать.
Результаты достижения цели истории
После определения способов достижения цели каждый из них можно декомпозировать на успешный результат (happy path) и всевозможные исключения — когда цель достигается частично или не достигается вообще.
Для первой итерации можно спроектировать только успешный сценарий, а остальные считать неуспешными. В следующую итерацию к успешному сценарию добавить частично успешные сценарии, тем самым расширяя пути достижения цели.
Например, путь изменения места прибытия будет декомпозирован по итерациям так:
В технике путей, как и в спайке, важно не переусердствовать с декомпозицией истории на более мелкие. Например, в истории с авиабилетами можно раздробить способ оплаты картой на платёжные системы: Visa, Mastercard, МИР и так далее. Но слишком простые истории с однотипной реализацией лучше объединять, чтобы не затягивать с получением результата.
Интерфейсы
Ещё один способ декомпозировать историю — разделить её на экраны интерфейса и на платформы.
Как разделить историю на экраны
Разные экраны подразумевают разработку функциональности для каждой ключевой персоны. Например, изменить бронирование авиабилета можно через экран администратора в службе поддержки или через экран пассажира в приложении.
Команда декомпозировала историю на экраны и получила следующие результаты для проектирования в итерациях:
В первой итерации пассажир сможет изменить бронирование через обращение в службу поддержки, а во второй — самостоятельно.
Разделение на платформы
Разными платформами для реализации истории можно считать операционные системы пользователя или браузеры:
- iOS и Android;
- Windows и macOS;
- Chrome, Safari, Opera, Mozilla Firefox.
К примеру, команда решила реализовать функциональность по изменению бронирования через экран пользователя в приложении. Приложение доступно для операционных систем iOS и Android. Команда проанализировала, на какой платформе больше всего скачивают приложение (в App Store или Google Play), и пришла к выводу, что пользователей на платформе iOS больше. Соответственно, можно сначала реализовать функциональность для этой платформы.
Реализацию истории на экранах и платформах проще оценить по времени и выполнимости. Эту технику можно комбинировать с другими (например, с путями), чтобы декомпозировать получившиеся небольшие истории ещё точнее.
Данные
Техника данных позволяет разделить историю по группам элементов, которые можно реализовывать в порядке важности для заказчика и пользователя.
Например, приложение может предоставить клиенту следующие данные о доплате за изменение бронирования:
- Штраф авиакомпании.
- Сервисный сбор приложения.
- Разница между тарифами на первое и изменённое бронирование.
- Сбор за обработку платежа.
- Итоговая сумма доплаты.
Эти элементы данных можно разделить на группы:
- Детализация суммы доплаты.
- Итоговая сумма доплаты, рассчитываемая на основании данных детализации.
Системный аналитик обсудил данные о доплате с заказчиком и выяснил:
- Детализация суммы доплаты важна тем пассажирам, кто летает в командировки, потому что это важно для бухгалтерии его работодателя.
- Итоговая сумма доплаты важна тем пассажирам, кто летает за свой счёт. Таких пассажиров, как правило, не интересует детализация суммы.
СА может разделить историю по группам элементов данных:
- Как пассажир, я хочу видеть итоговую сумму за изменение бронирования, чтобы принять решение об изменении.
- Как пассажир, я хочу видеть детализацию итоговой суммы за изменение бронирования, чтобы передать её в бухгалтерию для компенсации стоимости билета.
Так как во второй истории детализация важна пассажиру для отчётности, СА может заменить «видеть» на «скачать»:
- Как пассажир, я хочу скачать детализацию итоговой суммы за изменение бронирования, чтобы передать её в бухгалтерию для компенсации стоимости билета.
Команда разработки может сначала реализовать первую историю, предоставив части пользователей возможность принять решение об изменении брони, а затем реализовать вторую историю — для тех пассажиров, что летают за счёт работодателя.
Правила
Последняя в группе техник SPIDR (но не последняя по важности) — это техника правил. Она позволяет реализовать функцию в кратчайшие сроки путём исключения из первой итерации бизнес-правил или ограничений.
Например, заказчик обозначил правило:
Пассажир может изменить бронь авиабилета минимум за четыре часа до окончания регистрации на рейс.
Для этого команде нужно спроектировать дополнительные проверки, которые будут запрещать пассажиру изменять бронирование, если регистрация на рейс уже заканчивается. Но заказчик хочет реализовать функциональность изменения брони как можно быстрее. Оценив риски, команда разработки предложила реализовать функциональность следующим образом:
Команда исключила обозначенное бизнес-правило из первой итерации, чтобы быстрее реализовать функциональность для изменения брони.
Важно понимать, что некоторыми бизнес-правилами можно пренебречь, но есть правила, которые исключать нельзя. К таким правилам относятся технические ограничения системы или правила, которые регулируются законодательством.
Рассмотрим на примере следующего правила:
Пассажир возрастом до двенадцати лет не может лететь в самолёте без сопровождения взрослого.
Это правило диктует законодательство РФ, и исключение его из первой итерации влечёт неоправданные риски.
Для качественного результата рекомендуется комбинировать несколько техник SPIDR. Иногда декомпозиция крупной пользовательской истории с помощью разных техник может выдавать одинаковый результат — так системный аналитик может подтвердить точность и неделимость каждой получившейся пользовательской истории.
Вы — системный аналитик в компании, которая предоставляет услуги по разработке ПО больнице для домашних животных. Заказчик сформулировал верхнеуровневую историю:
«Как владелец питомца, я хочу следить за процессом предоставления услуги для моего домашнего животного, чтобы быть уверенным в его безопасности».
Вы с командой декомпозировали эту историю с помощью разных техник. Соотнесите получившиеся задачи и мелкие истории с применённой техникой.
Исследовать виды услуг, предоставляемые клиникой.
Спайки
Задачи на исследование возникают при декомпозиции истории с помощью техники спайка.
Как владелец питомца, я хочу наблюдать трансляцию с камер наблюдения во время предоставления услуги, чтобы быть уверенным в безопасности своего питомца.
Пути
Наблюдение за трансляцией с камер — это один из путей, через которые можно реализовать пользовательскую историю.
Как владелец питомца, я хочу получать записи с камер наблюдения на электронную почту, чтобы быть уверенным в безопасности своего питомца.
Данные
Предоставление записей с камер наблюдения — ещё один возможный путь реализации истории.
При проведении хирургической операции видеозаписи и личное присутствие владельца животного недопустимы с гигиенической и этической точки зрения.
Правила
Определение чётких правил, которые можно исключить или которые нельзя исключать ни в коем случае, помогает уменьшить и конкретизировать границы задачи.
Исследовать политику клиники по поводу того, может ли клиент наблюдать за выполнением услуги сотрудниками клиники.
Спайки
Команда решила, что прежде, чем приступить к реализации истории, необходимо провести исследование в спайке.
Реализовать возможность хозяина питомца обозначать согласие в личном кабинете на присутствие при проведении конкретной процедуры.
Данные
Проставление согласия в личном кабинете можно реализовать с помощью добавления чекбокса на экран пользователя. А значит, для реализации задачи понадобится добавить совсем небольшую часть данных.
Как владелец питомца, я хочу наблюдать за предоставлением услуги в приложении клиники, чтобы быть уверенным в безопасности животного.
Интерфейсы
Приложение — это один из вариантов интерфейса, где можно реализовать описанную функциональность. При необходимости задачу можно разделить на поддерживаемые операционные системы, например iOS или Android.
Подведём итоги
SPIDR — группа техник для деления большой трудноизмеримой и неопределённой пользовательской истории или Job Story на измеримые и простые составляющие, которые удобно планировать и брать в работу.
Каждая техника имеет свою особенность:
- Спайки (Spikes) — выделите из истории спайк, чтобы получить новые знания о том, как реализовать историю.
- Пути (Path) — разделите историю по способам достижения цели истории и её результатам.
- Интерфейсы (Interfaces) — разделите историю по экранам и платформам.
- Данные (Data) — разделите историю по группам элементов данных.
- Правила (Rules) — разделите историю по бизнес-правилам или ограничениям.
Чат поддержки