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

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

Почему это важно?

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

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

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

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

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

Хороший пример – написание юнит-тестов. Зачем мне тратить своё драгоценное время на написание тестов, если у нас есть тестировщики, которые потом и так всё протестируют? А затем, что юнит-тесты необходимы не только для облегчения процесса кодинга – они нужны также и на последующих этапах. И нужны как воздух: с ними процесс интеграции и проверки регрессии ускоряется в десятки, сотни раз, на них базируется пирамида автоматизации . И это даже если не брать в расчёт ускорение вашей собственной работы: ведь «потрогав» код в каком-то месте, вам самому нужно убедиться в том, что вы ненароком что-нибудь не сломали. И один из самых быстрых способов это сделать – прогнать юнит-тесты.

Workflow

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

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

Говоря о workflow разработки, многие, кто использует Git, сразу вспоминают (всуе) о некоем «стандартном git-flow», считая его идеальным, правильным, и часто внедряют его у себя. Даже на конференциях, где я выступал, рассказывая про workflow в Badoo, меня несколько раз спрашивали: «Зачем вы изобрели своё, почему не используете стандартный git-flow?» Давайте разбираться.

Во-первых , обычно, говоря про этот флоу, имеют в виду вот эту картинку. Я взял её из статьи Vincent Driessen “A successful Git branching model”, в которой описывается схема, довольно успешно работавшая на нескольких его проектах (было это в далёком 2010 году).

Сегодня некоторые крупные игроки на рынке хостинга кода вообще предлагают свой флоу, критикуя «стандартный git-flow» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.

Если всё так сложно, да ещё и флоу – это не догма, а всего лишь рекомендация, то почему бы не использовать одну ветку для всего: Master для Git или Trunk для SVN? Зачем усложнять?

Тем, кто смотрит на проблему однобоко, этот подход с одной веткой может показаться очень удобным. Зачем мучиться с какими-то ветками, париться со стабилизацией кода в них, если можно написать код, закоммитить (запушить) в общее хранилище – и радоваться жизни? И правда, если в команде работает не очень много человек, это может быть удобно, поскольку избавляет от необходимости слияния веток и организации веток для релиза. Однако данный подход имеет один очень существенный недостаток: код в общем хранилище может быть нестабильным. Вася, работающий над задачей №1, может легко сломать код других задач в общем хранилище, залив свои изменения; и пока он их не исправит/ не откатит, код выкладывать нельзя, даже если все остальные задачи готовы и работают.

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

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

Feature branches

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

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

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

Ещё опаснее конфликты, связанные с логикой кода, когда SCM сливает код без проблем (ведь по строкам в файлах конфликтов нет), но из-за изоляции разработки какие-то общие методы и функции в коде изменили своё поведение или вообще удалены из кода. В компилируемых языках проблема, как может показаться, стоит менее остро – компилятор валидирует код. Но ситуации, когда сигнатуры методов не поменялись, а логика изменилась, никто не отменял. Такие проблемы сложно обнаруживать, и они ещё более отдаляют счастливый релиз и заставляют перетестировать код много раз после каждого слияния. А когда разработчиков много, кода много, файлов много и конфликтов много, всё превращается в сущий ад, ибо пока мы исправляли код и перепроверяли его, основная версия кода уже ушла далеко вперёд, и надо всё повторять заново. Вы всё ещё не верите в юнит-тесты? Хе-хе-хе!

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

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

Параллельная работа

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

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

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

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

В этом случае можно использовать промежуточную ветку, общую для нескольких разработчиков, но ещё недостаточно стабильную, чтобы быть выложенной на продакшн (Master или Trunk). В нашем флоу для мобильных приложений такая ветка называется Dev, на схеме Vincent Driessen она называется develop.

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

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

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

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

Feature flags

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

А вот и будем! В этом нет ничего страшного. Подход, который может быть применён в этой ситуации, – feature flags . Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.

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

Последней задачей в процессе разработки новой большой фичи в этом случае будет задача «включить фичефлаг» (или «добавить пункт меню» в примере с новой страницей).

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

Заключение

Итак, при декомпозиции задач важно помнить три простых правила:

