Нужен ли такой команде скрам?
От: Yodo  
Дата: 29.06.21 09:43
Оценка:
Есть команда, пилит продукт по чему-то похжему на канбан. Задачи периодически появляются, назначаются, едут по доске слева на право, закрываются.
Обсуждения голосом каждый день плюс в Jira и мессенжерах.

Никаких стори-поинтов, сроков, дедлайнов, ретроспектив. Выпустили фичу, зарелизили. Параллельно каждый разработчик может вести 2-3 задачи.
Если одна блокируется по каким-то причинам, переключается на №2 и №3.

Т.е. так все неспешно течет, фичи делаются. Клиенты пользуются продуктом.

Что не так? Нужен ли такой команде скрам?
Re: Нужен ли такой команде скрам?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 29.06.21 10:31
Оценка: 2 (1) +5
Здравствуйте, Yodo, Вы писали:

Y>Что не так?

Все так.

Y>Нужен ли такой команде скрам?

Нет.
Re: Нужен ли такой команде скрам?
От: Буравчик Россия  
Дата: 29.06.21 10:38
Оценка: +3
Здравствуйте, Yodo, Вы писали:

Y>Что не так? Нужен ли такой команде скрам?


Ты скажи, что не так. Что ты хочешь улучшить в процессе?
Best regards, Буравчик
Re[2]: Нужен ли такой команде скрам?
От: Yodo  
Дата: 29.06.21 11:21
Оценка:
Б>Ты скажи, что не так. Что ты хочешь улучшить в процессе?

Процесс норм. Только выглядит скучным. Любая задача в нем, даже сложная — это текучка и рутина, которая тянется без сроков и тихо завершается, выходя в релиз либо закрываясь как не реализованная.
Технически все вроде неплохо. Но есть опасения, что рано или поздно такой подход приведет к выгоранию участников процесса и получится как в этой теме
http://rsdn.org/forum/management/7947687.flat#7947687
Автор: Firstborn
Дата: 09.02.21


В общем, посмотрел видео с теткой, которая тренирует скрам мастеров.
https://www.youtube.com/watch?v=4RDlmO4h4S4

Дельная мысль, которую она доносит — это обязательное подтверждение и осознание результата. А также использование результата как серотонинового "топлива" для следующей задачи.
Т.е. четкая последовательность: задача — результат — задача — результат. Т.е. подход со спринтами, который пропогандирует скрам и который является более дискретным и обязует бить задачи на подзадачи и на каждой подзадаче акцентировать результат. Но может же быть так — один разраб пилит задачу №1 — два месяца, второй пилит задачу №2 — три месяца и искуственно измельчать эти задачи смысла нет.

Т.е. вопрос такой. Дает ли подход со спринтами и явной фиксацией результатов плюс к боевому духу команды и отдельных ее участников или же все сваливается также в рутину.

В случае скрама, цель — "дать что-то ценное стейкхолдеру, совершить итерацию +1". Такая цель ведет зачастую к итерациям ради итераций и к измелчению задач ради того чтобы засунуть в спринт и распределить.
В случае продуктового "нескрама", цель — эволюционно улучшать продукт, обеспечивая ему конкурентное преимущество. Т.е. неважно сколько было итераций, важно вывести какую-то крупную фичу или стратегическое изменение в релиз. И на это может уйти например год.
Re: Нужен ли такой команде скрам?
От: СвободуАнжелеДевис СССР  
Дата: 29.06.21 11:37
Оценка:
Y>Что не так? Нужен ли такой команде скрам?

нет
Нет времени на раскачку!
Re[3]: Нужен ли такой команде скрам?
От: bnk СССР http://unmanagedvisio.com/
Дата: 29.06.21 11:58
Оценка:
Здравствуйте, Yodo, Вы писали:

Y>В случае скрама, цель — "дать что-то ценное стейкхолдеру, совершить итерацию +1". Такая цель ведет зачастую к итерациям ради итераций и к измелчению задач ради того чтобы засунуть в спринт и распределить.

Y>В случае продуктового "нескрама", цель — эволюционно улучшать продукт, обеспечивая ему конкурентное преимущество. Т.е. неважно сколько было итераций, важно вывести какую-то крупную фичу или стратегическое изменение в релиз. И на это может уйти например год.

