Всем привет! Меня зовут Виктор, я системный аналитик компании Спортмастер.
И сегодня я хотел бы поговорить о декомпозиции задач и передаче их в разработку.
Любой объект состоит из частей, будь то автомобиль или программный продукт. И чтобы собрать любой из этих объектов в единое целое из составных частей, потребуется время.
Иногда это даже занимает много времени.
Особенно если до этого вы не просто разобрали основную часть, а решили докопаться до сути на атомном уровне.
Где грань между адекватной постановкой задач и полным хаосом? Поделюсь примером, как мы в «Спортмастере» периодически получаем задания на разработку от бизнеса.
Как видно из приведенных примеров, описание каждой задачи во многом зависит от фантазии и здравого смысла заказчика.
Где-то больше, где-то меньше, но аналитикам нужно как-то с этим работать.
Иногда еще указывают границы функционала, а иногда просто присылают тему.
Если передать такую задачу непосредственно в разработку, на выходе будет что-то непонятное.
Что ты должен делать? Подойдите к заказчику ногами и расспросите все требования, уточните, что именно должно быть на выходе.
Правда, есть и золотые заказчики, которых, по сути, большинство — они пишут все требования в Confluence, так что можно в любой момент пойти спокойно почитать и задать вопросы.
И когда с объемом фичи все понятно, можно приступать к нарезке задачи.
Зачем нужна декомпозиция
Основная цель декомпозиции — чтобы бизнес мог быстро реализовать все свои пожелания, и чтобы от самой идеи до появления функционала для пользователя проходило как можно меньше времени.Для этого можно выполнять более мелкие задачи, от которых до пользователя дойдёт хоть и небольшой, но всё же работающий функционал.
Помимо достижения глобальной цели удовлетворения потребностей пользователя и бизнеса, декомпозиция задач позволяет быстрее получать обратную связь от заказчика о том, в правильном ли направлении идет разработка или результат совсем не такой, как хотелось бы.
клиент представил.
Если задача изначально большая и мы беремся за нее целиком сразу, то мы потратим на нее много времени и после замечаний заказчика нам придется все выбросить.
Ну а если задача небольшая, день-два работы максимум, то ничего страшного.
Переделка займет примерно столько же времени.
Второй подход также будет дешевле.
Не говоря уже о сэкономленных нервах с обеих сторон.
Если один функционал разбит на несколько частей, разработчики могут работать над ними параллельно.
Таким образом мы распараллелим поток и ускорим вывод функционала в продакшен.
Важно то, что задачи должны как можно меньше зависеть друг от друга.
Плюс быстрое тестирование и исправление ошибок.
Опять же, небольшой функционал тестировать гораздо проще и быстрее, чем чудовищную махину.
А если что-то пойдет не так, разработчик потратит совсем немного, чтобы это «исправить», и все заработает быстрее.
На этапе дробления задач вместе с заказчиком можно сразу понять, какой функционал важен именно здесь и сейчас, чтобы начать получать прибыль, что можно оставить на потом, а что, возможно, отвалится на его месте.
свое за ненадобностью.
Бизнесу важно знать, как быстро появится работающий функционал.
А разбивая его на задачи, мы можем предсказать и более точно оценить время, которое потребуется на их реализацию, чем когда у вас один большой фронт работ. Но помимо того, что небольшие задачи легче оценить по времени на их выполнение, разработчику также легче оценить риски, которые могут возникнуть в процессе работы.
Например, обновились фреймворки, были выведены из строя некоторые методы, проблемы с кодом и т. д. Беря на себя небольшие задачи, мы минимизируем все эти риски, и даже если такая задача что-то блокирует в потоке, этого не будет. так критично, как если бы это был здоровенный кусок (который все заблокировал бы).
При необходимости можно будет сделать работающее решение и поставить технический долг в бэклог, с которым можно будет разобраться чуть позже, когда проблемы будут решены.
Основные подходы и правила декомпозиции
Существует два основных подхода к декомпозиции задач: горизонтальный и вертикальный.В горизонтальном режиме задачи делятся по типу работы, по уровням или по компонентам.
Например, у нас каждая задача проходит несколько этапов: фронтенд, бэкенд, база данных.
А при горизонтальном подходе одна задача уходит на задний план, вторая на передний план, а третья приводит к изменениям в базе данных.
Что не так с этим подходом? Мы не получаем рабочий функционал после выполнения каждой отдельной задачи.
Только собрав результаты из трех источников, мы можем получить какой-то результат и обратную связь по нему.
По этой причине горизонтальная декомпозиция чаще всего не используется.
Гораздо удобнее вертикальный подход, при котором каждая задача может быть визуально функциональной — задача проходит все этапы и на выходе получается результат, который можно проанализировать, протестировать, показать заказчику и при необходимости скорректировать.
И быстро ввести его в эксплуатацию и пользоваться.
Если говорить о правилах, то здесь я выделил только три.
Во-первых, задача должна быть логически завершена, то есть независима сама по себе.
Он не должен ломать вокруг себя логику и обязательно должен нести хоть какой-то деловой смысл, который пользователь получит в результате.
При этом не следует разбивать на части те задачи, которые не имеют бизнес-смысла (в идеале их вообще не должно существовать).
Во-вторых, результат выполнения одной небольшой задачи должен иметь небольшое значение.
Чем меньше изменений, тем быстрее они попадают в общий код и тем самым код не устаревает. Кроме того, небольшие задачи помогают избежать конфликтов между разработчиками во время слияния.
В-третьих, не следует разбивать проблему на очень микроскопические части.
Если разбить его на слишком мелкие детали, на решение этих задач уйдет много времени.
На каждом этапе им, возможно, придется изменить приоритеты, восстановить связи зависимостей, и все.
Таким образом, скорость разработки не увеличится, а, наоборот, резко снизится.
Поэтому нужно искать золотую середину.
Методы разложения
В зависимости от источника количество способов декомпозиции сильно варьируется: где-то указано всего восемь, где-то десять, где-то двадцать.Хотелось бы остановиться на методах, которые мне приходится использовать каждый день в работе.
Множественные потребности
Этот метод удобнее всего использовать, когда в рассказе присутствуют союзы «и» и «или».Например, потребитель хочет оформить заказ и оплатить его картой или бонусами.
Эту задачу можно разделить на три: первая, в которой пользователь делает заказ, вторая, где он оплачивает его картой, и третья, где используются бонусы.
Случаи использования
Другой распространенный метод — разделение задач в зависимости от варианта использования.В этом случае одна история состоит из одного основного пути и нескольких альтернативных.
Допустим, пользователь хочет купить продукт, и это будет основной сценарий.
Но есть и альтернативные способы – он может сразу положить товар в корзину и оплатить, а может захотеть сравнить этот товар с другими перед покупкой.
И тогда сравнение продуктов выносим в отдельную задачу.
Возможно, он хочет не покупать прямо сейчас, а отложить куда-нибудь в сторону, добавить в избранное и вернуться к нему позже.
Или пользователю понравился товар и он готов его купить, но его нет в наличии.
Это значит, что нам нужно сообщить ему, когда товар появится.
И таким образом мы получаем четыре сценария.
От простого к сложному
Главная страница сайта «Спортмастер» состоит из баннеров.И самое простое, что мы можем сделать, — это взять одну картинку и показать ее пользователю.
Это самый простой и быстрый способ донести необходимую информацию.
Тогда мы сможем расширить функционал и добавить не одну картинку, а три-четыре, которые объединяются в сетку.
Это отдельная задача.
При таком подходе функционал должен расти с каждой последующей задачей.
Мы можем, например, сделать карусель из сетки, а затем добавить ссылки, тексты, кнопки и все остальное.
В общем, сначала реализуем самый простой и быстрый вариант, а потом переходим к более сложному.
Совсем недавно я работал над аналогичной задачей по реализации баннера.
Баннер должен был висеть на главной странице и управляться из CMS. Если спросить клиента, чем именно он хотел бы управлять, он с радостью, не моргнув глазом, ответит – всем.
Поэтому здесь важно было немного углубиться в тему и выделить, чем нужно управлять прямо сейчас, что просто часто, а что практически не используется вообще.
И таким образом расставить приоритеты реализации и разделить ее на задачи.
Операции (CRUD)
Вероятно, это самый распространенный метод разложения.Здесь задачи разделены на операции Создание, Чтение, Обновление и Удаление.
Он подойдет для задач, где нужно чем-то управлять или настраивать.
Например, задача оформления заказа разбита на четыре более мелкие: создание заказа, его просмотр, редактирование и удаление.
Опции интерфейса
Используется, когда необходимо поддерживать несколько вариантов интерфейса.Например, сайт должен поддерживать несколько языков.
Сначала делаем русскую версию.
Потом при запуске в других странах добавляем английский.
Если в стране используется другой язык, кроме английского, мы также можем добавить его.
В этом случае проще сначала сделать все на одном языке, а потом постепенно добавлять переводы.
Совсем недавно мы завершили проект личного кабинета для юридических лиц, которому требовалась мультиязычная поддержка.
Сроки были сжатые, поэтому изначально мы делали все на одном языке, но заложили основу для дальнейшего перевода.
Теперь добавление поддержки нового языка — это всего лишь одна небольшая задача.
Если вам нужно добавить сразу несколько языков, для каждого из них создается отдельная задача.
Разделение по ролям
Подходит для ситуаций, в которых функционал предполагает работу нескольких ролей и групп пользователей.На сайте «Спортмастер» пользователь может иметь разные роли.
Например, пользователи делятся по ролям на авторизованного пользователя, анонимного пользователя и, скажем, пользователя колл-центра.
Последнюю роль также можно разделить на две – это может быть как обычный пользователь, так и администратор.
Мы можем создать отдельную задачу для каждой роли.
Начните с отображения для анонимного пользователя, а затем добавьте некоторые расширенные функции в рамках задачи для авторизованного пользователя.
И не забывайте о технических ролях операторов колл-центра и функционале для них.
Обработка ошибок
Если сроки сжаты и минимальный функционал нужен как можно быстрее, обработку ошибок можно вынести в отдельную задачу.Здесь речь идет не о написании тестов, а об обработке ошибок пользователей и систем, с которыми интегрирован сайт. Представим, что мы обрабатываем страницу каталога, содержащую плитку с товарами.
Каждая карточка имеет описание, фото и дополнительную информацию.
Так получилось, что некоторая часть информации не поступает из баз данных.
Возможно, если речь идет о бренде или материале, то этим можно пренебречь и просто не показывать информацию.
Но если вы не знаете ни цены, ни названия, стоит ли показывать эту карту? Что делать в такой ситуации? Этот вопрос можно вынести в отдельную задачу и потом обрабатывать каждое отдельное поле.
То есть если цена не пришла, то совершаем одно действие; если описание товара утеряно, выполняем другое.
То же самое касается и ошибок пользователя.
Если он что-то ввел неправильно и отображается ошибка, например «Страница не найдена» или ошибка 500, нам нужно показать ему конкретную информацию о том, что произошло, и дать ему сценарий того, что он может делать дальше.
Этот метод также подходит для ситуаций, когда вам нужно быстро получить обратную связь по функционалу, чтобы решить, сохранять его или нет.
Статический, затем динамический
Это один из моих любимых способов.Подходит в ситуациях, когда есть возможность реализовать функционал «как заглушки», то есть внешние системы не готовы поддерживать функционал.
Например, некоторыми блоками на главной странице невозможно управлять из CMS. Или меню, когда мы создаем его в своем коде и показываем пользователю, но бизнес не может им управлять.
А чтобы что-то менять, бизнесу нужно постоянно идти в развитие и просить об этом.
Здесь мы делаем потребности пользователя и получение прибыли приоритетом.
Пользователь получает готовый функционал сразу, хотя внутри мы можем испытывать некоторые неудобства.
Поэтому мы делим задачу на несколько и сначала делаем новый блок доступным пользователю, но бизнес пока не может управлять им напрямую.
Но тогда мы можем интегрироваться с какой-то системой или базой данных, где бизнес сам сможет менять местами элементы и добавлять новые самостоятельно, а мы будем их рисовать без участия разработки.
Мы часто используем этот метод: сначала создаем на наших данных функционал, которым невозможно управлять извне, а затем добавляем динамику и начинаем получать данные от сторонних систем.
Производительность
Если задача в целом сложная и объемная и непонятно, с какой стороны за нее браться, то производительностью можно пренебречь.Первая задача — включить готовый функционал, который хоть как-то, пусть и медленно, но работал.
И следующая задача – ускорить работу.
Например, это может быть медленный поиск товаров, применение фильтров, получение некоторой информации.
Иногда большая часть усилий уходит на быстрое создание функции — первоначальная реализация не так уж сложна.
Но вы можете многому научиться на медленной реализации, плюс она имеет некоторую ценность для пользователя, который в противном случае не смог бы выполнить некоторые важные действия.
Во всех этих случаях задачи разбиваются на «заставить работать» и «сделать это быстро».
Возможные трудности
Если вы решите использовать декомпозицию задач в своих проектах, то, скорее всего, первой трудностью, с которой вы столкнетесь, будет зависимость задач друг от друга.По моему опыту, это наиболее распространенная проблема, которая приводит к блокировке всего потока.
Чтобы этого избежать, следует подойти к декомпозиции ответственно и уделить ей достаточное количество времени.
Другая трудность заключается в определении того, насколько точно следует разложить задачу.
И здесь единственные границы – здравый смысл.
Для примера возьмем компонент выбора города.
Там есть кнопки, немного текста, поле ввода.
Насколько точно должна быть решена эта задача? Мы взяли для себя правило, что задача должна пройти весь поток не более чем за одну неделю (около 40 часов).
Речь идет обо всех этапах: этап аналитики, разработки, тестирования.
Плюс учитываются два этапа backend и frontend разработки, включая ревью и тестирование на каждом.
Еще у нас была проблема с тем, что границы эпопеи не всегда ясны.
Недавно нам поставили задачу сделать заказ.
Где ее границы? Какой должен быть результат? Нам было непонятно, нужно ли нам делать весь функционал до самого конца или выделить какую-то часть.
Оплата включена в этот эпик или это отдельный эпик? Есть проблемы, при которых сложно понять, как и когда их разложить.
Большую часть задач мы декомпозируем на этапе эпического приема, но бывают ситуации, когда это необходимо сделать, например, на этапе аналитики.
Берем задачу в работу и считаем, что все необходимые данные уже есть в наших интеграционных системах, но в процессе анализа выясняется, что либо нас не устраивает формат данных, либо есть проблема с качеством сами данные, либо требуется дополнительная работа со стороны других систем, с которыми мы связаны.
Дальше нам предстоит выполнить задачу «как заглушку» и добавить в бэклог еще один пункт, к которому мы приступим после того, как решим основные проблемы.
Вот, кажется, и все.
Было бы здорово, если бы вы в комментариях поделились историями о том, какой подход к декомпозиции задач вы используете и почему.
Спасибо за чтение! Теги: #Управление разработкой #Управление проектами #Анализ и проектирование систем #аналитика #тайм-менеджмент #постановка задач #Спортмастер #декомпозиция задач #декомпозиция #управление задачами
-
Руководство По Созданию Сайтов От Яндекса
19 Oct, 24 -
Что Вы Думаете О Mmorpg?
19 Oct, 24 -
Appfuscator — Облачная Безопасность .Net
19 Oct, 24
