Абзац до этого цитировать не буду, он там посвящен скраму

НагуглиЛ* кейсы на nexus

The result of implementing Nexus was a 300 percent increase in velocity.

вот это мог написать только коуч, не владелец бизнеса

https://s3.amazonaws.com/scrumorg-website-prod/drupal/2017-03/Terminales%20Case%20Study_0.pdf

Когда в команду приходит СМ, там процессы далеки от идеала. И самое хреновое - причины тому в большинстве случаев находятся за пределами команды. По факту СМ вынужден сражаться с существующей иерархией, зачастую с риском для себя. И это не считая дисфункций в самой команде, которые тоже легко не устраняются - он должен собирать факты для ретро, и готовить ее. Если на него ещё что то повешают - можно забыть про аджайл. Только сдается мне, что когда топ менеджмент задаётся вопросом - чем занят СМ - на самом деле аджайл нужен для галочки. Может инвестор затребовал?

++

Всем привет, а подскажите, надо ли PO разговаривать с командой/участниками о карьерных перспективах? и кто этим должен заниматься если работаем по SAFe?

не знаю как в SAFe, но в целом Product Owner-у как правило не до этого - у него геморроя хватает. Он же и швец, жнец и на дуде игрец. В плане карьерных перспектив команды/участников его помоему волнует только бюджет по части ФОТ и возможность бизнеса маневрировать независимо от состава команд. Если PO включается в игры HR, то видимо он не шибко наделён полномочиями (fake PO, proxy PO).

Скрам-мастера вместе с HR-ами должны сами там договориться, как они будут мотивировать участников в командах. А ему принести бюджет и аргументы за.

Скрам-мастера вместе с HR-ами должны сами там договориться, как они будут мотивировать участников в командах. А ему принести бюджет и аргументы за.

Спасибо

Скрам-мастера вместе с HR-ами должны сами там договориться, как они будут мотивировать участников в командах. А ему принести бюджет и аргументы за.

ему=PO, правильно я понял?

Ему. Да. Он же бюджет ведет

ага, тогда сходится)

Гибчайший покер планирования для сисадминов - вообще без цифр:

класс)

Planning Poker в скрам фром тренчес назвали уже беспоезной херней =) Дошло, наконец

Planning Poker в скрам фром тренчес назвали уже беспоезной херней =) Дошло, наконец

А как оценивать трудозатраты ?

ну вы и без покера можете, не дети же.

У меня команда из 10 человек, не сказать что особо ошибается в эстимировании. Задачки в большинстве случаев типовые.

вот а как? ждать пока самый мудрый скажет , так остальным думать не надо

когда один оценивает это очень удобно, не надо напрягаться, потом есть на кого скинуть, что если наш гуру ошибся нам то что,

у вас контора какая-то странная, что надо на кого-то скидывать. Никто никогда не виноват

Чем вас не устраивает эстимирование и реэстимирование итерационное по ходу?

И с чего вы взяли, что один человек оценивает?

Просто есть специализации - кто-то я движком работает, кто-то с интеграциями, кто-то с фронтендом - каждый proficient в своей области. Там где надо смежное - спросить можно всех

Чем вас не устраивает эстимирование и реэстимирование итерационное по ходу?

А это как?

когда один оценивает это очень удобно, не надо напрягаться, потом есть на кого скинуть, что если наш гуру ошибся нам то что,

чет негативно как-то

Делишь проект на фазы, эстимируешь в целом, добрался до майлстоуна - сверяешься.

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

как-то совсем верхеуровнево)

так а 1 фаза = спринту ?

не обязательно. Зачм зацикливаться на спринтах

есть подход No Estimating :)

не обязательно. Зачм зацикливаться на спринтах

а когда заказчик увидит результат?

Все зависит от проекта. Если у вас проект делается через deadline=driven development, там никого не волнует agility 🙂

Все зависит от таска. Research проект может быть, может типовые задачи только, где никакой спринт не надо, может конкретная фича - тут тоже зависит от сроков и состава команды.

