Что такое фича в agile

Features — Фичи

Фича представляет собой функциональность решения, которая несет ценность для бизнеса, удовлетворяет потребности заинтересованных лиц и имеет такой размер, что она может быть реализована одним Agile Release Train в рамках одного Интервала Планирования (Planning Interval, PI).

Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

Что мы делаем
Наша команда
Блог
Контакты

Расписание тренингов
Карта тренингов
Сертификации
Обучение Scrum Master
Обучение Product Owner
Обучение Kanban

Услуги для компаний
Тренинги для групп от 10 чел.
Кейсы клиентов

Как правильно нарезать Фичи для Инкрементов Программы SAFe®

Как подготовить Фичи к планированию Инкремента Программы?

Перевод статьи Ian Spence и Keith de Mendonca Right-sizing Features for SAFe® Program Increments выполнен с разрешения авторов.

Одной из ключевых активностей, необходимой для успеха вашей реализации SAFe®, является аккуратная подготовка Фич (Features) перед планированием Инкремента Программы (PI). И существенной частью этой подготовки является нарезка тех целевых Фич, реализация которых требует более чем одного PI.

В этой статье мы хотим поделиться нашим опытом нарезки Фич. А также, вслед за Ричардом Лоуренсом с его популярным постером о Нарезке Историй, дать вам бесплатный постер с правилами Нарезки Фич, который вы сможете использовать в своей SAFe программе. Вот такие мы добрые.

Фичи — это ведь просто большие истории, разве не так?

Для Владельцев Продуктов (Product Owners) и Менеджеров Продуктов (Product Managers) очень соблазнительно рассматривать Фичи как гигантские Пользовательские Истории (User Stories) и работать с ними в бэклоге программы, используя те же подходы, что и для Пользовательских Историй в бэклогах команд.

Но мы обнаружили, что описание Фичи в формате Историй может приводить к проблемам (подробности вы найдете в статье Features and Capabilities на сайте Scaled Agile Framework), и также не стоит применять к Фичам те же правила нарезки, что и к Пользовательским Историям.

В Scaled Agile Framework Фичи и Истории (включая как Пользовательские Истории, так и Enabler-истории) четко различаются с точки зрения целей, структуры и содержания:

Фичи — это видимые блоки бизнес-результата, которые понимает клиент, и именно на уровне гранулярности Фич клиент может приоритизировать потребности.
Фичи могут охватывать несколько пользовательских ролей, пользовательских историй и сценариев использования (use cases).
Над одной Фичей могут одновременно работать несколько команд — команды могут объединяться для поставки Фич.
Разработка Фичи может длиться несколько Спринтов. Реализация Фич происходит посредством реализации всех необходимых Историй.
Разработка Фичи должна легко помещаться в Инкремент Программы. Запомните: Фича должна помещаться в длительный Инкремент Программы так же, как Истории должны помещаться в Спринт.
Истории — это блоки работы, на которые команды делят Фичи с целью их инкрементальной разработки и поставки. Их задача — помочь команде (и заинтересованным лицам) проверять, обсуждать, договариваться и совместно выстраивать процесс поставки Фичи.
Разработка Истории должна быть завершена в течение одного 2-недельного Спринта.
Истории могут существовать и без Фич, что позволяет командам проводить изменения без необходимости создания дополнительных Фич.

Существует целый ряд источников, описывающих правила нарезки Историй, наши самые любимые из них — опубликованные Ричардом Лоуренсом (включая его знаменитый постер о Нарезке Историй) и Дином Леффингвеллом (детали вы можете найти в статье Story на сайте Scaled Agile Framework). Эти правила актуальны и при использовании Фич: они реально помогают командам выявлять, разделять и упорядочивать Истории, которые требуются для разработки Фичи. Но эти правила перестают быть такими действенными в нарезке Фич.

