британские ученые, говорят, всё измерили )

Ошибка объединения. В 99.99% случаев эти 15 минут будут бездарно просраны каждым пользователем.

Наконец-то без "не"-конструкций! Как же это здорово!

https://less.works/case-studis/mts-kassa.html кейс про нас вышел. Еще не читал. @MurriMay спасибо!

А здесь вообще про Agile говорят? Или объвления обсуждают?))

Я не в курсе такого хайпа. Каждой конструкции свое применение. Новый плакат крутой.

Ну вот у меня конкретная проблема: Она длиться от спринта к спринту Вот на примере текущего: 4 разработчика оценили Задачи на спринт на 12.5 Стори поинтов в сумме (мы их считаем, как Число рабочих часов на неделе * на фокус фактор члена команды, т.е сколько процентов времени он эффективно выполняет задачи) Через 2 часа спринт заканчивается, выполнено 7 sp Добавлено задач на 7 sp в итоге как было 12.5 sp, так и осталось На данный момент проблемы в следующем (как мне кажется): 1. Команда не умеет находить проблемы и решать их Задача, запланированная на 1 час, выполняется больше 8. Когда спрашиваешь, в чем проблема, объяснить не могут, решить самостоятельно тоже не могут, помощи попросить не могут, потому что не могут объяснить. Это проблема некомпитентности разработчиков - или вопрос обучения? (Увольнять или учить?) 2. Никто не может планировать и составлять схемы Когда начинают делать одну задачу, выясняется, что сначала нужно сделать еще 2 и так в лес по дрова Я предполагаю, что может быть проблема в том, что Мы работаем на своем движке php и когда писали его, схемы его работы не было Но такое случается даже с простейшими задачами типа "Сверстать блок-слайдер" В общем, у меня два вопроа: 1. как научить людей планировать? 2. как научить людей находить и формулировать проблему? (я не говорю уже о решении)

По сколько SP команда делала в предыдущие спринты? Так же по 7 из 12 взятых или успевали все?

Ну то есть в прошлый спринт выполнили 13 из 24

Наконец!

Как это? КОманда в прошлый спринт была вдвое мощнее?

Если в часах планировать не получается, может стоит попробовать в сторипойнтах без привязки к часам?

Ну вот у меня конкретная проблема: Она длиться от спринта к спринту Вот на примере текущего: 4 разработчика оценили Задачи на спринт на 12.5 Стори поинтов в сумме (мы их считаем, как Число рабочих часов на неделе * на фокус фактор члена команды, т.е сколько процентов времени он эффективно выполняет задачи) Через 2 часа спринт заканчивается, выполнено 7 sp Добавлено задач на 7 sp в итоге как было 12.5 sp, так и осталось На данный момент проблемы в следующем (как мне кажется): 1. Команда не умеет находить проблемы и решать их Задача, запланированная на 1 час, выполняется больше 8. Когда спрашиваешь, в чем проблема, объяснить не могут, решить самостоятельно тоже не могут, помощи попросить не могут, потому что не могут объяснить. Это проблема некомпитентности разработчиков - или вопрос обучения? (Увольнять или учить?) 2. Никто не может планировать и составлять схемы Когда начинают делать одну задачу, выясняется, что сначала нужно сделать еще 2 и так в лес по дрова Я предполагаю, что может быть проблема в том, что Мы работаем на своем движке php и когда писали его, схемы его работы не было Но такое случается даже с простейшими задачами типа "Сверстать блок-слайдер" В общем, у меня два вопроа: 1. как научить людей планировать? 2. как научить людей находить и формулировать проблему? (я не говорю уже о решении)

Я за Всех уволить )

Вообще да, обучить и уволить:)

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

Там нет тим Лида. Был наставник в течение месяца после найма Теперь они (новички)- отдельная команда уже месяц Но у них чет не получается ничего))

Вам точно на этом проекте нужен именно скрам?

Там нет тим Лида. Был наставник в течение месяца после найма Теперь они (новички)- отдельная команда уже месяц Но у них чет не получается ничего))

Нет конечно. Вот как с тобой сложно, ты сам про это начал. Сейчас вот Pavel начнет бомбить и плавно в пятницу приплывем. Я на полном серъезе одно время хотел рассмотреть под микроскопом труды Ленина и его поведение в разрезе современных концепций менеджмента. Т.е наложить "сейчас" на "тогда". Думаю очень интересно было бы.

Слушайте, вопрос - вам не кажется, что в слове instead есть некое противоречие, как будто кроме импрувментов в бэклоге спринта больше ничего нет?

Instead of это не только «вместо», но и «кроме». Instead of <only>.