Если у вас фиксированных сроков или бюджета (что то же самое по сути) нет, то IMHO скрам вам не нужен.
Re: Нужен ли такой команде скрам?
От: Ночной Смотрящий Россия  
Дата: 29.06.21 12:20
Оценка:
Здравствуйте, Yodo, Вы писали:

Y>Что не так? Нужен ли такой команде скрам?


Если клиенты на 100% довольны — не нужен. А вот если какие то вопросы у них есть — тогда все зависит от того что это за вопросы.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: Нужен ли такой команде скрам?
От: sr_dev  
Дата: 29.06.21 15:04
Оценка: 12 (1)
Здравствуйте, bnk, Вы писали:

bnk>Если у вас фиксированных сроков или бюджета (что то же самое по сути) нет, то IMHO скрам вам не нужен.


а если есть — то тем более. фиксированный бюджет и итерации вещи несовместимые по очевидной причине — итераций может быть сколько угодно.

фиксированный бюджет — это водопад и только водопад — описали задачу, согласовали, описали решение, согласовали, спланировали (тут подписали договор с кучей приложений), сделали.

в действительности, конечно же, не "сделали", а сорвали сроки и пошли в лучшем случае извиняться, а в худшем предлагать оплатить сделанную часть работ и разойтись по хорошему. оценочную трудоемкость при подписании договора умножили на 3 (можно на 33), навешав лапши клиенту — в этом важнейшее искусство ведения бизнеса кастомной разработки.

умные заказчики не работают по фикс прайсу, но неумных на рынке процентов 70 минимум. исполнители же ненавидят фикс прайс все без исключений.
Re: Нужен ли такой команде скрам?
От: sr_dev  
Дата: 29.06.21 15:22
Оценка: +2
Здравствуйте, Yodo, Вы писали:

Y>Есть команда, пилит продукт по чему-то похжему на канбан. Задачи периодически появляются, назначаются, едут по доске слева на право, закрываются.

Y>Обсуждения голосом каждый день плюс в Jira и мессенжерах.

Y>Никаких стори-поинтов, сроков, дедлайнов, ретроспектив. Выпустили фичу, зарелизили. Параллельно каждый разработчик может вести 2-3 задачи.

Y>Если одна блокируется по каким-то причинам, переключается на №2 и №3.

Y>Т.е. так все неспешно течет, фичи делаются. Клиенты пользуются продуктом.


Y>Что не так? Нужен ли такой команде скрам?


скрам этой команде нужен как диарея, а скрам коучи как туберкулёз.

понятная ваша мысль про серотониновое топливо, но триггер закрытия куска работы у девелопера есть и без спринтов — достаточно тикетов на доске. а вот 20-25% рабочего времени в митингах (груминги, ретроспективы, коллективные планинги, покеры со стори-поинтами) у кого-то могут вызвать явление, называемое "корчи вампира на солнце"
Re: Нужен ли такой команде скрам?
От: SkyDance Земля  
Дата: 29.06.21 19:54
Оценка: +2
Y>Что не так? Нужен ли такой команде скрам?

Нет. Что нужно, это team building + offsites, плюс либо хорошие деньги (чтобы работали за деньги), либо реально драйвовый продукт (чтобы гордиться им).
Re[3]: Нужен ли такой команде скрам?
От: Дельгядо Филипп Россия  
Дата: 30.06.21 10:57
Оценка: 8 (1) +4
Здравствуйте, Yodo, Вы писали:

Б>>Ты скажи, что не так. Что ты хочешь улучшить в процессе?



Y>Дельная мысль, которую она доносит — это обязательное подтверждение и осознание результата. А также использование результата как серотонинового "топлива" для следующей задачи.


Меньше слушая коучей.
Если очень хочешь, то добавь в текущий процесс фиксацию результата — демо по сложным задачам, неформальные сборы раз в пару недель "похвастаться", приноси внутрь обратную связь от клиентов — это гораздо лучше и эффективнее, чем скрам.


Y>Т.е. вопрос такой. Дает ли подход со спринтами и явной фиксацией результатов плюс к боевому духу команды и отдельных ее участников или же все сваливается также в рутину.


Нет, не дает.
Re[3]: Нужен ли такой команде скрам?
От: maxkar  
Дата: 30.06.21 14:03
Оценка:
Здравствуйте, Yodo, Вы писали:

