что такое декомпозиция системы

Что такое декомпозиция системы

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

Еще в XVII веке Р.Декарт писал: «Расчлените каждую изучаемую вами задачу на столько частей (. ), сколько потребуется, чтобы их было легко решить». Успех и значение аналитического метода состоит не только и не столько в том, что сложное целое расчленяется в конечном счете на простые части, а в том, что будучи соединены надлежащим образом, эти части снова образуют единое целое. Этот момент агрегирования частей в целое является конечным этапом анализа, поскольку лишь только после этого мы сможем объяснить целое через его части — в виде структуры целого.

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

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

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

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

Модели систем как основание декомпозиции

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

Содержательная модель как основание декомпозиции

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

Пример 1.

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

Рис.15.1 — Первый уровень дерева целей из примера 1

Декомпозиция проведена по модели входов организационной системы

Рис.15.2 — Схема входов организационной системы

Модель организационной системы включает входы:

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

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

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

Выше уже упоминалось, что основанием декомпозиции служит модель «рассматриваемой системы», но какую именно систему следует под этим понимать? Всякий анализ проводится для чего-то, и именно эта цель анализа и определяет, какую систему следует рассматривать. Система, с которой связан объект анализа, и система, по моделям которой проводится декомпозиция, не обязательно совпадают. Отношение между ними может быть любым: одна из них может быть подсистемой или надсистемой для другой, они могут быть и разными, но как-то связанными системами. Например, анализируя цель «выяснить этиологию и патогенез ишемической болезни сердца», в качестве исследуемой системы можно взять сердечно-сосудистую систему, а можно выбрать конкретный кардиологический институт. В первом случае декомпозиция будет порождать перечень подчиненных подцелей научного, а во втором — организационного характера.

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

Связь между формальной и содержательной моделями

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

Пример 2.

Схема входов организационной системы на рис.2. является полной: к ней нечего добавить (перечислено все, что воздействует на систему), а изъятие любого элемента лишит ее полноты.

Пример 3.

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

Пример 4.

К числу полных формальных моделей относится марксова схема любой деятельности человека, которая в «Капитале» применялась для анализа процесса труда (см.рис.3). В схеме выделены: субъект деятельности; объект, на который направлена деятельность; средства, используемые в процессе деятельности; окружающая среда; все возможные связи между ними.

Рис.15.3 — Общая схема деятельности

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

Проблема полноты моделей

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

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

Алгоритмизация процесса декомпозиции

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

Компромиссы между полнотой и простотой

Начнем с обсуждения требований к древовидной структуре, которая получится как итог работы по всему алгоритму. С количественной стороны эти требования сводятся к двум противоречивым принципам:

полноты (проблема должна быть рассмотрена максимально всесторонне и подробно);

простоты (все дерево должно быть максимально компактным — «вширь» и «вглубь»).

Эти принципы относятся к количественным характеристикам (размерам) дерева. Компромиссы между ними вытекают из качественного требования — главной цели: свести сложный объект анализа к конечной совокупности простых подобъектов либо (если это не удается) выяснить конкретную причину неустранимой сложности.

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

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

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

Типы сложности

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

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

Алгоритм декомпозиции

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

Блок 1. Объектом анализа может быть что угодно — любое высказывание, раскрытие смысла которого требует его структурирования. На определение объекта анализа затрачиваются весьма значительные усилия. Формулировка глобальной цели системы, как правило, требует неоднократного уточнения и согласования. От правильного выбора объекта анализа зависит, действительно ли мы будем делать то, что нужно.

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

Блок 3. Этот блок содержит набор фреймовых моделей и рекомендуемые правила их перебора либо обращение к эксперту с просьбой самому определить очередной фрейм.

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

Блоки 5-10 были достаточно пояснены ранее.

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

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

Подведем итог

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

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

Рис.15.4 — Укрупненная схема алгоритма декомпозиции

Источник

Как справиться с декомпозицией задач и не перестараться

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

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

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

Зачем нужна декомпозиция

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

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

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

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

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

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

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

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

Основные подходы и правила декомпозиции

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

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

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

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

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

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

Способы декомпозиции

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

Несколько потребностей

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

Сценарии использования

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

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

От простого к сложному

Главная страница сайта «Спортмастер» состоит из баннеров. И самое простое, что мы можем сделать — взять одну картинку и показать ее пользователю. Это самый простой и быстрый способ донести нужную информацию. Дальше мы можем наращивать функционал и добавлять не одну картинку, а три-четыре, которые объединяются в сетку. Это уже отдельная задача.

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

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

Операции (CRUD)

Это, наверное, самый распространенный способ декомпозиции. Здесь задачи деляться по операциям Create, Read, Update и Delete. Он подходит для задач, где нужно чем-то управлять или что-то конфигурировать. Например, задача по оформлению заказа делится на четыре более мелкие: создание заказа, его просмотр, редактирование и удаление.

Варианты интерфейса

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

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

Разделение по ролям

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

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

Обработка ошибок

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

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

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

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

Статические, затем динамические

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

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

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

Производительность

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

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

Возможные трудности

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

Еще одна трудность — определить, насколько мелко надо декомпозировать задачу. И здесь границами выступает только здравый смысл. Например, мы берем компонент выбора города. В нем есть кнопки, какой-нибудь текст, поле ввода. Насколько мелко нужно бить эту задачу?

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

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

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

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

Источник