Фича

Как фичи внедряются в продукт

Как правило, создание фич происходит обособленно от разработки общего продукта и включает следующие этапы: 

формулирование основных целей, которых поможет достичь внедрение фич в проект (например, увеличение числа пользователей, приобретающих платную подписку, или отрыв от конкурентов);

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

сбор идей с помощью интервью, опросов, А/В-тестирования, записей на видео пользовательских сессий, UX-тестирования, продуктовой аналитики и анализа конкурентов;

создание структуры идей — их отбор по компонентам, по сферам применения, по стратегической важности, по взаимосвязям проблем пользователей с востребованностью фич;

расстановка приоритетов создания фич. Фичи оцениваются по их ценности (вкладу в продукт) и по трудозатратам на их реализацию

В зависимости от этих критериев фичи делятся на: Quick Wins (дающие большую ценность и наиболее быстро создаваемые), Big Bets (ценные, но труднореализуемые), Maybes (те, что легко реализуются, не имеют большой ценности и могут быть разработаны позже), Time Sinks (фичи не в приоритете);

отбор (скоринг) фич по критериям и их оценка по шкале от 0 до 10. Сравнение проводится по целевым метрикам, увеличению прибыли, привлечению и удержанию клиентов, по стратегической ценности и по иным параметрам;

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

ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ приглашает всех желающих пройти обучение по созданию успешных и ценных фич для различных направлений IT. Записаться на данные курсы можно на нашем сайте.

Алгоритм перехода с мономодульности на многомодульность

common-модульcore-модульесли вашему модулю нужно что-то из зависимостей, не стоит сразу этот код физически также перетаскивать в модули

• Создать апи фичи, поместить его в новый api-модуль. То есть полностью создать модуль :feature-scanner-api со всеми интерфейсами.
• Создать :feature-scanner-impl. В этот модуль физически перенести весь код, относящийся к фиче. Все, от чего зависит ваша фича, студия сразу подсветит.
• Выявить внешние зависимости фичи. Создать соответствующие интерфейсы. Эти интерфейсы разбить на логические api-модули. То есть в нашем примере создать модули :core-utils, :core-network-api, :core-db-api, :feature-purchase-api с соответствующими интерфейсами.
  Советую все-таки сразу вкладываться в название и смысл модулей. Понятно, что с течением времени интерфейсы и модули могут немного перетасовываться, схлопываться и т. д., это нормально.
• Создать апи внешних зависимостей (ScannerFeatureDependencies). В зависимости :feature-scanner-impl прописать созданные недавно api-модули.

• Так как в app у нас находится все легаси, то вот что делаем. В app мы подключаем все созданные для фичи модули (api-модуль фичи, impl-модуль фичи, api-модули внешних зависимостей фичи). Супер важный момент. Далее в app создаем имплементации всех необходимых интерфейсов зависимостей фичи (Сканера в нашем примере). Данные имплементации будут скорее просто проксями от ваших апи зависимостей к текущей реализации этих зависимостей в проекте. При инициализации компонента фичи подставляете данные имплементации.
  Сложно словами, хотите пример? Так он уже есть! По сути что-то подобное уже есть в feature-scanner-example. Еще раз приведу его немного адаптированный код:

  То есть основной посыл здесь такой. Пусть весь необходимый для фичи внешний код живет в app, как и жил. А сама фича уже будет с ним работать по-нормальному, через апи (имеется в виду апи зависимостей и api-модули). В дальнейшем имплементации будут постепенно переезжать в модули. Но зато мы избежим бесконечной игры с перетаскиванием из модуля в модуль необходимого внешнего для фичи кода. Мы сможем двигаться четкими итерациями!

• Profit

Дополнительные советы

Насколько большими/мелкими должны быть фичи?Чистота app-модуляappappappapi-impl-модулиapp:adapterappclean_app:stub-moxy-javaapp

Flexibility-usability tradeoff

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

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

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

Посмотрите на фейсбук, он пару лет назад вынес из себя свой мессенджер. Зачем? Как вы думаете?