Y>Дельная мысль, которую она доносит — это обязательное подтверждение и осознание результата. А также использование результата как серотонинового "топлива" для следующей задачи.

Вы внимательно ее слушали? Она там же говорит, что авторизация результата — это внутренний индивидуальный процесс. И самые хорошие лидеры учат членов команды делать это самостоятельно.

Y>Т.е. четкая последовательность: задача — результат — задача — результат.

И в зависимости от решаемых задач приносит это все на уровень рутины/повторяющихся действий. Может убивать всю тягу к исследованиям (большие задачи здесь хороши) и заодно мотивацию.

Y>Т.е. вопрос такой. Дает ли подход со спринтами и явной фиксацией результатов плюс к боевому духу команды и отдельных ее участников или же все сваливается также в рутину.

При такой постановке вопроса — снизит боевой дух и достаточно быстро приведет к выгоранию.

Вы уже пытаетесь ввести универсальную меру "достижения" как решение бизнес-задач. Что расценивается как попытки лишить индивидуальности. В рамках презентации — вы сразу же всех засовываете на уровень энергии ниже 45%. На уровне выше у каждого члена команды свои цели. И именно эти индивидуальные цели дают основной вклад в личную мотивацию, самосознание и росту. А решение бизнес-задач — побочный продукт саморазвития. Это не значит, что людям плевать. Это значит, что это не основной результат для них. Включать его в мотивацию можно, но нужно очень аккуратно все делать (у меня это обычно часть identity команды а не индивидуума).

И это в лучшем случае вы получите энергию в районе 40%. А в худшем получится бюрократическая организация с (ожидаемым) уровнем энергии порядка 20%. Для организации по разработке ПО ниже уже особо некуда. Я конечно не знаю, может у вас там все ужасно и рост до 35-40% будет прогрессом. Но для этого нужно индивидуально со всеми заниматься, понимать текущее состояние, разрабатывать планы развития и т.п.

Для начала я советую посмотреть на вашу личную мотивацию. Очень много признаков того, что вы просто хотите занять доминантную позицию. Это, в свою очередь, происходит из-за того, что команда уже работает хорошо и роль "организатора процессов" ей не особо нужна. Вы воспринимаете это как угрозу и включаете соответствующее поведение. Стоит разобраться в ситуации и выяснить, сколько внимания в текущей роли нужно уделять данной команде, каких (других) ролей ей не хватает, где основные проблемы. Может быть — переключиться на другие команды. Потом уже можно смотреть, что происходит в команде, какие объективные проблемы (а не просто "вам скучно") и т.д. Собирать обратную связь. Причем в таком виде, чтобы вам доверяли и говорили про реальные вещи. Может, разработчиков то все устраивает и у них есть свои достижения, которые вы просто не видите?
Re: Нужен ли такой команде скрам?
От: scf  
Дата: 30.06.21 14:24
Оценка:
Здравствуйте, Yodo, Вы писали:

Y>Что не так? Нужен ли такой команде скрам?


Работает — не трогай. Такой команде скрам не нужен, но он может быть нужен заказчикам для определенности по срокам. В скраме у задачи есть трудоемкость и сроки, без скрама — "сделаем когда-нибудь"
Re: Нужен ли такой команде скрам?
От: rosencrantz США  
Дата: 16.07.21 20:47
Оценка: 6 (1)
Здравствуйте, Yodo, Вы писали:

Y>Что не так? Нужен ли такой команде скрам?


Всё нормально, скрам такой команде не нужен.

Скрам — это про управление ожиданиями. Если вопрос управления ожиданиями не стоит (потому что нет ожиданий или потому что они как-то и так уже управляются), то всё в порядке.

Скрам — это когда есть чувак с бабками, который толком не может объяснить что хочет, и есть команда, которая способна сделать что нужно, только вот выяснить что именно нужно — практически невозможно. Тут скрам приходит и говорит: самый большой фейл, который может произойти — это 2 недели работы на выброс — хуже этого не будет.
Re[2]: Нужен ли такой команде скрам?
От: rosencrantz США  
Дата: 16.07.21 20:56
Оценка: +1
Здравствуйте, sr_dev, Вы писали:

_>понятная ваша мысль про серотониновое топливо, но триггер закрытия куска работы у девелопера есть и без спринтов — достаточно тикетов на доске.




