Что такое декомпозиция в тестировании

Декомпозируй это!

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

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

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

Применительно к тестированию продуктов декомпозицию можно рассматривать по нескольким принципам.

Функциональная декомпозиция — разбиение продукта на выполняемые им функции.

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

Обратите внимание на рисунок: там показано, как для функции «Навигация» проведена более глубокая декомпозиция.

Компонентная декомпозиция – когда мы с вами смотрим, из каких компонентов или частей состоит тестируемая программа.

Декомпозиция графического пользовательского интерфейса (GUI) – опираясь на данный принцип, декомпозиция проводится по тем элементам, что визуально доступны для пользователя программы.

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

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

Декомпозиция применяется не только в части анализа и исследования продукта. Она помогает работать с задачами (это полезно знать не только менеджерам проектных команд).

В теории все видится достаточно просто и ясно: из большой задачи нужно получить ряд маленьких — никаких проблем. Но когда суть доходит до дела, многие просто не понимают критериев декомпозиции задачи. Это непонимание ведет к неприятным вещам: неравномерная нагрузка на тестировщиков проекта, неверная оценка трудозатрат, неправильное понимание задач и разное представление о результатах внутри команды. Чтобы вам стало проще, хотим рассказать про принцип SMART.

Принцип SMART в декомпозиции

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

Specific – конкретный. Это про результат. Какого результата хотим достичь?
Результат должен быть однозначным и понятным всем участникам процесса: сотрудникам команды тестирования, заказчикам, руководителям разных уровней.

Measurable – измеримый. Нам нужны задачи, которые могут быть измерены. Количественно и / или качественно.

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

Relevant – актуальный, значимый. Действительно ли выполнение задачи так важно для нас? Является ли данная задача необходимой именно сейчас? Что мы получим, если решим эту задачу? А что будет, если не решим?

Time-bound – ограниченный во времени. Любая задача должна иметь свой срок, в течение которого ее необходимо решить. Установление временных рамок и границ для выполнения задачи позволяет сделать процесс контролируемым и прозрачным. Руководитель в любой момент времени может увидеть прогресс выполнения задачи.

Кроме того, оценить прогресс и понять, что уже протестировано, а что еще — нет, также помогает декомпозиция. Обратите внимание на приведенную таблицу:

Отмечая проверенные области таким образом, вы, ваши коллеги и ваш руководитель сразу будете видеть статус продукта, что уже проверено, а что нет, избегая дублирования проверок.

А теперь хотим задать вопрос в студию: как вы считаете, техника «эквивалентное разделение» в тест-дизайне — это декомпозиция?

P.S.: Примеры по декомпозиции продукта «Браузер» уважительно подсмотрены у Натальи Савастюк и размещены в статье за их наглядность и простоту.
Ссылка: Декомпозиция в тестировании и при анализе приложения

Эстимирование и декомпозиция задач — важные подходы к работе для IT-специалистов

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

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

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

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

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

Какие качества эстимирование развивает у команды?

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

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

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

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

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

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

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

Как эстимирование помогает обрабатывать риски?

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

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

Существует более сложная техника оценки задач, связанная с риск-менеджментом — композитная эстимация . Этот подход представляет собой создание таблицы, в которой будут собраны наиболее часто встречающиеся в проектной разработке риски. В случае изменений требований или условий таблица дополняется и актуализируется.

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

Что такое декомпозиция задач?

Практика эстимирования в культуре ДжазТим тесно связана с декомпозицией задач и понятием Definition of Done — критерии выполнения задач . Если задача слишком большая, нетривиальная или на первый взгляд неподъёмная, мы разбиваем её на мелкие подзадачи. При этом учитываем важный нюанс: результат каждой небольшой подзадачи должен быть конкретным и демонстрируемым.

Принцип декомпозиции задач

В чём заключается важность и польза декомпозиции?

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

А точно ли завершена задача? Поговорим о критериях выполнения

Мы уже упоминали о том, что при использовании декомпозиции каждая небольшая задача должна иметь определённые характеристики, чтобы считаться завершённой. Понятие «выполненная задача» тесно связано с Definition of Done — согласованными с заказчиком и командой критериями выполнения задачи . Обычно они представлены в виде небольшого чек-листа. В нём по пунктам выделены основные требования, которым должен соответствовать результат. Особенно актуально использование такого чек-листа в сложных задачах: например, при разработке модуля системы, который может иметь влияние на работоспособность другой функциональности.