Например, мы никогда не будем рекомендовать выносить требования по производительности в отдельную Фичу, которая будет сделана позже, даже несмотря на то, что реализация этих “Историй производительности” будет производиться в конце разработки Фичи. Это также касается обработки ошибок, CRUD и изменениям данных — мы можем отложить разработку Историй, связанных с этими важными атрибутами программного обеспечения, и сделать их ближе к концу разработки Фичи, но мы не будем группировать их в отдельную Фичу.

В ходе нарезки Фич важно помнить, что это реальные элементы релиза системы, которые должны предоставлять пользователям надежное и готовое к использованию решение. Да, Фичи создаются путем последовательной реализаций Историей, но сами по себе они должны описывать готовое к использованию решение. Заметьте, что готовность решения к использованию подразумевает отсутствие недоделок, а вовсе не реализацию всех возможных Историй.

Есть еще одно важное отличие в декомпозиции Историй и Нарезке Фич. Когда мы декомпозируем Историю, мы обычно делим ее на несколько примерно одинаковых по размеру новых Историй, которые в совокупности полностью заменяют оригинальную Историю. При нарезке Фич мы обычно просто находим наиболее важную часть и оставляем остальное на потом.

Нарезка фич

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

Какие стратегии нарезки вы можете использовать? Мы выбрали 10 наиболее полезных моделей для нарезки:

KISS (Keep it simple stupid) – цель заключается в максимально простой реализации, которая может быть проведена без влияния на производительность системы и т.д. Часто это основной удачный кейс с базовой обработкой ошибок. Отложите все “рюшечки” на более поздние фичи, когда базовая часть уже будет стабильно работать с достаточно высоким уровнем качества.
Отложите Необязательные Сценарии — подразумевает ли Фича множество необязательных сценариев? Определите их в отдельные Фичи и отложите до момента, когда будет реализована основная функциональность.
Разделите по Областям Бизнеса – можно ли разрабатывать Фичу инкрементально для разных типов бизнеса? Начните с наиболее простого бизнеса, чтобы получить быструю обратную связь. Например, можем ли мы сделать простое решение для розничного банкинга перед тем, как расширять его и предлагать подразделениям, занимающимися инвестиционными, торговыми и прочими банковскими операциями? Также обратите внимание на региональные особенности: во многих областях бизнеса существуют разные правила для США, Европы и Азии. Возможно, мы сможем запустить Фичу для одной географической зоны, прежде чем добавлять ее для других зон посредством дополнительных Фич.
Проводите Разделение по Каналам — можем ли мы организовать релизы Фичи таким образом, чтобы инкрементально поддерживать разные каналы / пути выхода на рынок / одну функциональность на разных носителях? Например, для предоставления клиентам доступа к мобильному банкингу, банковскому приложению или услугам банка в отделении используются разные операционные системы или разные каналы. Логично иметь одинаковую функциональность для всех этих случаев, но поставка Фичи для каждого канала может быть организована отдельными Фичами (а в некоторых случаях она может оказаться вообще ненужной).
Разделите Поддержку Групп Пользователей – требуются ли разным пользователем разные наборы историй? Понимание потребностей разных групп пользователей может помочь вам разделить Фичу и лучше понять выгоды, которые в результате получит каждая из групп. Например, наша новая Фича может обращаться к разным демографическим группам, но каждая группа захочет использовать ее по-разному. В таком случае нарезка Фичи позволит нам сфокусироваться только на тех историях, которые актуальны для конкретной демографической группы и раньше понять интересы наиболее приоритетных для нас групп пользователей.
Подключайте Исходные Данные Инкрементально — требуются ли для поставки ценности все исходные данные? Возможно, мы можем организовать работу с Данными инкрементально или провести разделение в зависимости от источников их получения?
Изолируйте Специфические Сценарии — сконцентрируйтесь сперва на наиболее популярных / частых сценариях, а затем добавляйте более специфические как отдельные Фичи. Не исключено, что вы обнаружите, что их ценность невелика и они вообще не нужны.
Находите Общие Enablers – бизнес-фичи зачастую опираются на одно и то же базовое поведение системы, вследствие чего внедрение первых фич кажется очень сложным и громоздким. Выявление таких общих сценариев способно снизить риски, уменьшить оценку реализации и в целом упростить внедрение многих бизнес-фич.
Выявите Группу Историй – помните, что 80% результатов для бизнеса скорее всего придут от 20% историй. Определите эти истории и работайте с ними как с отдельной Фичей. Подробности вы найдете в Story Mapping.
Определите Spike – иногда вам не хватает знаний даже для того, чтобы что-либо запланировать. В таком случае — выявляйте spike.