1. Задачи должны быть в виде логически завершённых кусочков кода.
2. Эти кусочки кода должны быть маленькими и должны максимально быстро попадать в общий код.
3. Эти кусочки должны разрабатываться параллельно и выкладываться независимо друг от друга.

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

Желаю удачи в разработке новых фич!

Теги: Добавить метки

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

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

Прежде чем изложить способы декомпозиции в задачах управления, поясним смысл декомпозиционного подхода. Пусть характер функции многих переменных f (х 1 , ..., x т ) таков, что максимум по любой из переменных хг не зависит от значений других переменных. Тогда задача оптимизации по т перемен­ным распадается на т задач оптимизации по одной перемен­ной. Решение такой совокупности задач настолько же проще исходной, насколько проще решить т уравнений, с одним не­известным по сравнению с решением системы уравнений с т неизвестными. Столь благоприятная ситуация может встре­титься лишь в исключительном случае. Однако если из т пе­ременных задачи можно составить k комплексов (k <m ) - та­ких, что оптимальное значение каждого комплекса z опреде­ляется независимо, то, найдя первоначально z * v (где v =) из задачи с k переменными, можно затем снизить размерность задачи до т- k с учетом уравнений

z v (х )= z * v ; v =.

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

Рассмотрим основные структуры оптимизационных задач, позволяющие провести декомпозицию.

/. Переменные исходной задачи распределены между агре­гированными переменными z v :

Вектор х v имеет размерность r v , так что общее число переменных в задаче (5.39) равно т=^ Гу.

Решение -задачи может быть проведено в два этапа:

определение /г агрегированных переменных из условия

/о(21,г2,...,2й) ->- тах при //(гь...,г»)>0, /=1,п; (5.40)

нахождение корней уравнений

2у(^)=2у", (5.41)

принадлежащих области допустимых значений переменных ис­ходной задачи Ух-

Если система (5.41) имеет несколько допустимых решений» то решение задачи (5.40) не единственно; если же все решения системы (5.41) не оказываются допустимыми по ограничениям на переменные х^Ух, то либо нужно ввести в агрегированную задачу (5.40) ограничения на г, соответствующие ограничениям х^Ух, либо (когда это сделать сложно) выбрать из числа до­пустимых векторов х ближайший к решению системы (5.41)> подставить его в функции }о и // и оценить, существенны ли уменьшение значения ^о и нарушение ограничений ^^"^^.

Отметим, что переход от ограничений на исходные перемен­ные к ограничениям на агрегированные переменные требует решения 2/г задач вида

из которых находят верхнюю 2у и нижнюю г у границы для агрегированных переменных.

Как правило, исходная задача не имеет форму (5.39), и для декомпозиции прибегают к различным приемам, связан­ным с параметризацией решения.

2. Снятие ограничений с введением параметра в критерий. оптимальности. Пусть декомпозиции задачи мешает наличие ограничений вида