Почему гугл делает отдельные проекты? Почему есть отдельно gmail и отдельно google drive. Почему они не сделали одного большого монстра?

Donald A. Norman (The invisible Computer, MIT Press)

Andrew Odlyzko (The invisible problems of invisible Computer: A sceptical look at information appliances)

Новая задача

Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.

Джуниор (англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- (англ. middle — средний) и сеньор-разработчики (англ. senior — старший).

Бэкенд или бэк (англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт (англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком (англ. full stack — полная куча / полный набор).

Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.

Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.

Спринт — период от одной до четырёх недель, за который сотрудники должны успеть выполнить задачу или задачи. Спринты являются частью Скрам.

Скрам (англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл (англ. agile — гибкий).

Валидация — проверка данных, которые вводит пользователь.

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

До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:

— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.

— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?

— Надо проверить в гитхабе историю коммитов.

Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.

Репозиторий — хранилище исходных файлов проекта.

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

Говнокод — очень плохой код.

Код ревью — проверка кода.

Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.

Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.

У стола его уже ждал тимлид:

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

— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.

— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.

— Но у меня уже есть задача на эту неделю, я не успею всё исправить.

— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.

[править] Классификация

◄ ►

Баги в WinXP. Теперь и с музыкой.

И еще немного.

Баги классифицируются по степени их вредности:

• showstoppers (совсем капут, программа крашится или виснет; либо же крашится или виснет ЭВМ, на котором был баг, если ЭВМ был соединен в локальную сеть, или вообще был сервером, то упасть может несколько ЭВМ сразу, вплоть до всей сети);
• серьёзные;
• мелкие;
• фигня;
• придирки тестировщиков;
• полезный баг, который можно обозвать фичей и вообще не исправлять.

по частоте появления:

• постоянно;
• иногда (самый сволочной тип бага, «плавающий»);
• только на машине у заказчика.

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

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

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

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

FeatureToggle

Мы не придумали ничего нового в данном подходе, мы просто использовали его в нужное время и в нужном месте. Зачастую FeatureToggle используются в приложениях, чтобы проводить A/B тестирование или включать/отключать различную функциональность в зависимости от настроек на сервере. Мы стали использовать этот подход локально, чтобы решить свои проблемы при работе с ветками.

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

Работает это следующим образом:

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

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

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

AMAZON

А смысл статьи в том, что Amazon думает не о новых фичах, а о «Core UX Features».

Амазон продает довольно много товаров и соответственно у него есть многоуровневое меню.

И когда вы двигаете курсором по этому меню оно открывается мгновенно. И это очень круто. Потому что у вас нет этой бесящей задержки.

Когда как если вы зайдете практически в любой другой онлайн магазин вы увидите эту гадкую задержку. Можете сами это проверить, например, зайдя в онлайн-магазины ДНСа или Ситилинка. Вы увидите, что вы когда двигаетесь по элементам меню, то список открывается примерно через секунду. И это раздражает.

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

И Amazon решил эту проблему. И решил очень элегантно.

И теперь мы можем двигать свою мышку по-диагонали, при этом меню будут отображаться мгновенно.

Вот после такого решения я готов аплодировать Amazon. Эту статью я прочитал в 2013 и она до сих пор не выходит у меня из головы. Это и есть работа с «Core UX Features».

И я убежден, что компании, которые уделяют настолько пристальное внимание «Core UX Features» становятся лидерами на рынке

Hick’s Law

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

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

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

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

W. E. Hick On the Rate of Gain of Information

Form follows function

Форма следует за функцией.

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

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

Красота это отсутствие избыточных элементов, в том числе и отсутствие декоративных элементов.

Разработка

Буст

boostускорениеПримеры употребления:

• «Я создала задачу на буст списка»
• «Мы бустили открытие диалоговых окон»
• «Мне кажется, что сейчас уже заметный буст есть»

Катить

Примеры употребления:

• «Тут ручное тестирование не требуется, я сам задачу закачу»
• «Не забудьте, мы завтра катим эту фичу»
• «Когда катится задача со списками?»

Комплитить

completeзаканчиватьПримеры употребления:

• «Я закомплитила родительскую таску, потому что все сабтаски закомпличены»
• «Можно уже комплитить таску?»
• «Сторю пока комплитить рано, надо вначале баги пофиксить»

Консистентность

consistencyсистемностьПримеры употребления:

• «В моке кнопка серая, а у нас везде синие, неконсистентно получается»
• «Сделала миксин и переменные так же, как там, чтобы поддержать консистентность»
• «Выглядит консистентно»

Матчится

matchсовпадатьПримеры употребления:

• «Этот стиль вот совсем не матчится с тем, что сейчас на проде»
• «Нужно сматчить эти два мока»
• «Отлично матчится с недавно зарелиженной фичей»

Пинать

ПодопнутьдопинатьПримеры употребления:

• «Надо допинать уже эту таску»
• «Подопни чутка и можно в тестирование»
• «Мы уже столько раз допинывали эту фичу»

Ручка

handlerобработчикПримеры употребления:

• «Какое название у ручки, в которой пользователи приходят?»
• «Тут дергаются сразу три ручки»
• «При клике на кнопку мы из этой ручки получаем айди объекта»

Скоуп

scopeобъемПримеры употребления:

• «В чьем скоупе данная фича?»
• «Это в скоупе вот этой команды, спроси у них»
• «Нет, это не из нашего скоупа»

Фича

featureхарактеристикаПримеры употребления:

• «Завтра релизим эту фичу вместе с фиксом багов»
• «Ваша команда классную фичу разработала»
• «Для нового функционала обязательный фича-тур»

Флоу

flowтечениеПримеры употребления:

• «В нашем флоу ревью обязательно, нельзя его пропускать»
• «Та команда работает по другому флоу»
• «Какое флоу у вебсайта?»

Horror Vacui

И это мой любимый эффект, на русском языке самым верным переводом будет «Боязнь пустоты».

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

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

Например, посмотрите на картины Адольф Вёльфли (он провел 35 лет в сумасшедшем доме), Жан Дюбюффе, Дэвид Карсон, Воган Оливер, Клей Уилсон, Роберт Крамб.

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

Исследования показывают, что horror vacue обратно пропорциональна воспринимаемой ценности. Люди, например, исследовали магазины одежды, которые выставляли витрины в своих магазинах, и оказалось, что степень заполненности витрин манекенами, одеждой, ценниками, акциями, оказалось обратно пропорциональной средней цене товаров и престижности магазина.

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

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

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

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

Tinder

Можно приводить и другие примеры. Например, приложения для знакомств. Есть у нас Tinder, который лидер на рынке. У него по сравнению со всеми другими приложениями просто невероятно скудный функционал.

Можно только лишь свайпать и переписываться.

При этом MATCH GROUP имеет Market Cap $20B. Конкуренты там даже и рядом не валялись. Хотя у конкурентов фич в разы больше.

Вот, например, отличный пример того, что фичи могут отталкивать от приложения. Одно из приложений для знакомств сделало прям огромное количество фич. Тут вам и какой-то «Photoline» которого нет у тиндера, и естественно это конкурентное преимущество. И лайв стримы, которых тоже нет у тиндера, второе конкурентное преимущество. Только вот приложение забыло про самое главное, что я при регистрации указал, что мне интересны девушки, а приложение почему-то показывает мне не только девушек. И это для меня настолько странно, что удалить это приложение это самое рациональное, что только может сделать пользователь.

Как минимум могут отталкивать сложным интерфейсом. Я могу зайти в приложение и сказать НЕТ СПАСИБО, разбираться я вот с этим не буду.

Другие приложения для знакомство тоже соревнуются конкурентными преимуществами. Вот вам пример:

Тут есть и голосование за победителей. Явное преимущество над тиндером. И фотоконкурс. И даже новости. Ну и самое классное, что тут есть flash-игра из 2002 года. Видимо, создатель этого продукта раньше делал flash игры и решил, что им нельзя пропадать. Скорее всего, в этой компании не в курсе, что в моем телефоне уже давно есть PUBG, Heartstone, FIFA, Clash of Clans и Brawl Stars.

А знаете каким образом мыслят в этих компаниях? Они смотрят на статистику. Смотрят, например, сколько людей кликают на игры. И окажется, например, что на игры кликало 5% пользователей. И в компании считают, что раз есть игра, то ее нужно оставить, ведь люди ей пользуются.

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

Итог. Приложения выиграли у тиндера по количеству фич. А тиндер выиграл их всех по количеству заработанных денег.

Организационное

Апрув

approveодобрятьПримеры употребления:

• «Поставил тебе апрув в задаче»
• «Ты посмотрел? —Да, апрув»
• «Заапрувь, пожалуйста, мою заявку на отпуск»

Валидный

validправильныйПримеры употребления:

• «Валидный поинт»
• «Тебе подходит моё решение? Да, валидно!»
• «Посмотри, валидно ли оставить так, как есть»

Инпут

inputвкладПримеры употребления:

• «Все еще жду инпута на присланные моки»
• «Я получил инпут от клиента»
• «Хороший инпут мы получили»

Капиай

KPIKey Performance Indicatorключевой показатель результативностиПримеры употребления:

• «Добавь капиай для измерения успеха данной цели»
• «Есть список требований и капиаи к ним»
• «Нужен капиай, чтобы понять работает ли твоя схема или нет»

Пинговать

pingударяться со стукомПримеры употребления:

• «Пингани мне в личке, когда закончишь»
• «Надо пингануть ответственного»
• «Я пинганул сисопсам о завтрашнем релизе»

Эскалировать

escalateобострятьПримеры употребления:

• «Я эскалировал проблему»
• «Давайте не будем эскалировать»
• «Предлагаю заняться эскалированием этого вопроса»

Жизненные проблемы

Потенциальные решения

Третий вариант

не в отдельный компонент, а в отдельный даггеровский модульПервый путьSingletonAppComponentAppComponentAppComponentВторой путьPerFeature

• Удобный механизм DI, позволяющий использовать фичи в рамках других фичей (в нашем примере мы хотим в рамках Сканера и Антивора использовать фичу Покупок), без костылизации и боли.
• Тончайший AppComponent.
• Фичи не должны знать об имплементациях других фичей.
• Фичи не должны быть доступны по умолчанию кому угодно, хочется иметь какой-то строгий механизм контроля.
• Возможно отдать фичу в другое приложение с минимальным количеством телодвижений.
• Логичный переход на многомодульность и лучшие практики по этому переходу.

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

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

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

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

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

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

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

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

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

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

При нарезке Фич мы обычно просто находим наиболее важную часть и оставляем остальное на потом.

Как проходит генерация признаков: 3 задачи этого этапа Data Mining и способы их решения

Генерация признаков включает в себя 3 взаимосвязанные задачи , каждой из которых мы посвятили отдельную статью:

извлечение признаков (feature extraction) – превращение данных, специфических для предметной области, в понятные для модели числовые векторы

В частности, именно здесь выполняется токенизация и лемматизация текстов, обработка изображений и геоданных;

преобразование признаков (feature transformation) – изменение данных для повышения точности алгоритма, например, нормализация или изменение вероятностного распределения;

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

машинному обучению

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

Генерация признаков — пожалуй, самый творческий этап Data Preparation

Все подробности Feature Engineering и другие детали Data Preparation в нашем новом обучающем курсе для аналитиков больших данных: подготовка данных для Data Mining. Приходите, будет интересно!

Смотреть расписание
Записаться на курс

Источники

1. https://www.bigdataschool.ru/bigdata/data-preparation-operations.html
2. https://www.mql5.com/ru/articles/2029
3. https://habr.com/ru/company/ods/blog/325422
4. http://datareview.info/article/universalnyj-podxod-pochti-k-lyuboj-zadache-mashinnogo-obucheniya/