Есть команда, пилит продукт по чему-то похжему на канбан. Задачи периодически появляются, назначаются, едут по доске слева на право, закрываются.
Обсуждения голосом каждый день плюс в Jira и мессенжерах.
Никаких стори-поинтов, сроков, дедлайнов, ретроспектив. Выпустили фичу, зарелизили. Параллельно каждый разработчик может вести 2-3 задачи.
Если одна блокируется по каким-то причинам, переключается на №2 и №3.
Т.е. так все неспешно течет, фичи делаются. Клиенты пользуются продуктом.
Б>Ты скажи, что не так. Что ты хочешь улучшить в процессе?
Процесс норм. Только выглядит скучным. Любая задача в нем, даже сложная — это текучка и рутина, которая тянется без сроков и тихо завершается, выходя в релиз либо закрываясь как не реализованная.
Технически все вроде неплохо. Но есть опасения, что рано или поздно такой подход приведет к выгоранию участников процесса и получится как в этой теме http://rsdn.org/forum/management/7947687.flat#7947687
Дельная мысль, которую она доносит — это обязательное подтверждение и осознание результата. А также использование результата как серотонинового "топлива" для следующей задачи.
Т.е. четкая последовательность: задача — результат — задача — результат. Т.е. подход со спринтами, который пропогандирует скрам и который является более дискретным и обязует бить задачи на подзадачи и на каждой подзадаче акцентировать результат. Но может же быть так — один разраб пилит задачу №1 — два месяца, второй пилит задачу №2 — три месяца и искуственно измельчать эти задачи смысла нет.
Т.е. вопрос такой. Дает ли подход со спринтами и явной фиксацией результатов плюс к боевому духу команды и отдельных ее участников или же все сваливается также в рутину.
В случае скрама, цель — "дать что-то ценное стейкхолдеру, совершить итерацию +1". Такая цель ведет зачастую к итерациям ради итераций и к измелчению задач ради того чтобы засунуть в спринт и распределить.
В случае продуктового "нескрама", цель — эволюционно улучшать продукт, обеспечивая ему конкурентное преимущество. Т.е. неважно сколько было итераций, важно вывести какую-то крупную фичу или стратегическое изменение в релиз. И на это может уйти например год.
Здравствуйте, Yodo, Вы писали:
Y>В случае скрама, цель — "дать что-то ценное стейкхолдеру, совершить итерацию +1". Такая цель ведет зачастую к итерациям ради итераций и к измелчению задач ради того чтобы засунуть в спринт и распределить. Y>В случае продуктового "нескрама", цель — эволюционно улучшать продукт, обеспечивая ему конкурентное преимущество. Т.е. неважно сколько было итераций, важно вывести какую-то крупную фичу или стратегическое изменение в релиз. И на это может уйти например год.
Если у вас фиксированных сроков или бюджета (что то же самое по сути) нет, то IMHO скрам вам не нужен.
Здравствуйте, bnk, Вы писали:
bnk>Если у вас фиксированных сроков или бюджета (что то же самое по сути) нет, то IMHO скрам вам не нужен.
а если есть — то тем более. фиксированный бюджет и итерации вещи несовместимые по очевидной причине — итераций может быть сколько угодно.
фиксированный бюджет — это водопад и только водопад — описали задачу, согласовали, описали решение, согласовали, спланировали (тут подписали договор с кучей приложений), сделали.
в действительности, конечно же, не "сделали", а сорвали сроки и пошли в лучшем случае извиняться, а в худшем предлагать оплатить сделанную часть работ и разойтись по хорошему. оценочную трудоемкость при подписании договора умножили на 3 (можно на 33), навешав лапши клиенту — в этом важнейшее искусство ведения бизнеса кастомной разработки.
умные заказчики не работают по фикс прайсу, но неумных на рынке процентов 70 минимум. исполнители же ненавидят фикс прайс все без исключений.
Здравствуйте, Yodo, Вы писали:
Y>Есть команда, пилит продукт по чему-то похжему на канбан. Задачи периодически появляются, назначаются, едут по доске слева на право, закрываются. Y>Обсуждения голосом каждый день плюс в Jira и мессенжерах.
Y>Никаких стори-поинтов, сроков, дедлайнов, ретроспектив. Выпустили фичу, зарелизили. Параллельно каждый разработчик может вести 2-3 задачи. Y>Если одна блокируется по каким-то причинам, переключается на №2 и №3.
Y>Т.е. так все неспешно течет, фичи делаются. Клиенты пользуются продуктом.
Y>Что не так? Нужен ли такой команде скрам?
скрам этой команде нужен как диарея, а скрам коучи как туберкулёз.
понятная ваша мысль про серотониновое топливо, но триггер закрытия куска работы у девелопера есть и без спринтов — достаточно тикетов на доске. а вот 20-25% рабочего времени в митингах (груминги, ретроспективы, коллективные планинги, покеры со стори-поинтами) у кого-то могут вызвать явление, называемое "корчи вампира на солнце"
Нет. Что нужно, это team building + offsites, плюс либо хорошие деньги (чтобы работали за деньги), либо реально драйвовый продукт (чтобы гордиться им).
Здравствуйте, Yodo, Вы писали:
Б>>Ты скажи, что не так. Что ты хочешь улучшить в процессе?
Y>Дельная мысль, которую она доносит — это обязательное подтверждение и осознание результата. А также использование результата как серотонинового "топлива" для следующей задачи.
Меньше слушая коучей.
Если очень хочешь, то добавь в текущий процесс фиксацию результата — демо по сложным задачам, неформальные сборы раз в пару недель "похвастаться", приноси внутрь обратную связь от клиентов — это гораздо лучше и эффективнее, чем скрам.
Y>Т.е. вопрос такой. Дает ли подход со спринтами и явной фиксацией результатов плюс к боевому духу команды и отдельных ее участников или же все сваливается также в рутину.
Здравствуйте, Yodo, Вы писали:
Y>Дельная мысль, которую она доносит — это обязательное подтверждение и осознание результата. А также использование результата как серотонинового "топлива" для следующей задачи.
Вы внимательно ее слушали? Она там же говорит, что авторизация результата — это внутренний индивидуальный процесс. И самые хорошие лидеры учат членов команды делать это самостоятельно.
Y>Т.е. четкая последовательность: задача — результат — задача — результат.
И в зависимости от решаемых задач приносит это все на уровень рутины/повторяющихся действий. Может убивать всю тягу к исследованиям (большие задачи здесь хороши) и заодно мотивацию.
Y>Т.е. вопрос такой. Дает ли подход со спринтами и явной фиксацией результатов плюс к боевому духу команды и отдельных ее участников или же все сваливается также в рутину.
При такой постановке вопроса — снизит боевой дух и достаточно быстро приведет к выгоранию.
Вы уже пытаетесь ввести универсальную меру "достижения" как решение бизнес-задач. Что расценивается как попытки лишить индивидуальности. В рамках презентации — вы сразу же всех засовываете на уровень энергии ниже 45%. На уровне выше у каждого члена команды свои цели. И именно эти индивидуальные цели дают основной вклад в личную мотивацию, самосознание и росту. А решение бизнес-задач — побочный продукт саморазвития. Это не значит, что людям плевать. Это значит, что это не основной результат для них. Включать его в мотивацию можно, но нужно очень аккуратно все делать (у меня это обычно часть identity команды а не индивидуума).
И это в лучшем случае вы получите энергию в районе 40%. А в худшем получится бюрократическая организация с (ожидаемым) уровнем энергии порядка 20%. Для организации по разработке ПО ниже уже особо некуда. Я конечно не знаю, может у вас там все ужасно и рост до 35-40% будет прогрессом. Но для этого нужно индивидуально со всеми заниматься, понимать текущее состояние, разрабатывать планы развития и т.п.
Для начала я советую посмотреть на вашу личную мотивацию. Очень много признаков того, что вы просто хотите занять доминантную позицию. Это, в свою очередь, происходит из-за того, что команда уже работает хорошо и роль "организатора процессов" ей не особо нужна. Вы воспринимаете это как угрозу и включаете соответствующее поведение. Стоит разобраться в ситуации и выяснить, сколько внимания в текущей роли нужно уделять данной команде, каких (других) ролей ей не хватает, где основные проблемы. Может быть — переключиться на другие команды. Потом уже можно смотреть, что происходит в команде, какие объективные проблемы (а не просто "вам скучно") и т.д. Собирать обратную связь. Причем в таком виде, чтобы вам доверяли и говорили про реальные вещи. Может, разработчиков то все устраивает и у них есть свои достижения, которые вы просто не видите?
Здравствуйте, Yodo, Вы писали:
Y>Что не так? Нужен ли такой команде скрам?
Работает — не трогай. Такой команде скрам не нужен, но он может быть нужен заказчикам для определенности по срокам. В скраме у задачи есть трудоемкость и сроки, без скрама — "сделаем когда-нибудь"
Здравствуйте, Yodo, Вы писали:
Y>Что не так? Нужен ли такой команде скрам?
Всё нормально, скрам такой команде не нужен.
Скрам — это про управление ожиданиями. Если вопрос управления ожиданиями не стоит (потому что нет ожиданий или потому что они как-то и так уже управляются), то всё в порядке.
Скрам — это когда есть чувак с бабками, который толком не может объяснить что хочет, и есть команда, которая способна сделать что нужно, только вот выяснить что именно нужно — практически невозможно. Тут скрам приходит и говорит: самый большой фейл, который может произойти — это 2 недели работы на выброс — хуже этого не будет.
Здравствуйте, sr_dev, Вы писали:
_>понятная ваша мысль про серотониновое топливо, но триггер закрытия куска работы у девелопера есть и без спринтов — достаточно тикетов на доске.
_>а вот 20-25% рабочего времени в митингах (груминги, ретроспективы, коллективные планинги, покеры со стори-поинтами) у кого-то могут вызвать явление, называемое "корчи вампира на солнце"
Из моего опыта все эти церемонии часто получаются бестолковыми из-за того, что их драйвят очень специфические люди. Реакционисты, далёкие от реальности проекта, анти-токсичные, позитивно настроенные. Плохо, что баг попал в продакшн, но всё равно мы молодцы (вместо давайте прикинем как он пролез, как избежать в будущем). Вася до 3 часов ночи сидел и деплоил руками — такой герой-молодец (вместо как нам сделать более надёжные процедуры деплоймента).
Здравствуйте, sr_dev, Вы писали:
_>фиксированный бюджет — это водопад и только водопад — описали задачу, согласовали, описали решение, согласовали, спланировали (тут подписали договор с кучей приложений), сделали.
Сработает на малых проектах, но на больших — неизбежно "осмысление на ходу". Поэтому в такой реальности даже solution design и его обсуждение — это тоже отдельная статья расходов, которая может быть в итоге едва ли не половина бюджета.
_>в действительности, конечно же, не "сделали", а сорвали сроки и пошли в лучшем случае извиняться, а в худшем предлагать оплатить сделанную часть работ и разойтись по хорошему. оценочную трудоемкость при подписании договора умножили на 3 (можно на 33), навешав лапши клиенту — в этом важнейшее искусство ведения бизнеса кастомной разработки.
Умение работать по фиксу — оно должно быть взаимным. Т.е. и заказчик, и исполнитель должны жёстко играть в правила этой игры. Иначе да, будет ой, когда каждый пытается задокументировать хоть что-то, что можно в случае грядущих проблем предъявить как косяк и нарушение условий контракта.
Здравствуйте, Yodo, Вы писали:
Y>Что не так? Нужен ли такой команде скрам?
Я пришел к выводу, что скрам нужен для низкоквалифицированных/немотивированных команд с сильным лидом. Чтобы жестко контролировать декомпозицию задач, понимание требований, сроки. Если команда сеньорная, когда каждый может взять юзер-стори и превратить её в качественный код за предсказуемое время, то канбан эффективнее.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, sr_dev, Вы писали:
_>>фиксированный бюджет — это водопад и только водопад — описали задачу, согласовали, описали решение, согласовали, спланировали (тут подписали договор с кучей приложений), сделали.
MD>Сработает на малых проектах, но на больших — неизбежно "осмысление на ходу". Поэтому в такой реальности даже solution design и его обсуждение — это тоже отдельная статья расходов, которая может быть в итоге едва ли не половина бюджета.
_>>в действительности, конечно же, не "сделали", а сорвали сроки и пошли в лучшем случае извиняться, а в худшем предлагать оплатить сделанную часть работ и разойтись по хорошему. оценочную трудоемкость при подписании договора умножили на 3 (можно на 33), навешав лапши клиенту — в этом важнейшее искусство ведения бизнеса кастомной разработки.
MD>Умение работать по фиксу — оно должно быть взаимным. Т.е. и заказчик, и исполнитель должны жёстко играть в правила этой игры. Иначе да, будет ой, когда каждый пытается задокументировать хоть что-то, что можно в случае грядущих проблем предъявить как косяк и нарушение условий контракта.
Полностью согласен с вами.
Несмотря на тонны книг по управлению проектами и рисками, даже несмотря на половину стоимости проекта на дизайн и обсуждение — по-прежнему разработка по фикс прайсу это игра в кости. Бросаем первую кость — это сколько удалось согласовать бюджета. Бросаем вторую кость — это сколько стоило по факту (клиенту не говорим). Разницу кладем в карман или отдаем.
Исключение — это когда кастомизируем свой готовый продукт, который клиент уже успел полюбить.