Примеры плохой нарезки

Мы выявили несколько опасных ловушек, которые могут подстерегать вас в ходе нарезки:

Откладывание нефункциональных требований на потом — типичная модель нарезки фич, которая может привести к проблемам. Конечно, в ходе реализации Фичи мы можем приступать к работе с нефункциональными требованиями после разработки первоначального набора историй, но не следует проводить релиз Фичи, качество и производительность которой не дотягивают до требуемого уровня. Мы видели немало команд, которые имели серьезные трудности из-за того, что в гонке за количеством Фич в продукте переставали следить за качеством.

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

Слишком ранняя нарезка – проводите нарезку только такой Фичи, которая 1) нужна в самом ближайшем будущем или 2) слишком большая (на текущий момент), чтобы эффективно встроиться в систему. Помните, что оценки реализации Фич постоянно меняются: то, что сегодня кажется слишком большим, в будущем может получить куда меньшую оценку.
Слишком глубокая нарезка – нет необходимости нарезать Фичу на множество меньших фич за один присест. Обычно достаточно определить первые один-два кусочка, а к остальному вернуться после завершения их реализации.
Нарезка по компонентам – мы заметили, что техническим специалистам бывает сложно сопротивляться соблазну нарезать фичи по архитектурным компонентам, подсистемам или слоям. Это тактическое решение, которое нередко применяется на уровне Историй, особенно в случае компонентно-специфических команд или с командами, которые всячески пытаются уместить свои истории в двухнедельный спринт. Это плохая привычка, и с ней нужно всерьез бороться, особенно когда вы имеете дело с более крупными компонентами, такими, как Фичи.
Откладывание Тестирования Фичи — фичи нередко требуют дополнительного тестирования, сверх того, что необходимо для тестирования набора входящих в них Историй. Одна из ловушек, возникающих в ходе нарезки — откладывание тестирования на более поздний этап вместо того, чтобы включать необходимый объем тестирования как часть каждой из небольших Фич.
Нарезка по операциям или шагам процесса — когда речь идет о реализации процесса, зачастую возникает соблазн разделить Фичу по шагам или по операциям, требующимся на каждом шаге. Например, можно определить входящий поток, обработку и выходные данные процесса в разные Фичи или еще проще — разделить процесс на создание, доступ, изменение и удаление элементов. При нарезке Фич это происходит довольно часто и является ошибкой, поскольку реализация только одного шага процесса практически не приносит бизнес-ценности. Сфокусируйтесь на каком-нибудь корневом поведении, присущем Фиче, и создайте максимально простое сквозное решение. Последующие дополнительные Фичи могут включать разные вариации поведения и прочие “рюшечки”, но добавлять их следует только после того, как базовая функциональность от начала до конца процесса успешно прошла релиз и уже находится в руках пользователей. Такая необдуманная нарезка зачастую приводит к ситуации, когда 90% Фичи уже готово, но решение не может удовлетворить ни одну из реальных потребностей пользователей. Они могут внести какие-то данные, найти какие-то данные, что-то поменять, но не могут физически завершить процесс, которому пытаются следовать.

Постер о нарезке фич

IJ_HOW-TO-SLICE_rus-a4[1]

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

Кибербезопасность в Agile

Текущий опыт выстраивания процессов для обеспечения кибербезопасности в проектах Sbergile (методология гибкой разработки Сбербанка).

erid: LjN8KTEeS
ООО «ИТ Медиа»

erid: LjN8KFUsG
ООО «ИТ Медиа»