Приведём примеры пунктов, которые могут быть в Definition of Done:

Написаны/обновлены Unit-тесты.
Результат проверен на девелопмент-сервере.
Код смержен в мастер-ветку.

Также за основу пунктов для чек-листа могут быть взяты требования к приложению.

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

Помимо Definition of Done все выполненные задачи должны иметь ряд общих характеристик:

Демонстрируемый результат . Это может быть подготовленная фича, обнаруженный и устранённый баг — всё, что легко доказать и показать. В случае, если задача подразумевала исследование, должен быть подготовлен мануал по использованию изученного подхода или технологии, документ с выводами, диаграмма.
Измеримый и конкретный результат . Менеджер, заказчик и вся команда могут легко убедиться, что задача выполнена и понять, какую пользу она принесёт проекту.

Декомпозиция и работа с рисками

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

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

Основы риск-менеджмента в ДжазТим

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

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

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

Как постепенно и безболезненно ввести практику декомпозиции и эстимирования на вашем проекте?

Начните с внедрения культуры декомпозиции задач. Введите на проекте правило: задача не может занимать больше 1 рабочего дня. Будьте готовы к вероятности сопротивления со стороны команды. Инженеры могут настаивать, что они уже декомпозируют, но если задача слишком сложная, иногда работа над ней растягивается на неделю. Поясните инженерам, что это неправильный подход. Результат любой выполненной задачи к концу дня должен быть измеримым, чётким и демонстрируемым. Если с разработчиков не требовать серьёзности в таком важном вопросе, это может привести к излишней расслабленности и безрезультатности. Практика декомпозиции задач способствует прогрессу и развитию ответственности у команды, улучшает логистику в продвижении по задачам проекта.
Стоит постепенно выходить на систему распределения времени разработчиков: в день необходимо закрыть 3 небольших задачи по 2-3 часа. При этом результат должен быть измеримым, конкретным и демонстрируемым. Например, если ваш разработчик осваивает новую технологию, пусть подготовит мануал или диаграмму по её применению.

Этапы внедрения практики декомпозиции и внедрения задач

Выгоды сочетания практик декомпозиции и эстимирования

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

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

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

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

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

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

Мы работаем по контракту T&M, поэтому иногда в первые итерации на проекте может отсутствовать даже список задач, которые необходимо реализовать. Несмотря на это, наши менеджеры готовы взять на себя постановку задач и по запросу заказчика составить их предварительную оценку. Когда список задач составлен, мы декомпозируем и эстимируем каждую задачу проектного плана. В дальнейшем внимательно отслеживаем бюджет и заранее сообщаем заказчику о рисках отклонения от эстимации, предлагаем варианты решения возникшей проблемы. Благодаря эффективному применению эстимирования и декомпозиции задач отклонение фактически затраченного времени от изначальной эстимации для T&M проектов в нашей компании не превышает 20%.

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

Вот притащили вам с охоты мамонта: выше вас ростом, упитанный и на вид пока несъедобный. Что делать?! Декомпозировать, конечно: лапы отдельно, шкуру отдельно. Но с чего начать? И когда хоть примерно будет готов ужин?

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

Уровни декомпозиции

Казалось бы, проще простого: режем проект на большие части, эти части — ещё на части, а те части — снова на части. Но действительно ли всё так просто?!

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 сервисов ищите тут).

Здесь имеется ввиду, что есть какой-то интеграционный протокол, либо файловый протокол, либо XML, либо шина данных (сервер очередей вроде RabbitMQ, ZerroMQ или Apache Kafka) — подробнее о разнице штатной интеграции и по API наш техдир рассказывает тут. С чем именно интегрировать и по какому протоколу, на этапе предварительной оценки не столь важно — важнее, есть ли для этого документация. А у неё обычно бывает два состояния:

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

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

Соответственно, если на проекте планируется интеграция с внешним сервисом, на неё нужно закладывать большие резервы. Лайфхак, если нужно интегрироваться, а протокола пока нет — делать MOCK-объекты. Это специальные заглушки для интеграционного протокола, которые можно быстро сделать. А как только будет реальный протокол — просто заменить их (но обязательно с перепроверкой).

Как все это «подружить»

Начинаем с крупных компонентов: первый, второй третий — можно расписать подробно. Следом важно примерно понять, какие есть пользователи (роли) и какие у них сценарии. Сами сценарии в смету лучше не прописывать. Дальше — идём по страницам. После — работаем с отдельными блоками, используя уже известную схему «Откуда эта хрень на странице?!».