правильно, какая разница, как оценили, если есть deadline 😂

Не, всмысле какая разница. Если ты понимаешь что профакапится, погоды дедлайн не сделает (все таки есть capacity) - хотя ему можно противопоставить market value

А если DeadLine нет, бизнес спрашивает, когда будет готово?

Так не бывает =) deadline есть в 90% случаев

ну вот, сам себе противоречу

т.е. все равно оценки нужны, вопрос как Marat предлагает оценивать)

есть же разные техники кроме Planning Pocker

у нас он отлично зашел и работает

не обязательно. Зачм зацикливаться на спринтах

Если не зацикливаться на спринтах, получается iterative waterfall

аахаха, это пять

нет никакого iterative waterfall'a, если есть deadline. и скама нет, если есть deadline.

Друзья! Накидайте пж практиков по масштабированию. Предпочтительно Less. 👤➡️👥

когда у вас конкуретны на пятки наступают, а хотфиксы каждый день, а клиентов много - у вас есть пожаротушительная команда, и дедлайны для market value фич

ничего нет, если есть дедлайн 👍, почти буддизм

Нет ничего кроме дедлайна, и каждый день - свидетель приближений его =)

когда у вас конкуретны на пятки наступают, а хотфиксы каждый день, а клиентов много - у вас есть пожаротушительная команда, и дедлайны для market value фич

тогда у вас не скрам и делов-то)

дык я никогда и не говорил =) я просто говорил что планнинг покер НИНУЖЕН в виде игры с карточками. все вышесказанное только мое мнение, и не претендует на масштабирование на другие проекты =)

Нет ничего кроме дедлайна, и каждый день - свидетель приближений его =)

Сложность задачи и время выполнения не зависит друг от друга (в какой-то простой формуле), там проблема в том что 1sp != 1sp с точки зрения времени

То есть даже если команда давно работает и не меняется, есть внешние факторы и зависимости которые влияют на время

Заказчику достоверно нельзя назвать срок, можно только назвать предел.

Рейндж

Ну он всегда от нуля :)

У нас бывает так, думаешь что задачу типа делать надо, а программист говорит "а можно вот так", и там вжух и уже в продакшене.

Просто надо посмотреть на нее с другой стороны. :)

У нас бывает так, думаешь что задачу типа делать надо, а программист говорит "а можно вот так", и там вжух и уже в продакшене.

"вхуж вжух и в продакшене" driven development?)

devops

😂

Байка рассказанная товарищем (в ней он Чел) Пришел чел (Ч) к программисту (П) в компании, разработчики которой работают по Agile: Ч: Что такое Agile? П: Это "хренак-хренак и в продакшен" Ч: А потом? П: Приходит вот тот бородач-мастер и говорит, что надо там подпилить, тут подпоять. И мы опять "хренак-хренак и в продакшен" Ч: ????? П: да ладно, мы так уже 2 года по Agile работаем Ч: а заказчик что говорит? П: А что заказчик? Он каждые 2 недели получает результат. Вот завтра он увидит, как мы увеличили кнопку и поставили её в другое место

Друзья! Накидайте пж практиков по масштабированию. Предпочтительно Less. 👤➡️👥

Похоже, что обсуждение взаимодействия планового отдела и скрам-команд затеряло мой пост. По-прежнему жду и надеюсь)

teal, orange, agile, lean.. вот что надо организациям =)

Agile Greece Summit, прямо сейчас =)

О, я тоже тут сейчас)

Я сейчас поработал месяц с "бирюзовой" Кнопкой и должен сказать, сильно разочарован

Затягивают сроки ?

Читают мне нотации

О, я тоже тут сейчас)

при таком количестве народу в этом чате кто-то да должен был ещё здесь оказаться)

Читают мне нотации

как то без контекста, сложно понять проблему.

увидела на скриншоте реально бирюзовые кнопки и несколько подвисла, пытаясь осознать, как именно интерфейсные кнопки могут читать нотации