Декомпозиция целей и задач | Тайм-блог
Декомпозицией в тайм-менеджменте называют разделение целей или задач на отдельные небольшие шаги — подзадачи. Например, задача «навести порядок на кухне» делится на следующие этапы: убрать со стола, помыть посуду, протереть газовую плиту, подмести. А чтобы достичь цели «улучшить физическую форму» нужно заняться физкультурой, сесть на диету и отказаться от вредных привычек.
В этой статье мы выясним, для чего нужна декомпозиция целей и задач, познакомимся с ее основными принципами и узнаем, как ее выполнять.
Зачем нужна декомпозиция?
Декомпозиция очень часто используется в планировании, и это не случайно. Она помогает:
Облегчить выполнение задач. Крупные задачи часто кажутся непомерно сложными, что вызывает у нас приступы прокрастинации. Декомпозиция позволяет разложить такие «страшные» задачи на простые и понятные кусочки. Например, написать большую книгу — довольно сложно, а ежедневно писать по 1000 слов — вполне осуществимая задача.
Оценить реалистичность цели. Во время декомпозиции становится понятно, насколько цель достижима и не нужно ли ее подкорректировать. Например, мы решили научиться виртуозно играть на классической гитаре за три месяца. Но если мы разделим эту цель на отдельные этапы, то увидим, что на ее достижение уйдет как минимум три года.
Составить план достижения цели. Все подзадачи, на которые мы дробим цель — это конкретные шаги по ее достижению. В результате вместо абстрактной мечты у нас появляется подробный план по воплощению этой мечты в реальность.
Оценить ресурсы. В процессе декомпозиции мы узнаем, какие нам понадобятся материалы и инструменты, сколько времени и денег уйдет на каждый этап и каких людей потребуется привлечь для работы.
На самом деле, декомпозиция — это неотъемлемая часть нашего мышления. Приступая к любому делу, мы автоматически пытаемся если и не разбить его на этапы, то хотя бы выделить из него первоочередное действие. А столкнувшись с каким-нибудь незнакомым объектом или явлением, мы всегда стараемся мысленно разделить его на какие-то составные части.
Другое дело, что в тайм-менеджменте декомпозиция применяется осознанно, а значит и более эффективно.
Основные принципы
Прежде чем углубляться в теорию, давайте немного поговорим об инструменте, которым мы будем пользоваться.
Для разделения целей и задач на подзадачи, мы с вами будем рисовать вот такую диаграмму:
Такая иерархическая структура называется деревом целей. С его помощью можно окинуть свой план одним взглядом, понять, чем его дополнить, и сразу найти его слабые места. Почти все приведенные в этой статье примеры декомпозиции будут представлять собой такие деревья.
В принципе для построения деревьев можно использовать любую программу для создания схем — Microsoft Visio или, например, сервис draw.io. Древовидные структуры умеют создавать и некоторые современные органайзеры, например, LeaderTask.
Однако удобнее всего рисовать такие деревья в виде ментальной карты. Мы для этой цели будем пользоваться бесплатной программой X-mind.
Итак, приступим. В общем виде декомпозиция выглядит так:
- Выбираем задачу или цель.
- Спрашиваем себя: какие шаги потребуется предпринять для ее осуществления? Записываем результат. У нас получаются цели (или задачи) 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.
Поделиться:
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: методы приоритезации задач
Одним из самых важных факторов, влияющих на скорость разработки и успех запуска проекта, является правильная декомпозиция идеи продакт-менеджера в задачи для непосредственно программирования. Как правильно это делать? Взять сценарий работы новой фичи от продакта и сразу начать кодить? Сначала написать приёмочные тесты, а потом – код, который будет обеспечивать их прохождение? А, может, переложить всё на плечи разработчиков – и пусть они в ходе скрам-покера сами решают?
Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.
Почему это важно?
Необходимо помнить о том, что процесс разработки – это не только непосредственно сеанс написания кода. Когда мы говорим о разработке, я призываю смотреть на весь процесс целиком, начиная от постановки задачи и заканчивая стабильной работой фичи у наших пользователей. Если не брать в расчёт все этапы, которые предшествуют кодированию и следуют за ним, то очень легко можно попасть в ситуацию, когда все что-то делают, выполняют свои KPI, получают бонусы, а результат получается плачевный. Бизнес загибается, конкуренты «душат», но при этом все – молодцы.
Почему так происходит? Всё просто: человеческая психология заставляет людей смотреть на ситуации с точки зрения собственного комфорта. Разработчику не всегда хочется думать о том, что будет с кодом после его написания. Решил задачу – и хорошо. Его крайне редко это интересует (именно поэтому мы, айтишники, и работаем в этой отрасли – наша мотивация в основном держится на интересности задач), ведь в отношениях с людьми столько неопределённости. Гораздо более комфортно многие разработчики чувствуют себя, сидя за компьютером и сосредоточившись на решении своей собственной интересной задачи – блокчейнах с нейросетями – им совсем не хочется отвлекаться и думать о каких-то продакт-менеджерах, дедлайнах, пользователях, которые потом будут использовать их гениальное произведение (а то ещё и критиковать начнут!).
Это не плохо и не хорошо – мы ценим разработчиков именно за вдумчивое и грамотное решение технических задач. Но узкий взгляд на проблемы часто останавливает развитие. И речь о развитии не только конкретных людей, но и компании в целом. Ведь рост компании и совершенствование корпоративной культуры возможны только с ростом каждого сотрудника. Поэтому нам важно иногда вылезать из «кокона» и заставлять себя смотреть на проблемы шире, чтобы этот рост стимулировать.
И, разумеется, если такой важный этап, как декомпозиция, поручить человеку, который смотрит на всё исключительно с точки зрения собственного удобства, есть реальный риск огрести кучу проблем на последующих этапах: при слиянии результатов его работы с результатами других, при code review, при тестировании, выкладке в продакшн, и т. д.
Таким образом, определяя для себя, как правильно разбить ту или иную задачу, прикидывая, с чего следует начать и куда в итоге прийти, важно учитывать как можно больше факторов, а не смотреть на проблему только «со своей колокольни». Иногда для того чтобы всё работало быстрее и эффективнее на следующих этапах, приходится делать что-то сложнее и медленнее на том этапе, за который отвечаете вы.
Хороший пример – написание юнит-тестов. Зачем мне тратить своё драгоценное время на написание тестов, если у нас есть тестировщики, которые потом и так всё протестируют? А затем, что юнит-тесты необходимы не только для облегчения процесса кодинга – они нужны также и на последующих этапах. И нужны как воздух: с ними процесс интеграции и проверки регрессии ускоряется в десятки, сотни раз, на них базируется пирамида автоматизации. И это даже если не брать в расчёт ускорение вашей собственной работы: ведь «потрогав» код в каком-то месте, вам самому нужно убедиться в том, что вы ненароком что-нибудь не сломали. И один из самых быстрых способов это сделать – прогнать юнит-тесты.
Workflow
Многие команды, чтобы как-то формализовать отношения между участниками процесса, договариваются о правилах работы в коллективе: согласовывают стандарты кодирования, общий workflow в системе контроля версий, устанавливают расписание релизов и т. д.
Стоит ли говорить, что если изначально договориться о процессе, не принимая во внимание весь жизненный цикл фичи, то можно получить замедление и «грабли» в будущем? Особенно если учесть рост проекта и компании. О преждевременной оптимизации не забываем, но если есть процесс, который хорошо работает на разных масштабах, то почему бы его не использовать изначально?
Говоря о workflow разработки, многие, кто использует Git, сразу вспоминают (всуе) о некоем «стандартном git-flow», считая его идеальным, правильным, и часто внедряют его у себя. Даже на конференциях, где я выступал, рассказывая про workflow в Badoo, меня несколько раз спрашивали: «Зачем вы изобрели своё, почему не используете стандартный git-flow?» Давайте разбираться.
Во-первых, обычно, говоря про этот флоу, имеют в виду вот эту картинку. Я взял её из статьи Vincent Driessen “A successful Git branching model”, в которой описывается схема, довольно успешно работавшая на нескольких его проектах (было это в далёком 2010 году).
Сегодня некоторые крупные игроки на рынке хостинга кода вообще предлагают свой флоу, критикуя «стандартный git-flow» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.
Если же поискать на git-scm.com (хорошо бы вообще погуглить), то с удивлением можно обнаружить, что никакого рекомендованного (и уж тем более «стандартного») workflow не существует. Всё потому, что Git – это, по сути, фреймворк для систем хранения версий кода, и то, как вы организуете это самое хранение и совместную работу, зависит только от вас самих. Всегда нужно помнить о том, что, если какой-то флоу «взлетел» на каких-то проектах, это вовсе не означает, что вам он тоже полностью подойдёт.
Во-вторых, даже у нас в компании у разных команд разный флоу. Флоу разработки серверного кода на PHP, демонов на С/ С++ и Go, флоу мобильных команд – они разные. И пришли мы к этому не сразу: пробовали разные варианты, прежде чем остановиться на чём-то конкретном. К слову, отличается в этих командах не только workflow, но ещё и методологии тестирования, постановки задач, релизы и сам принцип доставки: то, что поставляется на ваши личные серверы и на компьютеры (смартфоны) конечных пользователей, не может разрабатываться одинаково по определению.
В-третьих, даже принятый workflow является скорее рекомендацией, чем непререкаемым правилом. Задачи у бизнеса бывают разные, и хорошо, если вам удалось выбрать процесс, покрывающий 95% случаев. Если же ваша текущая задача не вписывается в выбранный флоу, имеет смысл посмотреть на ситуацию с прагматической точки зрения: если правила мешают вам сделать эффективно, к чёрту такие правила! Но обязательно посоветуйтесь с вашим менеджером перед принятием окончательного решения – иначе может начаться бардак. Вы можете банально не учесть какие-то важные моменты, которые известны вашему руководителю. А, возможно, всё пойдёт как по маслу – и вы сумеете изменить существующие правила так, что это приведёт к прогрессу и станет залогом роста для всех.
Если всё так сложно, да ещё и флоу – это не догма, а всего лишь рекомендация, то почему бы не использовать одну ветку для всего: Master для Git или Trunk для SVN? Зачем усложнять?
Тем, кто смотрит на проблему однобоко, этот подход с одной веткой может показаться очень удобным. Зачем мучиться с какими-то ветками, париться со стабилизацией кода в них, если можно написать код, закоммитить (запушить) в общее хранилище – и радоваться жизни? И правда, если в команде работает не очень много человек, это может быть удобно, поскольку избавляет от необходимости слияния веток и организации веток для релиза. Однако данный подход имеет один очень существенный недостаток: код в общем хранилище может быть нестабильным. Вася, работающий над задачей №1, может легко сломать код других задач в общем хранилище, залив свои изменения; и пока он их не исправит/ не откатит, код выкладывать нельзя, даже если все остальные задачи готовы и работают.
Конечно, можно использовать теги в системе контроля версий и код-фриз, но очевидно, что подход с тегами мало отличается от подхода с ветками, как минимум потому что усложняет изначально простую схему. А уж код-фриз тем более не добавляет скорости работе, вынуждая всех участников останавливать разработку до стабилизации и выкладки релиза.
Так что первое правило хорошей декомпозиции задач звучит так: задачи нужно разбивать так, чтобы они попадали в общее хранилище в виде логически завершённых кусочков, которые работают сами по себе и не ломают логику вокруг себя.
Feature branches
При всём многообразии вариантов workflow у нас в компании у них есть общая черта – они все основаны на отдельных ветках для фич. Такая модель позволяет нам работать независимо на разных этапах, разрабатывать разные фичи, не мешая друг другу. А ещё мы можем тестировать их и сливать в общее хранилище, только убедившись, что они работают и ничего не ломают.
Но и такой подход имеет свои недостатки, основанные на самой природе фичебранчей. В конце концов, после изоляции результат вашей работы нужно будет слить в общее для всех место. На этом этапе можно огрести немало проблем, начиная от мерж-конфликтов и заканчивая очень длительным тестированием/ багфиксингом. Ведь отделяясь в свою ветку кода, вы изолируете не только общее хранилище от ваших изменений, но и ваш код – от изменений других разработчиков. В результате, когда приходит время слить свою задачу в общий код, даже если она проверена и работает, начинаются «танцы с бубном», потому что Вася и Петя в своих ветках затронули одни и те же строки кода в одних и тех же файлах – конфликт.
Современные системы хранения версий кода имеют кучу удобных инструментов, стратегий слияния и прочее. Но избежать конфликтов всё равно не удастся. И чем больше изменений, чем они витиеватее, тем сложнее и дольше эти конфликты разрешать.
Ещё опаснее конфликты, связанные с логикой кода, когда SCM сливает код без проблем (ведь по строкам в файлах конфликтов нет), но из-за изоляции разработки какие-то общие методы и функции в коде изменили своё поведение или вообще удалены из кода. В компилируемых языках проблема, как может показаться, стоит менее остро – компилятор валидирует код. Но ситуации, когда сигнатуры методов не поменялись, а логика изменилась, никто не отменял. Такие проблемы сложно обнаруживать, и они ещё более отдаляют счастливый релиз и заставляют перетестировать код много раз после каждого слияния. А когда разработчиков много, кода много, файлов много и конфликтов много, всё превращается в сущий ад, ибо пока мы исправляли код и перепроверяли его, основная версия кода уже ушла далеко вперёд, и надо всё повторять заново. Вы всё ещё не верите в юнит-тесты? Хе-хе-хе!
Чтобы этого избежать, многие стараются как можно чаще сливать результаты общей работы в свою ветку. Но даже соблюдение этого правила, если фичебранч будет достаточно большим, не поможет избежать проблем, как бы мы ни старались. Потому что чужие изменения вы к себе в код получаете, но ваши изменения при этом никто не видит. Соответственно, необходимо не только почаще заливать чужой код в свою ветку, но и свой код в общее хранилище – тоже.
Отсюда – второе правило хорошей декомпозиции: фичебранчи должны содержать как можно меньше изменений, чтобы как можно быстрее попадать в общий код.
Параллельная работа
Хорошо, но как же тогда работать в отдельных ветках, если несколько программистов трудятся над одной и той же задачей, разбитой на части? Или если им нужны изменения в общих для разных задач частях кода? И Петя, и Вася используют общий метод, который в рамках задачи Пети должен работать по одному сценарию, а в задаче Васи – по другому. Как им быть?
Тут многое зависит от вашего цикла релизов, потому что моментом завершения задачи мы считаем момент попадания её на продакшн. Ведь только этот момент гарантирует нам, что код стабилен и работает. Если не пришлось откатывать изменения с продакшна, конечно.
Если цикл релизов быстрый (несколько раз в день вы выкладываетесь на свои серверы), то вполне можно сделать фичи зависимыми друг от друга по стадиям готовности. В примере с Петей и Васей выше создаём не две задачи, а три. Соответственно, первая звучит как «меняем общий метод так, чтобы он работал в двух вариантах» (или заводим новый метод для Пети), а две другие задачи – это задачи Васи и Пети, которые могут начать работу после завершения первой задачи, не пересекаясь и не мешая друг другу.
Если же цикл релизов не позволяет вам выкладываться часто, то пример, описанный выше, будет непомерно дорогим удовольствием, ведь тогда Васе и Пете придётся ждать дни и недели (а в некоторых циклах разработки и года), пока они смогут начать работать над своими задачами.
В этом случае можно использовать промежуточную ветку, общую для нескольких разработчиков, но ещё недостаточно стабильную, чтобы быть выложенной на продакшн (Master или Trunk). В нашем флоу для мобильных приложений такая ветка называется Dev, на схеме Vincent Driessen она называется develop.
Важно иметь в виду, что любое изменение в коде, даже слияние веток, вливание общих веток в стабильный Master и т. д., обязательно должно быть протестировано (помните про конфликты по коду и логике, да?). Поэтому если вы пришли к выводу, что вам необходима общая ветка кода, то нужно быть готовым к ещё одному этапу тестирования – после момента слияния необходимо тестировать, как фича интегрируется с другим кодом, даже если она уже протестирована в отдельной ветке.
Тут вы можете заметить, что можно ведь тестировать только один раз – после слияния. Зачем тестировать до него, в отдельной ветке? Верно, можно. Но, если задача в ветке не работает или ломает логику, этот неработоспособный код попадёт в общее хранилище и мало того, что помешает коллегам работать над своими задачами, ломая какие-то участки продукта, так ещё и может подложить бомбу, если на неправильных изменениях кто-то решит базировать новую логику. А когда таких задач десятки, очень тяжело искать источник проблемы и чинить баги.
Также важно понимать, что, даже если мы используем промежуточную разработческую ветку кода, которая может быть не самой стабильной, задачи или их кусочки в ней должны быть более-менее завершёнными. Ведь нам необходимо в какой-то момент зарелизиться. А если в этой ветке код фич будет ломать друг друга, то выложиться мы не сможем – наш продукт работать не будет. Соответственно, протестировав интеграцию фич, нужно как можно скорее исправить баги. Иначе мы получим ситуацию, похожую на ту, когда используется одна ветка для всех.
Следовательно, у нас появляется третье правило хорошей декомпозиции: задачи должны разделяться так, чтобы их можно было разрабатывать и релизить параллельно.
Feature flags
Но как же быть в ситуации, когда новое изменение бизнес-логики – большое? Только на программирование такой задачи может уйти несколько дней (недель, месяцев). Не будем же мы сливать в общее хранилище недоделанные куски фич?
А вот и будем! В этом нет ничего страшного. Подход, который может быть применён в этой ситуации, – feature flags. Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.
Простым и понятным аналогом может быть, например, пункт в меню для новой страницы в приложении. Пока новая страница разрабатывается по кусочкам, пункт в меню не добавляется. Но как только мы всё закончили и собрали воедино, добавляем пункт меню. Так же и с фичефлагом: новую логику оборачиваем в условие включённости флага и меняем поведение кода в зависимости от него.
Последней задачей в процессе разработки новой большой фичи в этом случае будет задача «включить фичефлаг» (или «добавить пункт меню» в примере с новой страницей).
Единственное, что нужно иметь в виду, используя фичефлаги, – это увеличение времени тестирования фичи. Ведь продукт необходимо протестировать два раза: с включённым и выключенным фичефлагом. Сэкономить тут можно, но действовать следует крайне деликатно: например, тестировать только то состояние флага, которое выкладывается пользователю. Тогда в процессе разработки (и выкладки по частям) задачи её тестировать вообще не будут, а проведут тестирование только во время проверки последней задачи «включить фичефлаг». Но тут надо быть готовым к тому, что интеграция кусков фичи после включения флага может пройти с проблемами: могут обнаружиться баги, допущенные на ранних этапах, и в этом случае поиск источника проблемы и устранение ошибок могут дорого стоить.
Заключение
Итак, при декомпозиции задач важно помнить три простых правила:
- Задачи должны быть в виде логически завершённых кусочков кода.
- Эти кусочки кода должны быть маленькими и должны максимально быстро попадать в общий код.
- Эти кусочки должны разрабатываться параллельно и выкладываться независимо друг от друга.
Куда уж проще? Кстати, независимая выкладка, на мой взгляд, — самый важный критерий. Из него так или иначе проистекают остальные пункты.
Желаю удачи в разработке новых фич!
Декомпозиция задач: что это и зачем нужно
Приходит маркетолог интернет-магазина к разработчику с задачей:
- добавить на страницу товара счётчик, сколько раз его купили.
Для маркетолога это одна строчка текста. Он думает, что такую простую задачку можно сделать за 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: методы приоритезации задач
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: методы приоритезации задач
Вот притащили вам с охоты мамонта: выше вас ростом, упитанный и на вид пока несъедобный. Что делать?! Декомпозировать, конечно: лапы отдельно, шкуру отдельно. Но с чего начать? И когда хоть примерно будет готов ужин?
Если вам достался жирненький проект, вопросы примерно такие же — какой круг задач предстоит, и как их предварительно оценить. Декомпозиция — крутой способ разложить всё по полочкам и прикинуть объём работ, заложить резервы на трудные блоки и докопаться до неприятных задач со звездочкой. Как это сделать, мы уже рассказывали в одном из обучающих видео. А для любителей вдумчивого чтения мы преобразовали его в крутую статью.
Уровни декомпозиции
Казалось бы, проще простого: режем проект на большие части, эти части — ещё на части, а те части — снова на части. Но действительно ли всё так просто?!
1 уровень. Крупные блоки или компоненты
Это может быть блок с е-коммерсом, личный кабинет, мобильное приложение, супер-навороченная админка. В общем, любые блоки работ, которые могут быть как-то между собой связаны, но которые можно делать изолированно друг от друга.
2 уровень. Страницы сайта или экраны мобильного приложения
В случае с блоком «мобильное приложение», как на схеме выше, разбиваем его на экраны. Но как узнать, что вы учли все-все-все возможные экраны? Для проверки полноты берите в расчёт сценарии использования — это даст понимание, какие задачи юзеры будут решать в приложении (или на сайте) и каким примерно образом они это будут делать.
Пример
Для e-commerce основной сценарий — продавать, а путь пользователя в нём выглядит так: каталог → список товаров → карточка товара и так далее.
Есть соблазн написать в смете только сценарий использования и его оценку (скажем, сценарий покупки товара или сценарий заказа такси) — ну, ведь понятно же, что там внутри. Нет, непонятно, и есть большой риск потерять множество шагов, поскольку такие сценарии большие, и их крайне сложно адекватно оценить целиком.
Когда сценарий раскладывается на экраны, шансов ошибиться становится меньше. Но помните, что каждый сценарий стоит проверять на связанность — достаточно ли вам вот этих экранов, чтобы этот сценарий сбылся?
Пример
У нас есть маркетплейс — магазин, куда другие производители могут загружать свои товары. Сценарии, лежащие на поверхности: загрузка своих товаров (загрузка и описание, разделы каталога и вот это вот всё), покупка товара (шаги покупателя на пути к цели), обработка заказа (как будут распределяться деньги, как будет получать свою долю маркетплейс и так далее). Если всё это не расписать подробно, можно запросто упустить кучу нюансов.
Будет ещё легче, если вы выделите ключевые роли на проекте (пользователь, администратор интернет-магазина и т. д.), у каждой из которых есть свой сценарий, а у каждого сценария — свой набор экранов. И тогда проверить полноту экранов ещё проще — достаточно посмотреть, связан и выполняется ли сценарий конкретной роли по ним.
3 уровень. Содержание экранов
В общем случае у вас на экранах могут быть какие-то вкладки либо какие-то блоки — грубо, вложенные экраны. Например, страница корзины/оформления заказа — здесь всегда есть блок товаров со своим сценарием (добавить-убавить-очистить), а еще блоки доставки, оплаты, авторизации, бонусной системы и так далее. Бывают ситуации, когда эти блоки также разбивают на экраны по шагам. Зависит от решения, принятого по итогам аналитики — бывает, что удобнее их всё-таки «слить» воедино.
Задача менеджера, когда он добрался до такого экрана, — посмотреть, из чего тот состоит. Бывает, экран легко разбить на блоки, бывает — сложно. Яркий пример сложной разбивки — калькуляторы: по ним чаще всего неочевидно, что происходит и как процесс расчёта делить на шаги.
Когда вы добираетесь до третьего уровня, нужно быть супер-внимательными, потому что на странице могут появляться самые разные вещи. И важно понимать, откуда они там вообще берутся — от этого будут сильно зависеть ваши оценки.
Откуда эта хрень на странице?!
Итак, вы добрались до какого-то блока или страницы. Самое время задать себе вопрос «Откуда это на странице?!». Но проджекты, аналитики и аккаунт-менеджеры (и даже заказчики) вот тут часто-часто ленятся — «подумаем об этом потом».
Например, аналитик сказал: «это мы как-нибудь на коде решим», а потом на планинге сидят 4 умных человека, смотрят друг на друга и спрашивают: «кто это придумал, что это за маразм?!». Такая ситуация — явный признак, что где-то недоработали раньше. Бывает, конечно, что принятие какого-то решения действительно откладывается, но это должно быть осознанно и где-то зафиксировано.
Чем меньше вы понимаете в момент «Откуда это на странице!?», тем больше у вас должен быть зазор в смете. И когда к вам приходит клиент и говорит «а почему тут такой большой зазор?!», у вас должен быть готовый ответ — потому что вы не понимаете, как работает то, то и это (лучше — фиксированный перечень конкретных вопросов), и что эти вопросы вы будете выяснять вместе с ним позже.
Итак, какими могут быть варианты, откуда берутся данные на странице?
Вариант 1. Хардкод
Самый простой в реализации вариант ответа на наш вопрос — хардкод. Это значит, что программисты сели, прямо в коде зафигачили какую-то штуку, и теперь поменять ее могут только они. Самые частые блоки, с которыми так делают — логотипы компаний, иногда ссылки на соцсети, время от времени такое делают с меню (всё реже), телефонами (плохо!), декоративными элементами на верстке. Всё это — более-менее разумные моменты. Неразумно, это когда в код зашиваются, например, ВСЕ страницы или SEO-тексты блоками.
Вариант 2. Включаемая область
У включаемых областей есть специфика: во-первых, их можно случайно удалить. Во-вторых, если в них указываются даты мероприятий или цены на товары, это чревато путаницей, поскольку у этих областей нет связанности: если поменять дату или цену в одном месте, в другом она останется той же. Клиенты зачастую сразу говорят, что такого им не нужно — а значит, придётся продумывать, как менять цены, даты и прочие изменяемые поля автоматически и повсеместно.
Вариант 3. Из админки (из базы данных)
Итак, мы знаем, что какие-то данные выбираются из базы данных. Тогда нам нужно понимать, из какой сущности и из какого поля. Примеры сущностей в интернет-магазине: «товар», «раздел», «пользователь», «заказ» — то есть то, что состоит из каких-то полей. Поля — например, «цена».
Но достаточно ли нам будет понимать, из какой сущности и из какого поля выводятся данные? Не совсем. Когда выбираете какую-то информацию из базы, она может выводиться не в том виде, как она там хранится, а в несколько модифицированном.
Например, это формула
Когда информация хранится в базе, но ее нужно как-то определенным образом модифицировать, появляется понятие «формула». Одна из самых опасных вещей, которую менеджеры часто пропускают.
Когда вам аналитик говорит «ну там это как-то считается» — навострите ушки, впереди точно будет затык. Математики не понимают программистов и считают что, их формулу достаточно переписать и следом «просто» запрограммировать — делов-то. Но когда клиента начинаешь спрашивать о формуле, часто слышишь что-то вроде «ой, она у нас там в excel», или «механика пока непонятна», или вообще «ну скопируйте вон с того сайта».
Видите формулу — копайте глубже. У неё внутри есть коэффициенты — а откуда берутся эти коэффициенты? Добро пожаловать в новый виток расследования «Откуда эта хрень на странице!?».
Вот из-за этого о формулах никто не любит думать:)
Например, это файл
В зависимости от используемой технологии бывает, что часть данных хранится в файлах. Может показаться, что это какая-то сущность или поле сущности, но это всё-таки ФАЙЛ.
Очень часто файлы в самой базе данных не хранятся, чтобы не «раздувать» её. Из-за этого работа с ними организована иначе. В случае банального каталога товаров файлом может быть фотография у пользователя (userpic), описания, спецификации в pdf и всё такое прочее. Такие файлы находятся не совсем в базе, но при оценке важно понимать, что они есть.
С файлами ещё бывает история, что их нужно хранить на отдельных серверах, или в облаках S3, закачивая по специальному протоколу, но это уже нюансы масштабирования. На старте проекта, окупаемость которого непонятна, городить тут огород я не вижу смысла. Исключение — тяжелый видео-контент. Его лучше сразу писать в видеохостинги.
— Владимир Завертайлов, CEO & Founder
Как данные попадают в базу данных?
Обычно администратор или контент-менеджер садится и забивает данные ручками. Тогда здесь должен возникать вопрос, а хватит ли ему стандартных компонентов админки для этого. Для этого ПМ должен быть очень хорошо знаком с возможностями стандартной административной панели. А ещё с ними должен быть знаком аналитик и тестировщик (про кодера, понятно, молчим). В Сибирикс все QA-специалисты проходят базовый курс контент-менеджера, чтобы понимать, на что способна админка. Ну, а про то, что QA-спецы у нас обычно вырастают в проджект-менеджеров, мы уже как-то писали.
Пример
У вас на дизайне есть слайдер, где расставлены точки, по клику на которые открывается всплывашка, в которой есть фотография, описание и ссылка на куда-нибудь. Вопрос: как расставлять эти точки? Как вариант — координаты X и Y, но вряд ли контентщик будет счастлив от такого функционала. А значит, придётся что-то придумывать. И значит, в смету нужно это заложить.
Второй момент, который проджекты часто упускают, — права доступа и хватит ли их. А значит, это тоже нужно иметь ввиду и сразу перечислить потенциальные роли.
Вариант 4. Интеграция со сторонним ресурсом
Один из источников данных в базе — пользовательский контент. И здесь важно понимать, как он попадает в базу. На этом этапе часто теряется один из крупных сценариев: например, как пользователь вносит отзывы. У отзывов часто бывает рейтинг — штука с виду простая, но внутри она может быть довольно сложно организована. У чего больше рейтинг? Там, где поставили одну оценку в 10 баллов, или где 1000 оценок, но разных? Среднеарифметическое тут работает плохо. Но хитрые алгоритмы есть — привет, ещё один резерв в смете.
Если данные берутся всё-таки с внешнего источника, то без интеграции никак. Вариантов интеграции может быть несколько:
Парсинг
Парсинг — не самая приятная тема. Когда вам говорят «сходите за этими данными на сторонний ресурс и аккуратненько всё своруйте», заканчивается это чаще всего плохо. А когда еще этих ресурсов 10−15−20, — тогда вообще смерть. Потому что данные или структура на них, как правило, могут меняться, а вы об этом узнаете в самую последнюю очередь, когда всё уже отвалится.
Другая проблема — админы сайтов, с которым парсятся данные, не слишком счастливы, что эти данные кто-то «ворует», и будут всячески защищаться. А это приводит к «падению» парсинга и попаданию в черные списки. Вы попытаетесь с этим бороться добавлением каких-нибудь платных proxy — короче, целый квест. Есть особые сервисы для организации парсинга — например, Mozenda, Automation Anywhere, Beautiful Soup, WebHarvy или Content Grabber (полный список из 30 сервисов ищите тут).
API
Здесь имеется ввиду, что есть какой-то интеграционный протокол, либо файловый протокол, либо XML, либо шина данных (сервер очередей вроде RabbitMQ, ZerroMQ или Apache Kafka) — подробнее о разнице штатной интеграции и по API наш техдир рассказывает тут. С чем именно интегрировать и по какому протоколу, на этапе предварительной оценки не столь важно — важнее, есть ли для этого документация. А у неё обычно бывает два состояния:
- она есть — это когда можно в любой момент зайти и посмотреть на неё глазами, а внутри реально описаны методы;
- она «почти есть» — как правило, это говорит о том, что внутри ерунда, а вы будете подопытными обезьянками, на которых будут всё эту сырую штуку тестировать.
Хуже всего бывает, когда говорят «ну вы, программисты, между собой договоритесь и разберитесь сами как-нибудь». Если протокол не формализован и взаимной ответственности нет, критический путь проекта будет пролегать через интеграцию, и на ней он завалится. Или по крайней мере, здесь потратится куча времени на согласование с программистом заказчика его протокола и отладку.
Соответственно, если на проекте планируется интеграция с внешним сервисом, на неё нужно закладывать большие резервы. Лайфхак, если нужно интегрироваться, а протокола пока нет — делать MOCK-объекты. Это специальные заглушки для интеграционного протокола, которые можно быстро сделать. А как только будет реальный протокол — просто заменить их (но обязательно с перепроверкой).
Как все это «подружить»
Начинаем с крупных компонентов: первый, второй третий — можно расписать подробно. Следом важно примерно понять, какие есть пользователи (роли) и какие у них сценарии. Сами сценарии в смету лучше не прописывать. Дальше — идём по страницам. После — работаем с отдельными блоками, используя уже известную схему «Откуда эта хрень на странице?!».
Как только вы слышите слово «калькулятор» или «считается», напрягайтесь 🙂 Когда есть интеграция со сторонним сервисом — тоже. В остальном — ничего страшного, и всё довольно прозрачно 🙂
Когда это может не сработать
Если на проекте есть какая-то дремучая математика, и вы живете в мире, полном злых неожиданностей, то декомпозиция по экранам будет давать сбой. В общем случае она довольно хорошо показывает, что и как происходит на типовых проектах.
Успехов в декомпозиции и почаще заглядывайте к нам на YouTube-канал за новыми полезными видео для проджектов (и не только)!
Как разложить проект на задачи
Успешное планирование и управление проектами может быть достигнуто путем создания декомпозиции задач и подзадач. Каждый проект может быть представлен в виде ряда взаимосвязанных задач, которые подчинены и согласованы с целями и задачами проекта. Разложение проектов на более мелкие действия или задачи позволяет упростить планирование за счет оценки трудозатрат и отображения результатов проекта в древовидной структуре.
Декомпозиция проекта на задачи — это процесс, который начинается после утверждения проекта для планирования и дальнейшей разработки.Этот процесс направлен на создание иерархического представления проектной работы, которое включает в себя простые операции, задачи и подзадачи. Процесс состоит из следующих шагов:
- Определите проект, который будет разбит на более мелкие виды деятельности
- Определите цели и задачи этого проекта
- Укажите основные или стратегические задачи, которые достигают целей и задач проекта на высоком уровне
- Оцените эти задачи по сложности и выясните, есть ли необходимость использовать подпроекты вместо
- Организовать основные задачи в логической последовательности
- Установите приоритеты между задачами
- Свяжите цели основных задач друг с другом
- Определите ресурсы, необходимые для выполнения основных задач
- Разбейте каждую задачу на более мелкие действия или подзадачи.
- Выделите необходимые ресурсы для подзадач
- Организовать подзадачи в логические вехи для мониторинга состояния завершения
- Разработка блок-схемы задач, которая показывает все уровни разбивки проекта.
Решение для декомпозиции задач CentriQS CentriQS позволяет пользователям разбивать большие задачи на более мелкие подзадачи для создания структур разбивки работ. Декомпозиция задач в CentriQS — очень простой процесс. Пользователи могут добавлять задачи как подзадачи в родительскую задачу или просто перетаскивать их в родительскую задачу. Когда задача становится родительской для других задач, ее состояние и продолжительность изменяются автоматически в зависимости от ее подзадач. | |
% PDF-1.4 % 1 0 объектов > endobj 2 0 объектов > endobj 3 0 объектов > endobj 4 0 объектов > endobj 5 0 объектов > endobj 6 0 объектов > endobj 7 0 объектов > endobj 8 0 объектов > endobj 9 0 объектов > endobj 10 0 объектов > endobj 11 0 объектов > endobj 12 0 объектов > endobj 13 0 объектов > endobj 14 0 объектов > endobj 15 0 объектов > endobj 16 0 объектов > endobj 17 0 объектов > endobj 18 0 объектов > endobj 19 0 объектов > endobj 20 0 объектов > endobj 21 0 объектов > endobj 22 0 объекта > endobj 23 0 объектов > endobj 24 0 объектов > endobj 25 0 объектов > endobj 26 0 объектов > endobj 27 0 объектов > endobj 28 0 объектов > endobj 29 0 объектов > endobj 30 0 объектов > endobj 31 0 объектов > endobj 32 0 объектов > endobj 33 0 объектов > endobj 34 0 объектов > endobj 35 0 объектов > endobj 36 0 объектов > endobj 37 0 объектов > endobj 38 0 объектов > endobj 39 0 объектов > endobj 40 0 объектов > endobj 41 0 объектов > endobj 42 0 объектов > endobj 43 0 объектов > endobj 44 0 объектов > endobj 45 0 объектов > endobj 46 0 объектов > endobj 47 0 объектов > endobj 48 0 объектов > endobj 49 0 объектов > endobj 50 0 объектов > endobj 51 0 объектов > endobj 52 0 объектов > endobj 53 0 объектов > endobj 54 0 объектов > endobj 55 0 объектов > endobj 56 0 объектов > endobj 57 0 объектов > endobj 58 0 объектов > endobj 59 0 объектов > endobj 60 0 объектов > endobj 61 0 объектов > endobj 62 0 объекта > endobj 63 0 объектов > endobj 64 0 объектов > endobj 65 0 объектов > endobj 66 0 объектов > endobj 67 0 объектов > endobj 68 0 объектов > endobj 69 0 объектов > endobj 70 0 объектов > endobj 71 0 объектов > endobj 72 0 объекта > endobj 73 0 объектов > endobj 74 0 объектов > endobj 75 0 объектов > endobj 76 0 объектов > endobj 77 0 объектов > endobj 78 0 объектов > endobj 79 0 объектов > endobj 80 0 объектов > endobj 81 0 объектов > endobj 82 0 объекта > endobj 83 0 объектов > endobj 84 0 объекта > endobj 85 0 объектов > endobj 86 0 объектов > endobj 87 0 объектов > endobj 88 0 объектов > endobj 89 0 объектов > endobj 90 0 объектов > endobj 91 0 объектов > endobj 92 0 объекта > endobj 93 0 объекта > endobj 94 0 объекта > endobj 95 0 объектов > endobj 96 0 объектов > endobj 97 0 объектов > endobj 98 0 объектов > endobj 99 0 объектов > endobj 100 0 объектов > endobj 101 0 объектов > endobj 102 0 объекта > endobj 103 0 объекта > endobj 104 0 объекта > endobj 105 0 объектов > endobj 106 0 объектов > endobj 107 0 объектов > endobj 108 0 объектов > endobj 109 0 объектов > endobj 110 0 объектов > endobj 111 0 объектов > endobj 112 0 объектов > endobj 113 0 объектов > endobj 114 0 объектов > endobj 115 0 объектов > endobj 116 0 объектов > endobj 117 0 объектов > endobj 118 0 объектов > endobj 119 0 объектов > endobj 120 0 объектов > endobj 121 0 объектов > endobj 122 0 объекта > endobj 123 0 объекта > endobj 124 0 объекта > endobj 125 0 объектов > endobj 126 0 объектов > endobj 127 0 объектов > endobj 128 0 объектов > endobj 129 0 объектов > endobj 130 0 объектов > endobj 131 0 объектов > endobj 132 0 объекта > endobj 133 0 объектов > endobj 134 0 объекта > endobj 135 0 объектов > endobj 136 0 объектов > endobj 137 0 объектов > endobj 138 0 объектов > endobj 139 0 объектов > endobj 140 0 объектов > endobj 141 0 объектов > endobj 142 0 объектов > endobj 143 0 объектов > endobj 144 0 объекта > endobj 145 0 объектов > endobj 146 0 объектов > endobj 147 0 объектов > endobj 148 0 объектов > endobj 149 0 объектов > endobj 150 0 объектов > endobj 151 0 объектов > endobj 152 0 объектов > endobj 153 0 объектов > endobj 154 0 объектов > endobj 155 0 объектов > endobj 156 0 объектов > endobj 157 0 объектов > endobj 158 0 объектов > endobj 159 0 объектов > endobj 160 0 объектов > endobj 161 0 объектов > endobj 162 0 объектов > endobj 163 0 объектов > endobj 164 0 объектов > endobj 165 0 объектов > endobj 166 0 объектов > endobj 167 0 объектов > endobj 168 0 объектов > endobj 169 0 объектов > endobj 170 0 объектов > endobj 171 0 объектов > endobj 172 0 объектов > endobj 173 0 объектов > endobj 174 0 объектов > endobj 175 0 объектов > endobj 176 0 объектов > endobj 177 0 объектов > поток xMO0 @ h; FB6V% UUe, T 000
.Классическая декомпозиция
Классический метод разложения возник в 1920-х годах. Это относительно простая процедура, которая служит отправной точкой для большинства других методов разложения временных рядов. Существует две формы классического разложения: аддитивное разложение и мультипликативное разложение. Они описаны ниже для временного ряда с сезонным периодом \ (m \) (например, \ (m = 4 \) для квартальных данных, \ (m = 12 \) для месячных данных, \ (m = 7 \) для ежедневных данных данные с недельным рисунком).
При классическом разложении мы предполагаем, что сезонная составляющая постоянна от года к году. Для мультипликативной сезонности значения \ (m \), которые формируют сезонную составляющую, иногда называют «сезонными индексами».
Разложение присадок
- Шаг 1
- Если \ (m \) — четное число, вычислите компонент цикла тренда \ (\ hat {T} _t \), используя \ (2 \ times m \) — MA. Если \ (m \) — нечетное число, вычислите компонент цикла тренда \ (\ hat {T} _t \), используя \ (m \) — MA.
- Шаг 2
- Вычислите ряд с детрендами: \ (y_t — \ hat {T} _t \).
- Шаг 3
- Чтобы оценить сезонную составляющую для каждого сезона, просто усредните отклоненные значения для этого сезона. Например, для месячных данных сезонный компонент за март представляет собой среднее значение всех отклоненных значений за март в данных. Эти сезонные значения компонентов затем корректируются, чтобы обеспечить их добавление к нулю. Сезонная составляющая получается путем объединения этих месячных значений и последующей репликации последовательности для каждого года данных.Это дает \ (\ hat {S} _t \).
- Шаг 4
- Компонент остатка рассчитывается путем вычитания оцененных компонентов сезонного и трендового цикла: \ (\ hat {R} _t = y_t — \ hat {T} _t — \ hat {S} _t \).
Мультипликативное разложение
Классическое мультипликативное разложение аналогично, за исключением того, что вычитания заменяются делениями.
- Шаг 1
- Если \ (m \) — четное число, вычислите компонент цикла тренда \ (\ hat {T} _t \), используя \ (2 \ times m \) — MA.Если \ (m \) — нечетное число, вычислите компонент цикла тренда \ (\ hat {T} _t \), используя \ (m \) — MA.
- Шаг 2
- Вычислите ряд с детрендами: \ (y_t / \ hat {T} _t \).
- Шаг 3
- Чтобы оценить сезонную составляющую для каждого сезона, просто усредните отклоненные значения для этого сезона. Например, для месячных данных сезонный индекс за март — это среднее значение всех отклоненных значений за март в данных. Эти сезонные индексы затем корректируются, чтобы обеспечить их добавление к \ (m \).Сезонная составляющая получается путем объединения этих месячных индексов и последующей репликации последовательности для каждого года данных. Это дает \ (\ hat {S} _t \).
- Шаг 4
- Компонент остатка рассчитывается путем деления предполагаемых компонентов сезонного и трендового цикла: \ (\ hat {R} _ {t} = y_t / (\ hat {T} _t \ hat {S} _t) \).
На рисунке 6.8 показана классическая декомпозиция индекса электрооборудования. Сравните это разложение с показанным на рисунке 6.1. Прогон значений остатка ниже 1 в 2009 году предполагает, что имеется некоторая «утечка» компонента цикла тренда в компонент остатка. Оценка цикла тренда чрезмерно сглаживала падение данных, и соответствующие значения остатков были затронуты плохой оценкой цикла тренда.
Рисунок 6.8: Классическая мультипликативная декомпозиция индекса новых заказов на электрооборудование.
,Страница не найдена
К сожалению, страница, которую вы искали на веб-сайте AAAI, не находится по адресу, по которому вы щелкнули или ввели:
https://aaai.org/papers/aaai/1994/aaai94-172.pdf
Если указанный выше URL заканчивается на «.html», попробуйте заменить «.html:» на «.php» и посмотрите, решит ли это проблему.
Если вы ищете конкретную тему, попробуйте следующие ссылки или введите тему в поле поиска на этой странице:
- Выберите темы AI, чтобы узнать больше об искусственном интеллекте.
- Чтобы присоединиться или узнать больше о членстве AAAI, выберите Членство.
- Выберите «Публикации», чтобы узнать больше о AAAI Press и журналах AAAI.
- Для аннотаций (а иногда и для полного текста) технических документов AI выберите Библиотека .
- Выберите AI Magazine, чтобы узнать больше о флагманской публикации AAAI.
- Чтобы узнать больше о конференциях и собраниях AAAI, выберите Conferences
- Для ссылок на Симпозиумы AAAI выберите Симпозиумы.
- Для получения информации об организации AAAI, включая ее должностных лиц и сотрудников, выберите Организация.
Пожалуйста, помогите исправить страницу, которая вызывает проблему
Веб-страница
, который направил вас сюда, должен быть обновлен, чтобы он больше не указывал на эту страницу. Вы поможете нам уничтожить старые ссылки? Пожалуйста, напишите веб-мастеру ссылающейся страницы или используйте их форму для сообщения о неработающих ссылках. Это может не помочь вам найти страницу, которую вы ищете, но, по крайней мере, вы можете избавить других людей от проблем. Большинство поисковых систем и каталогов имеют простой способ сообщить о неработающих ссылках.
Если это представляется целесообразным, мы будем признательны, если вы обратитесь к веб-мастеру AAAI с указанием того, как вы сюда попали (то есть URL-адрес искомой страницы и ссылочный URL-адрес, если он доступен). Спасибо!
Содержание сайта
Основные разделы этого сайта (и некоторые популярные страницы) доступны по ссылкам на этой странице. Если вы хотите узнать больше об искусственном интеллекте, вы должны посетить страницу AI Темы. Чтобы присоединиться или узнать больше о членстве AAAI, выберите Членство.Выберите Публикации, чтобы узнать больше о AAAI Press, журнале AI, и журналах AAAI. Чтобы получить доступ к цифровой библиотеке AAAI, содержащей более 10 000 технических документов AI, выберите «Библиотека». Выберите «Награды», чтобы узнать больше о программах наград и наград AAAI. Чтобы узнать больше о конференциях и собраниях AAAI, выберите «Собрания». Для ссылок на программные документы, президентские адреса и внешние ресурсы AI выберите Ресурсы. Для получения информации об организации AAAI, включая ее должностных лиц и сотрудников, выберите «О нас» (также «Организация»).Окно поиска, поддерживаемое Google, будет возвращать результаты, ограниченные сайтом AAAI.
,