Р/(х)=о; 1=ЦГ, (5.43>

в которые могут входить все составляющие х. Отбросив огра­ничения (5.43), придет к задаче с расширенным множеством допустимых решений. Такая расширенная задача допускает декомпозицию, ее решение обозначим через х. Оно вовсе не обязано удовлетворять условиям (5.43). Чтобы сохранить воз­можность декомпозиции и в то же время получить допустимое решение, в критерий оптимальности !о вводят дополнительные слагаемые, зависящие от функций Р, и от некоторого вектора параметров К. Выбором последнего стремятся добиться, чтобы решение задачи на расширенном множестве оказалось допу­стимым по ограничениям (5.43).

Поясним этот способ на примере задачи

Если бы условия

не было, то задача (5.44) распадалась бы на и задач малой размерности:

гоу (х") --> тах при х" еУ^у, у= 1,й.

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

/ К = ^ гоу(^) + Ф (Р, ? ) --> тах при х" V еV^, v = 1,1г. (5.46)

При этом ^функция Ф должна быть такой, чтобы задача (5.46) допускала декомпозицию, т. е. функция К аддитивно зависела бы от 2"у и 2оу; с другой стороны, при выполнении условий (5.45) Т? должна либо совпадать с /о, либо монотонно расти с ростом /о. Только в этом случае решение, допустимое по усло­виям (5.45) и обеспечивающее максимум К, обеспечивало бы в то же время максимум ^о. В задаче (5.46) это требование вы­полнено при выборе Ф в форме

Ф=ц?=7.^ гу(^).

Задача (5.46) примет вид:

При любом фиксированном значении К задача (5.47) распа­дается на 1г задач малой размерности. Подставив их решения х""*(К) и соответствующие значения г* ,(\), зависящие от X, в условия (5.45), можно найти такое значение К*, при котором г\ удовлетворяют (5.45). При этом х*(К*)- искомое решение (5.44).

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

в котором множитель а>0, а ^ у - векторы, имеющие ту же размерность, что и х"". Ясно, что добавление к ^ слагаемого

(5.48) не препятствует декомпозиции; функция же ^ ^о=/о+5(а,^,р)

для достаточно большого а при любом (З^х выпукла по х. При фиксированных а и ^ V задача (5.42) распадается на под­задачи вида

Практически слагаемое (5.48) добавляют к /? только после того, как выясняется, что без добавления этого слагаемого ^ подобрать не удалось. Это выясняется в вычислительном про­цессе, когда малые изменения ^ вызывают резкое изменение вектора х*(^); при этом величина Р(х*(л)) также испытывает скачок, меняя знак и оставаясь далекой от нуля. В этом слу­чае назначают первоначально а>0, а р=0 в выражении для В (5.48). Затем на каждой следующей итерации выбирают |3 по формуле

р^"-") =(х"^+х »у ^-"щ 1+у),

в которой у имеет порядок 0<у^2. Когда х V ->х" V *, величина (3^" также стремится к х""*, а дополнительное слагаемое (5.48) исчезает.

3. Декомпозиция за счет сечения множества допустимых ре­шений с последующей параметризацией. Пусть структура зада­чи такова, что определить максимум на некотором сечении а множества О гораздо проще, чем на самом О, причем множе­ство таких сечений покрывает все множество О. Введя пара­метр а, значение которого выделяет конкретное сечение с? (а), можно решить семейство задач на множествах а(а), получив при некотором а=а* решение исходной задачи. Приведем не­сколько характерных структур.

а) Пусть х 4 , х 2 и у- векторы, а vi, У-г, Уу- множества их допустимых значений. При фиксированном у=у° задача

распадается на две подзадачи меньшей размерности:

Их решение позволяет найти зависимости х""*(у°), х 2 *(у°) и ]*6\(у°), !*ог(у°)- Максимум по у° их суммы достигается при у=у*. Подстановка этого вектора в х \ "*(у°) и х 2 * (у°) вместо у° определяет решение исходной задачи (5.49). Параметром, определяющим сечение множества О, является в данном случае вектор у°.

б) Рассмотрим задачу

}о(х,у) - »- тах при у^О, х^У. .

Множество V здесь предполагается просто организованным, так что при фиксированном у=у° задача

/о*(У°) -^ тах/(/°е=Д.

легко разрешима. Например, задача (5.51) может быть зада­чей линейного программирования, для которой имеются эф­фективные вычислительные алгоритмы. Получив "!а*(у 0 ), опре­деляют оптимальное значение у* из условия

ШЛ -^ тах/

в) Рассмотрим задачу (5.44) и зафиксируем значения 2у на уровне г/°у. Тогда задача (5.44) распадается на 1г задач ма­лой размерности:

В результате их решения получают ^*оу (У* у) и.г^С^у). На втором этапе решают задачу координации, т. е. определе­ния у*:

^ гоу («/у°) --*- тах при ^ (/у 0 = 0. у=1 у=1

Эту задачу можно решить с использованием функции Лагран-жа, т. е. преобразовать к форме

К = ^ [гоу (> тах, у=1

причем множитель К заведомо найдется, если функции ^*оу вы­пуклы. Матрицы смежности и декомпозиция оптимизационных задач.

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

}о(х) ->- тах при /,(ж)>0; /=1,п; х^Ух; х=(х1, ...,Хт) (5.52)

удобно характеризовать матрицей, каждая строка которой со­ответствует одной из функций !1"а=0,п), а каждый столбец- одной из переменных Х1 (1=1, от). Элемент, стоящий на пересе­чении /"-той строки и г-го столбца такой матрицы, равен 1, если 1-тая переменная входит в /-тое условие, и равен 0 - если не входит. Построенную таким образом матрицу называют мат­рицей смежности; она имеет (п-\-\) строку и т столбцов.

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

Рис. 5.5. Матрицы смежности:

а-для задачи с автономными ограничениями; б-для задачи, декомпозируемойзасчет модификации критерия оптимальности; в-для задачи, декомпозируемой с исполь­зованием фиксации переменныху; г - преобразованная к диагональной форме с гори< зонтальным и вертикальным окаймлениями

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

f 0 (x 1 ,...,x m ) max при f i (x i )  0; i=
(5.53)

Соответствующая матрица, если отбросить первую строку, ока­зывается диагональной (рис. 5.5, а). На рис. 5.5 клетки мат­рицы, в которых стоят единицы, заштрихованы.

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

2. Задача, в которой часть ограничений наложена на сово­купность переменных. Пусть в задаче (5.52) часть функций синдексами 0,1, ..., r может зависеть от всех или почти всех пе­ременных, а остальные ограничения наложены на каждую из переменных автономно. Матрица смежности такой задачи пока­зана на рис. 5.5,б.

С использованием модифицированной функции R [см., на­пример, (5.46)], в которую войдут ограничения с индексом от 1 до r , рассматриваемая задача может быть сведена к задаче с автономными ограничениями, но с дополнительными парамет­рами  в целевой функции. Таким образом, матрица смежности, имеющая диагональную форму с горизонтальным окаймлением, характерна для задач, решение которых целесообразно прово­дить методами, основанными на введении неопределенных па­раметров в модифицированную целевую функцию.

3. Задача, в которой часть переменных входит во все огра­ничения. Обозначим переменные, входящие во все или почти все функции f i в задаче (5.52), через у=(х 1 , ..., x r ). Остальные переменные входят только в одну из этих функций. Матрица смежности подобных задач может быть приведена к форме рис. 5.5, б. Ее называют диагональной с вертикальным окайм­лением. При фиксированном значении вектора у задача пре­вращается в задачу типа (5.53), а ее матрица смежности после отбрасывания первых r столбцов оказывается диагональной.

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

4. Общая задача оптимизации сложных систем. В общей задаче оптимизации сложных технологических систем, которая имеет большое число переменных и наложенных на них огра­ничений, часто оказывается, что матрица смежности сильно разрежена (имеет много нулей). Эту матрицу стремятся преоб­разовать путем перестановок строк и столбцов к диагональ­ной форме с вертикальным и горизонтальным окаймлением (рис. 5.5,г). На рис. 5.5, г в заштрихованных клетках стоят в основном единицы, а в незаштрихованных - только нули. Множество индексов переменных, входящих в большинство функций, обозначено ; множество индексов условий, содер­жащих большинство переменных, обозначено .

При декомпозиции задачи переменные, входящие в (свя­зующие переменные), фиксируют, а из функций, входящих в , составляют модифицированную целевую функцию R (х,  ). Задачу о максимуме R решают при фиксированных значениях связующих переменных. При поиске максимума R по тем пере­менным, которые входят в множество , учитывают только ограничения, индексы которых составляют множество . Таким образом учитывают соответствующий заштрихованный диаго­нальный блок.

Преобразование разреженных матриц большой размерности к блочно-диагональной форме (рис. 5.5,г) проводят с исполь­зованием ЦВМ.

Таким образом, общая схема решения оптимизационных задач с использованием декомпозиции состоит из двух этапов:

1) переход к более простой задаче, решение которой зависит от некоторого параметра, и доказательство того, что суще­ствует такое значение параметра, при котором это решение совпадает с решением исходной задачи; 2) расчет нужного значения параметра. Эта схема будет использована далее при характеристике решения некоторых задач оптимального управ­ления.

Недавно мы с клиентом полностью изменили стратегию его бизнеса. Нужно было видеть его реакцию.

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

А причиной всему стало всего одно слово, вернее даже инструмент, декомпозиция. И сейчас Вы узнаете почему.

Майкл Джексон жив

Помните знаменитую походку Майкла Джексона? Да! Ту самую лунную походку, которую повторяют и будут повторять в ближайший век еще точно.

Это когда он идет вроде бы вперед, но обратным способом (вроде так можно это описать).

Вот такая вот, иду вперед, а на самом деле назад

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