Как только вы слышите слово «калькулятор» или «считается», напрягайтесь 🙂 Когда есть интеграция со сторонним сервисом — тоже. В остальном — ничего страшного, и всё довольно прозрачно 🙂

Когда это может не сработать

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

Успехов в декомпозиции и почаще заглядывайте к нам на YouTube-канал за новыми полезными видео для проджектов (и не только)!

оценка времени
управление проектами
управление временем
scrum
planning poker

Декомпозиция требований? Самая техническая сторона проджекта

Всем привет. Сегодня предлагаю поговорить про декомпозицию требований и как это делается в Agile.

Начнем с самих основ. В статье затрону вопросы, что такое декомпозиция, при чем тут Agile и зачем и как это делать.

И начнем мы… с конца. С ответа на вопрос зачем нам это делать?

В разработке проектов / продуктов перед реализацией того или иного функционала, проджект / продакт менеджеру необходимо держать в голове вопрос: “Какой самый быстрый недорогой способ реализации фичи для конечного пользователя?”. Если правильно перефразировать, то этот вопрос, в том контексте, который рассматриваем мы, должен больше звучать как: “Какие есть варианты наискорейшей доставки ценности конечному пользователю?”. Вроде бы похожие вопросы, но, если перевести их на менеджерский язык, то получаем некие различия. Первый вопрос — больше про реализацию того или иного целостного большого функционала.

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

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

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

Что такое слайсинг?

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

Вот как выглядит любая декомпозиция:

На картинке, мы видим и одну большую систему (автомобиль) и комплект запчастей помельче (сидения), и еще мельче (гаечки, трубочки, винтики, шурупчики).

Процес декомпозиции и его результат имеет ряд преимуществ, среди которых:

Возможность быстро получать фидбек (аминь!). Разбив стори на логически завершенные кусочки функционала, мы можем смело бежать к клиенту и показывать, чего накодили для наискорейшего приема правок. Так дешевле.
Быстрое тестирование и багфикс. Имея маленький функционал, который станет частью большого функционала, у нас есть возможность быстрее найти баги и пофиксить их. Пример: разработка формы заказа еды, отдельно от разработки витрины онлайн магазина. Если мы потестим форму заказа быстренько, то успеем допилить и валидацию правильную и верные ответы сервера на запрос. А возможно, после ревю юристов, нам потребуется еще допилить GDPR позиции (мало ли).
Определение важной и менее важной работы. Когда мы декомпозируем большую задачу, мы сразу же видим, что будет важнее всего и пойдет в работу в первую очередь, а что будет менее важно и будет реализовано позже или не реализовано вовсе.
Лучшая прогнозируемость результатов спринта. Если например, у нас есть скорость работы команды17 сторипоинтов, а она работает над сторями 8, 13 сторипоинтов, то есть вероятность, что мы что-то не успеем. Но что? Гораздо легче ответить на этот вопрос, когда работаем над сторями по 3 сторипоинта.
Больше доверия и веры в себя. Выплывает из предыдущего — когда мы можем спрогнозировать конец спринта, к команде повышается доверие со стороны бизнеса. То же касается и веры в себя. Конечно, приятнее закрыть 10 сторис, чем 3, просто чисто на психологическом уровне. Последнее утверждение достаточно спорное, потому что важно остлеживать осознание того, что 10 сторис были частью великого — не всем доставляет удовольствие пофиксить 15 своих же багов и гордиться собой:)
Экономия времени на оценку. Гораздо легче оценивать мелкие сторисы, описанные с разных сторон разработки, чем продумывать логику взаимодействия в большой задаче.
Смягчение рисков. Декомпозируя задачи, нам легче выделить риски, влияющие на ту или иную реализацию. Например, подумали, что форму нужно сделать на какой-то новой технологии. Уже вырисовался риск того, что продажи в интернет-магазине можем не успеть запустить вовремя потому что технология для нас новая или не успеем покрыть юнит-тестами или еще что-то. В общем, мы можем прогнозировать раньше, чем наступит капец.
Лучшее распределение работы в рамках спринта. Декомпозиция на мелкие задачи позволит многие вещи запаралелить и избежать оверзагруженности в конце спринта + лучше прозрачность отслеживания своего вклада в разработку фичи.

Когда делать декомпозицию?

Итак, как же понять, на каком этапе нам в работе нужна декомпозиция?

