@AndreyTT

Как вы разделяете задачи фронта и бэка на проекте?

Коллеги, опытные РП и тимлиды, поделитесь опытом, пжл:
Есть продукт, общая платформа с четким разделением на бэк и фронт и, вдобавок, есть разделение на 7 веток проектных, поэтому параллельно идут задачи на всех ветках с оперативными переключением. Задачи ставят аналитики у которых нет компетенции Б/Ф разделять. Поэтому раньше, при возникновении требования, ставилось две задачи в Redmine, с одинаковым описанием, но отдельно для бэка и фронта. Но две задачи в RM это две сущности для одного, фактически, логического требования. И, вдобавок, часто фронт включается, когда бэк сделал 60-80% своей работы. Поэтому мне не нравится эта система с двумя задачами, но уходя от нее и ставя одну задачу, нельзя распаралелить работу Б/Ф.
Расскажите, а как вы на проектах ставите задачи, вы или аналитики и как контролируете выполнение задач бэк-фронтом?
  • Вопрос задан
  • 693 просмотра
Пригласить эксперта
Ответы на вопрос 4
inoise
@inoise
Solution Architect, AWS Certified, Serverless
У вас Redmine, а значит у вас есть User Story - верхний уровень и то что обычно называют задачей. Стори уже бьются на задачи (обычно называют подзадачами). Почему так:
- пользователи "тупые" и не способны ставить задачи. они высказывают "пожелания" и поэтому это "пользовательские истории".
- задачи создает тимлид, разбивая истории на вменяемые части для отдельных людей.
- в случае если история=задача (о, чудо) то можно отдельно задачу не ставить
Ответ написан
Комментировать
Immortal_pony
@Immortal_pony
Тимлид указывает в комментарии при переводе задачи на исполнителя.
Ответ написан
Комментировать
@Vitsliputsli
Если у вас "четкое" разделение на фронт и бэк, значит, по сути у вас 2 технических проекта, взаимодействующих между собой. И у них не может быть одной и той же задачи, т.к. делают они разное.
Судя по остальному тексту, вы не декомпозируете задачи, отсюда и такие вопросы. Тогда, у вас 2 варианта, начать декомпозировать задачи на отдельные подзадачи, где будет отдельный исполнитель, можно прикинуть трудозатраты, указывать зависимости и т.п. К тому же, в redmine из коробки можно строить древовидную структуру задач. Тогда у вас появится хоть какой-то контроль и вы сможете планировать. Либо не заморачиваться, т.к. 1 или 2 задачи на ситуацию не повлияют, и пусть разработчики сами делят задачи и планируют.
Ответ написан
dyfran
@dyfran
И, вдобавок, часто фронт включается, когда бэк сделал 60-80% своей работы.

wtf?

Вы реализуете конкретные фичи. Мне как заказчику было бы глубоко насрать, что фронты все сделали и молодцы, а бэки нет и фича по итогу не работает, де факто, простите, все мудаки)

Нужен верхнеуровневый таск "фича такая-то", которая уже бьется на технические таски (BA, SA, Dev, QA) и только потом, когда все куски сделаны и протестированы (отдельно и вместе) - релизиться. Заодно в рамках одной задачи можно настроить элементарный sla в отчетах (у нас jira) и понимать где у вас в процессе узкие места, где боль, а где и почему задачи зависают в рамках конкретных фич и дальше от этого уже плясать. Может поменять рабочий воркфлоу, что-то убрать, что-то добавить, увеличить ресурсов бэков и так далее.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы