Привет! у меня появился вопрос. У меня есть стрим, который

делает мобильное приложение как продукт

Контекст такой - аналитики пишут постановку ->одна постановка идет и в команду андроид и в команду ios->также идет постановка на бек. Бек это отдельная команда за пределами стрима.

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

Эпик. Аутентификация. Андроид
Стори. Регистрация. Андроид
Сабтаск. Выбор кода страны при вводе номера. Андроид

Так если придется дублировать все для каждого гео и стора, то это ту мач задач и ненаблюдаемо. Кто-то решал такой кейс? Если да, то как строилась иерархия требований?

Пример решения: стоиться WBS от требований до саб-тасков по поставкам. Все измерения, не являющиеся поставляемым результатом - делаются лейблами (метками). По меткам делаются фильтры и доски, отображающие движение по измерению. При этом отдельной поставки по измерению нет (как процесса), поставка есть только по иерархии WBS. Но доски позволяют видеть -как едете и когда возможно приедет. Если нужна котролируемая поставка - по включаем в артифкаты WBS (то есть дублируем (там где у вас туу мач).

А что такое "задачи на разные сборки" и почему их "требуется заводить"?

Делаем так, есть feature как например: Возможность авторизации через смс, в рамках этой сущности создаются подзадачи Android, iOS, backend, marketing, etc, для каждой подзадачи также создаётся чек лист работ, в исходной сущности, которая является родительской настраиваются связи для мониторинга.

Я честно говоря не понял конкретно как это сделать) Поясни пожалуйста)

Скажу прямо, я отвечать не буду на твои сообщения так как насмотрелся на полемику с другими участниками

Мне кажется как раз наоборот все очень наблюдаемое будет если ты по разные срезы заведешь «дублирующую» задачу. Тебя именно количество задач не устраивает?

Авторизация через смс это фича. А есть уровень выше фичи? А как выделяешь отдельные задачи на гео сборки? Те важна специфика - что например фича авторизации она немного разная по ui потому что то какое в Пакистане отличается от того который в Бразилии. Также если фича авторизации с точки зрения логики она одна, но с точки зрения разработки немного разная для сборки с гугл сервисами и без гугл сервисов И вот проблема - мы сделали подзадачу на андроид, у нас работает авторизация через смс. Мы делаем 2 сборки. 1 под плей маркет, другая по хуавей. Плей маркет принял сборку, а хуавей затянул и выкатил требования. Как это разделять и визуализировать?

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

Да, меня не устраивает делать 2 разных эпика под андроид и айос, дублировать все стори и сабтаски, хоть и с минимальными отличиями. А потом еще и дублировать задачи под сборки

Выношу как администратор предупреждение за крайне неэкологичное общение и переход на личности, еще 2 будет бан

Это не переход на личности. На твоём месте мог бы быть кто угодно, и твоя личность тут непричём.

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

Обычно, достаточно понять методику отстраивание WBS(ИСР), если тут выдержена декомпозиция по поставляемым сущностям (что обычно не так, потому что это и знание и навык не рождающийся естественным путем) Лучший объяснятель rita mulcahy, точнее ее книги. Возьму пример из выше >Авторизация через смс это фича. А есть уровень выше фичи? Это невереный тип декомпозиции. Переделайте это в существительные, вместо глаголов и вы получите фичи, и фичи агрегрирующие (стостоящие из нескольких фич). Агрегация подобного рода возможна только если вы мыслите результатами, то есть существительными. Как только услованя jira у вас заполниться существительными, вместо глаголов (возможно кроме самого нижнего уровня декомпозиции в виде саб-тасков), наступит неожиданная ясность.

Сереж, я pre PMP и волонтер PMI, потому хорошо с этим знаком 🤓. Главный вопрос как быть с гео и маркетами, так как это плодит избыточное на мой взгляд количество сущностей

