Декомпозиция в разработке мобильных приложений, полезные техники и примеры из практики
Декомпозиция — это деление целого на части, или научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших задач, пусть и взаимосвязанных, но более простых.
Для чего нужна декомпозиция
Для решения сложных задач. Решение сложной задачи заменяем решением нескольких простых задач. Декомпозиция позволяет привести сложную задачу до понятной структуры, которую можно реализовать.
Декомпозиция в этом случае позволяет справиться и с прокрастинацией, когда мы встречаемся со сложным вопросом и не занимаемся ее решением по совершенно объективным причинам: мы уверены, что все завалим и даже не беремся за рассмотрение.
Для оценки ресурсов. Декомпозиция позволяет оценить ресурсы на задачу: время, деньги и т. д.
- Для оценки реалистичности. Задача может быть со временными ограничениями, финансовыми, прочими блокировками. Декомпозировав задачу, можем выбросить нереальные блокировки.
Для расстановки приоритетов и делегирования. Здесь мы можем обозначить приоритеты и что-то делегировать. Все это поможет выполнить задачу быстрее.
Правила декомпозирования
1. Разбиваем систему по уровням. Исходная система располагается на нулевом уровне. После её разбиения получаются подсистемы первого уровня. Разбиение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и т. д. Для обозримости рекомендуют выделять на каждом уровне не более 7 подсистем. Это связано с особенностями человеческого мозга: именно столько элементов человек может удержать в памяти.
2. Недопустимо, чтобы одной из подсистем являлась сама система, так как получаем закольцовывание логики.
3. При декомпозиции текущего уровня не нужно думать про следующие уровни.
4. Разбиение должно происходить только по одному, постоянному для всех уровней признаку. Это важный момент.
Разбиение может происходить:
-по типам платформ — mobile, ios, back, front, web.
-по этапам/фазам бизнес-процесса.
-по позитивным/негативным сценариям.
-по списку требований. В первом сценарии реализуем одно требование, во втором — второе и т. п. Цель — сделать число целей каждой задачи минимальным (в идеале, по одному).
-горизонтальная/вертикальная декомпозиция. Горизонтальная — задачи декомпозируются по типу работы, которую необходимо выполнить. Здесь нужно задействовать back, web, front и т. д. Фактически каждая из частей не приводит к конечному результату сама по себе. Для готового функционала необходима реализация всей совокупности связанных задач всеми участниками процесса.
Вертикальная - выделение более мелких задач, фич, функций таким образом, что каждая такая пользовательская история может быть реализована и выпущена отдельно от остальных задач. На таком подходе основывается создание «продуктовой команды», когда эксперты разных направлений группируются по типам задач.
До какого уровня декомпозировать?
Обычно в качестве нижнего (элементарного) уровня подсистем берут такой, на котором располагаются подсистемы, понимание устройства которых или их описание доступно исполнителю, руководителю группы или отдельному человеку. Иерархическая структура ориентирована всегда субъективно и зависит от команды: для более квалифицированного специалиста она будет менее подробна. Чем ниже уровень команды, тем более подробной должна быть декомпозиция.
Для понятия глубины нам важно найти баланс: декомпозиция не должна быть слишком подробной, но и не слишком обобщенной.
Полезные техники
1. Vague Terms, или «неточная формулировка». Если задача сформулирована расплывчато, мы можем постепенно уточнять формулировку. Появляющиеся уточнения и будут элементами декомпозиции. Как это можно использовать на практике, подробно обсуждается здесь.
2. Conjunctions, или «союз». В User-story мы выражаем мысли с помощью союзов “и, при условии, или, когда” и т. д. Если поделим user-story по этим союзам, то получим декомпозированную задачу. В этом отрывке данная техника рассматривается на реальном примере.
Что еще важно учесть
1. Текущие внешние связи. Понять, какие внешние связи уже есть с системой. Система состоит из частей, которые между собой взаимодействуют, а также обменивается с другими системами (в том числе с пользователем, с ОС, если это приложение, внешние интеграции и т. д.). Любая связь нашего модуля и внешнего (нашей задачи) — это потенциально отдельная задача. Именно на связях находятся основные риски.
2. Будущие внешние связи. Это те связи, которые появятся с другими системами.
3. Пользовательские истории. Понять, какие пользовательские истории затрагиваются нашими изменениями, а какие добавляются. Каждая пользовательская история — это потенциально отдельная подзадача.
4. Положительные и негативные сценарии. Пользовательские истории делим на положительные/отрицательные сценарии.
5. Нефункциональные требования. Это требования, которые не относятся непосредственно к функциональности приложения, но предъявляются к нему (требования к версии ОС, типам устройств для мобильных приложений, версиям браузеров, железа, внутренние требования к процессам (долгое ревью, тщательное тестирование, соблюдение архитектуры, работа с техдолгом и т. д.). Не технические требования: требования законодательства, специфические требования заказчика (например, тестовый сервер через VPN), аудит и т. д.
Надо всегда помнить, что состав задачи — это не только кодинг, но и риски, кодревью, затраты на прием, тестирование и управление.
Что делать, если для декомпозиции не хватает знаний, если много зависимостей, блокировок? Отдельные решения этих вопросов можно найти по ссылке.