Разумное планирование позволяет не только избежать сложностей на дальнейших этапах, но и более адекватно оценить нагрузку на команду, правильно «рассчитать силы».
Важно определить и зафиксировать показатели и маркеры, благодаря которым можно будет понять, что цель достигнута и все основные требования выполнены.
Планирование и контроль малых частей (спринтов) значительно облегчает выпуск качественного продукта в целом. Обнаружение ошибок и неточностей на ранних этапах позволяет оперативно их устранить.

Следующий этап «Выполнение» полностью совпадает с этапом «спринта» в Agile. На данном этапе роль ЭПО, скорее, консультационная — на тот случай, если в процессе реализации того или иного решения возникнут непредвиденные проблемы или поступят новые вводные.

По результатам выполнения спринта команды проводят демонстрацию или демо-встречу участников команды и других заинтересованных лиц для показа продукта команды, созданного за данный спринт. Эта активность совпадает с этапом «контроль» — «cheсk». На данном этапе ЭПО осуществляет контроль выполнения установленных требований, реализации достигнутых решений. В том случае, если в результате спринта реализуется эпик или продукт готов к релизу, проводятся приемо-сдаточные испытания. Они могут считаться расширенными демо — увеличивается масштаб контроля, контролируется взаимодействие с другими системами, проверяется сквозной бизнес-процесс. Основной задачей ЭПО на данном этапе является не столько проверка выполнения требований кибербезопасности, сколько оценка готовности продукта к опытной или промышленной эксплуатации.

По итогам спринта и демонстрации выполненных работ команда проводит ретроспективу. По сути, это этап «Воздействие» — act цикла PDCA. Ретроспектива —встреча участников команды, владельца продукта и скрам-мастера, а также ЭПО по кибербезопасности для обсуждения совершенствования процессов деятельности команды и выявления факторов, мешающих продуктивной работе. На этом этапе происходит в том числе и оценка действий команды по обеспечению кибербезопасности, а также формируются подходы к более эффективному сотрудничеству.

Еще одним важным аспектом интеграции является ведение и учет достигнутых договоренностей — артефактов. Agile пропагандирует минимизацию сопроводительной документации, но необходимость фиксации достигнутых договоренностей остается актуальной. Именно по артефактам ЭПО может проконтролировать процесс разработки, включая реализацию требований. Учет артефактов также позволит по прошествии времени поднять историю создания продукта, использовать ранее полученный опыт, оценить адекватность и правильность принятых решений.

Мост построен?

Текущий опыт выстраивания процессов взаимодействия ЭПО с командами Sbergile показывает, что это позволило более широко раскрыть преимущества методологии Agile. ЭПО уже не воспринимается командами как полицейский, запрещающий движение. Для команд ЭПО, скорее, полноценный участник процесса, советник по вопросам кибербезопасности. Исчезло недоверие и предвзятое отношение к ЭПО. С другой стороны, владелец продукта и команда больше погрузились в вопросы обеспечения кибербезопасности в продукте. Многие вопросы безопасности уже не требуют постоянного внимания со стороны ЭПО, а функциональные тесты включают вопросы кибербезопасности. Владелец продукта, понимая необходимость соблюдения принципов кибербезопасности, сам организует работы по развитию продукта в этом направлении. Тем самым достигается основное преимущество Agile — гибкая, оперативная разработка и выпуск качественного и безопасного продукта.

Автор: Антон Каралкин, руководитель направления отдела розничных клиентов Управления экспертизы кибербезопасности Сбербанка.

Введение фич: три шага к успеху – Feature Injection: three steps to success

Авторы: Chris Matts & Gojko Adzic

Введение фич (feature Injection) – это фреймворк бизнес аналитического процесса, который позволяет командам использовать все ценное, что есть в традиционных бизнес аналитических методиках, в проектах с частыми итеративными поставками, такими как проекты на основе agile и lean. Он фокусируется на разработке через тестирование (test-driven-development) и разработке на основе поведения (behaviour-driven-development) при поставке бизнес ценности и гарантирует, что команда делает фичи и проекты, которые поставляют ценность, избегая бесполезных трат, связанных с расползшимся содержанием проекта (scope) и кодом, который делается «на всякий случай».