Сразу забегу вперёд, чтобы вы не расстраивались. В этой статье мы рассмотрим разные примеры использования данной темы в маркетинге/бизнесе. Особенно обратите внимание на третий пример.

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

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

Вы едете отдыхать

Приведу пример на самом желанном. Вам нужно поехать в отпуск s_____ (вставьте страну, куда бы сейчас хотели поехать).

Для этого вам нужно купить билеты, подготовить чемодан с вещами, деньги, закрыть все дела на работе. Кстати о работе. Там вам нужно сделать… И пошел список дел.

Теперь понимаете о чем я? Вы берете любую задачу и разбиваете ее на подзадачи, а потом на еще более мелкие задачи.

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

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

Декомпозиция цели

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

Причем в корне. Одна из ключевых способностей эффективных людей – что все свои задачи они расписывают максимально подробно, буквально по 10-15 минут. Но это лирика. Переходим к главному вопросу.

Зачем ЭТО в маркетинге?

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

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

1. Вам нужно достичь , но Вы не понимаете, что лучше продавать и через какой канал (чтобы выставить себе );
2. Вы знаете конверсию своих рекламных материалов и вам нужно посчитать рекламы или сколько стоят ;
3. Вы хотите продать 150 единиц продукта, но не понимаете сколько нужно сделать действий для этого;

А также как говорится “Многое другое”. Думаю направления понятны. Теперь рассмотрим три варианта реализации

1 вариант – низкая сложность

Представим, что у вас розничный магазин, которому нужно сделать оборот в месяц в размере 1 950 000 руб.

1. Средний чек в 3 470 рублей;
2. Средняя конверсия в покупку 35%.

Внимание, вопрос знатокам. Какое число клиентов должно посетить магазин за месяц?

Считаем (1 950 000 (оборот) / 3 470 (средний чек)) / 35% (конверсия в покупку) = 1 606.

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

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

НАС УЖЕ БОЛЕЕ 29 000 чел.
ВКЛЮЧАЙТЕСЬ

2 вариант – средняя сложность

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

1. Средний чек – 137 000 рублей;
2. Конверсия 10% – из холодного звонка в продажу (на каждом этапе);
3. Рентабельность 25% (всем бы такую рентабельность в оптовом бизнесе)

Опять вопрос знатокам. Сколько нужно делать холодных звонков, ежемесячно, чтобы зарабатывать 5 млн. рублей чистой прибыли? Вы не поверите, но 150 000 звонков! Тому утверждение ниже скрин.

Расчеты 1

Тут только несколько вариантов: либо поднимать средний чек, либо увеличивать конверсию. Я просто поиграл с цифрами и увеличил конверсию из встречи в продажу в 2 раза, то есть получилось 20 процентов. Чистый доход увеличился даже чуть больше, чем в два раза.

Расчеты 2

А если подтянуть другие цифры? Такие как проход секретаря или назначения встречи. Жаль, что не все так просто в жизни. Но, думаю, эти статьи с примерами скриптов Вам помогут.

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

Наша цель:

Определить стоит ли идти в нишу в данном регионе;

Узнать бюджет и возможную стоимость клика.

Но не стоит полагать, что вы можете узнать точные цифры по результату прогноза.

В данной статье для наглядности я использовал сервис “Декомпозиция 5.рф”. Он является удобным инструментом для понимания того, на что вы можете повлиять (как на уровне вашей рекламной компании, так и на уровне отдела продаж), чтобы успешнее продвигать свое дело или бизнес, на что стоит сделать упор для увеличения вашей чистой прибыли.

Итак, приступим.

Для чего нужно медиапланирование?

Для начала поймем, что такое Медиапланирование.

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

Для составления медиаплана или прогноза бюджета в контекстной рекламе (давайте договоримся что медиаплан и прогноз бюджета это одно и тоже) требуются следующие вводные:

Адрес сайта или описание ниши (если сайта нет).

Конверсия сайта (показатель насколько эффективно ваш сайт перерабатывает переходы в заявки, звонки или другое целевое для вас действие). Если вы не знаете конверсию сайта, то среднее значение для лендинговых (одностраничных) сайтов условно равно 5%, для интернет магазина берем 1-1,5%.

