Введение фич: три шага к успеху – Feature Injection: three steps to success
| November 25, 2012 | Posted by admin under Практики, Статьи |
Авторы: Chris Matts & Gojko Adzic
http://www.infoq.com/articles/feature-injection-success
Введение фич (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)
-
Anonymous