Эта статья – высокоуровневое вступление в тему Введения фич и связанных с этим методик. Мы объясняем ключевые элементы фреймворка и иллюстрируем реалистичными примерами. Чтобы статья не стала слишком длинной, мы даем ссылки для дальнейшего изучения, вместо того, чтобы вдаваться в детали, касающиеся отдельных инструментов и методик.

Почему вас должно заинтересовать Введение фич?

Допустим, выработаете в IT отделе интернет магазина, который продает книги и потребительскую технику, и вице-президент по маркетингу начинает новый проект, интеграцию с решением по аналитике продаж, которое делает другая компания. Продавец этого решения как-то убеждает вице-президента, что интеграция будет полезной, но требования очень расплывчаты, часто выражаются как “пошлите им все данные, которые у нас есть”. После первоначального анализа ваша команда глубоко ушла в обсуждение сложных решений о структуре данных, экспорте файлов и масках для соблюдения требований конфиденциальности и защиты данных. Вы знаете, что нельзя посылать данные кредитных карточек, но никто не знает в точности, нужно ли делать маски для домашнего адреса заказчика и его даты рождения. Люди из маркетинга настаивают на пересылке данных в реальном времени, не обращая внимания на жалобы со стороны команды архитекторов, касающиеся влияния такой нагрузки на регулярную работу системы. Когда за пивом архитектор озвучивает свои опасения директору продаж, своему школьному другу, весь проект кладется на полку, официально ожидая дальнейшего анализа. Звучит знакомо? В таком случае, читайте дальше, чтобы понять, как избежать такой ситуации.

Если вы работаете в IT отделе в крупной организации, ваша команда, скорее всего, должна приоритезировать и сбалансировать запросы множества заинтересованных лиц, и задействовать множество людей и даже групп при подготовке к разработке программного обеспечения, потому что знания не централизованы. Вы, наверное, думаете, что как только вы поставите фичу, кто-то попросит внести в нее изменения, и кажется что если бизнес пользователи не продумали решение с начала до конца, то это приведет к расползанию содержания проекта и ненужным переделкам. Если вы являетесь представителем бизнеса в такой организации, вы, возможно, считаете, что инкрементальный или эволюционный подходы разработки, движимые насущным содержанием проекта (таким как пользовательские истории), не могут поставить бизнес ценность. Обе проблемы вызваны сложностью организации крупного бизнеса и систем, их можно наблюдать по следующим симптомам: часто у бизнес пользователей, которые общаются с командой разработки, нет четкой идеи, откуда идет бизнес ценность проекта; а команда разработчиков слишком фокусируется на низкоуровневых деталях и теряет видение всего в целом.

Введение фич – эффективный способ предотвращения таких проблем. При этом, он обходит подводные камни, связанные с более традиционным последовательны процессом разработки (такие как паралич анализа, длинные фазы анализа и проведенные зря работы по анализу требований, которые меняются еще до реализации). Цель Введения фич – связать сообщество бизнес аналитиков с сообществом agile разработчиков. С одной стороны, Введение фич позволяет традиционным бизнес аналитикам, привыкшим к UML / Use Case-ам или SSADM, эффективно участвовать в Agile и Lean проектах, слегка сдвинув акценты и без необходимости проходить значительное обучение новым методикам. С другой стороны, это помогает agile и lean командам получать преимущества от достаточного анализа, в то время, когда он требуется, что позволяет предотвратить расползание содержания проекта или проблем с поставкой бизнес ценности с сложных промышленных проектах.

Три этапа Введения фич

Введение фич появилось на основе практики, а не как разработанный процесс. Первоначальная идея возникла у Криса Мэттса (Chris Matts), когда он и Rohit Darji проводили парный анализ – они сидели за общим столом из-за нехватки места, в эру доткомов. В 2003 году Энди Полс (Andy Pols) и Мэттс разработали эту идею, когда искали способ вовлечь традиционных бизнес аналитиков в agile проект. Мэттс расширил ее, когда работал с Sanela Hodzic в 2004. Тогда Мэттс ввел использование примеров для подтверждения или разрушения моделей. Последний элемент в этой картине – взгляд на IT проект как на процесс поступления информации – появился благодаря разговору Мэттса с Дэвидом Андерсоном (David Anderson) на конференции Agile 2007.

