tgoop.com/microservices_arch/479
Last Update:
Краткая выжимка моих ответов из обсуждения этой темы.
Определения:
PBI - элемент беклога (очередь задач на выполнение).
У каждого PBI должна быть бизнес-ценность, а элементы беклога выстраиваются в порядке максимизации бизнес-ценности.
Обсуждение началось с понятия «техническая таска», которыми могут быть enabler, spike, acceptance criteria.
Важно отметить, что:
Enabler всегда привязан к story/epic, он enabler для этого PBI, поэтому наследует бизнес-ценность этого PBI.
Acceptance criteria - это свойство pbi, определяется как часть pbi, у которого определена бизнес-ценность.
Spike - это предусловие для pbi и наследует бизнес-ценность pbi.
Не важно что за pbi рассматривается, - бизнес-ценность должна быть и она должна быть сводимой к некоторой цели, иначе невозможно выставить приоритеты.
Если архитектор ставит задачи команде в обход PO (например по квотам) - это дисфункция, так как квотирование означает, что бизнес-ценность по каким-то причинам не может быть донесена. Бизнес-ценность при этом может быть определена на уровне продукта, компании, группы компаний.
Таким образом, техническая задача или нет - совершенно не важно, если есть возможность определить ее бизнес-ценность и выразить ее. Невозможность определить бизнес-ценность говорит либо о том, что ее нет, либо о том, что есть нехватка контекста/знаний/опыта для ее определения.
Что делать с техническими задачами вида «настроить CI/CD»?
Это не техническая задача, это своего рода операционная деятельность команды и она вполне выражается в бизнес-ценности, но не на уровне бизнес-ценности продукта. Есть определенные метрики, просадка которых грозит бизнесу банкротством, как например, снижение скорости развития (и сразу конкуренты обошли на повороте). Успешная настройка CI/CD будет обладать высокой бизнес-ценностью для команды, для которой внутренним продуктом является как раз развертывание CI/CD командам.
Аналогия с хирургией. В хирургии беклог – это пациенты, ранжированные по степени тяжести состояния. Никто в этот беклог не поместит «кипячение инструмента», «подготовку баллона с кислородом», «дезинфекцию операционной», «покупку новой лампы». Если эти важные, инфраструктурные процессы будут проседать, – инструмент закончится, пациенты будут умирать от заражений, не будут дожидаться своей очереди и так далее, это как раз и есть проблема сопуствующих, поддерживающих процессов.
Хирург в общем случае не моет пол и не катает тележку с пациентом. Не, он, конечно может, но тогда число пациентов, которым он может провести операцию, сократиться (то есть число выполненных бизнес-задач из беклога).
В Team Topologies предложили решение, которое мы практикуем уже лет 20 даже на моей памяти, они его скорее формализовали, – enabling team. Ты должен уметь пользоваться инструментом, но следить за его работоспособностью будут другие люди. Тебе поставят, развернут и настроят CI/CD, но ты обязан уметь пользоваться этим инструментарием, это твой условный скальпель.
Другой класс задач – это архитектурные изменения. Например, в компании перепиливается архитектура, чтобы обеспечить надежность в пять девяток и сделать публичной статистику uptime. Технических изменений много, но они все несут бизнес-ценность, а бизнес-ценность в том, чтобы изменить свою конкурентную позицию на рынке, – брать клиентов высокой надежностью. Это рациональное, взвешанное бизнес-решение, на текущий момент уже год идут изменения и каждый архитектор, PO и разработчик понимает какие конкретно это несет выгоды для бизнеса и почему это важно именно сейчас.
BY Микросервисы / распределенные системы
Share with your friend now:
tgoop.com/microservices_arch/479