Так зачем же делать медиаплан перед запуском рекламы? Я хочу быстрее настроить да и получать какой то трафик на сайт. Согласен, но если рассматривать работу на потоке, то это нужно как минимум:

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

Прогноз бюджета

Заходим в Яндекс Директ и переходим во вкладку Прогноз бюджета.

Для Прогноза бюджета вам нужно выполнить три шага (выбрать 3 настройки).

Первый шаг – выбор региона показа нашего рекламного объявления

Второй шаг – нам нужно указать параметры расчета.

Время, за которое будет сделан расчет (неделя, месяц, квартал или год);

Площадка (в данном случае на всех или на мобильных);

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

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

Для сбора списка ключевых фраз и минус-фраз используется

Обработка результатов прогноза

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

В нашем случае выбрана позиция спецразмещения с объемом трафика -100%.

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

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

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

Нам нужно определиться, на какой позиции мы будем стараться показывать наше объявление.

Допустим у нас нет 82 296.40 руб., у нас, скажем, есть 66 112.70 руб. в месяц, то выбираем второе спецразмещение с объемом трафика -85%.

Из этого отчета нам понадобиться следующие показатели:

Прогноз показов - 27 792;

Прогноз кликов - 3 748.

Также нам понадобится третий показатель CPC (цена клика). Он рассчитывается следующим образом:

CPC = Прогноз бюджета / Прогноз кликов

CPC = 66 112.70 / 3 748 = 17.64 руб.

Вот мы и получили наши показатели для дальнейшего медиапланирования в “Декомпозиции 5.рф”

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

Выбор раздела "Оплата за клик"

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

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

Пример

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

Наш товар или услугу запрашивают в месяц примерно 28 000 раз (в Яндексе). Этот показатель мы посмотрели из Прогнозатора бюджета от Яндекса, там же мы взяли среднюю цену за клик 17 руб., кликабельность объявления поставили 5%, мы надеемся что рекламная компания будет хорошая.

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

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

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

Посетители попадают на наш сайт или посадочную страницу, например, ее конверсия 2% (заявка на покупку, консультацию, любое целевое действие, которое вы поставите). Выставляем конверсию (в продажу), то есть эффективность работы (ваш собственный или вашего отдела продаж). Пусть они в этом примере закрывают 25% сделок, средний чек выставляем 25 000 рублей и рентабельность (какой процент из этих 25 000 рублей вы вынимаете для себя чистыми, после вычета всех расходов). Например, если чистыми остается 11 200 руб., то рентабельность составит 20%. Видим, что бизнес процесс с такими показателями выдает нам 11 200 рублей ежемесячной прибыли.

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

Найдете более выгодное предложение от поставщиков, тем самым поднимите рентабельность до 35%. Обратите внимание как изменилась чистая прибыль.

Первый и, возможно, самый главный этап работы с Product Backlog в Agile заключается в декомпозиции задач, разбиении разноплановых требований на атомарные, понятные пользовательские истории (User Stories). Чем качественнее разбиты требования, тем понятнее их смысл и способы реализации, а также тем точнее можно запланировать время работы над ними. Чем задачи, тем выше шансы достичь целей спринта, тем более прогнозируемые составы релизов.

Как же провести декомпозицию требований в Product Backlog? Рассмотрим 8 техник, которые помогут эффективно выполнить разбивку требований на User Stories. В работе по Agile большим плюсом будет одновременное применение нескольких вариантов декомпозиции, поэтому важно представлять спектр возможных методов.

Зачем и в какой момент следует проводить декомпозицию требований?

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

• Если в рамках итерации (спринта) мы работаем над несколькими большими и сложными задачами, то, во-первых, такие задачи будет сложно оценить с высокой точностью, во-вторых, недооценка даже одной из них может сильно повлиять на достижение целей спринта. Ведь не выпустить 1 из 2 запланированных фич, это сразу -50% полезного результата.
• Мелкие и атомарные задачи напротив имеют не такое серьезное влияние на цели спринта, так как их больше планируется на спринт (а значит каждая имеет меньший вклад) и их оценка будет гораздо точнее.

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

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

Два основных подхода к декомпозиции.

Существует две концепции, два базовых подхода к декомпозиции крупных задач на пользовательские истории – «горизонтальное» и «вертикальное» разбиение:

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

Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:

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

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