Отбирая ключевые идеи, Kent McDonald определил Введение фич как фреймворк трехэтапного процесса (Feature Injection : A gentle introduction. presented at Agile2009):

Определите ценность.
Введите фичи.
Определите примеры.

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

Определите ценность

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

Чтобы быть уверенными, что программное обеспечение поставит ожидаемую бизнес ценность, нужно четко определить и разъяснить ее. Несколько существующих процессных фреймворков пытаются делать это, с разной степенью успеха. Пользовательские истории требуют явного определения бизнес ценности. Многие команды бьются за то, чтобы сделать это правильно, а в результате историй становится слишком много (см. story card hell). В частности, в комплексных промышленных системах ценность не всегда очевидна командам разработчиков и требует разъяснения и анализа на более высоком уровне. Mark Denne и Jane Cleland-Huang в книге Software by Numbers описывают подход к разработке на основе финансового моделирования, но для команд это часто вызывает затруднения, потому что бизнес ценность трудно описать одним числом, и определение этих значений не легче, чем оценка того, сколько времени потребует разработка. Число, присвоенное ожидаемой бизнес ценности становится “основанием”, на котором строится проект, и редко пересматривается. Это ведет к похоронам или зомбированию проектов.

При использовании фреймворка Введения фич команды сначала “охотятся за ценностью”, создавая модель поставки бизнес ценности, вместо того, чтобы пытаться описать ее только одним числом.

Например, модель ценности для примера с аналитикой продаж будет что-то вроде следующего: мы получим доход от роста продаж уже существующим заказчикам, мы надеемся использовать аналитику продаж, предлагая товары, которые люди активно покупают, вместо того, чтобы быть пассивно системой покупок. Используя этот подход мы надеемся увеличить наши продажи на 10% в первый месяц и на 200% за шесть месяцев.

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

Модель для бизнес ценности позволяет нам создать стратегию, дает способ сказать: “Вот вещи, которые мы делаем сейчас, и будем делать в будущем”, и, возможно, что более важно, способ сказать: “Эти вещи мы НЕ делаем сейчас и в будущем ”. Ключевым моментом является то, что модель бизнес ценности (business value model) позволяет согласовать понимание, которое есть у команды разработчиков и бизнес инвесторов или спонсоров.

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

Явное определение допущений помогает создать общее понимание того, откуда появляется ценность, позволяя команде отмечать новые возможности или предотвращать движение в тупиковом направлении. Например, команда архитекторов может предложить использование уже доступной статистики, такой как «10 наиболее популярных товаров, которые продаются каждую неделю», чтобы проверить реагируют ли заказчики позитивно на активные продажи. Это можно сделать, не интегрируясь с третьей стороной для создания аналитики, и возможно даст быстрый возврат инвестиций.

Вот некоторые инструменты, которые можно использовать в охоте за ценностью и создании модели

