Декомпозиция задач: что это и зачем нужно
Приходит маркетолог интернет-магазина к разработчику с задачей:
- добавить на страницу товара счётчик, сколько раз его купили.
Для маркетолога это одна строчка текста. Он думает, что такую простую задачку можно сделать за 15 минут. А разработчик пожимает плечами: «Подумаю, потом назову срок». Что за дичь? А вот так.
Прежде чем эту задачу делать, её было бы неплохо декомпозировать — то есть понять, из чего она состоит, на что влияет и в каком порядке её стоит делать. В случае со счётчиком покупок это получится такой набор подзадач:
- Добавить в базу товаров столбец с количеством покупок.
- Написать новый или доработать старый метод для АПИ, чтобы сайт получал значение из этого столбца.
- Добавить строку текста на страницу товара.
- Протестировать метод и вёрстку.
- Подумать, что делать с редкими случаями, например, товар купили, а потом вернули; или если товар суперпопулярный и его купили 9999999999999999 раз.
В зависимости от архитектуры системы могут быть и другие действия. Поэтому назвать срок сразу разработчик не может: сначала надо понять, что вообще нужно делать и сколько времени займёт каждый пункт.
Чем крупнее задача, тем сложнее обойтись без декомпозиции. «Покрасить кнопку в красный» можно не раскладывать. А «Добавить новый раздел в админку» точно стоит сначала разобрать по частям: тут работа и для фронтенда, и для бэкенда. Декомпозиция нужна не всегда, но очень часто.
Была одна большая задача, стало несколько маленьких.Зачем декомпозировать
Понять, что и в каком порядке делать. «Добавить счётчик на страницу» кажется задачей для фронтенд-разработчика. Но на самом деле он сможет сделать свою часть, только когда будет готова база данных и АПИ — механизм, по которому эти данные подтягиваются на сайт.
Если фронтенд попробует сам предположить, как будет выглядеть запрос, то после интеграции могут всплыть непредвиденные баги: бэкенд мог реализовать АПИ не так, как думал фронтенд-разработчик. Декомпозиция поможет понять, с какой стороны подступиться и в какой последовательности двигаться.
Оценить сроки. Когда задача разложена на части, можно оценить по времени каждую и понять, сколько потребуется на всё вместе. Понятно, что не получится запустить счётчик за день, если только на базу данных и АПИ нужно два.
Упростить тестирование. Тестировать проще, когда понятно, что нужно проверить. В случае со счётчиком: базу данных, метод и вёрстку.
Расставить приоритеты. Декомпозиция может показать, что задача большая и требует времени. Например, если маркетолог хочет указать не только количество покупок, но и количество городов, в которые товар доставляли. Разработчик может показать, что делать всё вместе — две недели, но счётчик покупок можно выкатить быстрее. А маркетолог уже решит, как лучше поступить.
Как декомпозировать
Декомпозировать можно по-разному, это зависит от масштаба и сути задачи.
Например, запуск мобильного приложения можно декомпозировать сначала на уровне платформ: iOS и Android. Потом — на уровне пользовательских сценариев: регистрация, просмотр контента, покупка, переписка с контактами. Сценарии можно разложить на интерфейс и серверную часть. А их — на отдельные конкретные задачи.
Чаще всего задачи раскладывают вертикально и горизонтально. Вертикально — значит по типам работ. Горизонтально — значит вглубь одного типа работы. Вот как это работает со счётчиком покупок в интернет-магазине:
Вертикальная декомпозиция:
Бэкенд: считать количество покупок и отдавать данные на фронт.
Фронтенд: запрашивать данные при загрузке страницы и выводить.
Горизонтальная декомпозиция:
Бэкенд:
- добавить столбец с количеством покупок в БД;
- считать в этом столбце, сколько раз товар купили;
- добавить метод, который будет возвращать количество покупок по id товара.
Фронтенд:
- добавить на страницу товара строку с количеством покупок;
- обращаться с помощью метода к БД во время загрузки страницы;
- настроить отображение счётчика на экранах разных размеров.
Кто должен декомпозировать
Декомпозировать задачу может сам разработчик, тимлид, менеджер проекта или другой компетентный сотрудник: универсальных правил здесь нет. Руководитель службы разработки Яндекс.Практикума Александр Трегер рассказывает, как это работает у них:
Когда появляется новая большая задача, один из опытных разработчиков берёт её на себя. С этого момента он за неё отвечает: собирает встречи, даёт заказчикам обратную связь, определяет, как решить задачу, декомпозирует её. Для разработчиков это возможность расширить свою зону ответственности, попробовать себя в роли архитектора и менеджера проекта.
Иногда нужно выделить время и разобраться в задаче, подумать про пограничные случаи, изучить технологию, придумать решение. Бывает, что на этом этапе задача может разделиться на несколько этапов: что делаем сейчас, а что потом. Так было, например, с проверкой домашних работ от студентов: сначала они приходили в виде архива на проверку, потом появился полноценный интерфейс для ревью кода. Система будет развиваться и дальше, но декомпозиция помогает понять, что и в какой последовательности можно сделать, чтобы быстрее получить результат.
👉 Почитайте полное интервью с Александром Трегером. Там больше подробностей о разработке Практикума.
Agile in IT: 8 методов декомпозиции задач
Первый и, возможно, самый главный этап работы с Product Backlog в Agile заключается в декомпозиции задач, разбиении разноплановых требований на атомарные, понятные пользовательские истории (User Stories). Чем качественнее разбиты требования, тем понятнее их смысл и способы реализации, а также тем точнее можно запланировать время работы над ними. Чем задачи, тем выше шансы достичь целей спринта, тем более прогнозируемые составы релизов.
Как же провести декомпозицию требований в Product Backlog? Рассмотрим 8 техник, которые помогут эффективно выполнить разбивку требований на User Stories. В работе по Agile большим плюсом будет одновременное применение нескольких вариантов декомпозиции, поэтому важно представлять спектр возможных методов.
Остановимся на этих моментах немного подробнее. Разработка ПО довольно непредсказуемый процесс и содержит много задач и зависимостей, которые трудно точно оценить заранее. Вполне естественно, что в процессе реализации какие-то требования потребуют больше времени, чем прогнозировалось изначально. Влияние на релиз больших и мелких задач в этом случае будет различным:
- Если в рамках итерации (спринта) мы работаем над несколькими большими и сложными задачами, то, во-первых, такие задачи будет сложно оценить с высокой точностью, во-вторых, недооценка даже одной из них может сильно повлиять на достижение целей спринта. Ведь не выпустить 1 из 2 запланированных фич, это сразу -50% полезного результата.
- Мелкие и атомарные задачи напротив имеют не такое серьезное влияние на цели спринта, так как их больше планируется на спринт (а значит каждая имеет меньший вклад) и их оценка будет гораздо точнее.
Декомпозицию задач можно проводить как в начале очередного спринта при его планировании, так и во время спринта, выполняя разбивку требований для последующих итераций. Второй вариант предпочтительнее. Лучше не привязывать декомпозицию задач к конкретному спринту, чтобы приходить к его планированию с уже готовым, разбитым на пользовательские истории бэклогом. В этом случае, если имеется запас декомпозированных требований, то:
- Во-первых, мы не ограничиваем выбор задач для спринта (можем работать только над тем, что декомпозировали).
- Во-вторых, при планировании уже не нужно тратить время на разбивку и команда может сосредоточиться на формировании спринта исходя из приоритетов, обсудить зависимости и нюансы реализации требований.
Существует две концепции, два базовых подхода к декомпозиции крупных задач на пользовательские истории – «горизонтальное» и «вертикальное» разбиение:
- В случае «горизонтальной» декомпозиции, задачи разбиваются по типу работы (функции), которую необходимо выполнить, по компонентам, которые задействованы в работе. В этом случае при разбиении общей большой задачи разработчику будет выделена одна часть, тестировщику другая, техническому писателю третья и так далее. Фактически каждая из частей не приводит к конечному результату сама по себе, чтобы выпустить готовый функционал, необходима реализация всей совокупности связанных задач всеми участниками процесса.
- «Вертикальный» метод декомпозиции напротив предполагает выделение более мелких задач, фич, функций таким, образом, что каждая такая пользовательская история может быть реализована и выпущена отдельно от остальных задач. При этом в разработку могут быть вовлечены различные роли, могут быть задействованы несколько модулей и систем.
Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:
- При «вертикальном» разбиении каждая задача может быть реализована, протестирована и продемонстрирована заказчику\пользователям, являясь для них понятной и измеримой в отличии от «технических» задач при «горизонтальной» декомпозиции.
- При «вертикальной» декомпозиции каждая конечная пользовательская история несет в себе ценность для бизнеса, а значит такие задачи проще сравнивать и приоритезировать.
- Поскольку в реализации задач, которые разбиты по «вертикальному» принципу участвуют специалисты различных ролей, то им проще выявить возможные сложности, зависимости и риски, которые могут возникнуть в процессе работы.
Теперь, когда с необходимостью и принципами декомпозиции все ясно, рассмотрим различные методы разбиения больших задач бэклога на атомарные пользовательские истории. Во всех этих вариантах и техниках применяется принцип «вертикальный» декомпозиции.
Метод 1: Разбиение по этапам\фазам бизнес процесса.
Используя этот метод можно попробовать разбить большую задачу, описывающую некий бизнес процесс на составные части и этапы. Для этого в данном процессе необходимо выделить последовательную цепочку шагов , которые могут быть реализованы и выполнены независимо друг от друга. В качестве пояснения этого метода декомпозиции можно привести следующий пример:
- В бэклоге у нас есть большое требование — реализовать для клиента функцию покупки в интернет магазине.
- В рамках процесса покупки можно выделить, например, следующие этапы:
- вход в личный кабинет
- просмотр товаров в «корзине»
- формирование счета на оплату
- отправка счета по почте
- выполнение оплаты различными способами: банковский перевод, карта и т.п., подтверждение оплаты.
- Каждый такой этап можно выделить и описать в виде отдельной пользовательской историей.
В результате мы разбиваем большой бизнес процесс на составляющие его этапы. Какие-то этапы при этом могут быть критичными и обязательными, а какие-то опциональными. Такая декомпозиция дает возможность:
- Во-первых, определить различные приоритеты для каждой истории и сосредоточиться в первую очередь на самых важных для бизнеса этапах.
- Во-вторых, при таком разбиении лучше понятен сам процесс, его шаги и составные части, возможные зависимости меду этапами.
Метод 2: Разбиение по позитивным и негативным сценариям.
Фактически каждая функциональность имеет правильный\прямой сценарий использования, который приводит к ожидаемому\позитивному результату. Однако, когда пользователь работает с тем или иным функционалом могут произойти отклонения от правильного процесса: переданы не те данные, выполнены не все обязательные условия, нет необходимых прав доступа и т.п. Такие отклонения от прямого сценария работы приведут к негативным результатам (действие не выполнится, функция отработает некорректно и т.п.).
Соответственно мы можем выполнить декомпозицию на ожидаемый сценарий использования функционала и на неправильные, но возможные и вероятные сценарии работы. Для каждого сценария важно выделить отдельные пользовательские истории:
- Для позитивного – реализация правильной работы функционала.
- Для негативных – реализовать правильную отработку той или иной возможной ошибки, разработать альтернативный сценарий.
В качестве примера декомпозиции требований на позитивные\негативные сценарии снова рассмотрим функцию покупки в интернет магазине:
- Позитивный сценарий: пользователь заходит в свою учетную запись на сайте и совершает покупку оплачивая ее по карте. Или в формате пользовательской истории: «как клиент я могу войти в свою учетную запись, чтобы совершить покупку по карте».
- Негативный сценарий 1: клиент пробует совершить покупку без авторизации.
- Негативный сценарий 2: пользователь пробует совершить покупку, но у него на счету не хватает средств и оплата не проходит.
- Негативный сценарий n: клиент пробует совершить покупку, но его учетная запись заблокируется из-за неправильного ввода пароля.
Подобный тип декомпозиции позволяет выделить, проанализировать и запланировать отработку различных исключений и неверных сценариев использования ПО, которые в любом случае будут возникать.
Метод 3: Разбиение по правилам\условиям бизнес процесса.
В отличии от предыдущего метода в данном случае мы разбиваем процесс не на этапы а на логические ветки, возможные варианты отработки функционала. Фактически мы определяем набор сценариев, по которым может выполняться процесс при выполнении тех или иных правил\условий.
- В качестве иллюстрации данного метода декомпозиции возьмем тот же пример: необходимо реализовать для клиента функцию покупки в интернет магазине.
- В данном случае мы можем выделить, например, следующий набор правил для совершения покупки:
- Определена минимальная сумма, если сумма покупки меньше, то клиенту показывается соответствующая подсказка.
- Если сумма покупки превышает определенное значение, то клиенту предлагаются дополнительные варианты оплаты.
- Если выставленный счет не оплачен в течение 2 дней, то заказ автоматически отменяется.
- Реализацию каждого такого условия, можно вынести в отдельную задачу
Данный метод разбиения требований позволяет:
- Выявить и вынести в отдельную пользовательскую историю различные правила и ограничения, которые могут встречаться в рамках процесса\функционала. Так меньше риск забыть или пропустить какие-то важные условия.
- Как правило реализация в бизнес процессе тех или иных условий будет иметь разный приоритет: что-то требуется реализовать в первой версии продукта, а без чего-то определенное время можно обойтись. Декомпозиция единого процесса по условиям\правилам позволит построить очередность реализации отдельных пользовательских историй.
Метод 4: Разбиение по видам операций.
Существует ряд относительно стандартных операций, которые часто встречаются в различных функциях. Эти операции можно отнести к разряду набора действий «по умолчанию»: создать, читать, обновить или удалить. Сокращенно метод называется CRUD – от слов Create, Read, Update, Delete. Операции CRUD очень распространены в случаях, когда функциональность включает управление объектами, такими как продукты, заказы, пользователи, файлы и т.д.
На примере все того же интернет магазина можно сделать такую декомпозицию функциональности по работе с карточкой продукта:
- Create — создание нового продукта в интернет магазине
- Read — просмотр описания продукта
- Update — редактирование\обновление описания продукта
- Delete — удаление продукта из магазина
Декомпозируя функциональность таким образом достаточно легко ответить на следующие вопросы:
- Какие из операций являются действительно необходимыми для работы с тем или иным объектом? Как правило операции связанные и не имеет смысла реализовывать, например, создание объекта без возможности его просматривать. Однако, выделение операций позволит расставить для них приоритеты.
- Каким образом необходимо реализовать каждую из операций? Возможно одна и та же операция должна быть реализована несколькими способами. В этом случае декомпозицию можно продолжить и вынести реализацию каждого из способов в отдельную пользовательскую историю. Например, нам необходимо реализовать создание нового объекта через интерфейс web-приложения, через панель администратора на сайте магазина, путем добавления информации в базу данных и т.д.
Метод 5: Декомпозиция по типам платформы/ОС.
Тут все довольно просто – критерием разбиения требований на составные части является необходимость реализации одного и того же функционала для разных платформ, устройств, операционных систем.
Например, нам необходимо разработать в веб-приложении функцию оплаты пользователем какой-то покупки. В этом случае можно декомпозировать требование на задачи по реализации функции покупки:
- Для разных платформ: персональные компьютеры, планшеты, смартфоны.
- Для разных ОС: Windows, iOS, Android.
- Для работы в различных браузерах.
Разбивая требование таким образом, может довольно легко выделить наиболее приоритетные направления для развития продукта и сфокусироваться на них в первую очередь. Например вначале вы можем сосредоточиться на разработке мобильной версии приложения, а версию для десктоп оставить для более поздних релизов.
Метод 6: Разбиение по типам данных и параметрам.
Для некоторых функций можно можно выделить различные типы данных или параметров, которые они должны обрабатывать. Соответственно, мы можем разбить большое требование\фичу на ряд мелких пользовательских историй, в рамках каждой из которых нужно реализовать работу только с каким-то одним типом данных.
В качестве примера можно рассмотреть функцию поиска для интернет-магазина. В данном случае декомпозиция на подзадачи может быть выполнена на основе разных запросов с строке поиска, например:
- Поиск с использованием текста (наименование товара)
- Поиск с использованием числовых значений (номер товара)
- Поиск с использованием регулярных выражений
При использовании данного метода декомпозиции мы можем четко определить допустимые и недопустимые параметры для реализуемой функции (например, функции поиска). В этом случае поддержку части типов данных\параметров можно предусмотреть сразу, а другие могут быть реализованы упрощенным способом или запрещены к использованию.
Метод 7: Разбиение по ролям\правам доступа.
Многие бизнес процессы и функциональности часто подразумевают участие\работу с ними нескольких ролей и групп пользователей. Каждая группа пользователей с определенной ролью и правами доступа, может выполнять только определенную часть функций из общего процесса.
При разбиении функционала по работе с товарами в интернет магазине на основе ролей использования можно выделить, например, такие задачи:
- Владелец интернет магазина:
- Создание\удаление продукта в интернет магазине.
- Просмотр и редактирование описания продукта.
- Администратор интернет магазина:
- Просмотр и редактирование описания продукта.
- Отработка запросов\комментариев клиентов.
- Клиент\покупатель:
- Просмотр описания продукта.
- Резерв\покупка товаров в интернет магазине.
Разбивая общую функциональность на роли, которые должны выполнять ее части, мы более четко понимаем, какие именно функции необходимы и кто имеет права для их исполнения. В этом случае на первых этапах можно приоритезировать и реализовать только базовые наборы функций для каждой из ролей, а в последствии расширять их возможности.
Метод 8: Декомпозиция по сценариям тестирования\тест-кейсам.
Данная стратегия декомпозиции позволяет разбить большие пользовательские истории задавая вопрос, как та или иная часть функциональности будет проверена. Мы определяем какие сценарии необходимо проверить, какие тесты выполнить, чтобы узнать, работает ли эта функция. В результате мы сформируем набор тест-кейсов, каждый из которых и будет представлять собой отдельную задачу. Каждая задача должна быть реализована так, чтобы тестовый сценарий был успешно пройден.
Рассмотрим пример функциональности – клиент выбирает товар в интернет магазине и откладывает его в «корзину» для совершения покупки. В рамках этой функциональности могут быть выделены следующие тестовые сценарии (ниже только пример части возможных тест-кейсов):
- Товар есть в наличии и он доступен покупки.
- Товар есть в наличии, но он уже зарезервирован другим покупателем
- Товара нет в наличии
Какие преимущества дает использование данного метода декомпозиции:
- Эта стратегия фактически объединяет многие техники декомпозиции, которые были рассмотрены ранее. В процессе формирования списка тест-кейсов мы автоматически проанализируем:
- Условия и правила бизнес процесса
- Позитивные и негативные сценарии использования функционала
- Форматы данных и параметров.
- Анализируя тестовый сценарий легко понять насколько он распространен и вероятен в условия реального использования продукта, что позволяет выставить соответствующие приоритеты.
- При таком способе разбиения мы сразу получаем и описание для задачи\пользовательской истории и сценарий, по которому можно проверить успешность ее реализации.
Смотрите также:
Agile: 7 техник оценки задач
Agile: методы приоритезации задач
Как справиться с декомпозицией задач и не перестараться
Всем привет!
Меня зовут Виктор, я системный аналитик в компании «Спортмастер». И сегодня я хотел бы поговорить о декомпозиции задач и передачи их в разработку. Любой объект состоит из частей, будь это автомобиль или программный продукт. И чтобы собрать любой из этих объектов в единое целое из составных частей, потребуется время. Иногда — даже очень много времени. Особенно, если перед этим вы не просто разобрали основную часть, а решили докопаться до сути на атомарном уровне.
Где же та грань между адекватной постановкой задач и тотального хаоса? Поделюсь примером того, как к нам в «Спортмастере» периодически поступают задачи в разработку от бизнеса.
Как видно из приведенных примеров, описание каждой задачи зависит по большей части от фантазии и здравого смысла заказчика. Где-то оно больше, где-то оно меньше, но аналитикам надо как-то с этим работать. Иногда указывают еще и границы функционала, а иногда присылают просто тему. Если передать такую задачу сразу в разработку, на выходе получим что-то непонятное. Что приходится делать?
Идти к заказчику ногами и выспрашивать все требования, уточнять, что именно должно быть на выходе. Правда, бывают еще золотые заказчики, которых, на самом деле, большинство — они пишут все требования у себя в Confluence, поэтому можно в любой момент пойти и спокойно почитать, задать вопросы. И когда уже все понятно с рамками фичи, можно приступать к нарезке задачи.
Зачем нужна декомпозиция
Основная цель декомпозиции заключается в том, чтобы бизнес мог быстро реализовывать все свои хотелки, и чтобы от самой идеи до появления функционала у пользователя проходило как можно меньше времени. Для этого можно делать более мелкие задачки, от которых пусть небольшой, но все-таки рабочий функционал будет доходить до пользователя.
Помимо достижения глобальной цели удовлетворения потребностей пользователя и бизнеса, декомпозиция задач позволяет получать более быстрый фидбэк от заказчика, в правильном ли направлении копает разработка, или же получилось совсем не то, что заказчик себе представлял.
Если задача изначально большая и мы взялись за нее сразу целиком, то мы потратим на нее очень много времени и после комментариев заказчика нам придется все выбросить. Ну а если задача маленькая, день-два работы от силы, — ничего страшного. Переделка займет еще примерно столько же. Второй подход, к тому же, обойдется еще и дешевле. Не говоря уже о сэкономленных нервах с обеих сторон.
Если один функционал разбить на несколько кусочков, разработчики могут работать над ними параллельно. Таким образом мы распараллелим поток и ускорим вывод функционала в прод. Важная штука — при этом задачи должны как можно меньше зависеть друг от друга.
Плюс быстрое тестирование и исправление багов. Опять же, мелкий функционал гораздо проще и быстрее тестировать, чем монструозную махину. И если что-то пойдет не так, на «пофиксить» разработчик потратит совсем немного, и все быстрее заработает.
На этапе разбивки задач вместе с заказчиком можно сразу понять, какой функционал важен прямо здесь и сейчас, чтобы уже начать получать прибыль, что можно оставить на потом, а что, возможно, само отвалится за ненадобностью.
Бизнесу же важно знать, как быстро появится рабочий функционал. И при разбивке на задачи мы можем спрогнозировать и более точно оценить время, которое потребуется на их реализацию, чем когда у тебя один большой фронт работ. Но помимо того, что мелкие задачи легче оценить в плане времени на их проработку, разработчику также проще оценить риски, которые могут возникнуть в процессе работы.
Например, обновились фреймворки, какие-то методы вывели из эксплуатации, проблемы с кодом и прочее. Беря в работу небольшие задачи, мы минимизируем все эти риски, и даже если такая задача что-то заблокирует в потоке, это будет не так критично, как если бы это был здоровенный кусок (который бы заблокировал вообще всё). В случае необходимости можно будет сделать рабочее решение и в бэклог положить техдолг, с которым можно будет разобраться чуть позже, когда проблемы будут решены.
Основные подходы и правила декомпозиции
Существуют два основных подхода к декомпозиции задач — горизонтальный и вертикальный. При горизонтальном задачи делятся по типам работ, по уровням или по компонентам. Например, у нас каждая задача проходит через несколько стадий: фронтенд, бэкенд, базы данных. И при горизонтальном подходе одна задача идет в бэк, вторая во фронт, а третья приводит к изменениям в базе данных.
Чем плох данный подход? Мы не получаем рабочий функционал после выполнения каждой отдельной задачи. Только собрав результаты из трех источников, мы можем получить какой-то результат и фидбэк на него. По этой причине горизонтальную декомпозицию чаще всего не используют.
Гораздо удобнее вертикальный подход, при котором в каждой задаче можно сделать наглядный функционал — задача проходит по всем стадиям и на выходе есть результат, который можно проанализировать, протестировать, показать заказчику и поправить, если надо. И быстренько запустить в работу и использовать.
Если говорить про правила, здесь я выделил всего три. Во-первых, задача должна быть логически завершенной, то есть независимой сама по себе. Она не должна ломать логику вокруг себя и обязательно должна нести в себе хоть какой-нибудь бизнес-смысл, который в результате получит пользователь. При этом не стоит разбивать на части те задачи, которые не несут бизнес-смысла (в идеале их вообще не должно быть).
Во-вторых, результат выполнения одной небольшой задачи должен нести небольшие изменения. Чем меньше изменения, тем быстрее они попадают в общий код, и таким образом код не устаревает. Кроме того, маленькие задачи помогают избежать конфликта между разработчиками при мердже.
В-третьих, не стоит разбивать задачу на совсем уж микроскопические части. Если разбить слишком мелко, очень много времени уйдет на управление этими задачами. На каждом этапе их, возможно, придется переприоритезировать, заново проставлять связи зависимости и вот это всё. Таким образом, скорость разработки не увеличится, а наоборот, резко упадет. Поэтому нужно искать золотую середину.
Способы декомпозиции
В зависимости от источника, количество способов декомпозиции очень сильно варьируется: где-то их указывают всего восемь, где-то десять, где-то двадцать. Я бы хотел остановиться на тех способах, которыми мне приходится пользоваться каждый день на работе.
Несколько потребностей
Этот способ удобнее всего использовать, когда в истории присутствуют союзы «и», «или». Например, потребитель хочет сделать заказ и оплатить его картой или бонусами. Эту задачу можно разделить на три: первая, в которой пользователь делает заказ, вторая, где он оплачивает его картой, и третья, где в ход идут бонусы.
Сценарии использования
Еще один часто встречающийся способ — делить задачи в зависимости от сценария использования. В этом случае одна история представляет из себя один основной путь и несколько альтернативных. Допустим, пользователь хочет купить товар, и это будет основной сценарий. Но есть еще альтернативные пути — он может сразу положить товар в корзину и оплатить, а может захотеть перед покупкой сравнить этот товар с другими. И тогда отдельной задачей мы делаем сравнение товаров.
Возможно, он не хочет покупать прямо сейчас, а отложить куда-нибудь, добавить в избранное, чтобы позже к нему вернуться. Или пользователю понравился товар и уже готов его купить, но его нет в наличии. Значит, надо дать ему знать о том, когда товар появится. И вот таким образом получается четыре сценария.
От простого к сложному
Главная страница сайта «Спортмастер» состоит из баннеров. И самое простое, что мы можем сделать — взять одну картинку и показать ее пользователю. Это самый простой и быстрый способ донести нужную информацию. Дальше мы можем наращивать функционал и добавлять не одну картинку, а три-четыре, которые объединяются в сетку. Это уже отдельная задача.
При таком подходе с каждой последующей задачей функционал должен расти. Мы можем, например, сделать из сетки карусель, а потом добавить какие-нибудь ссылки, тексты, кнопки и остальное. В общем, сначала реализуем самый простой и быстрый в исполнении вариант, а затем движемся к более сложному.
Как раз недавно я занимался похожей задачей по реализации баннера. Баннер должен был висеть на главной управляться из CMS. Если спросить у заказчика, а чем бы именно он хотел управлять, он, не моргнув, радостно ответит — всем. Поэтому здесь было важно немного погрузиться в тему и выделить то, чем нужно управлять прямо сейчас, чем просто часто, а чем почти совсем не пользуются. И таким образом расставить приоритеты по реализации и поделить на задачи.
Операции (CRUD)
Это, наверное, самый распространенный способ декомпозиции. Здесь задачи деляться по операциям Create, Read, Update и Delete. Он подходит для задач, где нужно чем-то управлять или что-то конфигурировать. Например, задача по оформлению заказа делится на четыре более мелкие: создание заказа, его просмотр, редактирование и удаление.
Варианты интерфейса
Используется, когда надо поддержать несколько вариантов интерфейса. Например, сайт должен поддерживать несколько языков. Сначала мы делаем русскоязычную версию. Затем, при запусках в других странах, добавляем английский. Если же в стране используется язык, отличный от английского, то можем добавить и его. В этом случае проще все сделать сначала на одном языке, а потом постепенно добавлять переводы.
Совсем недавно мы завершили проект личного кабинета для юридических лиц, в котором нужна была поддержка мультиязычности. Сроки были сжатые, поэтому изначально сделали все на одном языке, но заложили основу для дальнейшего перевода. Теперь, чтобы добавить поддержку нового языка, нужна всего лишь одна небольшая задача. Если нужно добавить сразу несколько языков, на каждый из них заводится отдельная задача.
Разделение по ролям
Подходит для ситуаций, в которых функциональность подразумевает работу нескольких ролей и групп пользователей. На сайте «Спортмастера» у пользователя могут быть разные роли. Например, пользователи делятся по ролям на авторизованного пользователя, анонимного пользователя, и, допустим, пользователь колл-центра. Последняя роль также может делиться на две — это может быть как рядовой пользователь, так и администратор.
Для каждой роли мы можем сделать отдельную задачу. Начать с отображения для анонимного пользователя, а затем добавить какой-нибудь расширенный функционал в рамках задачи для авторизованного. И не забыть про технические роли операторов колл-центра и функционал для них.
Обработка ошибок
Если сроки сжатые, а минимальный функционал нужен как можно быстрее, можно вынести обработку ошибок в отдельную задачу. Здесь речь идет не о написании тестов, а об обработке ошибок пользователей и систем, с которыми интегрирован сайт. Представим, что мы обрабатываем страницу с каталогом, которая содержит плитку с товарами. В каждой карточке есть описание, фото и дополнительная информация.
Случилось так, что какая-то часть информации не приходит из баз данных.
Возможно, если речь идёт о бренде или материале, то этим можно пренебречь и просто не показать информацию. Но если не дойдет цена или название, стоит ли показывать эту карточку?
Что в такой ситуации делать? Этот вопрос можно вынести в отдельную задачку и затем обрабатывать каждое отдельное поле. То есть, если не пришла цена, то выполняем одно действие, потерялось описание товара — другое. То же самое с ошибками пользователя. Если он ввел что-то некорректно и отобразилась ошибка, например, «Страница не найдена» или ошибка 500, мы должны показать ему конкретную информацию о том, что случилось, и предложить ему сценарий, что он может сделать дальше.
Этот способ также подходит для ситуаций, когда нужно быстро получить обратную связь на функциональность, чтобы решить, оставлять ее или нет.
Статические, затем динамические
Это один из моих любимых способов. Подходит в ситуациях, когда можно реализовать функционал «на заглушках», то есть внешние системы не готовы поддержать функционал. Например, какие-то блоки на главной странице не могут управляться из CMS. Или меню, когда мы делаем его у себя в коде и отображаем пользователю, но при этом им не может управлять бизнес. И чтобы внести изменения, бизнесу надо постоянно ходить в разработку и просить это сделать.
Здесь мы выносим потребности пользователя и получение прибыли в приоритет. Пользователь получает готовый функционал сразу, пусть мы внутри можем испытывать некоторые неудобства. Поэтому мы делим задачу на несколько и сначала делаем новый блок доступным для пользователя, но бизнес им пока напрямую управлять не может. Но затем мы можем интегрироваться с какой-то системой или базой данных, где бизнес сам сможет менять пункты местами и добавлять новые самостоятельно, а мы их будем отрисовывать без участия разработки.
Мы часто используем этот способ: сначала делаем функционал на своих данных, которыми нельзя управлять со стороны, а потом уже добавляем динамику и начинаем получать данные из сторонних систем.
Производительность
Если задача в целом сложная и объемная, непонятно, с какого конца за нее взяться, то производительностью можно пренебречь. В первую задачу вынести готовый функционал, который хоть как-то, пусть медленно, но работал. А следующей задачей сделать ускорение работы. Например, это может быть медленная работа поиска товаров, применение фильтров, получение какой-либо информации
Иногда большая часть усилий вкладывается в быстрое создание функции — первоначальная реализация не так уж сложна. Но можно многому научиться из медленной реализации, плюс это имеет определенную ценность для пользователя, который иначе не смог бы выполнить какое-нибудь важное действие. Во всех этих случаях задачи разбиваются на «заставьте это работать» и «сделайте это быстрым».
Возможные трудности
Если вы решите использовать декомпозицию задач в своих проектах, то скорее всего первой сложностью, с которой вы столкнетесь, будет зависимость задач друг от друга. По моему опыту, именно эта проблема приводит к блокированию всего потока и встречается наиболее часто. Чтобы этого избежать, к декомпозиции стоит подходить ответственно и уделять ей достаточное количество времени.
Еще одна трудность — определить, насколько мелко надо декомпозировать задачу. И здесь границами выступает только здравый смысл. Например, мы берем компонент выбора города. В нем есть кнопки, какой-нибудь текст, поле ввода. Насколько мелко нужно бить эту задачу?
Мы для себя вывели правило, что задача должна проходить по всему потоку не больше, чем за одну неделю (около 40 часов). Речь идет про все стадии: стадию аналитики, разработки, тестирования. Плюс учитываются две стадии разработки бэкенда и фронтенда, включая ревью и тестирование на каждой.
Еще у нас была проблема с тем, что не всегда понятны границы эпика. Недавно нам поставили задачу с оформлением заказа. Где у нее границы? Что должно получиться на выходе? Нам было непонятно, нужно ли нам делать весь функционал до самого конца, или выбрать какую-то часть. Входит ли в этот эпик оплата, или это уже отдельный эпик.
Бывают задачи, с которыми сложно понять, как их декомпозировать и когда. Большую часть задач мы декомпозируем на стадии приема эпика, но бывают ситуации, когда это нужно сделать, например, на этапе аналитики. Мы берем задачу в работу и считаем, что все нужные данные в наших интеграционных системах уже есть, но в процессе анализа выясняется, что либо нас не устраивает формат данных, либо проблема в качестве самих данных, либо требуется доработка со стороны других систем, с которыми мы связаны. Тогда нам приходится делать задачу «на заглушках» и заводить еще один пункт в бэклог, к которому мы приступим уже после того, как решим основные проблемы.
Вот, вроде бы, и всё. Будет здорово, если поделитесь в комментариях историями о том, какой подход к декомпозиции задач используете вы и почему.
Спасибо, что дочитали!
Человечная декомпозиция работы / Хабр
За 15 лет работы разработчиком я обнаружил, что ложные убеждения о человеческой природе — основные враги хорошей декомпозиции. Если знать о них и стремиться не угодить к ним в ловушку, со временем можно сформулировать советы по созданию качественной декомпозиции. Так произошло со мной, и я спешу поделиться этим знанием.
Определения
Фича (feature) — бизнес-возможность, автоматизируемая в программном продукте. Это англицизм, который широко применяется в ИТ-индустрии. Я не нашёл для него хорошего русского аналога.
Декомпозиция (уровня разработки) — процесс разделения работы над фичей на отдельные задачи, часто включающий выбор исполнителя. Также декомпозицией называют результат процесса декомпозиции, то есть совокупность получившихся задач.
Смётка — способность человека строить в уме модель функционирования механизма или природного явления, предсказывать поведение и находить причины неполадок посредством сосредоточенного усилия и интуиции. Смётка является ограниченным, но восполнимым ресурсом. Истощает её переключение контекста и суета. Для её восстановления требуется опыт созерцания, на подобие того, что происходит на рыбалке. Это определение соответствует пониманию из книги «Дзен и искусство ухода за мотоциклом» и уточняет более общее значение из словаря: способность быстро соображать, рассчитывать.
Состояние потока — режим работы мозга, при котором работает аналитическая подсистема мозга, без тех существенных энергозатрат, которые ей требуются без вхождения в это состояние. Вхождение в это состояние возможно при высоком интересе к решамемой задаче и виду деятельности. Но необходимо так же иметь возможность долгое время оставаться в одиночестве, чтобы никто не отвлекал на другие работы. Результаты, достижимые в этом состоянии совершенно несопоставимы с тем, что можно получить при обыкновеной работе с постоянными переключениями контекста на разные задачи. Затраты энергии тоже несопоставимы. Человечная декомпозиция имеет своей целью максимизировать возможноть для исполнителя попадать в состояние Потока при решении рабочих задач.
Более 5 лет я работаю бэкенд-разработчиком в FunBox. В компании мы считаем, что хорошие продукты — результат развитой инженерной культуры и стремимся практиковать этот принцип в разработке решений для мобильных операторов. Тут есть свои особенности стека и процессов, но есть и универсальные аспекты, применимые в любой предметной области. Один из них — подход к декомпозиции. Благодаря продуктовому характеру работы и инженерной культуре мне удалось получить опыт и озарения, о которых я не могу молчать.
Навигация по статье:
В статье речь идёт о ситуации, когда на уровне бизнеса уже определено какую проблему нужно решить и сформированы по крайней мере бизнес требования. Имея эти требования, нужно организовать непосредственный процесс разработки. Под декомпозицией в статье понимается именно декомпозиция уровня разработки, а не декомпозиция уровня бизнес-анализа.
К своим озарениям я пришёл в рамках разработки B2B продукта, находящегося в промышленной эксплуатации. Абстрактно обрисую типичную фичу. Допустим, фича будет содержать бизнес-агрегат из пары моделей (сущностей), для которого нужно реализовать экраны создания, редактирования, просмотра и удаления. Ещё нужно реализовать алгоритм вычисления чего-то связанного с этим бизнес-агрегатом, а результат вычислений отправить на email. Предполагается, что сверху фича оценена хотя бы 10-12 дней. В ней достаточно пространства для творческого осмысления и проектирования. Команда состоит из профессионалов разного уровня от младшего до старшего. Команда включет тимлида, который стремится в том числе заниматься кодированием, чтобы не терять ощущение профессии, продукта и сохранять внутреннюю мотивацию. За границами команды никого не интересует как происходит процесс разработки, и никто в него не вмешивается. По крайней мере пока всё в порядке.
Народная мудрость гласит: «слона нужно есть по частям». Полезно разделить разработку всей фичи на задачи меньшего размера, чтобы снизить риски, сфокусировать усилия и повысить управляемость процесса. Я расскажу как я это делаю, как к этому пришёл, и от чего ушёл. Последнее для меня наиболее важно.
Следующие ложные убеждения о человеческой природе могут приводить к неудачным решениям при декомпозиции:
- Человек от природы порочен, и только давление общества заставляет его сдерживать свои порывы.
- Человек ленив, и его нужно заставлять работать, иначе он будет прокрастинировать.
- Человек склонен до бесконечности улучшать любой достаточно хороший результат, даже если это не несёт никакой ценности заинтересованным лицам (перфекционизм).
- Человеком движет жажда материальных ценностей для себя (эгоизм и алчность).
- Человек нуждается в подчинении и в том, чтобы ему подчинялись (авторитаризм).
- Человек не любит людей и стремится избегать взаимодействия с ними в процессе решения рабочих и жизненных задач (мизантропия).
Когда я называю эти убеждения ложными в отношении человеческой природы, вот что я имею в виду. Даже если время от времени эти свойства бывают присущи конкретному человеку на конкретном этапе его духовного развития, это не значит что все люди таковы или что они не могут преобразиться. Следовательно, не стоит класть эти частные случаи в основу видения и выстраивать стратегию поведения, считая их общезначимыми. Это обрекает людей на страдания и не даёт раскрыть свои возможности. От этого как раз снижается продуктивность за которую ведётся борьба.
Преодолев эти убеждения, можно глубже понять ценность человечной декомпозиции работы, хотя это преодоление не требуется для применения советов и практик данной статьи. Предположу, что опыт их применения может помочь сформировать более истинные представления о человеческой природе.
Опровержение этих убеждений не является предметом данной статьи. Над этим бьются философы и духовные лидеры на протяжении всей истории, и для каждого человека поиск опровержений будет глубоко личным. Я лишь вскользь коснусь возможных направлений поиска, до которых сам дошёл на данный момент.
Отступление. Направления поиска более реалистичных взглядов на человека и мир
Агностикам в вопросе существования высших сил может быть ближе миросозерцание гуманистов, например Эриха Фромма. Я попытался кратко сформулировать своё понимание миросозерцания гуманистов в докладе «Гуманистическая декомпозиция работы».
Спустя полгода после доклада я познал более глубокое экзистенционально-персоналистическое миросозерцание Николая Бердяева. Попробую кратко суммировать по памяти своими словами. Следуя своей интуиции, Бердяев верит в существование меона, испускающего свободу и породившего Бога. Бог же создал сей мир и человека по своему образу и подобию. Свобода человека не от Бога, а от меона. Бог над этой свободой не властен. И Бог желает, чтобы из этой свободы человек творил новый мир.
Созидание нового мира не есть лишь создание идеальных произведений искусства и науки. Это сверхлюбовь ко всему космосу, созерцание всего одухотворенным, включая неодушевлённые предметы. Созидание нового мира — это проявление сверхдобра, то есть преодоление посюстороннего различения добра и зла, при котором борьба за добро легко обращается во зло. Это отказ от желания судить грешников и создавать для них Ад на этом или ином свете. Созидание нового мира — это обнаружение своих даров (способностей) и подвижническое их развитие и дарение людям, несмотря на необходимость потом и кровью зарабатывать хлеб насущный.
Человек же может распорядиться меонической свободой регрессивно в силу неблагоприятных обстоятельств. Будучи не в силах созидать новый мир, он в отместку может разрушать мир сей. На протяжении истории для большинства людей преобладали неблагоприятные обстоятельства, и от недостатка интуиции формировалось перекошенное, иллюзорное миросозерцание, основанное на статистической видимости.
Эсхатологическое миросозерцание Бердяева более глубокое и радостное, чем секуляризованное миросозерцание гуманистов, но оба они закладывают фундамент для преодоления ложных убеждений о человеческой природе.
В этой статье, в отличие от предыдущего доклада, я отказался от слова «гуманистический» в пользу «человечный» в отношении декомпозиции работы, ибо оно точнее, шире и не перегружено смыслом, не относящимся к делу.
Вера в первые 4 ложных убеждения может заставить человека согласиться со следующим утверждением:
Работа заполняет время, отпущенное на неё.
Это «Первый закон Паркинсона», который в 1955 году сформулировал историк Сирил Норткот Паркинсон в сатирической статье на основе наблюдений за британской бюрократией. К сожалению, эта сатира очень быстро распространилась и стала универсальным законом. Даже менеджмент в индустрии программного обеспечения взял его на вооружение, стал тиражировать и бороться с его проявлениями.
В книге «Человеческий фактор. Успешные проекты и команды» Том ДеМарко и Тимоти Листер обосновывают неприменимость этого закона к людям, занимающимся креативной деятельностью, в противоположность серийному промышленному производству и бюрократии. Здесь и далее я ставлю название закона в кавычки, чтобы подчеркнуть отношение к нему как к ложному утверждению в контексте, отличном от описания бюрократии.
Стили декомпозиции работы лежат в континууме:
- от микротаскинга, то есть дробления на неделимые атомарные задачи;
- до #NoEstimates, то есть полного отсутствия формального дробления и оценки трудозатрат.
Микротаскинг
Если считать «закон Паркинсона» истинным и соглашаться с ложными убеждениями о человеческой природе, то возникнет понятное желание минимизировать потенциальный ущерб для капитала. Люди такого склада могут прибегнуть к следующим принципам организации производства:
Если человек ленив (ложное убеждение № 2), то задания нужно делать максимально мелкими, чтобы не было возможности ни минуты сфилонить и получить оплату за прокрастинацию.
Если человек не любит людей и общение (ложное убеждение № 6), то всех участников производства нужно обезличить и организовать процесс так, чтобы не требовалось никакого взаимодействия, кроме того, что выражается в коде, документации к нему и тикетах.
Если человеком движет эгоизм и жажда материальных ценностей, то и работодатель и работник должны максимизировать свою выгоду и минимизировать потери. Нужно платить только за сделанные атомарные задания, устанавливая такую цену, чтобы она достаточно удовлетворяла потребности работника и стимулировала его больше работать без прокрастинации, но и без достаточного погружения в смысл. Чтобы делить работу над фичей на мелкие задания по 10—15 минут, нужны некие архитекторы. Они должны обладать авторитетом, и исполнители будут им с радостью подчиняться, ибо испытывают в этом потребность (ложное убеждение № 5).
Это устройство производственного процесса очень напоминает конвейер, на котором рабочие могут выполнять незатейливые, изолированные операции, не требующие ни большой квалификации, ни взаимодействия с другими людьми. Ещё Карл Маркс в 1840-х и Эрих Фромм в 1960-х годах описали такое устройство производства и экономические причины его существования. Также они описали, насколько губительно и невыносимо это для человека. Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.
Когда все задачи мелкие, то постоянно приходится переключать контекст внимания. Переключение контекста требует от мозга больших энергозатрат (об этом хорошо написано в книге Thinking Fast And Slow). Это огромный источник потерь для смётки. Ослабление смётки приводит к ошибкам. При микротаскинге нет места для восстановления мыслительных ресурсов, или, как это ёмко называет Максим Дорофеев, мыслетоплива. Забота об этом ложится на плечи работника.
К сожалению, мир таков, что достаточное количество людей оказывается искалеченными и им этот производственный процесс подходит. Возможно, он им ближе в сравнении со всем, что они могли испытать на традиционной работе. А заказчики, не избалованные хорошими исполнителями, готовы довольствоваться продуктами, разрабатываемыми в рамках подобного процесса.
Я не могу поверить, что такой подход может приводить к качественным результатам в долгосрочной перспективе. Технический долг и неконсистентность должны неизбежно накапливаться, так что дальнейшее развитие становится тяжким делом. Даже если предположить, что продукты, разработанные по такой системе атомарных задач, получаются приемлемого для заказчиков качества, я не могу не сочувствовать людям, вовлечённым в этот тип производства.
NoEstimates
#NoEstimates (термин возник из хештега в Твиттере) предполагает, что любая фича в продукте разрабатывается быстрее, чем заинтересованные в ней лица успевают спросить про оценку трудозатрат.
Я узнал об этой концепции из доклада Асхата Уразбаева на AgileDays’14. Основными условиями для достижения ситуации, когда не возникает необходимости в оценках, Асхат называет следующие:
- Непрерывная доставка ценности заказчику.
- Отсутствие зависимостей, которые могут что-то сломать. Для обеспечения этого свойства нужен налаженный процесс непрерывной интеграции (CI) с междукомандными интеграционными тестами.
- Уравновешивание возможностей, то есть пропускной способности команды, и потребностей заказчика.
Будучи под влиянием доклада и своего опыта, я пришёл к дополняющим условиям, повышающим шансы работать без оценок:
- Используются выдающиеся, не мейнстримовые технологии, дающие радикальный прирост продуктивности.
- Команды состоят из небольшого числа самомотивированных и высокопродуктивных профессионалов.
- Продукт вовлекает своих воплотителей настлько, что они сами предугадывают нужные фичи или реализовывают запрошенную стейкхолдерами функциональность за меньшее время, чем отнял бы процесс оценки и планирования.
Ситуация #NoEstimates максимально благоприятна для людей. К сожалению, она встречается редко и может длиться недолго. Например, до тех пор, пока крупный игрок на рынке не купит бизнес и не заменит эту культуру своей.
Всем, кто не входит в число счастливчиков, использующих #NoEstimates, нужно искать способ декомпозиции и оценок трудозатрат, который будет способствовать принятию удачных решений при реализации и не будет оказывать морального давления на исполнителей.
В континууме между микротаскингом и #NoEstimates лежит бесконечное множество стилей декомпозиции.
Кажется, мне удалось нащупать золотую середину и очертить стиль декомпозиции, подходящий людям творческим, неравнодушным к своему делу и своим коллегам, занятым в производственном процессе. Я назвал это человечной декомпозицией.
Свойства человечной декомпозиции
При человечной декомпозиции каждая задача удовлетворяет следующим критериям:
- Задача самодостаточна и целостна. Не должно быть аспектов в других задачах, которые могли бы ключевым образом повлиять на создаваемый образ решения данной задачи в голове.
- Задача не превышает 3—5 дней в предварительной оценке трудозатрат. Это ограничение позволит придать задаче обозримые границы и сделает её управляемой, помещающейся в голове.
Вся совокупность задач должна соответствовать архитектурному принципу Loose Coupling / High Cohesion (Слабая зависимость / Сильная сплочённость), а именно:
Loose Coupling: Зависимости между задачами должны быть минимальными.
High Cohesion: каждая задача должна содержать сильно сплочённые функциональные возможности, чтобы ничего нельзя было выбросить без потери целостности размышлений о задаче.
Замечание о характере зависимостей
Я заметил, что зависимости через модели и поля в БД гораздо лучше, чем зависимости по API сервисных объектов. Объясняю это тем, что проектирование изменений в БД производится тщательнее, поэтому, когда принято решение, вероятность его изменения низка.
Зависеть же от ещё не разработанных сервисных объектов крайне дискомфортно. Я бы советовал рассматривать зависимости между задачами по API сервисных объектов как decomposition smell (термин аналогичен code smell), то есть маркер низкого качества декомпозиции.
Верификация декомпозиции
Попытаться прийти к декомпозиции с такими свойствами можно итеративно, верифицируя получившийся набор задач. С проверкой помогут контрольные вопросы к отдельным задачам и набору в целом.
Контрольные вопросы к каждой задаче:
- Можно ли целостно думать о задаче в изоляции от других задач?
- Можно ли вынести из задачи что-то лишнее так, чтобы при этом не нарушилась целостность?
- Не слишком ли мала задача? Не должна ли она быть частью какой-то большей задачи, чтобы та была целостной?
Контрольные вопросы к совокупности задач:
- Нет ли между задачами слишком сильных зависимостей, возможно, неявных, в особенности если они даются разным исполнителям?
- Являются ли все задачи управляемыми по объёму (оценка не превышает 3—5 дней)?
- Не слишком ли мелко разбиты задачи и не нарушена ли их целостность?
Вопросы кажутся похожими, некоторые отличаются только объектом направленности. Так и есть. Но в процессе декомпозиции удобно переключаться между режимами анализа каждой задачи в отдельности и всей совокупности в целом. Найденные возможности улучшения при ответе на каждый вопрос порождают новую итерацию. На определённой итерации идеи улучшений заканчиваются и полученная совокупность задач с большой вероятностью будет обладать свойствами человечной декомпозиции.
Обоснование выбранной цифры для границы размеров задач
3—5 дней — цифра условная. Граница размера задачи, которая помещается в голове, будет зависеть от сложности технологии. Данную цифру я привожу для проекта на Ruby on Rails.
Как ни парадоксально, но какое-либо ограничение по трудозатратам не только давит на исполнителя, но и помогает направлять мыслительный процесс при декомпозиции, помогает фокусироваться.
Многих такая большая цифра может тревожить, если они склонны соглашаться c «законом Паркинсона». Я встречал два вида опасений, связанных с этим законом:
- Человек будет прокрастинировать (ложное убеждение № 2) всё время, которое ему выделят на работу, и под конец срока в авральном режиме сделает халтурное решение.
- Человек быстро сделает всё, что нужно, но так как ещё остаётся время, то он из перфекционизма (ложное убеждение № 3) будет заниматься ненужными улучшениями решения вместо того, чтобы перейти к следующей задаче.
При склонности опасаться первого пункта, руководитель может начать следить за скоростью приращения программного кода. Почти всегда чем ближе к окончанию срока задачи, тем быстрее прирастает код, тем больше вносится изменений. Это можно ошибочно принять за доказательство справедливости утверждения о лени человека. На самом же деле это объясняется тем, что чем ближе к окончанию срока, тем ниже неопределённость, тем больше готового кода и понимания, как его улучшить, чтобы довести до образцового состояния. В начале работы из-за большой неопределённости нужно много размышлять, писать в блокноте, проектировать. В том числе нужно прокрастинировать, то есть заниматься отвлечённой деятельностью вдали от компьютера, чтобы мозг в фоновом режиме мог сформировать образ решения.
Большие сроки на выполнение одной задачи требуют доверия к исполнителю. Важно понимать, что люди хиреют при отсутствии доверия к ним, а при наличии — расцветают. Могут быть и исключения, когда люди садятся на шею, но это патология, и будет ошибкой принимать её за правило. Нужно верить, что человек имеет потребность создавать ценности, быть полезным и в нормальном своём состоянии не будет вредить. Человек чувствует себя подавленным, если ему не удаётся уложиться в сроки или когда у него что-то не получается. В этой ситуации важно иметь регулярную обратную связь, чтобы вовремя обнаружить затруднения и поддержать.
При склонности опасаться второго пункта, руководитель может начать пытаться защититься от перфекционизма с помощью искусственно заниженных сроков, таких, чтобы вздохнуть было некогда, не то что сделать что-то избыточное по задаче.
Необоснованный перфекционизм чаще встречается у сотрудников с небольшим опытом. Они ещё не научились мыслить категориями ценности для бизнеса, но имеют потребность показать себя. Здесь продуктивным решением будет частая синхронизация с командой или наставником.
Примеры нарушения целостности задач и ощущения исполнителей
Приведу наиболее яркие и распространенные примеры нарушения целостности задач из своей практики.
Разделение работы над моделью и кодом, её использующим
Предположим, что реализуемая фича требует наличия сущности с персистентным хранением (модель в терминах Ruby on Rails) и CRUD пользовательского интерфейса для неё.
Напрашивающимся решением по декомпозиции будет завести задачу на реализацию модели и на реализацию пользовательского интерфейса, её использующего.
Но думать о модели без учёта использующей её части — это нарушение целостности. Могут получиться неудачные названия полей, типы данных, валидации. Можно не выполнить какое-нибудь требование технологии пользовательского интерфейса, накладывающее ограничения на модель. Или можно сделать модель такой, что код пользовательского интерфейса будет сложнее, чем мог бы, если бы его брали в расчёт сразу.
Пример ошибки раздельного проектирования модели и пользовательского интерфейса в проекте на Ruby on Rails
В Ruby on Rails удобно делать группу чекбоксов для множественного выбора через связь «многие-ко-многим». Это так называемая has_and_belongs_to_many
HABTM-связь между двумя моделями без отдельной модели для связующей таблицы.
Если рассматривать модель без учёта пользовательского интерфейса, то все знают, что HABTM-связь использовать не рекомендуется. Она выбрасывает модель связи, у которой могут появиться свои поля и поведение. Считается, что проектировщик может срезать углы, используя HABTM-связь, потому что не хочет задумываться о связующей модели как о сущности, имеющей собственную идентичность и состояние. Никто не хочет использовать не рекомендуемые приёмы. Но ситуация, когда связь нужна исключительно для выражения множественного выбора в веб UI, является исключением из правила. В этом случае искусственное введение связующей модели будет перебором и нарушением принципа «Бритва Оккама», то есть внесением сущностей сверх необходимого для объяснения явления или его моделирования.
Если работать и над моделью, и над веб UI, её использующим, в рамках одной задачи, то вовремя заметишь, что связь нужна только для создания группы чекбоксов, а отдельная модель для связующей таблицы — это перебор, и исправишь это.
На ревью кода коллегам сразу будут видны и модель, и код пользовательского интерфейса, её использующий, будет очевидно большинство принятых решений.
Может показаться, что если следовать этому правилу, то задачи будут слишком большими по оценке трудозатрат. Можно попробовать заводить две задачи. Одну — для реализации основного поведения, а вторую — для второстепенных улучшений, про которые сразу не подумаешь. Хотя если менеджмент понимающий, то я бы рекомендовал заводить крупные целостные задачи и не пользоваться этим советом.
Разделение внутри алгоритма
Рассмотрим пример фичи:
- Есть два множества строк.
- Первое множество влияет на состояние элементов второго множества, если элементы второго множества включают или не включают хотя бы один элемент из первого множества как подстроку.
- При любом изменении в первом множестве строк должно пересчитываться состояние элементов второго множества.
- При любом изменении в элементах второго множества, которые являются мутабельными, тоже должно пересчитываться состояние этих элементов.
- Всё усложняется тем фактом, что первое множество строится из нескольких источников и зависит от изменений в этих источниках.
- После пересчёта должна произойти выгрузка обновлённых состояний для другой системы.
Если для такой задачи делать человечную декомпозицию, то можно выделить основную задачу одному человеку на 5 дней, а вспомогательные задачи небольшого объёма дать коллегам, чтобы разгрузить голову основного исполнителя. Если же исходить из того, что люди ленивые и дата релиза уже назначена, то нужно «подстраховаться»: разбить весь объём работ на небольшие задачи менее двух дней в объёме трудозатрат и раздать двум доступным разработчикам.
Между кусками работы этих разработчиков будет много зависимостей. Один разработчик будет создавать узкоспециализированный сервисный объект, который должен будет использовать другой. До начала разработки они должны предугадать подходящий API и потом рассчитывать, что он не изменится, чтобы не подкинуть друг другу лишней работы. Принятый ими API не может быть достаточно хорошо продуман, ибо в этой ситуации некому думать об алгоритме целостно. В нём гарантированно будут ошибки, и он будет оказывать давление на психику исполнителей.
С горем пополам разработчики реализуют свои части мозаики алгоритма. С чувством уверенности, что они сделали свои части работы хорошо, даже автотесты проходят, они выкатятся на ручное тестирование. Хорошо, если ручные тестировщики есть в команде.
И тут выяснится, что только 10% сценариев использования работают корректно, а именно: при добавлении строки в первое множество происходит изменение состояния во втором множестве, при удалении же ничего не происходит.
Винить в этом разработчиков было бы несправедливо. Ни у одного из них не могло быть в голове целостной картины, ибо поставленные им задачи имели узкие границы, конкретные постановки и сроки без запаса по времени, а сроки срывать никто не любит. У них не было и достаточно политического веса, чтобы сказать, что по такой декомпозиции невозможно сделать работу качественно. Заранее можно иметь лишь интуитивное и смутное ощущение неправильности декомпозиции. Важным маркером здесь является наличие зависимостей между разработчиками по API сервисных объектов, но как это доказать в моменте, совершенно не очевидно.
Эта история из жизни позволила ретроспективно выявить проблемы и формализовать интуитивные действия при декомпозиции, которые мне удалось сформировать за годы работы.
Рассмотрим, какие стратегии помогут с небольшим количеством итераций приходить к человечной декомпозиции.
1. Отказ от декомпозиции
Если слово «декомпозиция» воспринимать буквально как разделение на части, то может показаться, что на выходе этого процесса должно обязательно получаться больше одной задачи.
Одна задача, даже большая, вполне может быть результатом процесса декомпозиции.
Если фича недостаточно велика и верхнеуровнево оценена в 3—5 дней, то может так случаться, что дальнейшее деление не даст преимуществ, но может создать проблемы, если ошибиться в границах задач. В особенности, если дать их разным исполнителям в надежде выполнить работу быстрее.
2. Делегирование исполнителю
У тимлида может сложиться ложное впечатление, что в его обязанности входит выполнение всех декомпозиций и спуск задач сверху членам команды разработки. Так может случиться, если в должностной инструкции не донести мысль, что от тимлида требуется обеспечить процесс декомпозиции, а не выполнить её самому. Ещё это впечатление может сложиться из ложного убеждения № 5, что человек нуждается в подчинении и чтобы ему подчинялись. Если же постановку задач делегировать их исполнителю, то никакой власти у тимлида не останется, никакого авторитета не будет и подчиняться ему как следует не смогут, при том что нуждаются в этом.
Тимлиду может даже казаться, что декомпозиция работы — это его основная обязанность, за которую его ценят. Или может казаться, что проще самому декомпозировать и требовать выполнения получившихся задач, чем помогать делать это другим. Эта иллюзия подкрепляется ложным убеждением № 6, что человек стремится избегать взаимодействия с людьми из-за мизантропии. Кажется, что проще спустить сверху готовое задание исполнителю, а не помочь ему сформировать это задание самостоятельно, исходя из понимания требований самим исполнителем.
На самом же деле декомпозиция работы для других людей — это крайне отчуждённая деятельность, которая выматывает и никогда не приносит удовлетворения. К тому же она имеет тенденцию превращать тимлида в «бутылочное горлышко» команды.
Если же декомпозицию делегировать, то у тимлида освобождается время для более творческой деятельности по стратегическому развитию продукта.
Тимлид может заниматься поиском инноваций и воплощением их в спокойном режиме вне критического пути создания ценности, непосредственно необходимой заказчику. Именно так произошло с тимлидом команды, к которой я принадлежу — тут я описываю настоящий опыт.
Таким образом, лучшим решением будет выбор главного исполнителя для реализации фичи и делегирование ему процесса декомпозиции. У главного исполнителя будет максимальная мотивация разобраться в требованиях и обеспечить себе и коллегам задачи с комфортными формулировками и оценками трудозатрат.
Лично я не могу приступить к написанию кода, пока у меня в голове не сложится приблизительный образ решения. Чтобы он сложился, необходимо точно знать, какую проблему и для кого нужно решить. Без этого мозг отказывается работать над задачей.
Если, напротив, меня поставят перед фактом назначенных мне конкретных задач с жёсткими требованиями по реализации и спущенными сверху оценками, то я оказываюсь демотивирован и ощущаю подавленность.
Можно возразить, что есть много разработчиков, предпочитающих работать по чётко сформулированным детальным требованиям, когда им говорят, что конкретно делать. Так и есть. Важно знать своих коллег и их предрасположенности. Таким сотрудникам я бы рекомендовал поручать второстепенные механизмы, требования к которым, как правило, более понятны и могут быть сформулированы заранее с достаточной точностью. Об этом далее в пункте 6 про выделение смыслового ядра.
3. Отказ от детального проектирования
Может сложиться убеждение, что для осуществления декомпозиции необходимо провести детальное проектирование или даже что декомпозиция и детальное проектирование — это одно и то же. Мне кажется, что декомпозиция всё-таки ближе к предварительному проектированию. Производя декомпозицию, лучше всё время оставаться как можно выше уровней реализации и проектирования — где-то между уровнем бизнес-требований и системных требований.
Удобно представлять себе весь объём функциональности как кусок мрамора. От него нужно отделять крупные части, границы которых очевидны уже во время предварительного проектирования.
Может помочь и такой приём: в воображении посмотреть на решение через прищуренные глаза. При этом картинка расплывчата, но различаются силуэты и границы подсистем.
Если произвести детальное проектирование во время декомпозиции, неизбежны ошибки и низкое качество. Ещё сильнее возрастают риски, если задачи будут делегированы голове, отличной от головы декомпозирующего. В результате исполнитель будет парализован в возможности вовремя распознать ошибки, допущенные уровнем выше, и тем более не сможет их исправить.
4. Группировка функциональности по сходному уровню сложности, неопределённости или риска
При планировании и оценке трудозатрат удобно разделять задачи по уровню сложности, неопределённости и риска. В зависимости от характера продукта может подойти разное количество баллов для оценки.
Допустим, получился вариант разделения на задачи и кажется, что он оставляет желать лучшего, но не понятно, как его улучшить. В этой ситуации нужно попробовать оценить, содержит ли каждая задача внутри себя вещи, сходные по уровню сложности, неопределённости или риска.
Если внутри задачи есть пункты с разными уровнями по этим свойствам, то с такой задачей можно застрять, при том что некоторые части уже готовы и их можно было бы продвинуть по конвейеру создания ценности. Это увеличивает объем незавершённой работы — W.I.P. (work in progress). Эмоциональное самочувствие исполнителя ухудшается, потому что на него давит этот незавершённый гештальт.
5. Поэтапная декомпозиция
Иногда бизнес приходит с очень большими фичами или наборами связанных фич, которые для бизнеса важны целиком, а не по частям.
В этом случае нужно разделить работу над этим большим набором фич по нескольким этапам, релизам, спринтам. Частично готовую функциональность можно выкатывать на продакшн, но скрывать за фича-флагами или за авторизацией, чтобы бизнес-пользователи их не видели.
Не нужно обеспечивать декомпозицию сразу по всем этапам. Нужно откладывать процесс декомпозиции до последнего момента, когда её уже необходимо сделать, чтобы коллектив не простаивал.
К этому моменту будет собрана максимально возможная информация для принятия решений и распределения работы по исполнителям. Бережливое производство учит откладывать момент принятия важных решений до последнего момента.
6. Выделение смыслового ядра
Часто в бизнес-фиче можно выделить смысловое ядро и второстепенные механизмы.
Например, смысловое ядро представляет собой алгоритм вычисления чего-либо, а второстепенный механизм осуществляет рассылку результатов вычисления на почту или поставляет их в точку интеграции с другой системой.
Эти концепты я почерпнул из главы 15 «Дистилляция» книги Эрика Эванса «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем». Для простоты рассуждений я объединил неспециализированные подобласти (Generic Subdomains) и связные механизмы (Cohesive Mechanisms), от которых очищается смысловое ядро (Core Domain), в категорию второстепенных механизмов.
Смысловое ядро всегда содержит больше сложности, неопределённости и риска, а второстепенные механизмы часто бывают более понятны, и границы их хорошо видны на этапе предварительного проектирования.
Хорошим решением может быть поручить смысловое ядро основному исполнителю по этой бизнес-фиче, а второстепенные механизмы отдать его помощникам. Таким образом, основной исполнитель освобождает свою голову от второстепенных деталей, снижается давление на него. Риск не уложиться в сроки релиза снижается.
Эта стратегия очень похожа на метафору хирургической бригады Фреда Брукса из книги «Мифический человеко-месяц».
Автор рекомендует назначать хирургом самого продуктивного программиста, а ассистентами менее продуктивных коллег с меньшим опытом.
Во времена, которые описывает Фред Брукс, системы были больше и обладали огромной случайной сложностью (accidental complexity) из-за неразвитости технологий и железа. Фичи были огромными, а итерации очень длинными.
Но стоит пойти дальше, ведь сейчас типичные бизнес-приложения разрабатываются небольшими приращениями, укладывающимися в итерации длиной от двух до четырёх недель. Технологии скрывают значительную часть сложности за абстракциями. Особенно в этом преуспевают omakase-фреймворки, в частности Ruby On Rails и подобные ему.
При этом есть огромный дефицит разработчиков на рынке, который только возрастает. Для компаний становится стратегически важно ускоренно выращивать младших сотрудников в средних и старших. Исходя из этой стратегии развития людей, стоит стараться чаще назначать хирургом не самого старшего, а самого младшего разработчика в команде и оказывать ему усиленную поддержку. Он будет вникать в фичу от уровня требований через декомпозицию с поддержкой наставника. Будучи максимально вовлечённым, младший разработчик будет ощущать драйв, осмысленность своей деятельности и быстрее расти.
Уже полтора года мы стараемся поступать таким образом, и опыт этот весьма результативный и благодатный.
В команде может оказаться добротный разработчик, отлично справляющийся с работой по чётким требованиям, но не желающий расти подобным образом. Ему можно поручать задачи по второстепенным механизмам, когда их декомпозирует хирург данной фичи. Других же разработчиков нужно назначать хирургами как можно чаще.
7. Выделение прототипа
Выделенное смысловое ядро может оказаться достаточно большим и неуправляемым по трудозатратам. Может быть не очевидным, как его разделить на подзадачи управляемого размера. В этом случае может выручить прототипирование. Стоит взять верхнеуровневую оценку трудозатрат на фичу и часть этого времени выделить на создание прототипа, а остальное время на продуктовую версию.
Можно поделить в пропорции «золотого сечения», когда меньшая часть времени отдаётся на прототип, можно поделить и в отношении 1:3. Но важно выделять на прототип достаточно времени, чтобы не ощущалось чрезмерное давление. Лучше по факту закончить прототипирование чуть раньше — тогда больше времени останется на продуктовую версию.
Как результат создания прототипа появится достаточно информации для разделения работы на задачи, выявления смыслового ядра и второстепенных механизмов, которые можно делегировать другим людям.
Прототип — это тренировочная версия фичи, целью которой является обкатка решений проектирования.
При разработке прототипа допускается снижение стандартов качества, чтобы уменьшить давление на разработчиков и немного сэкономить время. Например, можно не покрывать тестами побочные сценарии. Можно даже не разрабатывать через тесты, если это не оправдано в рамках проверки идеи. Можно не заботиться о логировании, обработке ошибок и надёжности.
Важно понимать и донести это до менеджмента, что ни в коем случае нельзя брать прототип как есть и дорабатывать его до продуктового состояния, как бы ни был велик соблазн.
Продуктовую версию следует разрабатывать с нуля в соответствии со всеми принятыми практиками и дисциплинами, на прототип же лишь посматривать для следования очертаниям решения. Главный эффект от прототипа — это формирование образа решения в голове и отбрасывание ошибочных предположений об алгоритме.
Когда нужно разработать какую-то фичу, обладающую достаточной новизной в системе, ощущается огромное давление. Нужно разработать всё сразу и не ниже уровня своего внутреннего стандарта. Это чувство парализует мозг и вгоняет в жёсткую прокрастинацию. Нужно дать возможность мозгу поэкспериментировать в более лёгкой, игровой форме, не требуя образцовых результатов.
Практика создания прототипов подробно описана в книге Дейва Томаса и Энди Ханта «Программист прагматик. Путь от подмастерья к мастеру» в 1999 году. Ещё раньше, в 1975 году, Фред Брукс описал подобную практику создания опытных систем в книге «Мифический человеко-месяц».
Приведу яркую цитату из Главы 11 «Планируйте на выброс» для тех, кто скептически относится к прототипам:
Поэтому планируйте выбросить первую версию — вам всё равно придётся это сделать.
У меня есть убеждение, что вместо стремления к недостижимому идеалу необходимо бороться за уменьшение степени несовершенства и боли. Для меня самым масштабным достижением на этом пути стало формулирование идей человечной декомпозиции.
Уже полтора года мы в команде осознанно применяем обозначенные в статье приёмы. Это дало тимлиду возможность не заниматься постоянно декомпозицией работы для других, а производить инновации: существенно улучшить архитектуру работы с логами, мониторингом и многими другими общими инфраструктурными механизмами. Тимлид смог поучаствовать в качестве основного разработчика в создании нескольких бизнес-фич. Младший разработчик смог сделать то же самое. Он получил драйв, самостоятельность и в результате вырос до мидла. Я сам стал работать ещё комфортнее, чем до изменений. Другие команды стали применять человечную декомпозицию и рассказали мне о положительном опыте.
Моя инструкция по человечной декомпозиции стала в FunBox частью должностных инструкций и отстаивается техническим руководством перед менеджментом в случае недопонимания.
Надеюсь, стремление к человечной декомпозиции поможет всем нам попасть в мир, в котором больше компаний с развитой инженерной культурой и продуктами, обладающими большей концептуальной целостностью.
Прийти к идеям человечной декомпозиции мне помогли следующие книги:
- Дейв Томас и Энди Хант «Программист прагматик. Путь от подмастерья к мастеру».
- Фред Брукс «Мифический человеко-месяц».
- Эрик Эванс «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем».
- Том ДеМарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды».
- Мери и Том Поппендик «Бережливое производство программного обеспечения. От идеи до прибыли».
Найти более глубокое обоснование идеям человечной декомпозиции и опровергнуть заблуждения о человеческой природе мне помогли эти книги (большинство из них есть в аудио):
- Все книги Эриха Фромма.
- Николай Бердяев все книги, в особенности: «Смысл творчества. Опыт оправдания человека», «О назначении человека. Опыт парадоксальной этики» и финальная «Царство Духа и Царство Кесаря».
- Федор Михайлович Достоевкий все книги, в особенности: «Братья Карамазовы».
- Кен Уилбер «Благодать и стойкость. Духовность и исцеление в истории жизни и смерти Трейи Киллам Уилбер».
- Даниэль Каннеман Thinking Fast And Slow.
- Роберт Пирсиг «Дзен и искусство ухода за мотоциклом», в особенности рассуждения автора о смётке и вещах, которые её истощают. Я и само это слово узнал из книги.
Направления дальнейшего моего поиска:
- Клер Уильям Грейвз «Спиральная динамика». Первый раз услышал о спиральной динамике от Максима Цепкова на конференции AgileDays’14, кстати, тогда же, когда и про #NoEstimates. Это знание сильно повлияло на меня.
- Кен Уилбер «Интегральный подход». У Уилбера много книг. Я только начал их изучение но кажется, его миросозерцание созвучно Николаю Бердяеву и потому интересно, до каких озарений дошёл современный нам человек, интересующийся широким спектром вопросов философии, психологии, духовности и науки.
Благодарю всех комментаторов за вклад в улучшение содержания статьи!
UPDATE 2020-10-27 Уточнение формулировки понятия о ложности убеждений о человеческой природе
Благодаря комментариям @JustDont
и @iiopy4uk_msk
мне удалось улучшить формулировку моего утверждения о ложности растиражированных убеждений о человеческой природе. А именно проблема возникает, когда описанные частные случаи поведения считаются общезначимыми свойствами человеческой природы, и от этого выстраивается априорная защита даже в креативных видах бизнеса. Это же относится и к «закону Паркинсона», согласие с которым может вытекать из данного обобщения.
UPDATE 2020-10-27 Добавление описания контекста, в котором выкристализовались идеи
После опубликования статьи я стал смотреть, что ещё пишут про декомпозицию, и оказалось, что она бывает на разных уровнях. Есть декомпозиция уровня бизнес-анализа, когда выясняется какие есть у бизнес проблемы и как их разбить на независимые фичи. А есть декомпозиция уровня разработки, когда уже от уровня бизнес-анализа поступили разумные готовые истории на разработку. При этом не исключается, что на уровне разработки станет понятно, что эти требования нужно вернуть на доработку аналитикам. Статья фокусируется на проблеме декомпозиции работы по реализуемым разумным требованиям.
Так же @iiopy4uk_msk
указал на полезность обозначения контекста для лучшего понимания подхода. Эти размышления привели к добавлению раздела Контекст. В нём я привёл описание типа продукта, типичной фичи, состава команды разработчиков и её отношений с внешним миром.
UPDATE 2020-11-20 Устное обсуждение статьи в сообществе DevOps Moscow
Статья заинтересовала Александра Титова и он пригласил меня обсудить её в сообществе DevOps Moscow. Я с самого начала существования этого сообщества с февраля 2013 года являюсь его участником. Мне очень понравился этот отпыт. Участники своими вопросами и мнениями помогли раскрыть содержание и ключевые идеи статьи. Смотреть запись трансляции советую только на повышенной скорости, потому что я разговариваю медленно и долго подбираю подходящие слова.
Благодарю Александра Титова и участников сообщества за общение!
UPDATE 2020-12-31 Конспект обсуждения статьи в сообществе DevOps Moscow
Добавил конспект обсуждения статьи и дополнительные мысли в виде треда комментариев к видео.
Поздравляю всех с наступающим Новым 2021 Годом!!!
UPDATE 2021-01-13 Уточнение определения смётки и добавление определения состояния потока
Благодаря акценту на понятии смётки при обсуждении в DevOps Moscow, я понял что её определение в начале статьи стоит дополнить. Я добавил, что это ограниченный, но восстанавливаемый ресурс, для восстановления которого требуется созерцание, вроде того, что бывает на рыбалке.
Так же я добавил определение состояния потока, ведь человечная декомпозиция пытается служить ему в первую очередь и делать возможными те выдающиеся результаты, которые только в этом состоянии достижимы.
Декомпозиция задач | Жизнь как проект
Сегодня поговорим о том, как добиться поставленных целей благодаря декомпозиции задач. В прошлой статье про целеполагание, я рассказала о нескольких методах постановки целей. Неважно, какой из них вам нравится использовать, главное, чтобы ваша цель была максимально конкретной, достижимой и измеримой. Но что делать после того, как у нас сформировались цели по каждому проекту или по каждой сфере жизни?
1. Нужно перефразировать цель в задачу.
Зачастую наши цели звучат слишком масштабно, пугая нас и демотивируя браться за их достижение. Для того, чтобы сделать цель более близкой, нужно перефразировать ее в конкретную задачу. Например, у вас есть цель: иметь красивый двухэтажный дом на заливе к 2022 году. Задача в обобщенном формате будет звучать так: построить двухэтажный дом.
2. Нужно декомпозировать главную задачу на ее мелкие составляющие.
Декомпозиция — это разделение чего-то большого, на меньшие составляющие. Ключевое слово — составляющие, а не части. Каждая составляющая — это самодостаточная единица. То есть, задача должна быть разобрана на мелкие подзадачи, которые являются ее составляющими.
Зачем нужна декомпозиция?Большие задачи сложно выполнять и морально, и физически. Для лучшего понимания процесса выполнения задачи, нужно разбить главную задачу на маленькие составляющие, а те, в свою очередь, на еще более мелкие составляющие — и так далее, пока не будет интуитивно понятен каждый шаг. Вы перестанете испытывать страх перед целью или откладывать ее на потом, когда перед вами будет список из простых шагов к этой цели, на выполнение которых тратится от нескольких минутов до пары часов.
Пример декомпозиции задачи
Для примера можно взять цель, которую я уже привела: иметь красивый двухэтажный дом на заливе к 2022 году. Соотвественно задача, которую мы будем декомпозировать: построить двухэтажный дом. Допустим, у нас уже есть финансы для постройки дома, не хватает только плана, дизайн-проекта, участка и самого дома.
Сама по себе задача «построить дом» кажется очень комплексной. Пока мы не разобъем ее на понятные составляющие, скорее всего нам будет очень непросто взяться за ее выполнение, так как мы даже не понимаем, с чего начать. Можно упростить себе задачу, декомпозиров ее на листе бумаги или в вашем таск-менеджере.
Первый уровень декомпозиции:
- Подобрать подходящий участок на заливе
- Подготовить дизайн-проект
- Построить фундамент
- Построить стены
- Проложить коммуникации
- Построить крышу
- Сделать внешнюю отделку
- Сделать внутреннюю отделку
- Обустроить территорию
- Сделать площадку для собаки
Уже стало чуть понятне. Шаг от нулевого представления о доме до его фундамента стал меньше, чем до уже готового дома. Но, все еще, выполнить каждый из этих шагов представляет значительные трудности, значит — нужно продолжить декомпозировать каждый пункт. Я распишу декомпозицию задачи постройки фундамента.
Построить фундамент
1. Нанять рабочих
2. Проконсультироваться о типах фундаментов
3. Нанять экскаватор
а. Найти 5 компаний с арендой экскаваторов
б. Сравнить цены
в. Заказать экскаватор
4. Вырыть котлован
5. Рассчитать необходимый объем материалов
6. Закупить цемент, песок и арматуру
а. сравнить цены в разных магазинах
7. Арендовать бетономешалку
8. Построить опалубку
а. Закупить материал для опалубки
б. Нанять рабочих для постройки опалубки
9. Заложить арматуру
10. Залить фундамент
Некоторые из этих задач можно разбить на еще более мелкие, но в целом все шаги для постройки фундамента нам стали понятны. Тоже самое нужно сделать с остальными задачами, пока не сформируется список из простых шагов. В конце декомпозиции, у вас будет четкий план и вам будет достаточно просто выполнять задачу за задачей по списку, и цель в имении собственного дома на заливе будет выполнена.
Такую декопозицию можно провести с любой задачей, и это заметно облегчит планирование и выполнение своих целей. Я убедилась на своем опыте, что декомпозиция, также, спасает от стресса и помогает учесть все детали при планировании пути достижения любых целей. А при ведении больших проектов, без нее вообще никак.
Декомпозиция бэклога 💎 — OnAgile Consulting
Огромное преимущество Agile перед классическим подходом — возможность не делать все и сразу, а поставлять результат инкрементально, по частям, получая ценную обратную связь и первые выгоды для компании.
Понимание того, как ускорить поставку результата, дает декомпозиция элементов бэклога. Основная задача декомпозиции — из общей идеи выделить самое главное, что должно быть сделано прямо сейчас. А все остальное несколько отложить. Но как выделить главное, когда нужно сделать все и сразу? Ведь клиенты и заказчики всегда просят именно так.
Существует два уровня декомпозиции: уровень самого продукта (обычно используются термины MVP, MLP) и уровень элементов бэклога — требования/функции/задачи (часто используется термин MMF).
Декомпозиция продукта1. Декомпозиция по задачам клиентовГлавный критерий правильно проведенной декомпозиции — каждый полученный элемент, будучи реализованным, должен иметь ценность, то есть он проверит некоторую гипотезу о потребителях, принесет определенную выгоду клиентам или, например, снимет технологический риск.
Стремление решить конкретную задачу — главная причина, почему клиенты используют тот или иной продукт или сервис. Поэтому, выбрав конкретный сегмент целевой аудитории и основную решаемую клиентами задачу, приступаем к ее реализации.
После получения обратной связи и проверки гипотезы о том, что предложенный продуктом способ решения задачи нравится пользователям, можно приступать к расширению функционала.
Основной метод этого паттерна декомпозиции — «рабочие истории» (Job Story), ориентированные на контекст, в котором возникает необходимость в продукте.
2. Выделение минимальной версии продуктаMinimum Viable Product, или MVP — минимальный жизнеспособный продукт (сервис, процесс), обладающий базовыми функциями, способными закрыть задачу первых пользователей.
В состав MVP включают достаточный минимум, который позволит протестировать идею. Цель прототипа — получить обратную связь от производства и пользователей, разработать гипотезы для дальнейшего развития продукта (сервиса, процесса).
3. Выделение основного сценарияПри работе над бизнес-процессом в первую очередь рассматривается основной сценарий, либо даже несколько последовательных шагов из него. Остальные шаги и все дополнительные ответвления реализуются позже, когда основной сценарий проверен и отлажен.
Декомпозиция элементов бэклога (на примере программного продукта)Декомпозируя продукт, мы не должны забывать, что в первой версии поставки результата кроме функциональных блоков необходимо учесть пользовательский опыт. Дизайн (интерфейс), безопасность и другие аспекты user experience позволяют вызвать эмпатию у пользователей продукта или сервиса, а значит получить больше обратной связи и начать формировать лояльность к продукту.
Итак, мы выделили ключевые функции продукта, теперь нам необходимо декомпозировать каждую из них.
1. По этапам рабочего процессаЕсли продукт предполагает некий рабочий процесс, его, как правило, можно разбить на отдельные шаги. К примеру, в приложении для вызова такси это будет определение адреса вызова машины, точки назначения, выбор категории такси, заказ, оплата картой или наличными, возможность оставить отзыв о поездке и тд. Уже на этом этапе декомпозиции понятно, какую часть функционала следует реализовать в первую очередь, а какую оставить на потом: например, на первом этапе заполнять адрес места отправления вручную, а позже добавить автоматическое определение местоположения пользователя.
2. Разделение по ролямЧасто внутри группы «клиенты (пользователи)» можно выделить несколько явно выраженных ролей, каждая из которых взаимодействует со своей частью функционала продукта. Это могут быть зарегистрированные и незарегистрированные пользователи, администратор или редактор и тд.
3. Разделение на позитивные и негативные сценарииПозитивный сценарий подразумевает, что клиент достиг своей цели при использовании продукта. В нашем примере с такси — успешно вызвал машину и доехал до точки назначения.
Негативные сценарии описывают любые отклонения в развитии событий: пользователь забыл пароль и вынужден восстанавливать его; или клиент решил отменить поездку; или расплатиться наличными вместо карты и тд. Часть негативных сценариев на первом этапе может быть реализована в упрощенном виде или отложена.
4. Декомпозиция по операциямЧасто PBI включает в себя различные операции: например, управление ассортиментом интернет-магазина. Внутри такой операции «по умолчанию» обычно находится несколько более мелких: добавление нового продукта, удаление тех, что больше нет в ассортименте, редактирование цены и описания товара и тд.
5. Разделение по бизнес-правиламПродукт обычно предполагает соблюдение общепринятых в конкретной сфере бизнес-правил: отмена бронирования товара, если он не был оплачен в течение определенного времени; поиск билетов по гибким датам; минимальная сумма для доставки товара и тд. Элементы бэклога можно декомпозировать так, чтобы сначала реализовать только часть бизнес-правил.
Достаточная степень декомпозицииДостаточная степень декомпозиции продукта и отдельной функции зависит от вида продукта или сервиса, состава команды и других ограничивающих факторов и обычно определяется экспериментальным путем.
В общем случае декомпозиция позволяет уменьшить время на поставку результата и получение обратной связи. Это, в свою очередь, позволяет увеличить скорость работы команды, снизить риски и связанную с ними стоимость внесения изменений в продукт, а также повышает удовлетворенность бизнес-заказчиков и потребителей.
Декомпозиция целей и задач | Тайм-блог
Декомпозицией в тайм-менеджменте называют разделение целей или задач на отдельные небольшие шаги — подзадачи. Например, задача «навести порядок на кухне» делится на следующие этапы: убрать со стола, помыть посуду, протереть газовую плиту, подмести. А чтобы достичь цели «улучшить физическую форму» нужно заняться физкультурой, сесть на диету и отказаться от вредных привычек.
В этой статье мы выясним, для чего нужна декомпозиция целей и задач, познакомимся с ее основными принципами и узнаем, как ее выполнять.
Зачем нужна декомпозиция?
Декомпозиция очень часто используется в планировании, и это не случайно. Она помогает:
Облегчить выполнение задач. Крупные задачи часто кажутся непомерно сложными, что вызывает у нас приступы прокрастинации. Декомпозиция позволяет разложить такие «страшные» задачи на простые и понятные кусочки. Например, написать большую книгу — довольно сложно, а ежедневно писать по 1000 слов — вполне осуществимая задача.
Оценить реалистичность цели. Во время декомпозиции становится понятно, насколько цель достижима и не нужно ли ее подкорректировать. Например, мы решили научиться виртуозно играть на классической гитаре за три месяца. Но если мы разделим эту цель на отдельные этапы, то увидим, что на ее достижение уйдет как минимум три года.
Составить план достижения цели. Все подзадачи, на которые мы дробим цель — это конкретные шаги по ее достижению. В результате вместо абстрактной мечты у нас появляется подробный план по воплощению этой мечты в реальность.
Оценить ресурсы. В процессе декомпозиции мы узнаем, какие нам понадобятся материалы и инструменты, сколько времени и денег уйдет на каждый этап и каких людей потребуется привлечь для работы.
На самом деле, декомпозиция — это неотъемлемая часть нашего мышления. Приступая к любому делу, мы автоматически пытаемся если и не разбить его на этапы, то хотя бы выделить из него первоочередное действие. А столкнувшись с каким-нибудь незнакомым объектом или явлением, мы всегда стараемся мысленно разделить его на какие-то составные части.
Другое дело, что в тайм-менеджменте декомпозиция применяется осознанно, а значит и более эффективно.
Основные принципы
Прежде чем углубляться в теорию, давайте немного поговорим об инструменте, которым мы будем пользоваться.
Для разделения целей и задач на подзадачи, мы с вами будем рисовать вот такую диаграмму:
Такая иерархическая структура называется деревом целей. С его помощью можно окинуть свой план одним взглядом, понять, чем его дополнить, и сразу найти его слабые места. Почти все приведенные в этой статье примеры декомпозиции будут представлять собой такие деревья.
В принципе для построения деревьев можно использовать любую программу для создания схем — Microsoft Visio или, например, бесплатный сервис draw.io. Древовидные структуры умеют создавать и некоторые современные органайзеры, например, LeaderTask.
Но удобнее всего рисовать такие деревья в виде ментальных карт. Для этого вам потребуются специальные программы для их создания: X-mind, MindNode, MindManager, бесплатная Freemind и т. д.
Итак, приступим. В общем виде декомпозиция выглядит так:
- Выбираем задачу или цель.
- Спрашиваем себя: какие шаги потребуется предпринять для ее осуществления? Записываем результат. У нас получаются цели (или задачи) 2-го порядка.
- Задаем к ним все тот же вопрос и снова записываем результат. Получаем цели 3-го порядка.
- Повторяем эту процедуру необходимое количество раз.
Уровень детализации зависит от ваших потребностей. Если вам, например, нужен план ежедневных действий, то остановиться можно на тех задачах, которые занимают от 15 минут до 2 часов.
В процессе декомпозиции важно соблюдать следующие правила:
1. Следить, чтобы записанных подзадач было достаточно для выполнения задачи верхнего уровня. Посмотрите на список подзадач и подумайте: если все это сделать, будет ли задача выполнена? Если нет, то каких-то подзадач явно не хватает.
2. Стараться не делить задачи более чем на 7 подзадач. По правилу Джорджа Миллера мы способны за один раз удержать в памяти 7±2 объекта, и если подзадач окажется больше, нам будет труднее воспринимать свои планы. В таких случаях можно разделить задачи на группы по какому-нибудь признаку:
Впрочем, последнее правило не является аксиомой: делайте так, как вам удобнее.
Способы декомпозиции
Универсального способа декомпозиции не существует: разные цели и задачи требуют разного подхода. Рассмотрим четыре самых популярных метода, которые могут использоваться как в чистом виде, так и в комбинации друг с другом.
1. Деление на этапы
Этот способ подойдет, если выполнение задачи или достижение цели можно представить как серию последовательных шагов. Например:
Но это очень простой случай: здесь вся работа состоит из одинаковых шагов. Давайте возьмем более сложную цель — «построить дом».
Для начала разделим процесс строительства на главные этапы. Например, на такие:
Теперь каждый из них нужно разделить на этапы поменьше. Для примера сделаем декомпозицию «Фундамента»:
Эти задачи можно детализировать более подробно. Например, для котлована: уложить песчано-щебневую подушку, смочить, утрамбовать и т. д.
Декомпозицию обычно продолжают до тех пор, пока не получатся задачи, которые можно органично вписать в ежедневный план. При необходимости запишите все инструменты, материалы и услуги в отдельный список, чтобы посчитать бухгалтерию проекта.
Полученные в результате декомпозиции этапы обычно равномерно распределяют по времени — дням, неделям и месяцам. Например:
Для планирования некоторых целей и задач удобнее использовать диаграмму Гантта.
Советы:
Не детализируйте этапы без необходимости (см. Метод набегающей волны). Часто нет нужды слишком уж забегать вперед: достаточно запланировать лишь первые шаги. Во-первых, до следующих этапов руки могут дойти очень нескоро. Например, пока вы не написали книгу, нет особого смысла думать о ее верстке или о выборе издательства. Во-вторых, в процессе работы вы можете получить новую информацию, которая заставит вас полностью пересмотреть свой подход к решению задачи.
Пометьте задачи, которые можно выполнить в любой момент. Это поможет вам рационально использовать свободное время или периоды вынужденного простоя. Например, многие материалы и инструменты для разных этапов строительства можно приобрести заранее.
Подумайте, можно ли запустить какие-то процессы параллельно основной работе. Например, внешнюю обделку дома можно совместить с работой электрика.
По возможности используйте SMART-критерии для формулировок. Не всегда это нужно, но часто полезно сделать все промежуточные цели и задачи максимально конкретными и измеримыми.
Если привязываете этапы к определенному времени, не планируйте «впритык». Всегда что-то может пойти не так, и тщательно расписанный план быстро развалится. Для таких непредвиденных случаев закладываете в свой график небольшой резерв времени. Если же все будет хорошо, вы сможете потратить сэкономленное время на выполнение следующих этапов.
2. Декомпозиция измеримых показателей
По сути, это просто разновидность предыдущего способа. Разница лишь в том, что этапами становятся не просто задачи, а некие числа. Такой подход уместен тогда, когда целью являются конкретные и измеримые показатели: уровень дохода, количество клиентов и т. д.
Давайте рассмотрим один нарочито простой пример.
Предположим, что каждое утро мы выполняем такое упражнение, как отжимания от пола. В настоящий момент мы делаем 4 подхода по 3 отжимания. Наша же цель — выполнять 4 подхода по 20 отжиманий, и на достижение этого показателя у нас есть 2 месяца.
Что ж, цель вполне осуществимая. Допустим, мы хотим ее достичь за 20 тренировок. Откроем Excel и запишем число занятий, начальный и конечный результат:
А теперь просто воспользуемся функцией автозаполнения:
У нас получился простой план тренировок на два месяца. По такому же принципу легко запланировать подтягивания, бег или различные упражнения с весом. Причем декомпозировать можно любые показатели: дистанцию, рабочий вес или скорость.
Увы, с некоторыми целями так просто не получится. Скажем, доходы, количество подписчиков паблика или число посетителей магазина не будут увеличиваться сами по себе. Здесь для каждого значения нужно составить список мер для достижения нужных показателей. Например:
Советы:
Подумайте, с какой прогрессией вы имеете дело — с арифметической или геометрической. Например, график работы над книгой (то есть число написанных слов по дням) может быть только арифметической прогрессией. А вот, скажем, число подписчиков канала YouTube в некоторых случаях может возрастать и в геометрической прогрессии.
Учитывайте форс-мажоры и непредвиденные трудности. Иногда удобно иметь сразу два графика: план максимум и план минимум.
3. Дерево зависимостей
Не все цели и задачи можно разложить на последовательные шаги. Иногда для достижения цели требуется комплекс мер, зачастую никак не связанных между собой. Такое обычно бывает, когда нам нужно что-то улучшить: увеличить доходы, усовершенствовать продукт, навести порядок в доме или заняться своим здоровьем.
Предположим, что наша цель — увеличить прибыль розничного магазина. Для начала нам необходимо понять, из чего она складывается и от чего зависит. Представьте, что вам нужно вывести формулу, в которой умножаются или складываются какие-то показатели и получается результат. Например, так:
Каждый из этих показателей можно опять же разложить на составляющие. Например:
Если детализировать дальше нет смысла, составьте список мер для улучшения каждого параметра. У вас должны получиться или конкретные задачи для органайзера, или пункты для чек-листа.
Часто подобные меры является лишь гипотезами, поскольку мы достоверно не знаем, какой эффект они окажут. Однако в совокупности они неизбежно повлияют на результат.
Советы:
Ранжируйте задачи. Обычно некоторые из них более эффективны для достижения цели, тогда как другие оказывают лишь незначительное влияние. Старайтесь выполнять задачи в порядке их предполагаемой эффективности.
Тестируйте гипотезы, прежде чем вкладывать в них большие ресурсы. Например, прежде чем рассылать коммерческое предложение по всей базе, проверьте его эффективность на небольшом количестве адресатов.
4. Одношаговая декомпозиция
У перечисленных выше способов есть две проблемы. Во-первых, планы, составленные после тщательной декомпозиции цели, легко могут рухнуть от какой-нибудь случайности. Во-вторых, иногда мы имеем очень смутное представление о том, как достичь цели, а потому вряд ли сможем детально все спланировать.
Чтобы двигаться к цели в условиях нестабильности или неопределенности используйте одношаговую декомпозицию. Алгоритм работает так:
1. Думаем над своей целью и вычленяем первоочередную задачу. Обычно это небольшие шаги, продолжительностью не более получаса.
2. Записываем задачу в органайзер.
3. Выполняем задачу.
4. Возвращаемся к пункту 1.
Такая незамысловатая техника будет работать, даже тогда, когда обстоятельства постоянно меняются. И даже если мы вдруг получим новую информацию, которая заставит нас кардинально пересмотреть свои методы, мы сможем безболезненно под нее перестроиться.
Да, при таком подходе нам каждый раз придется серьезно думать над первоочередным шагом, но в этом как раз и заключается преимущество этого метода.
Советы:
Убедитесь, что вы не забудете сделать следующий шаг по проекту. Сделайте проверку выполненных шагов регулярной задачей или добавьте соответствующий пункт в чек-лист ежедневного обзора.
- При таком подходе лучше фиксировать время, в рамках которого вы будете заниматься проектом. Например:
- Работа над сайтом — 3 часа в день
- Генеральная уборка — 1 час в день
- Навести порядок в скачанных файлах — 15 минут в день
Оформить это время можно в виде регулярной задачи.
Заключение
Мы рассмотрели лишь те способы декомпозиции целей и задач, которые чаще всего используются в личном тайм-менеджменте. На самом деле их значительно больше: в каждой сфере деятельности есть свои методы разделения целей на подзадачи.
Например, декомпозицию в компании можно провести по исполнителям, рыночным сегментам или по видам продукции. Особые способы декомпозиции применяются и в разработке программного обеспечения, например, по платформам или пользовательским сценариям. Если в вашей работе необходимо использовать именно такие методы, обратитесь к специальной литературе.
Вопросы
В каких случаях декомпозиция не нужна?
Во-первых, нет смысла делить на части заурядные задачи, которые мы легко выполним и без декомпозиции. Во-вторых, нет смысла что-то серьезно расписывать в условиях неопределенности или дефицита информации. В таких случаях достаточно запланировать только первый шаг.
Всегда ли декомпозиция полезна?
Нет, не всегда. В некоторых случаях она становится лишь очередным поводом для прокрастинации.
Например, человек решил заняться бегом. Но вместо того, чтобы просто начать бегать, он неделями выбирает себе спортивный костюм, кроссовки, составляет маршруты и подбирает подходящие треки для плеера.
В подобных ситуациях лучше отложить детальное планирование, определить первый шаг и начать действовать. Уже потом, если понадобится, можно внести в свои занятия какие-то улучшения.
Что делать, если я тщательно разделил цель на подзадачи, а план полностью сорвался? Например, из-за того, что я не предусмотрел какие-то важные нюансы?
Просто провести декомпозицию заново. В этом нет ничего страшного: корректировка планов — это нормальный рабочий процесс. Более того, полезно регулярно выполнять декомпозицию целей с чистого листа, с учетом полученного опыта и новых обстоятельств.
Что делать, если я распределил этапы по дням, но не уложился в сроки?
Если это единичный случай, просто сдвиньте сроки. Если такое повторяется постоянно, значит вы неверно оценили свои возможности или текущие обстоятельства. В этом случае пересмотрите свой план и выделите больше времени на прохождение этапов.
А что делать, если планы постоянно срываются?
В таких случаях лучше использовать одношаговую декомпозицию, то есть планировать лишь первоочередное действие.
Как разделить на подзадачи большую монотонную работу? Например, написание длинного текста, покраску забора, заполнение базы данных?
Такую работу удобнее делить не на подзадачи, а на различные временные отрезки. Воспользуйтесь, например, техникой Pomodoro.
Поделиться:
Что такое декомпозиция задач
Декомпозиция задач — это разделение более крупной (корневой) задачи на более мелкие, более управляемые элементы или подзадачи для работы с корневой задачей на самом низком возможном уровне и, следовательно, с большей простотой. Он создает иерархическую модель или структуру корневой задачи, которая включает в себя ряд подзадач. Он также описывает процедурные шаги для выполнения подзадач и определения содержания и уровней разбивки корневой задачи.
Декомпозиция задач может быть представлена как попытка сделать более широкие задачи более простыми и понятными посредством создания иерархий взаимозависимых подзадач.Декомпозиция задач состоит из двух основных этапов. Эти шаги:
- Моделирование . Моделирование задач обычно используется для декомпозиции задач и определения их содержания. Традиционная модель задачи выделяет иерархическую структуру корневой задачи и очерчивает отношения между этой задачей и ее подзадачами. Он описывает один или несколько возможных сценариев выполнения задачи.
- График . Создание блок-схем задач помогает получить графическое представление корневой задачи и ее подзадач.Блок-схема задач основана на связанных моделях задач и графически отображает разбивку задач.
Сыграть в демоверсию |
CentriQS -15% СКИДКА | VIP Task Manager |
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
| ||||||
Декомпозиция задач — обзор
9.2.1 Проектирование логической архитектуры
Логическая декомпозиция задач слияния данных является фундаментальным процессом при проектировании систем, направленных на объединение множественных и разнородных сигналов, собранных датчиками. В последние годы соответствующие исследования были сосредоточены на формализации логических моделей для слияния данных с нескольких датчиков, чтобы предложить соответствующую общую декомпозицию задач.Среди этих подходов мы можем процитировать модель Дасарати [12], которая классифицирует функции слияния данных с точки зрения типов входных и выходных данных / информации (например, данные, функции, объекты) и модель Omnibus [7], которая основана на Контур управления Бойда (т. Е. Наблюдение, ориентация, решение и действие), описывающий стратегию человеческого мышления. Хотя обе эти модели представляют интересный взгляд на логическую модель системы слияния данных, ниже будет более подробно описана модель Совместного директора лабораторий (JDL) [24].Эта модель подходит для данной презентации, поскольку она следует функциональному представлению процесса слияния данных, в котором описываются основные функции, база данных, в которой хранится информация, и связи между уровнями. С этой точки зрения легче определить подходящие методы и физические архитектуры для выполнения желаемого приложения.
В модели JDL выделено пять уровней обработки, которые представляют прогрессивные операции, выполняемые для обеспечения вывода на возрастающих уровнях абстракции.В этой структуре можно выделить связь между типом данных или выполняемой обработки и типом извлеченной информации. Исходя из необработанных данных датчика, в первую очередь необходимо сделать вывод о существовании объекта, основными характеристиками которого должны быть обнаружены положение и кинематические особенности. Затем данные используются для установления личности объекта, и с помощью временного и пространственного анализа можно определить поведение объекта. Принимая во внимание совместное поведение субъектов, оценивается текущая ситуация, а затем оценивается контекст развития ситуации.
В модели JDL эти задачи могут быть распределены по пяти уровням обработки, как показано на рисунке 9.1.
РИСУНОК 9.1. Модель процесса слияния данных JDL.
Уровень 0 — предварительная обработка источника : Перед тем, как процесс объединения данных может быть выполнен, необработанные данные предварительно обрабатываются. Примеры этой процедуры включают в себя обработку сигнала и изображения, пространственное и временное выравнивание и фильтрацию. Затем данные представляются в соответствующей форме другим модулям, синхронизируются и пространственно связаны.Пример пространственного выравнивания, используемого в мультимодальных системах слияния данных, показан в Kühnapfel et al. [37], где вычисляется функция калибровки для сопоставления координат 2D-видео стационарной камеры с углом прихода одномерного звука в линейной микрофонной решетке. В Marchesotti et al. [39] процедуры временного и пространственного выравнивания показаны для системы слежения, которая объединяет видео и радио (802.11 WLAN) сигналы мощности.
Уровень 1 — уточнение объекта : Предварительно обработанные данные объединяются для выполнения более надежной и точной оценки положения, скорости, атрибутов и характеристик объекта.На этом этапе применяются алгоритмы отслеживания и распознавания образов. Методы, которые объединяют видеоинформацию с данными, собранными другими датчиками (например, микрофонами, тепловизионными камерами), широко используются в приложениях слежения, чтобы справиться с проблемами окклюзии (т. Е. Наложения интересующих объектов в плоскости изображения) и ассоциации. целей между несколькими перекрывающимися и неперекрывающимися камерами. Например, в Cucchiara et al. [11] предлагается мультимодальная сенсорная сеть, в которой узлы датчиков PIR (пассивного инфракрасного), способные обнаруживать присутствие и направление движения людей на сцене, используются для повышения точности многокамерной системы слежения.
Уровень 2 — уточнение ситуации : Чтобы установить текущую ситуацию, отношения между объектами рассматриваются с использованием средств автоматизированного обоснования и искусственного интеллекта. Окружающий интеллект обычно использует несколько разнородных источников данных, чтобы понять поведение пользователя при предоставлении ему услуг. В Marchesotti et al. [38] авторы предложили вдохновленный биологией метод прогнозирования намерений в университетской лаборатории путем анализа положения, обнаруженного визуальным трекером, и объединения этой информации с параметрами (статус входа в систему, доступная пропускная способность сети, использование ЦП и т. Д.) по поводу загруженности ПК.
Уровень 3 — оценка воздействия : На этом этапе оценивается прогноз развития ситуации для определения потенциальных угроз и будущего воздействия. Как правило, автоматическое обоснование, искусственный интеллект, прогнозное моделирование и статистическая оценка используются для прогнозирования возможных рисков, убытков и соответствующих событий. В McCall et al. [41] показано автомобильное приложение, в котором информация, внутренняя (положение головы) и внешняя (положение полосы движения) по отношению к транспортному средству, объединяется с параметрами транспортного средства (скорость, угол поворота и т. Д.)), чтобы сделать вывод о намерении смены полосы движения при оценке воздействия действий водителя.
Уровень 4 — уточнение процесса : Этот уровень обработки необходим для повышения производительности системы путем анализа слияния данных и оптимизации использования ресурсов. Выполняется моделирование датчиков, вычисление показателей производительности и оптимизация ресурсов путем адаптации контура обратной связи других уровней параметров алгоритма. В Холле [23] показаны примеры автоматического регулирования параметров для мультисенсорных систем слежения.Подход основан на моделировании эталонной сцены, используемой для измерения качества выходных данных системы, чтобы применить стратегии адаптации параметров, когда снижение производительности является чрезмерным.
Уровень 5 — когнитивное совершенствование : Поскольку система обычно взаимодействует с людьми посредством человеко-компьютерных интерфейсов (HCI), когнитивные средства (см. [25]) должны рассматриваться для повышения эффективности предоставления информации или услуги пользователю. Например, в Rousseau et al.[50] предлагается общая структура с использованием мультимодальных интерфейсов для представления информации людям.
Уровень 6 — управление базой данных : Этот модуль необходим для эффективной обработки большого количества данных, используемых в процессе объединения данных. Это может быть очень сложной задачей, особенно в распределенных сенсорных сетях, где управление данными между узлами является тонким, а непредсказуемые задержки в сети могут затруднить запрос и передачу информации. Поэтому в литературе, посвященной этому вопросу, можно найти множество работ (например,g., [40]), где база данных (практически) полностью реплицируется на все узлы беспроводной сенсорной сети, делая работу базы данных независимой от сетевых задержек и разделения сети.
Что такое декомпозиция в управлении проектами?
Определение декомпозиции
Хотя это звучит так, будто вы не хотите, чтобы происходило при планировании проекта, декомпозиция может быть полезным инструментом при управлении проектами. Декомпозиция — это метод, используемый в управлении проектами, который разбивает рабочую нагрузку и задачи перед созданием иерархической структуры работ.Этот важный шаг может сэкономить время в долгосрочной перспективе.
Обзор процесса декомпозиции
Грубо говоря, процесс декомпозиции состоит из шести этапов. После того, как вы определили цели проекта, вам нужно будет собрать информацию, касающуюся результатов проекта и задач, которые уже были определены. Знание того, что нужно производить в качестве конечного продукта, и знание важных этапов помогут направить проект в правильном направлении.
После того, как информация о поставках и задачах собрана, при декомпозиции используется нисходящий подход к определению задач и подзадач. Менеджер проекта разбивает самые большие элементы (результаты, вехи, основные задачи) на самые мелкие задачи. Этот процесс может происходить в формате структурной декомпозиции работ или может быть выполнен в виде интеллект-карты и структурирован позже. Идея состоит в том, чтобы перейти от самых общих аспектов проекта к наиболее конкретным и подробным задачам в проекте.Например, если вы пишете техническое руководство, вы должны разбить его на мельчайшие компоненты — главы. Каждую главу можно разбить на исследования, план, черновик, редакцию, копию для печати.
После того, как проект разбит на самые маленькие задачи, можно создавать рабочие пакеты. Рабочий пакет — это набор связанных элементов действий, которые могут быть назначены ресурсу как подмножество всей работы, которая должна быть создана. Еще раз проверьте, чтобы проект был достаточно разбит на минимально возможные части.
Наконец, менеджер проекта организует рабочие пакеты в иерархическую структуру. Каждому пакету может быть присвоен определенный код. После завершения создания иерархической структуры работ рабочие пакеты назначаются ресурсам.
Если все сделано правильно, декомпозиция прояснит релевантность каждой задачи для общей картины проекта. В следующей статье этой серии рассматриваются преимущества декомпозиции проекта в управлении проектами.
Этот пост является частью серии: Decomposition Series
В этой серии статей исследуются аспекты декомпозиции в управлении проектами.
- Декомпозиция в управлении проектами
- Преимущества декомпозиции проекта
- Ручка и бумага для декомпозиции ваших проектов
- Использование декомпозиции в структурах декомпозиции работ
- Декомпозиция и оценка снизу вверх
- Программное обеспечение для декомпозиции и управления проектами
- Целенаправленная декомпозиция — что это?
- Декомпозиция и проект 2007
Функциональная декомпозиция
Что такое функциональная декомпозиция?
Функциональная декомпозиция — это метод анализа, который анализирует сложный процесс с целью изучения его отдельных элементов.Функция в этом контексте — это задача в более крупном процессе, посредством которого декомпозиция разбивает этот процесс на более мелкие, более простые для понимания единицы.
В бизнесе функциональная декомпозиция используется для облегчения понимания больших и сложных процессов и управления ими. Функциональная декомпозиция помогает решать проблемы и помогает в развитии бизнес-операций, компьютерного программирования, машинного обучения и множества других областей.
Ключевые выводы
- Функциональная декомпозиция разбивает большой сложный процесс на множество более мелких и простых единиц или задач, способствуя лучшему пониманию всего процесса.
- Диаграмма функциональной декомпозиции содержит всю функцию или проект вместе со всеми необходимыми подзадачами, необходимыми для его выполнения.
- Функциональная декомпозиция — это инструмент для решения проблем, используемый в нескольких контекстах, от бизнеса и промышленности до компьютерного программирования и искусственного интеллекта.
Общие сведения о функциональной декомпозиции
Функциональная декомпозиция берет свое начало в математике, где она относится к процессу анализа связей и отношений между всеми компонентами, которые создают функциональную взаимосвязь, чтобы исходная функция могла быть перекомпонована.По сути, функциональная декомпозиция требует чего-то сложного и упрощает его.
Кроме того, декомпозиция процесса или функции на более мелкие подфункции может помочь руководителям проектов определить, как отдельные функции или задачи помогают достичь общей цели проекта. И крупные, и малые предприятия используют функциональную декомпозицию в своем анализе проекта, чтобы определить, соответствует ли проект цели или есть более мелкие подфункции, которые задерживают процесс.
Диаграммы функциональной декомпозиции
Отдельные элементы процесса и их иерархические отношения друг с другом обычно отображаются на диаграмме, называемой диаграммой функциональной декомпозиции. Схема показана в формате сверху вниз, иллюстрируя процесс. Диаграмма функциональной декомпозиции содержит общую функцию или задачу, а также необходимые подфункции или задачи, необходимые для достижения общей цели.
Другие распространенные бизнес-методы для упрощения сложных проблем и процессов включают деревья решений, которые позволяют пользователям рассматривать несколько возможных путей решения проблемы, и блок-схемы, которые визуализируют временную последовательность процесса.
Приложения функциональной декомпозиции
Функциональная декомпозиция применяется в различных дисциплинах, таких как системная инженерия, архитектура программного обеспечения, теория баз данных, машинное обучение, представление знаний и обработка сигналов.
На практике функциональная декомпозиция используется инженерами для описания шагов, предпринимаемых при разбиении функции устройства, процесса или системы на ее основные компоненты. В результате анализа на диаграмме функциональной декомпозиции будут подробно описаны функции, задачи и подзадачи, а также то, как они работают вместе.Диаграмма может также адресовать любые проблемы, а также предлагать решения этих проблем.
Функциональная декомпозиция особенно важна в программировании. После создания диаграммы можно начинать кодирование, поскольку затем программист может сначала работать с самыми основными компонентами, а затем создавать приложение. Таким образом, функциональная декомпозиция помогает сфокусировать и упростить процесс программирования. Однако одним из недостатков является то, что функциональная декомпозиция может быть особенно трудоемкой и длительной.
Этапы функциональной декомпозиции
Процесс функциональной декомпозиции можно разбить на несколько этапов. Использование диаграммы функциональной декомпозиции является ключевым моментом на этом этапе.
- Найдите основную функцию : Какую основную задачу должно выполнять устройство или процесс?
- Перечислите основные подфункции : Эти подфункции или подзадачи способствуют успешному выполнению основной функции.
- Перечислить подфункции следующего уровня. : Эти подфункции обслуживают подфункции верхнего уровня.
- Проверьте диаграмму : Если есть функции, которые были пропущены, добавьте их на диаграмму.
границ | Декомпозиция задач: основа для сравнения различных моделей обучения в исследованиях пластичности человеческого мозга
Введение
Идея о том, что структура и функции человеческого мозга остаются в некоторой степени открытыми для изменений в результате опыта в течение жизни, в настоящее время хорошо обоснована (Wan and Schlaug, 2010; Zatorre et al., 2012), хотя исследователи еще не сформировали исчерпывающую точку зрения. о том, как и при каких условиях это происходит.
В этой статье мы сосредоточены на исследованиях пластичности, связанной с обучением, у людей, которые используют сложные навыки в качестве моделей, таких как жонглирование (например, Draganski et al., 2004; Boyke et al., 2008; Scholz et al. , 2009), гольф (например, Bezzola et al., 2011) или различные аспекты создания музыки (например, Lappe et al., 2008; Hyde et al., 2009). Работа с использованием таких навыков дополняет предыдущие и текущие исследования по более основным аспектам взаимоотношений между мозгом и поведением, таким как обучение простому заданию по касанию пальцем (например.г., Унгерлейдер и др., 2002).
Сложные задачи предлагают несколько преимуществ перед более простыми задачами в качестве моделей: они предполагают более экологически обоснованный опыт обучения; они предлагают возможность изучать высшие и общие аспекты обучения; они часто по своей сути интересны для субъектов, что дает преимущества, в частности, для лонгитюдных исследований в области мотивации и соблюдения; и, что наиболее важно, недавние данные свидетельствуют о том, что мультисенсорная и сенсомоторная природа таких задач особенно эффективна для индукции пластичности как в сенсорных, так и в ассоциативных областях коры головного мозга (Lappe et al., 2008; Paraskevopoulos et al., 2012).
Сложный характер задач также создает серьезные проблемы для сравнения и интеграции результатов в учебных исследованиях. Эти исследования обычно дают сложные результаты, включая изменения активности или структуры во многих различных областях мозга. Строго говоря, только прямое сравнение может продемонстрировать специфику пластических изменений. Однако они редко доступны; в большинстве обучающих исследований использовались либо контрольные группы без обучения, либо сравнение с базовым уровнем внутри предмета для оценки возможности развития или других неспецифических изменений.В недавнем обзоре 20 исследований структурных эффектов ряда когнитивных и мультисенсорных тренировочных парадигм, например, только три сравнивали интересующую задачу со второй задачей (Thomas and Baker, 2013). Поскольку прямых сравнений мало, выводы относительно специфичности эффектов задачи основываются на аргументах о значимости структуры мозга для очевидно связанных задач или на корреляционных доказательствах в форме отношений с изменением поведения. Как правило, это хорошо работает, когда результаты можно предсказать заранее, и действительно, исследования тренировок сообщают об изменениях в областях мозга (или других физиологических измерениях), которые, как известно из предыдущей работы, участвуют в связанных действиях (например,г., в слуховой и двигательной сферах для музыкального обучения; Hyde et al., 2009). Результаты, которые не предсказываются, например, из-за того, что отношения когнитивных систем более высокого порядка к обучению еще неизвестны, могут создавать более серьезные проблемы с интерпретацией. Это связано с несходством исследований, доступных для сравнения — исследования, использующие разные парадигмы, предлагают только очень слабую и сомнительную поддержку друг друга.
Помимо объяснения неожиданных результатов, разнообразие парадигм сложных задач мешает исследователям делать общие выводы о пластичности мозга на основе совокупных результатов.Как отмечает Эриксон (2012), «трудно добиться большей однородности в результатах такого разнородного набора исследований и основных целей». Есть основные вопросы о пластичности мозга, которые остаются нерешенными. Например, почему приобретение некоторых навыков приводит к увеличению показателей структуры или активности мозга (обычно интерпретируемых как усиление существующих возможностей или привлечение дополнительных механизмов), тогда как другие приводят к их снижению (обычно интерпретируемым как повышение эффективности и требующее меньше усилий по обработке)? Что определяет, будет ли навык перенесен на другое поведение или приведет ли он к очень специфическому поведенческому выигрышу? Будет сложно собрать воедино ответы из такой разнородной группы исследований.
В целом, сложные задачи проблематичны, потому что пространство их исследования обширно. Поскольку исследования нейровизуализации, подобные этим, требуют значительных ресурсов, особенно лонгитюдных исследований, которые позволяют нам напрямую проверять причинные гипотезы, систематическое изменение каждого аспекта парадигм обучения является непрактичным решением. Широкий и скудный охват потенциальных сложных задач, который уже представлен в литературе, затрагивает почти все когнитивные системы и в различных комбинациях.Даже когда в исследованиях якобы используются похожие задачи, они могут отличаться по десяткам потенциально важных параметров дизайна обучения, в том числе по используемому контрольному условию (т. Е. Отсутствие, между субъектами или внутри субъектов), размеру выборки, характеристикам популяции, продолжительности и интенсивности. обучения, и достигнутый уровень владения предметами. Одновременно быстрое развитие методов нейровизуализации и анализа еще больше снижает сопоставимость исследований.
Можно было бы спорить о возвращении к более простым парадигмам тренировки до тех пор, пока не будут более полно поняты основные механизмы пластичности, если бы не тот факт, что сейчас необходимо лучшее понимание пластичности, связанной с тренировкой сложных задач, и лежащих в ее основе механизмов.Важная мотивация, способствующая наблюдаемому увеличению количества исследований, исходит из многообещающих, но ранних попыток улучшить неврологическую реабилитацию после травмы или инсульта (Altenmüller et al., 2009), предотвратить снижение когнитивных функций в пожилом возрасте (Wan and Schlaug, 2010), а также развить слуховой аппарат. обучающие инструменты, которые нацелены на мозг для лечения расстройства обработки слуха (Musiek et al., 2002; Loo et al., 2010) и, возможно, для изменения способа оценки эффективности терапии и методов обучения (Erickson, 2012).
Мы должны найти новые способы интеграции знаний, полученных с помощью многих моделей. В оставшейся части статьи мы предлагаем один из таких подходов.
Структура для характеристики учебных задач
В профессиональной среде, в которой обучение персонала должно быть одновременно эффективным и действенным, разработчики учебных материалов усовершенствовали искусство обучения; т. е. подготовка слушателей с особыми навыками и знаниями. Вкратце, один из таких процессов проектирования обучения, известный как модель системного подхода Дика и Кэри (Dick et al., 2004) начинается с определения набора конкретных целей, называемых «производственными задачами» (ЦП). Затем используются блок-схемы, чтобы проиллюстрировать анализ сложных действий на более мелкие действия или функции. PO и разбивка задач служат в качестве ориентира, когда дизайнеры создают меры оценки, определяют соответствующую стратегию обучения, разрабатывают и выбирают учебные материалы и, наконец, оценивают эффективность обучения.
В то время как цель разработчиков учебных материалов — успешная и измеримая передача навыков и знаний, цели исследователей обычно заключаются либо в разработке парадигмы обучения, которая провоцирует изменения в определенной структуре или функции мозга, либо в лучшем понимании того, какие изменения могли произойти. вызвано существующей парадигмой обучения или естественным опытом обучения.В любом случае из учебного дизайна можно позаимствовать две идеи; использование ДО и анализ задач. Они полезны как при планировании исследований, так и при оценке существующих дизайнов на предмет сопоставимости.
Рабочие цели
ЗП состоит из описания поведения желаемого результата; обстоятельства, при которых должен быть достигнут результат, включая любое оборудование, инструкции, переменные среды, такие как состояние субъектов и наличие обратной связи или наставничества; и критерии, используемые для оценки успеваемости учащегося.Целесообразно создавать PO для обучающего исследования, потому что они помогают исследователям поддерживать согласованность между выполняемой задачей, инструкциями испытуемых и поведенческими переменными, а также рассмотреть возможность рассмотрения возможных альтернативных объяснений с помощью дополнительных средств контроля или мер. На рисунке 1A мы включаем некоторые предложения по написанию и использованию заказов на покупку.
РИСУНОК 1. Предлагаемые шаги и рекомендации по написанию целей производительности (A) и декомпозиции задачи (B) .
PO для некоторых обучающих исследований относительно просты и могут быть легко выведены из описания методов. Например, в недавнем исследовании (Landi et al., 2011) изучались структурные изменения, связанные с двигательной адаптацией. Заказ на поставку для этой задачи можно было бы записать следующим образом:
• Цель: Минимизировать среднее расстояние от цели до курсора за сеанс.
• Обстоятельства: Управление джойстиком с помощью большого и указательного пальцев правой руки для следования за движущейся целью при одновременном применении сложного возмущения.
• Критерии производительности: Расстояние между целью и курсором, усредненное для каждого блока и выраженное в процентах от базовой линии.
Извлечение PO из других учебных исследований, особенно тех, которые связаны с натуралистическим дизайном досуга, иногда менее прямолинейно, поскольку задачи не всегда подробно описаны. Это может быть связано с тем, что подробный отчет об очень популярной деятельности кажется ненужным, потому что обучение не находится под строгим контролем экспериментатора, или потому, что цель исследования может состоять только в том, чтобы показать, что какие-либо изменения были вызваны выполнением некоторой деятельности.
Тем не менее, в отчетах об исследованиях почти всегда делаются выводы о взаимосвязи между многими конкретными физиологическими данными и возможной когнитивной активностью, связанной с заданием. Детали того, как преподаются и изучаются сложные задачи в реальной жизни, могут иметь отношение к этой интерпретации. Например, начинающий скрипач, которого поощряют играть исключительно на слух, будет использовать другой набор когнитивных навыков, чем тот, кто учится путем чтения нот, что может объяснить различия в активности в зрительной и слуховой областях.Четкое определение предполагаемой направленности обучения на ранней стадии разработки исследования упрощает выявление дополнительных мер и средств контроля, которые могут иметь объяснительную ценность (например, вопросник после практики, чтобы лучше понять стратегию преподавателя).
Декомпозиция задач
Анализ задач имеет давнюю традицию в когнитивной психологии и бихевиоризме, где он применялся для разработки моделей поведенческих непредвиденных обстоятельств (например, Skinner, 1954), для создания вычислительных моделей (Newell and Simon, 1972), для анализа индивидуальных различий в рассуждениях ( Sternberg, 1977), а также для построения компьютерных моделей когнитивной архитектуры (Anderson et al., 2003, 2009; Qin et al., 2003).
В отличие от предыдущей работы, в которой целью было создание моделей поведения и познания, наша мотивация состоит в том, чтобы иметь возможность сравнивать результаты нейропластичности от многогранных задач и от исследователей, придерживающихся различных теоретических взглядов. Поэтому мы должны нацеливаться на уровень универсальности, который может быть связан с функциональными сетями и модулями, доступными для методов нейровизуализации, а не на более мелкомасштабный анализ, такой как конкретные мыслительные процессы. Мы также должны уделять приоритетное внимание изменениям, связанным с обучением, и мы должны стараться оставаться как можно более теоретически нейтральными, чтобы двум исследователям, изучающим сложные задачи, не нужно было сначала согласовывать когнитивные и механистические модели для каждого из многих компонентов задачи.
Мы предлагаем «декомпозицию задачи», при которой сложная задача разбивается на элементы, необходимые для достижения PO (предлагаемые шаги см. На Рисунке 1B). Чтобы облегчить согласие и ограничить внутренние теоретические предположения, мы предлагаем сформулировать элементы как потенциально измеримые поведения (например, держать в памяти последовательность заметок), а не как когнитивные конструкции (например, слуховую рабочую память). Выбор должен быть сделан в отношении общности элементов, например, разбивается ли движение руки на движения пальцев.Это будет зависеть от способности экспериментального плана разрешать более мелкие элементы, но при иерархическом моделировании элементы могут быть расширены или свернуты до разных уровней детализации для соответствия различным сравнительным целям. Общая таксономия поведенческих элементов может помочь в сравнении задач. Насколько нам известно, подходящей таксономии не существует, но можно легко заметить несколько повторяющихся элементов при работе с несколькими декомпозициями. Перечисление и стандартизация их формулировок были бы необходимым шагом для любого метаанализа.
Мы связываем элементы во времени, что просто и не требует многих когнитивных допущений. Элементы могут происходить последовательно или одновременно, а серия событий может происходить как дискретная единица или как цикл. Мы включили в качестве элементов поведения, обычно рассматриваемые как познание низшего, так и высшего порядка (например, визуальное наблюдение или оценка успеха действия). Могут быть также включены метакогнитивные элементы, такие как выбор различных стратегий, но это добавит уровня сложности, например, если один элемент оценки переключается между двумя возможными структурами.В первую очередь следует учитывать, является ли компонент очагом нейропластичности; то есть, вероятно, изменились с обучением таким образом, который можно было измерить.
Для некоторых задач выбор элементов и их расположение может привести к нескольким конкурирующим структурам, которые представляют нейрофизиологически значимые различия. В случае продольного исследования, в котором переходные эффекты наблюдаются в нескольких точках измерения (например, Taubert et al., 2010), различные структуры могут быть с пользой связаны с приобретением экспертных знаний.Различные структуры могут быть вызваны неверными предположениями или межличностными различиями; мы считаем, что даже в этих случаях было бы полезно задокументировать задачу в качестве основы для обсуждения — тогда проблемы могут быть решены эмпирически.
В следующем разделе мы проиллюстрируем, как можно использовать декомпозицию задачи для сравнения двух задач. В этой статье мы сосредоточены на задачах мультисенсорного обучения, но этот подход может быть применен и к более чисто когнитивному обучению (см., Например, обзоры Buschkuehl et al., 2012; Guida et al., 2012).
Пример использования декомпозиции задач
Используя этот подход, мы начинаем исследовать, как изменения концентрации серого вещества, измеренные с помощью морфометрии на основе вокселей, связаны с двумя обучающими задачами; зрительно-моторное отслеживание, описанное ранее (Landi et al., 2011), и 40 часов любительской игры в гольф как неконтролируемый досуг (Bezzola et al., 2011). Выводы, которые мы можем сделать из этого анализа, состоящего из двух задач, могут показаться тривиальными, поскольку сравнить два исследования без декомпозиции несложно.Однако наша цель здесь — предложить примеры диаграмм декомпозиции задач (TDD) и простую иллюстрацию принципа их использования для сравнения задач.
Мы подготовили возможную декомпозицию задач для каждого исследования (см. Рисунок 2) и выделили элементы, которые различаются между задачами (жирным шрифтом). Мы ожидаем найти аналогичные нейрофизиологические изменения в задачах, которые имеют общий компонент, и никаких изменений в этой области по сравнению с другими задачами, которые не имеют этого компонента или не подчеркивают адаптацию и обучение этого компонента.
РИСУНОК 2. Диаграммы декомпозиции задач для двух тренировочных парадигм, (A) задача слежения за зрительно-моторным механизмом, разработанная Landi et al. (2011), и (B) качели в гольф, которые, как мы предполагаем, были основной частью обучения игре в гольф (Bezzola et al., 2011). Подзадачи основного действия показаны прямоугольниками. Мы сгруппировали похожие элементы в классы для целей визуализации (восприятие — зеленый, мотор — синий, оценка / расчет ошибок — красный, память — желтый), хотя сами элементы, вероятно, будут более полезными для сравнения задач.Стрелки показывают зависимости между подзадачами, а толстые полосы указывают на одновременные действия. Полужирным шрифтом выделены компоненты, которые различаются между задачей зрительно-моторного отслеживания и ударом в гольф.
Задача зрительно-моторного слежения заключалась в том, чтобы минимизировать среднее расстояние от цели до курсора за сеанс, тогда как в практике игры в гольф требовалось выполнить удар в гольф, чтобы переместить мяч в целевое местоположение. TDD показывают частичное совпадение требований к задачам, связанным с планированием и выполнением двигательных функций.Этим можно объяснить сходные результаты изменений в моторных областях в спинном потоке, охватывающем первичную моторную кору (M1), противоположную (наиболее) тренированной руке, в обоих исследованиях. Напротив, расхождение задач в некоторых аспектах, в частности, зрительно-моторный контроль в двух и трех измерениях, действие руки и всего тела, включая баланс, а также тесная связь действия и результата по сравнению с интеграцией нескольких отдельных движений в более крупное. Последовательность действий, предполагающая большее планирование, может объяснить расхождение в результатах в лобных и теменных ассоциативных областях, поскольку было показано, что эти области связаны с планированием последовательностей действий и зрительно-моторной интеграцией (Andersen and Buneo, 2002; Molnar-Szakacs et al., 2006) и представление собственного тела в пространственных системах отсчета (Vallar et al., 1999) — элементы, которые являются важной частью гольфа, но не зрительно-моторным отслеживанием.
Такой анализ можно затем использовать для исследования объяснительных гипотез. Например, на основе предыдущего исследования функциональной магнитно-резонансной томографии (фМРТ) с использованием той же задачи (Della-Maggiore and McIntosh, 2005) Landi et al. (2011) ожидали изменений в сети, включающей M1, заднюю теменную кору (PPC) и мозжечок, но нашли только результат M1.Мозжечок и PPC функционально важны для исправления ошибок онлайн, но отсутствие структурных изменений может быть связано с схожестью задачи ручного отслеживания с повседневными задачами в этих отношениях. Более новые виды коррекции ошибок всего тела и мультисенсорных ошибок, необходимые для обучения ударам в гольф, могут стимулировать большую нейрофизиологическую адаптацию. Следующими шагами может быть сравнение этих результатов с результатами других ручных задач с этими требованиями по исправлению ошибок или их разработка.
Другие приложения и предостережения
Помимо выявления закономерностей требований к заданиям и нейрофизиологического эффекта в обучающих исследованиях, декомпозиция задач может использоваться и другими способами в исследованиях пластичности. Описание задач, используемых в исследованиях на людях и животных, может облегчить межполевые сравнения от систем до уровня схемы (например, Sagi et al., 2012). Гипотезы относительно причины расходящихся эмпирических результатов можно проверить, разработав задачи, в которых манипулируют только те подкомпоненты, которые, как предполагается, вызывают изменение.Также можно было бы начать с интересующей области мозга, определить общие характеристики или компоненты тренировок, которые приводят к улучшениям, и разработать реабилитационные задачи, акцентируя внимание на этих элементах.
У этого подхода есть несколько возможных ловушек: апостериорных моделей могут быть смещены в сторону компонентов задачи, которые имеют известные нейронные корреляты, соответствующие результатам исследования; пропуск важнейших компонентов задачи из-за недосмотра или предвзятости может привести к неправильному назначению результатов нейровизуализации компонентам задачи, включенным в модель; и поскольку большинство областей мозга участвуют во множестве различных когнитивных процессов, изменения в одной и той же области мозга могут быть вызваны разными компонентами задачи в зависимости от контекста.Эти проблемы параллельны задачам интерпретации данных нейровизуализации в целом (например, Vul et al., 2009; Simmons et al., 2011), и могут быть частично решены с помощью априорной настройки модели и осознания этих ограничений во время интерпретации.
Заключение
В быстро развивающейся области пластичности, связанной с обучением, интеграция результатов исследований будет иметь решающее значение. Для этого может быть полезен такой подход, как декомпозиция задачи, чтобы выделить соответствующие влияния требований задачи на нейропластичность и повысить информационную ценность и влияние каждого ресурсоемкого учебного исследования.Путем интеграции исследований мы сможем выявить конкретные и общие механизмы пластичности внутри и между модальностями, такими как двигательная, зрительная и слуховая системы, и улучшить наше понимание роли функций высшего порядка и ассоциативных областей в пластичности коры. . Мы утверждаем, что, если исследователи систематически рассматривают, какие подзадачи должны выполнять участники для достижения целей обучения, и сообщать о них в литературе наряду с другими аспектами дизайна своего исследования, это может превратить разнообразие учебных исследований в преимущество, а не в преимущество. препятствие, позволяя нам извлекать смысл из совокупных результатов и эффективно нацеливать будущие исследования.
Заявление о конфликте интересов
Авторы заявляют, что исследование проводилось при отсутствии каких-либо коммерческих или финансовых отношений, которые могут быть истолкованы как потенциальный конфликт интересов.
Благодарности
Мы хотели бы поблагодарить канадские институты исследований в области здравоохранения (стипендия Vanier Canada Graduate Scholarship; Эмили Б. Дж. Коффи) и Deutsche Forschungsgemeinschaft (HE6067 / 1-1 и 3-1; Sibylle C. Herholz).
Список литературы
Альтенмюллер, Э., Марко-Палларес, Дж., Мюнте, Т. Ф., и Шнайдер, С. (2009). Реорганизация нервной системы лежит в основе улучшения двигательной дисфункции, вызванной инсультом, с помощью музыкальной терапии. Ann. Акад. Sci. 1169, 395–405. DOI: 10.1111 / j.1749-6632.2009.04580.x
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Андерсон, Дж. Р., Андерсон, Дж. Ф., Феррис, Дж. Л., Финчем, Дж. М., и Юнг, К. Дж. (2009). Боковая нижняя префронтальная кора и передняя поясная кора задействованы на разных этапах решения проблем инсайта. Proc. Natl. Акад. Sci. США 106, 10799–10804. DOI: 10.1073 / pnas.0
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Андерсон, Дж. Р., Цинь, Ю., Сон, М. Х., Стенгер, В. А., и Картер, К. С. (2003). Модель обработки информации BOLD-ответа в задачах манипулирования символами. Психон. Бык. Ред. 10, 241–261. DOI: 10.3758 / BF03196490
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Бойк, Дж., Дримейер, Дж., Газер, К., Бучел, К., и Мэй, А. (2008). Изменения структуры мозга у пожилых людей, вызванные тренировкой. J. Neurosci. 28, 7031–7035. DOI: 10.1523 / JNEUROSCI.0742-08.2008
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Делла-Маджоре В. и Макинтош А. Р. (2005). Динамика изменений мозговой активности и функциональной связности, связанных с долговременной адаптацией к вращательной трансформации. J. Neurophysiol. 93, 2254–2262.DOI: 10.1152 / jn.00984.2004
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Дик В., Кэри Л. и Кэри Дж. О. (2004). Систематический дизайн инструкции . Бостон, Массачусетс: Аллин и Бэкон.
Драганский Б., Газер К., Буш В., Шуерер Г., Богдан У. и Мэй А. (2004). Нейропластичность: изменения серого вещества, вызванные тренировкой. Природа 427, 311–312. DOI: 10.1038 / 427311a
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Эриксон К.И. (2012). Доказательства структурной пластичности у людей: комментарий на Thomas and Baker (2012). Neuroimage 73, 237–238; обсуждение 265–267. DOI: 10.1016 / j.neuroimage.2012.07.003
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Гуида А., Гобет Ф., Тардье Х. и Николас С. (2012). Как фрагменты, долговременная рабочая память и шаблоны предлагают когнитивное объяснение данных нейровизуализации при приобретении опыта: двухэтапная структура. Brain Cogn. 79, 221–244. DOI: 10.1016 / j.bandc.2012.01.010
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Hyde, K. L., Lerch, J., Norton, A., Forgeard, M., Winner, E., Evans, A.C, et al. (2009). Музыкальное обучение формирует структурное развитие мозга. J. Neurosci. 29, 3019–3025. DOI: 10.1523 / JNEUROSCI.5118-08.2009
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Ланди, С. М., Багеар, Ф., и Делла-Маджоре, В. (2011).Одна неделя моторной адаптации вызывает структурные изменения в первичной моторной коре, которые предсказывают долговременную память через год. J. Neurosci. 31, 11808–11813. DOI: 10.1523 / JNEUROSCI.2253-11.2011
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Лаппе, К., Херхольц, С. К., Трейнор, Л. Дж., И Пантев, К. (2008). Корковая пластичность, вызванная краткосрочным одномодальным и мультимодальным музыкальным обучением. J. Neurosci. 28, 9632–9639. DOI: 10.1523 / JNEUROSCI.2254-08.2008
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Лоо, Дж. Х., Бамиу, Д. Э., Кэмпбелл, Н., и Люксон, Л. М. (2010). Компьютерное обучение слуха (CBAT): преимущества для детей с трудностями в обучении, связанными с речью и чтением. Dev. Med. Детский Neurol . 52, 708–717. DOI: 10.1111 / j.1469-8749.2010.03654.x
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Мольнар-Сакач, И., Каплан, Дж., Гринфилд, П.М., и Якобони, М. (2006). Наблюдение за сложной последовательностью действий: роль лобно-теменной зеркальной нейронной системы. Neuroimage 33, 923–935. DOI: 10.1016 / j.neuroimage.2006.07.035
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Musiek, F. E., Shinn, J., and Hare, C. (2002). Пластичность, слуховая тренировка и нарушения обработки слуха. Семин. Слышать. 23, 263–276. DOI: 10,1055 / с-2002-35862
CrossRef Полный текст
Ньюэлл, А., и Саймон, Х.А. (1972). Решение человеческих проблем . Энглвуд Клиффс, Нью-Джерси: Прентис-Холл.
Параскевопулос, Э., Кученбух, А., Херхольц, С. К., и Пантев, К. (2012). Доказательства индуцированной тренировкой пластичности в мультисенсорных структурах мозга: исследование MEG. PLoS ONE 7: e36534. DOI: 10.1371 / journal.pone.0036534
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Цинь, Ю., Сон, М. Х., Андерсон, Дж. Р., Стенгер, В. А., Фиссел, К., Гуд, А., и другие. (2003). Прогнозирование влияния практики на функцию фМРТ, зависящую от уровня оксигенации крови (жирный шрифт), в задаче символической манипуляции. Proc. Natl. Акад. Sci. США 100, 4951–4956. DOI: 10.1073 / pnas.0431053100
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Саги Ю., Тавор И., Хофштеттер С., Цур-Морёсеф С., Блюменфельд-Кацир Т. и Ассаф Ю. (2012). Быстрое обучение: новый взгляд на нейропластичность. Нейрон 73, 1195–1203.DOI: 10.1016 / j.neuron.2012.01.025
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Симмонс, Дж. П., Нельсон, Л. Д., и Симонсон, У. (2011). Ложноположительная психология: скрытая гибкость в сборе и анализе данных позволяет представить все как значимое. Psychol. Sci. 22, 1359–1366. DOI: 10.1177 / 0956797611417632
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Скиннер, Б. Ф. (1954). Наука обучения и искусство преподавания. Harv. Educ. Ред. 24, 86–97.
Штернберг Р. Дж. (1977). Составляющие процессы в рассуждении по аналогии. Psychol. Ред. 84, 353–378. DOI: 10.1037 / 0033-295X.84.4.353
CrossRef Полный текст
Тауберт, М., Драгански, Б., Анвандер, А., Мюллер, К., Хорстманн, А., Виллринджер, А., и др. (2010). Динамические свойства структуры человеческого мозга: связанные с обучением изменения в корковых областях и связанных волоконных связях. J. Neurosci. 30, 11670–11677.DOI: 10.1523 / JNEUROSCI.2567-10.2010
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Томас К. и Бейкер К. И. (2013). Обучение взрослого мозга новым трюкам: критический обзор доказательств структурной пластичности, зависящей от тренировок, у людей. Neuroimage 73, 225–236. DOI: 10.1016 / j.neuroimage.2012.03.069
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Валлар, Г., Лобель, Э., Галац, Г., Бертос, А., Пиццамиглио, Л., и Ле Бихан, Д. (1999). Лобно-теменная система для вычисления эгоцентрической пространственной системы координат у людей. Exp. Brain Res. 124, 281–286. DOI: 10.1007 / s002210050624
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Vul, E., Harris, C., Winkielman, P., and Pashler, H. (2009). Поразительно высокая корреляция в исследованиях фМРТ эмоций, личности и социального познания. Перспектива. Psychol. Sci. 4, 274–290. DOI: 10.1111 / j.1745-6924.2009.01125.x
CrossRef Полный текст
Заторре, Р. Дж., Филдс, Р. Д., и Йохансен-Берг, Х. (2012). Пластичность серым и белым: нейровизуализационные изменения в структуре мозга во время обучения. Нац. Neurosci. 15, 528–536. DOI: 10.1038 / nn.3045
Pubmed Реферат | Pubmed Полный текст | CrossRef Полный текст
Разложение на практике — Разложение — KS3 Computer Science Revision
Мы ежедневно выполняем множество задач, даже не задумываясь о них или не разбирая их, например, чистка зубов.
Пример 1: Чистка зубов
Чтобы разобраться в проблеме того, как чистить зубы, нам нужно рассмотреть:
- какую зубную щетку использовать
- как долго чистить
- как сильно нажимать на зубы
- какую зубную пасту использовать
Пример 2: Раскрытие преступления
Обычно только когда нас просят выполнить новую или более сложную задачу, мы начинаем обдумывать ее подробно — разложить задачу на части.
Представьте, что совершено преступление.Раскрытие преступления может быть очень сложной задачей, поскольку необходимо учитывать множество вещей.
Например, полицейский должен знать ответ на ряд более мелких проблем:
- какое преступление было совершено
- когда было совершено преступление
- где было совершено преступление
- какие доказательства
- были ли свидетели
- были ли подобные преступления в последнее время
Добавить комментарий