Разработка приложений и веб-продуктов достаточно непредсказуемый процес, в котором сложно оценивать большие куски работ и понять, в каком месте пойдет медленнее. Если в рамках спринта мы работаем над недекомпозированными задачами, то невыполнение 1–2 стори = 50% результата невыполнения спринта (образно). Декомпозицию лучше делать без привязки к конкретному спринту, и не делать ее непосредственно на планировании спринта. Самый оптимальный вариант — приходить на планирование спринта с уже декомпозированными задачами для получения более точной точечной оценки.

Как декомпозровать?

Существует два основных подхода к декомпозиции задач: горизонтальный и вертикальный. Давайте рассмотрим каждый из них.

Горизонтальная декомпозиция задач подразумевает декомпозицию задач по типу проводимых работ, по компонентам, задействованным в работе, по специалистам. Например, возможны разбивки: База данных — Сервер — Клиентское приложение; бекенд разработчики делают свою часть работ, фронтенд свою, тестиврощики свою. В итоге, при завершении работ по каждому компоненту или каждый специалистом, мы не можем оценить конечный результат, поскольку его еще нужно “собрать” в кучу, интегрировать. Горизонтальную декомпозицию лучше всего проводить на начальном этапе проекта, когда необходимо выделить логически завершенные большие куски проекта (фичи), которые в дальнейшем будут разрабатываться.

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

Нагляднее о горизонтальном и вертикальном слайсинге можно посмотреть на картинке:

Если переводить на язык практического проектного менеджмента, то, в моей практике, горизонтальный слайсинг — это выделение эпиков, над которыми мы будем работать (например, “Мобильный API”), а вертикальный — создание юзер сторис (например, “Передавать 5 последних опубликованных новостей в мобильное приложение”). У вас может быть по-другому. Например, горизонтальный слайсинг это — “Создание редактируемой странички блога”, а вертикальный уже: “верстка страницы поста, создание админ-панели для редактирования страницы поста, тестирование работоспособности, нагрузочное тестирование и т.д.”

Какие техники использовать для декомпозиции?

Существует 4 основные техники декомпозиции задач: Vague Terms, Conjunctions, Acceptance Criteria, and Workflow Steps. Рассмотрим их ближе.

Vague Terms — используется в условиях сильной неопределенности. Часто, при описании фичи, мы используем неопределенности. Например:

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

В данном случае, словосочетание “несколькими способами” несет в себя некую неопределенность — что такое “несколькими”, “какими именно способами”, “сколько их должно быть”. Точно такая же история и со словосочетанием “на протяжении нескольких дней” — сколько дней? Что такое “день” и т.д. Использовав слайсинг, мы приходим к уточнению вышеописанной стори таким образом:

Создать страницу оплаты, где отобразить корзину с выбранными товарами, форму для заполнения персональной информации, выбор способов оплаты.
Добавить функционал оплаты через: банковский терминал, LiqPay, PayPal, расчетный счет, наличными при получении.
Добавить сохранение введенной информации на протяжении 48 часов с момента клика на кнопку “Сохранить”.

Таким образом, мы видим, что уже +/- ориентируемся в том, какой объем работ нам нужно сделать и какие требования к этим работам выдвигаются.

Conjunctions — (с англ. — “союз) — если говорить простыми словами, то это те юзер стори, где мы выражаем мысли с помощью союзов “и, при условии, или, когда” и т.д.

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

В данном случае применяем декомпозицию и получаем:

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

Acceptance Criteria — декомпозиция задач на основании возможности применить к ним критериев приемки.

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

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

Создать UI элементы на странице, где будем спрашивать пользователя разрешение определять его геолокацию.
Создать UI элементы на странице, где пользователь сможет разрешить / запретить определение своей геолокации.
Определять геолокацию пользователя — страну и город.
Автоматически подставлять страну и город проживания пользователя в поля “Страна”, “Город” на странице оформления заказа.
Дать возможность изменить геолокацию на странице оформления покупки вручную пользователем предоставив ему список стран и городов в них.

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

Workflow Steps — это способ декомпозиции задач путем продумывания того, как пользователь будет взаимодействовать с нашей системой, какие шаги он пройдет для совершения целевого действия.

Как пользователь я хочу иметь возможность создать wish-лист с товарами магазина и иметь возможность совершить покупку из него.

Разбиваем по воркфлоу, получаем:

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

Как видим, после того, как мы разбили пользовательский воркфлоу, у нас нарисовались и неопределенности (например п.8 — какие способы оплаты доступны и т.д.) и критерии приемки.

Вместо выводов.

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