Раскручиваем стэк «почему» /пять«почему». Начинаем с запроса на фичу и раскручиваем стэк «почему», пока не дойдем до причины, а значит и до ценности.
Ставим вопрос “чем это будет полезно?”
Модель выравнивания цели (Purpose alignment model)
Рыночная модель зрелости бостонской консалтинговой группы (Boston Consulting Group Market Maturity Model)
Шаблоны инспектирования. Особенно полезно для нефункциональных требований (“no design” и т.п. для реальных требований (см. Competitive Engineering)

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

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

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

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

Система позволила бы компании увидеть прогнозы рисков, что позволило бы определить моменты в будущем, когда контрагент потенциально нарушит свои лимиты.

Введите фичи

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

Худшая ошибка анализа – начать с того, что мы имеем на входе, хотя это именно то, что делают многие команды. В истории, с которой начинается эта статья, команда зашла в тупик именно из-за этого, работая над требованиями к защите данных и проблемами с нагрузкой. Если работа над системой начинается со входных данных, это ведет к бесконечным вопросам типа “Что нам нужно?”, и затратам времени на анализ каждого возникшего предложения, чтобы понять, действительно ли нам это нужно. Это общий рецепт паралича анализа. Ценность входных данных системы – вариации при создании выходных результатов.

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

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

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

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

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

Инструменты, используемые для введения фич:

Традиционное Моделирование Сущность-Связь
Объектное моделирование (UML)
Модели в таблицах (см. пример ниже)
Effect mapping

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

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

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

Зная результаты, мы можем ввести фичи для расчетов. Мы работаем от результата к входным параметрам. Для расчета сумм нам нужно знать количество баррелей нефти в танкере, умноженное на цену за баррель. Расценки за нефть мы можем получить из специальной системы «цен на нефть».

Количество баррелей – это уже более интересно. По контракту количество баррелей может отличаться на 10%, поэтому, чтобы быть осторожнее, мы определили количество баррелей как 110%, по сравнению с суммой, прописанной в контракте. Эту информацию мы можем получить из специальной системы «нефтяных контрактов».

Когда танкер определен, мы можем получить более точное количество баррелей, с погрешностью 2%. Эта информация будет в «системе планирования». От введения этой лучшей точности выигрывают трейдеры, т.к. это дополнительный потенциал для торгов. Добавление этой информации относится к другой бизнес ценности.

Когда нефть загружена в танкер, известно точное число баррелей. Эта информация появляется в «системе операций». Опять же, выигрывают от нее трейдеры.

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

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

Наш первый шаг к достижению бизнес ценности выглядит примерно так …

Как только мы определили значения, которые нам нужны для системы, мы можем остановиться. У Введения фич есть определенная точка окончания, и поэтому нет опасности паралича анализа.

Определите примеры

Введение фич обеспечивает набор “счастливых путей” для создания результатов, которые поставляют бизнес ценность. Однако, это не дает все варианты ввода, которые могут иметь место и повлиять на результат, или все случаи, которые нужно рассмотреть для создания успешной системы. Чтобы определить все варианты, нужно расширить содержание проекта. Введение фич определяет область действия введенных фич особым образом, который в то же время эффективен в достижении всеобщего понимания, а именно – используя примеры. Примеры – это естественный способ обсуждения и выяснения идей в ежедневном общении. Мы используем их, даже не думая об этом. Например, если поискать слово “например”, то Google вернет больше чем 300 миллионов страниц. Примеры – это очень эффективный способ проверить допущения, сделанные в требованиях и перейти от того, что, как говорит заказчик, он хочет, к тому, что ему действительно нужно.

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

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

Сначала у нас были простые примеры с контрактами с фиксированной ценой за нефть. ( Нам нужна цена из контракта и способ отличить контракты с фиксированной ценой и с рыночной ценой. )

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

Бизнес смог понять примеры и дать больше сложных примеров.

Кроме моделирования данных в таблице, была сделана модель типа сущность-связь. Это помогло нам сфокусироваться на поиске интересных примеров. Например, покрывает ли контракт только одну поставку (танкеры) или он может покрывать более одной поставки нефти (баржи).

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

Высокоуровневые примеры дают контекст, достаточный для того, чтобы сфокусироваться на таких процессах, как разработка через тестирование (test-driven-development), и разработка, основанная на функционировании (behaviour-driven-development). Их можно разбить на более мелкие примеры, которые описывают, как должны работать разные функции системы, что помогает раскрыть высокоуровневые примеры. Если они достаточно детализированы, то по ним можно провалидировать разрабатываемую систему. Мы получаем объективную меру прогресса и основу для живой системы документации (living documentation system).

Инструменты для определения примеров:

Традиционное Моделирование Сущность-Связь
Объектное моделирование (UML)
Примеры в таблицах (см. пример)
Добавление примеров в спецификации
Проблемно-ориентированное проектирование (Domain Driven Design)