_>а вот 20-25% рабочего времени в митингах (груминги, ретроспективы, коллективные планинги, покеры со стори-поинтами) у кого-то могут вызвать явление, называемое "корчи вампира на солнце"


Из моего опыта все эти церемонии часто получаются бестолковыми из-за того, что их драйвят очень специфические люди. Реакционисты, далёкие от реальности проекта, анти-токсичные, позитивно настроенные. Плохо, что баг попал в продакшн, но всё равно мы молодцы (вместо давайте прикинем как он пролез, как избежать в будущем). Вася до 3 часов ночи сидел и деплоил руками — такой герой-молодец (вместо как нам сделать более надёжные процедуры деплоймента).
Re[5]: Нужен ли такой команде скрам?
От: Mr.Delphist  
Дата: 27.01.22 16:39
Оценка:
Здравствуйте, sr_dev, Вы писали:

_>фиксированный бюджет — это водопад и только водопад — описали задачу, согласовали, описали решение, согласовали, спланировали (тут подписали договор с кучей приложений), сделали.


Сработает на малых проектах, но на больших — неизбежно "осмысление на ходу". Поэтому в такой реальности даже solution design и его обсуждение — это тоже отдельная статья расходов, которая может быть в итоге едва ли не половина бюджета.

_>в действительности, конечно же, не "сделали", а сорвали сроки и пошли в лучшем случае извиняться, а в худшем предлагать оплатить сделанную часть работ и разойтись по хорошему. оценочную трудоемкость при подписании договора умножили на 3 (можно на 33), навешав лапши клиенту — в этом важнейшее искусство ведения бизнеса кастомной разработки.


Умение работать по фиксу — оно должно быть взаимным. Т.е. и заказчик, и исполнитель должны жёстко играть в правила этой игры. Иначе да, будет ой, когда каждый пытается задокументировать хоть что-то, что можно в случае грядущих проблем предъявить как косяк и нарушение условий контракта.
Re: Нужен ли такой команде скрам?
От: scf  
Дата: 27.01.22 20:40
Оценка: 1 (1)
Здравствуйте, Yodo, Вы писали:

Y>Что не так? Нужен ли такой команде скрам?


Я пришел к выводу, что скрам нужен для низкоквалифицированных/немотивированных команд с сильным лидом. Чтобы жестко контролировать декомпозицию задач, понимание требований, сроки. Если команда сеньорная, когда каждый может взять юзер-стори и превратить её в качественный код за предсказуемое время, то канбан эффективнее.
Re[6]: Нужен ли такой команде скрам?
От: sr_dev  
Дата: 28.01.22 10:32
Оценка:
Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, sr_dev, Вы писали:


_>>фиксированный бюджет — это водопад и только водопад — описали задачу, согласовали, описали решение, согласовали, спланировали (тут подписали договор с кучей приложений), сделали.


MD>Сработает на малых проектах, но на больших — неизбежно "осмысление на ходу". Поэтому в такой реальности даже solution design и его обсуждение — это тоже отдельная статья расходов, которая может быть в итоге едва ли не половина бюджета.


_>>в действительности, конечно же, не "сделали", а сорвали сроки и пошли в лучшем случае извиняться, а в худшем предлагать оплатить сделанную часть работ и разойтись по хорошему. оценочную трудоемкость при подписании договора умножили на 3 (можно на 33), навешав лапши клиенту — в этом важнейшее искусство ведения бизнеса кастомной разработки.


MD>Умение работать по фиксу — оно должно быть взаимным. Т.е. и заказчик, и исполнитель должны жёстко играть в правила этой игры. Иначе да, будет ой, когда каждый пытается задокументировать хоть что-то, что можно в случае грядущих проблем предъявить как косяк и нарушение условий контракта.


Полностью согласен с вами.

Несмотря на тонны книг по управлению проектами и рисками, даже несмотря на половину стоимости проекта на дизайн и обсуждение — по-прежнему разработка по фикс прайсу это игра в кости. Бросаем первую кость — это сколько удалось согласовать бюджета. Бросаем вторую кость — это сколько стоило по факту (клиенту не говорим). Разницу кладем в карман или отдаем.

Исключение — это когда кастомизируем свой готовый продукт, который клиент уже успел полюбить.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.