Комментарии 20
"2-3 часа активной работы к 11" -- это команда жаворонков какая-то?
Благодарю, было интересно почитать про организацию командной работы.
Как раз сегодня вспоминал расшифровку аббревиатуры PBR :)
У нас BPR проводит: либо PO, либо BA → разбираем новые бизнес-требования.
Потом SA после завершения работы над спайком проводит уже свой BPR, из которого уже рождаются задачи на разработку.
В нашей команде 2 подкоманды, и иногда проводим мини-PBR на одну подкоманду.
Вот, это уже лучше. Вопрос - кто и когда успевает делать spike? Это отдельная задача в рамках спринта? Кто и как ее оценивает в sp?
Спасибо за вопрос.
У нас по процессу как я и описывал.
PO берет задачу в квартал, на планировании spike распределяется на аналитика.
spike задача на аналитика, по решению которой аналитик должен подготовить статью в конфлюенс с подробным алгоритмом разработки для мидл\фронт, примерами запросов на интеграционных стендах, с ТУЗами и тп.
Параллельно дизайнер делает макеты если требуется по задаче. Консультируется и обсуждает клиентские путь в чате дизайна.
На PBR происходит показ подготовленного материала.
Spike не оценивается - задача на исследование, на нее также на доске беклога фиксируем примерное время исполнения.
Спасибо, в статье написано еще что spike может быть назначен на разработчика.
И если задача не оценивается в SP - то как потом вы управляете capacity команды? Получается некая "неучтенная" задача в понятиях скрама. То есть по хорошему надо выделить меньше SP на команду/человека. Что вы делаете в этом случае?
Да, вы абсолютно правы — Spike действительно выпадает из стандартного учёта в story points. Вот как мы с этим работаем:
Пример из практики
Возьмём задачу по переводу приложения на Kubernetes. Такой Spike включает:Поиск внутренних стандартов компании (инструкций)
Анализ пилотных внедрений (если они были)
Подготовку спецификации для основной задачи (исполнителю)
Как учитываем в capacity
Выделяем под Spike не более 1-2 дней (фиксируем в календаре)
Если Spike сложный — разбиваем на этапы с чёткими критериями завершения
При планировании спринта резервируем 20% времени разработчика на такие исследования
Приоритезация
Если параллельно идут бизнес-задачи — Spike получает статус «Фоновый режим»
Критичные Spike (например, для блокирующих багов) могут временно стать главным фокусом
Хоспади, опять эти ритуальные пляски и мнимая польза от них.
Как раз разгребаю дерьмо от идеальной команды, которую собрали по принципу 'родить за 1 месяц'. Причём один токсик из этой команды говорил, что так делать нельзя, что будет полурабочее говно. Но остальные проголосовали. И вот получилось полурабочее говно. И из всей команды остался только тот самый токсик, который просто выкидывает идеальный код от идеальной команды пачками. И его теперь никто не трогает с этими ритуальными плясками - нужен уже результат
Запомните, дети, если вы подбираете команду исходя из лычек, а не реального опыта, принимаете решения голосованием, а не экспертным мнением, то никакие ритуальные пляски не помогут. А любящая попиздеть команда вряд ли будет досконально разбираться с проблемами
Спасибо за эмоциональный отзыв — вижу, у вас был непростой опыт, и это действительно ценно.
Про «ритуальные пляски»
В статье я как раз показываю, как стандартные Agile-практики превращаются в рабочие инструменты — не потому что «так надо», а потому что:
Каждый ритуал (дейли, ретро и т.д.) рождался из реальных проблем нашей команды
Мы в течении многих лет тестировали, отменяли и пересматривали подходы. Я имею ввиду DOR, DOD, ведение встреч и тп.
Сейчас 17 человек работают синхронно без принуждения.
Благодарю вас за пример, однако как мне кажется ключевой вывод другой: проблемы решаются не поиском крайних, а честным разбором причин. Именно для этого мы и используем ретроспективы — чтобы исправлять системные сбои, а не тыкать в конкретных людей.
Так если все за него проголосовали, значит команда изначально была обречена на неуспех, т.к. они все были некомпетентны получается, что для них самих оказалось очевидным похоже лишь в конце.
Всё достаточно здраво выглядит, только я не очень понял, почему у вас РО кроме определения задач и приоритетов распределяет ресурсы, и главное как ему это удаётся) то что он их учитывает, это же не распределение
Спасибо за вопрос! Действительно, формулировка про "распределение ресурсов" может вызвать недопонимание. Поясню нашу практику:
PO:
Определяет приоритеты и последовательность задач, т.е приносит список задач на планирование.
Утверждает бэклог спринта перед стартом, т.е. могли "перехать" задачи из предыдущего спринта или же лиды направления принесли срочные тех.задачи. Бывают бизнес приоритеты изменяются или требования, которые нужно дополнительно отправить на аналитику. Все финально утверждается PO.
Координирует зависимости между задачами, т.е. последовательность выпуска задач согласно бизнес договоренностям при планировании.
Как я и говорил в статье:
PO не назначает конкретных исполнителей, этим занимается команда на планировании, т.е. любой участник команды может сказать "я хочу взять эту задачу" или же "для тебя есть друга задача она ниже, как ты любишь".
У PO есть свои инструменты, таблицы, графики и тп, но это выходит за рамки статьи и моей экспертизы.
Значит всё таки контроль и учёт, и это правильно) По моему опыту, как только скрам мастера, РО или какой нибудь релиз менеджмент начинает считать единички ресурсов и пребывать в иллюзии, что он управляет командой и объёмом разработки, аджайл на этом заканчивается.
Вообще у меня сложилась внутренняя иллюстрация аджайлу - это концепция протокола IP пересылать данные настолько хорошо, насколько получается. Есть задачи, есть люди которые их ставят. Есть команда, которая их выполняет в существующих условиях максимально качественно и быстро. Чтобы это хорошо работало, необходимо корректно ставить и приоритизировать задачи и обеспечивать команде условия, мотивацию и желание их решать. А инструменты это лишь инструменты
По описанию слишком все официально, что в свою очередь не навевает мыслей о заявленной эффективности..
Очень интересная статья. Спасибо. Есть что почерпнуть. А как пришли к такому подходу? Это был естественный, так сказать, эволюционный путь?
Спасибо за вопрос!
Да, это был именно эволюционный путь. Каждый инструмент появился как ответ на конкретные вызовы команды. Расскажу на примерах:
Я начал работать в команде в начале 2022года, тогда было 4 человека (1 middle, 2 frontend + я как аналитик) + PO.
В такой маленькой команде всё решалось быстро — собрались на пятиминутный созвон и тут же решили вопрос. Я тогда и аналитику делал, и тестировал, и демо проводил.Но когда команда начала расти, появились первые сложности. Например, пришел тестировщик — и на первом же демо выяснилось, что функционал немного расходится с требованиями. Потом подключился дизайнер — и оказалось, что стили съехали. Так родилось правило в DoD - "Изменения должны быть протестированы и не ломать существующий функционал (с проверкой аналитика и дизайнера)".
С дейликами тоже вышла интересная история. Сначала мы их проводили в 9 утра или в 9:30(уже не помню), но когда к нам присоединились ребята из других часовых поясов, некоторые пропускали. Чтобы не выяснять причины, на ретроспективе договорились проводить в 11:00. Второй критерий, опоздания на дейлик, иногда можно заработаться и забыть, а почта не включена и уведомление не пришло. Тогда также на ретроспективе договорились сделать бота о напоминаниях и ссылки на онлайн комнату. Также бот не только напоминает о встрече, но и случайно выбирает ведущего — так все остаются вовлеченными.
Большинство этих правил появилось именно так — мы сталкивались с проблемой, обсуждали её на ретро и вместе придумывали решение. Ничего не брали "из книжек" слепо — только то, что реально работало в наших условиях.
Бот для рокетчата самописный?
Команда на одной волне: неформальные правила ИТ разработки, которые реально работают