Техники декомпозиции требований в Agile

Метод 1: Разбиение по этапам\фазам бизнес процесса.

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

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

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

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

Метод 2: Разбиение по позитивным и негативным сценариям.

Фактически каждая функциональность имеет правильный\прямой сценарий использования, который приводит к ожидаемому\позитивному результату. Однако, когда пользователь работает с тем или иным функционалом могут произойти отклонения от правильного процесса: переданы не те данные, выполнены не все обязательные условия, нет необходимых прав доступа и т.п. Такие отклонения от прямого сценария работы приведут к негативным результатам (действие не выполнится, функция отработает некорректно и т.п.).

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

• Для позитивного – реализация правильной работы функционала.
• Для негативных – реализовать правильную отработку той или иной возможной ошибки, разработать альтернативный сценарий.

В качестве примера декомпозиции требований на позитивные\негативные сценарии снова рассмотрим функцию покупки в интернет магазине:

• Позитивный сценарий: пользователь заходит в свою учетную запись на сайте и совершает покупку оплачивая ее по карте. Или в формате пользовательской истории: «как клиент я могу войти в свою учетную запись, чтобы совершить покупку по карте».
• Негативный сценарий 1: клиент пробует совершить покупку без авторизации.
• Негативный сценарий 2: пользователь пробует совершить покупку, но у него на счету не хватает средств и оплата не проходит.
• Негативный сценарий n: клиент пробует совершить покупку, но его учетная запись заблокируется из-за неправильного ввода пароля.

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

Метод 3: Разбиение по правилам\условиям бизнес процесса.

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

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

Данный метод разбиения требований позволяет:

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

Метод 4: Разбиение по видам операций.

Существует ряд относительно стандартных операций, которые часто встречаются в различных функциях. Эти операции можно отнести к разряду набора действий «по умолчанию»: создать, читать, обновить или удалить. Сокращенно метод называется CRUD – от слов Create, Read, Update, Delete. Операции CRUD очень распространены в случаях, когда функциональность включает управление объектами, такими как продукты, заказы, пользователи, файлы и т.д.

На примере все того же интернет магазина можно сделать такую декомпозицию функциональности по работе с карточкой продукта:

• C reate - создание нового продукта в интернет магазине
• R ead - просмотр описания продукта
• U pdate - редактирование\обновление описания продукта
• D elete - удаление продукта из магазина

Декомпозируя функциональность таким образом достаточно легко ответить на следующие вопросы:

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

Метод 5: Декомпозиция по типам платформы/ОС.

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

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

• Для разных платформ: персональные компьютеры, планшеты, смартфоны.
• Для разных ОС: Windows, iOS, Android.
• Для работы в различных браузерах.

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

Метод 6: Разбиение по типам данных и параметрам.

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

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

• Поиск с использованием текста (наименование товара)
• Поиск с использованием числовых значений (номер товара)
• Поиск с использованием регулярных выражений

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

Метод 7: Разбиение по ролям\правам доступа.

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

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

• Владелец интернет магазина:
  • Создание\удаление продукта в интернет магазине.
• Администратор интернет магазина:
  • Просмотр и редактирование описания продукта.
  • Отработка запросов\комментариев клиентов.
• Клиент\покупатель:
  • Просмотр описания продукта.
  • Резерв\покупка товаров в интернет магазине.

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

Метод 8: Декомпозиция по сценариям тестирования\тест-кейсам.

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

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

• Товар есть в наличии и он доступен покупки.
• Товар есть в наличии, но он уже зарезервирован другим покупателем
• Товара нет в наличии

Какие преимущества дает использование данного метода декомпозиции:

• Эта стратегия фактически объединяет многие техники декомпозиции, которые были рассмотрены ранее. В процессе формирования списка тест-кейсов мы автоматически проанализируем:
  • Условия и правила бизнес процесса
  • Позитивные и негативные сценарии использования функционала
  • Форматы данных и параметров.
• Анализируя тестовый сценарий легко понять насколько он распространен и вероятен в условия реального использования продукта, что позволяет выставить соответствующие приоритеты.
• При таком способе разбиения мы сразу получаем и описание для задачи\пользовательской истории и сценарий, по которому можно проверить успешность ее реализации.