Ну вот у меня конкретная проблема: Она длиться от спринта к спринту Вот на примере текущего: 4 разработчика оценили Задачи на спринт на 12.5 Стори поинтов в сумме (мы их считаем, как Число рабочих часов на неделе * на фокус фактор члена команды, т.е сколько процентов времени он эффективно выполняет задачи) Через 2 часа спринт заканчивается, выполнено 7 sp Добавлено задач на 7 sp в итоге как было 12.5 sp, так и осталось На данный момент проблемы в следующем (как мне кажется): 1. Команда не умеет находить проблемы и решать их Задача, запланированная на 1 час, выполняется больше 8. Когда спрашиваешь, в чем проблема, объяснить не могут, решить самостоятельно тоже не могут, помощи попросить не могут, потому что не могут объяснить. Это проблема некомпитентности разработчиков - или вопрос обучения? (Увольнять или учить?) 2. Никто не может планировать и составлять схемы Когда начинают делать одну задачу, выясняется, что сначала нужно сделать еще 2 и так в лес по дрова Я предполагаю, что может быть проблема в том, что Мы работаем на своем движке php и когда писали его, схемы его работы не было Но такое случается даже с простейшими задачами типа "Сверстать блок-слайдер" В общем, у меня два вопроа: 1. как научить людей планировать? 2. как научить людей находить и формулировать проблему? (я не говорю уже о решении)

Вообще как работало у меня. Если в течение пары месяцев прогресс не наблюдался (с попаданием в оценку) и тимлид сам же в свою оценку не попадал, при этом у него не находилось адекватных аргументов на этот счет, я убирал тимлида из команды в другую (где, может, он бы показал себя лучше). А так, с тимлидом обычно всегда получалось договориться. Конечно, вначале все было не очень. Но постепенно попадание выходило на 100%. Из того, что работало: 1. Не брать в оценку задачи, если есть открытые вопросы по вводным 2. Не давать оценку, если могут возникнуть непредвиденные обстоятельства (например риск сломать что-то рядом) 3. Если зеленый разработчик дает оценку, то делает это вместе с тимлидом. Тимлид задает наводящие вопросы, в процессе которых сам разработчик догадывается, где он ошибся с оценкой. 4. Если задача совсем непонятная, по сути - RnD, то дается оценка на исследование, где оговаривается, каких результатво по исследованию нужно достичь. И так, итеративно задача проясняется и можно уже дать более точную оценку. 5. Ключевое, если уж ты оценил, то старайся свое слово сдержать и не подвести команду. Это касаемо именно решения технических вопросов планирования. Ну и понятно анализ итогов спринта, закладывание времени на тестирование и прочие штуки, которые отнимают время, но почему-то не учитываются при планировании. Без тимлида ,наверное, никак. Даже формально если его нет, должен быть разработчик, который по компетенциям должен быть лидером проекта, отвечающим за техническую часть. Обычно за 2-3 месяца планирование удавалось выстроить

Твоя ошибка, что ты используешь абсолютные оценки вместо относительных и называешь это sp ) Вторая проблема - команда работает всего месяц, ей еще месяц пристретиваться придется. В связи с этим вопрос - как ты поддерживаешь процесс пристреливания?

В процессе пристреливания команда должна понять что такое sp и понять свою производительность. Какие действия ты для этого предпринял?

Можно так сделать - взять средненькую задачу и дать ей скажем 3sp Дальше задачи сравнимать с ней и относительно нее уже давать 5, 8 , 13 или 1,2 sp

Дело в том, что такую оценку использовали до меня и по сути я пристреливаюсь Выше уже писали, что нужно попробовать оценивать не в планируемых идеальных часах, а в настоящих (не наших xD) стори поинтах

в одной команде мы разделили поинты и часы. историю оцениваем в поинтах, потом бьем на задачи и их уже в часах. через 2 месяца оказалось, что мы набираем по часам всегда на сторипоинтов 55-60 а закрываем стабильно 35-40 после этого команда отказалась от часов

а сколько длится спринт?

Я к тому что вы изначально sp взяли как часы (да с учетом фокус фактора), но тем не менее. Это не объем+сложность+неопределенность. Это просто часы.

сегодня проведу ретро, посмотрим, что еще выяснится)

Я к тому что вы изначально sp взяли как часы (да с учетом фокус фактора), но тем не менее. Это не объем+сложность+неопределенность. Это просто часы.

Кстати, на ретро говорят они или ты? :)

Ретроспектива начнется сразу после завершения Демо. До начала ретроспективы КАЖДЫЙ должен написать: STOP - действия, которые не приносят пользы LESS - действия, ценности от которых меньше, чем усилий KEEP - действия, которые мы делаем и хотим сохранить MORE - действия, которые нужно выполнять чаще START - действия или идеи, которые нужно привнести в команду Как будет проходить ретроспектива: 1. На доске нарисован круг, разбитый на 5 частей. 2. Спрашиваю КАЖДОГО, какие действия он записал в STOP. 3. Начинаем дискуссию на 5 минут - заполняем поле STOP 4. Переходим к LESS 5. Повторяем вот с прошлой недели так

А как все-таки определять, сколько SP закладывать на спринт?

Эмпирически. Возьмите на спринт 30. Успели - молодцы. В след раз берите больше. Не успели - сокращайте колиество. Потом ориентируйтесь на среднее за 3-5 спринтов.

Есть сайтик 1000 и 1 ретроспектива )) Или как-то так. Можно провести игровую ретру чтобы расслабить ребят. Расслабятся - начнут вовлекаться в развитие команды и процессов.

http://www.funretrospectives.com/

Тогда точно всех уволить)