Очень знакомые боли, и очень точно сформулированные. Спасибо за рассказ.

Спасибо за хороший анализ.
Интересно, что у вас достаточно сильно развилась система постановки задач, при этом в ней до сих пор не появилась оценка трудоемкости задач на этапе планирования — у вас оценка ставится только при начале работы над задачей. А это ведь базовый прием — тот же planning poker в Scrum и т.п.
Уверен, что вы не могли его не попробовать на более раннем этапе. Более вероятно, что попробовали и, не получив ожидаемого результата, отказались. Если так, то можете поделиться опытом — какие были результаты, почему отказались?

Как я и написал в статье, предварительная оценка задач планируется в каком-то виде. Что нам мешает сделать это сейчас? То, что перед тем как мы приступаем к задаче, она должна пройти этап декомпозиции командой системных архитекторов. Там решается какая часть функционала будет реализована на сервере, а какая на клиенте. Также решается какой API будет необходим. Только после этого мы можем оценить затраты на разработку бекенда. Но у нас нет запаса уже декомпозированных задач для предварительной оценки, так как декомпозированная задача — почти наверняка приоритетная, и мы должны ее начать как можно скорее. Поэтому мы почти всегда пропускаем этап предварительной оценки и этим занимается разработчик перед началом работы над задачей. Если мы понимаем, что затраты на разработку явно превышают выхлоп от фичи, мы сообщаем об этом продукту. После этого принимается решение: делать как есть, не делать, делать, но с измененными требованиями. Т.е. у нас затраты времени на предварительную оценку перекочевали во время дополнительных согласований по задаче в момент старта работы над ней.
Спасибо за статью!
1. Кто входит в продуктовую команду кроме продуктовых менеджеров? Исследователи (какие?), маркетинг?
2. Как решаете проблемы, связанные с заморозкой задач (изменились приоритеты, продуктовая команда изменила после исследований / действий регулятора / etc.)? Due date в этом случае на время заморозки как-то обнуляется?
3. Почему не формируете кросс-функциональные инженерные команды вокруг продуктовых команд? Как я поняла из текста, у вас сейчас матричная структура и проблемы планирования возникают именно из-за этого размазывания продуктовых задач по функциональным отделам.
4. Когда применялась схема работы №3, как были приняты решения о распределении квот между командами? Вычислялась ли какая-то бизнес-составляющая (доходность, перспективность, важность для пользователя и т.п.) продукта, что влияло на приоритеты в выделении инженеров?
1. В продуктовую команду также входят также аналитики, дизайнеры и поддержка пользователей (это важно, потому что пользовательский фидбек — одна из основ для принятия правильных продуктовых решений). Команда маркетинга рядом, но отдельно.
2. Неактуальные «на сейчас» задачи просто пропадают с «радаров» разработки. Технически это просто снятие определенного лейбла с тикета после чего он исчезает из фильтров.
3. Формируются, если необходимо. Я написал об этом в главе «Важное дополнение»
4. Не понял вопрос. Вы про квоты между командами разработки? Их не было. Если про квоты на вертикаль, то решение принималось на уровне Директора по Продукту.
Кстати, как соотносится количество ушедших более-менее навсегда в «неактуальное» состояние тикетов с количеством сделанных?

Во-первых, спасибо за эту статью. А во-вторых, не могли бы вы рассказать больше о Jira, раз вы её применяете? У меня ощущение, что эта система только мешает в реальной работе, но похоже я не умею её готовить.

Пожалуй, это тема для отдельной статьи :)
Если есть конкретные вопросы, задавайте.
Чем именно мешает?

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


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


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


Единственное что работает, это отказ от трека версий чрез Jira. Т.е. просто забиваем на версионность. Но мне так делать нельзя: нужно четко понимать когда какая фича вошла в релиз.

У нас монолит в части php кода. И все тикеты соответственно в рамках одного Jira проекта. Версии мы не используем. Проблем с формированием спринтов и их ведением не испытываем. Спринт делается для всей команды, а дальше он фильтрами дробится на каждую рабочую группу.
интересненько
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.