1. У нас на все страны с которыми работаем одна сборка, т.е у нас нет потребности создавать для разных стран отедьнве сборки, разница в них только в локализации 2. Выше фичи - эпики, ещё выше проекты, эпики это набор фич, не больше определённого объёма работ, когда они превышают лимит это идентифицируется как проект, со всеми вытекающими вплоть до назначения администратора или РП. 3. Для прочих сторов у нас так же одна и та же сборка что для Google Play, Мы работаем c Huawei, RuStore, Xiaomi. Это одна из задач в рамках релиза который был спланирован. Т.е мы определили список работ в релизе, в него по дефолтц добавляются задачи на сборки к перечисленным выше сторам, а так же задача на сборки WL для клиентов.

Просто сейчас условно 1 гео. Скоро будет 2. Сейчас 2 маркета только андроид, будет больше. Меня смущает что количество задач будет очень сильно расти и будет их очень много на досках

PrePMP это CAPM, да?)

я бы сказал тогда что это вопрос рисков и контроля. То есть уровень риска (и возможность контроля) является критерием для принятия решения об «избыточности сущностей». Зайдя с другой стороны - какое у вас сейчас основание для признания сущности избыточной? (кроме возможно культурного неприятия?)😇

А если попробовать рассмотреть проблему с другого угла: какие должны быть приложения относительно гео, устройства и использования? Мне кажется что вполне реально понять точку деления именно на основании реализации. Эпик (общий). Стори (общая) внутри Стори например тегами определяем гео и стор, к которым это применимо. А уже таски и сабтаски для каждого тега внутри Стори делают соответствующие команды на этапе декомпозиции..

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

Я запуталась. Разные гео - разный функционал для каждого? Если так, то имхо тебе надо заводить ещё одну сущность над эпиком, и тогда станет чуть проще. Но есть ещё и больший вопрос: ты спрашиваешь, как лучше это все в джире организовать, или насколько сам процесс такого разделения задач норм?

Можно вообще ради повышения эффективности спросить у бизнеса, что им приоритетнее развивать: geo expansion или фичу. И организовать работу вокруг этого приоритета

Ну уж нет

Как в джире

А не хочешь развернуть управление "по проекту" вместо "по продукту" и маркировать задачи подсисиемой/продуктом? Тут у тебя программа проектов вырисовывается. Каждый проект: платформа+гео+маркет

Сейчас mvp идёт проектом, но дальше будем продуктом. Не хочу плодить проекты там где они не нужны

Сколько времени занимает полный цикл выпуска фичи/постановки на всех платформах?

Месяц +-

Сколько в среднем задач в постановке для платформы?

Этого не скажу, так как не за работой уже

В моей голове Эпик - он же программа. Тот самый артефакт, на который смотрит продакт, что бы понять законченность всей инициативы. У эпика есть понятие "релизнутости". Вопрос к тебе - вы выкатываете то все дело как? Стор за стором одновременно андроид и айфон? В общем это даст понять. Думаю что примерно такая иерархия вырисовывается: Theme - Аутентификация Эпик - Регистрация Стори - Регистрация на Андроид Подзадача - Форма регистрации Пакистан Стори - Регистрация на бекенде Подзадача - Написать API спеку

Стори в данном случае заменил бы на таски, кажется куда логичнее

Понимаю о чем ты, но я все же предпочитаю делить на стори и таски (как в джире и засетаплено). Сторя для меня это некий разработческий артефакт, нечто у чего есть DoD, что комитится в гит и тд. А таски это не разработчекские активности вроде Написать документ или провести воркшоп

Имхо, как раз таски это работы распределеные по специалистам, а все что выше это для их логического объединения по бизнес функциям и с последующим мониторингом, имхо

Примерно к этому и пришел

it depends. если это одна и таже команда (например дизайнер и фронтендер), то да, подзадачи у стори. А если это другая команда и там свой релизный цикл то лучше отдельную сторю сделать

А как в гит флоу это выглядят, если у тебя сторя обший артефакт разработки, там может быть чуть ли не десятки коммитов 🤔

Не понял проблемы с гит флоу. Разрабочтик на беке свою сторю в done отправит когда все тесты пройдут и он смержит все это дело в dev. Так же и разработчик фронта.

Ох, это я тебя не понял, имел в виду что они работаю над одной стори вместе 😅

В этом случае лучше в одной сторе держать, да