Dеfault
британские ученые, говорят, всё измерили )
британские учёные всегда что-то говорят)))
Ivan
ну хоть какие-то ученые говорят, что уже хорошо 👍 😉
Yuriy
Представляюсь: - Компания Radeant - Не специалист, начинающий Scrum Master - За время работы решил множество проблем своей команды, могу подсказать, если у кого-то будут аналогичные проблемы - Ищу людей, у которых возникают такие же проблемы с командой, как и у меня. Тех, кто решал или пытается их решить. - Казань - Гуггл #whois
Marina
Marina
Внутренний тренинг так еще не называли :)
Denis
Наконец-то без "не"-конструкций! Как же это здорово!
Denis
Ошибка объединения. В 99.99% случаев эти 15 минут будут бездарно просраны каждым пользователем.
Artem
спокойней относитесь к "не" конструкциям ) Хайп прошел пару лет назад
Denis
Я не в курсе такого хайпа. Каждой конструкции свое применение. Новый плакат крутой.
Yuriy
А здесь вообще про Agile говорят? Или объвления обсуждают?))
Yuriy
Ну вот у меня конкретная проблема: Она длиться от спринта к спринту Вот на примере текущего: 4 разработчика оценили Задачи на спринт на 12.5 Стори поинтов в сумме (мы их считаем, как Число рабочих часов на неделе * на фокус фактор члена команды, т.е сколько процентов времени он эффективно выполняет задачи) Через 2 часа спринт заканчивается, выполнено 7 sp Добавлено задач на 7 sp в итоге как было 12.5 sp, так и осталось На данный момент проблемы в следующем (как мне кажется): 1. Команда не умеет находить проблемы и решать их Задача, запланированная на 1 час, выполняется больше 8. Когда спрашиваешь, в чем проблема, объяснить не могут, решить самостоятельно тоже не могут, помощи попросить не могут, потому что не могут объяснить. Это проблема некомпитентности разработчиков - или вопрос обучения? (Увольнять или учить?) 2. Никто не может планировать и составлять схемы Когда начинают делать одну задачу, выясняется, что сначала нужно сделать еще 2 и так в лес по дрова Я предполагаю, что может быть проблема в том, что Мы работаем на своем движке php и когда писали его, схемы его работы не было Но такое случается даже с простейшими задачами типа "Сверстать блок-слайдер" В общем, у меня два вопроа: 1. как научить людей планировать? 2. как научить людей находить и формулировать проблему? (я не говорю уже о решении)
Denis
Ну вот у меня конкретная проблема: Она длиться от спринта к спринту Вот на примере текущего: 4 разработчика оценили Задачи на спринт на 12.5 Стори поинтов в сумме (мы их считаем, как Число рабочих часов на неделе * на фокус фактор члена команды, т.е сколько процентов времени он эффективно выполняет задачи) Через 2 часа спринт заканчивается, выполнено 7 sp Добавлено задач на 7 sp в итоге как было 12.5 sp, так и осталось На данный момент проблемы в следующем (как мне кажется): 1. Команда не умеет находить проблемы и решать их Задача, запланированная на 1 час, выполняется больше 8. Когда спрашиваешь, в чем проблема, объяснить не могут, решить самостоятельно тоже не могут, помощи попросить не могут, потому что не могут объяснить. Это проблема некомпитентности разработчиков - или вопрос обучения? (Увольнять или учить?) 2. Никто не может планировать и составлять схемы Когда начинают делать одну задачу, выясняется, что сначала нужно сделать еще 2 и так в лес по дрова Я предполагаю, что может быть проблема в том, что Мы работаем на своем движке php и когда писали его, схемы его работы не было Но такое случается даже с простейшими задачами типа "Сверстать блок-слайдер" В общем, у меня два вопроа: 1. как научить людей планировать? 2. как научить людей находить и формулировать проблему? (я не говорю уже о решении)
По сколько SP команда делала в предыдущие спринты? Так же по 7 из 12 взятых или успевали все?
Yuriy
Ну то есть в прошлый спринт выполнили 13 из 24
Denis
Ну то есть в прошлый спринт выполнили 13 из 24
Как это? КОманда в прошлый спринт была вдвое мощнее?
Yuriy
Наконец!
нет ли здесь локальной оптимизации?)
Yuriy
Сейчас php + вёрстка + js
Denis
Если в часах планировать не получается, может стоит попробовать в сторипойнтах без привязки к часам?
Yuriy
Однако, все равно остаются открытыми мои вопросы
Глебка
Я за Всех уволить )
Nail’
Ну вот у меня конкретная проблема: Она длиться от спринта к спринту Вот на примере текущего: 4 разработчика оценили Задачи на спринт на 12.5 Стори поинтов в сумме (мы их считаем, как Число рабочих часов на неделе * на фокус фактор члена команды, т.е сколько процентов времени он эффективно выполняет задачи) Через 2 часа спринт заканчивается, выполнено 7 sp Добавлено задач на 7 sp в итоге как было 12.5 sp, так и осталось На данный момент проблемы в следующем (как мне кажется): 1. Команда не умеет находить проблемы и решать их Задача, запланированная на 1 час, выполняется больше 8. Когда спрашиваешь, в чем проблема, объяснить не могут, решить самостоятельно тоже не могут, помощи попросить не могут, потому что не могут объяснить. Это проблема некомпитентности разработчиков - или вопрос обучения? (Увольнять или учить?) 2. Никто не может планировать и составлять схемы Когда начинают делать одну задачу, выясняется, что сначала нужно сделать еще 2 и так в лес по дрова Я предполагаю, что может быть проблема в том, что Мы работаем на своем движке php и когда писали его, схемы его работы не было Но такое случается даже с простейшими задачами типа "Сверстать блок-слайдер" В общем, у меня два вопроа: 1. как научить людей планировать? 2. как научить людей находить и формулировать проблему? (я не говорю уже о решении)
По опыту - обычно дело или в людях или в тимлиде. Если разработчики не очень самостоятельны, обычно их подтягивает тимлид, подсказывая пути решений и периодически собирая от них обратку
Yuriy
Я за Всех уволить )
Может сначала как то обучить?) или такое не поддаётся обучению?))
Глебка
Эт сарказм)
Глебка
Вообще да, обучить и уволить:)
Nail’
Вообще да, обучить и уволить:)
Считай, благотворительность))
Глебка
Ага)
Yuriy
По опыту - обычно дело или в людях или в тимлиде. Если разработчики не очень самостоятельны, обычно их подтягивает тимлид, подсказывая пути решений и периодически собирая от них обратку
Там нет тим Лида. Был наставник в течение месяца после найма Теперь они (новички)- отдельная команда уже месяц Но у них чет не получается ничего))
Yuriy
Его просто нужно сделать нормально
Yuriy
Когда я пришёл сюда, он был сломан))
Konstantin
я бы заставил всех поработать в парах
Konstantin
подтянуть до одного уровня команду
Konstantin
совсем распиздяев которые сильно будут выбиваться наверное уволить
Konstantin
потом уже все остальное
Nail’
Там нет тим Лида. Был наставник в течение месяца после найма Теперь они (новички)- отдельная команда уже месяц Но у них чет не получается ничего))
Вообще как работало у меня. Если в течение пары месяцев прогресс не наблюдался (с попаданием в оценку) и тимлид сам же в свою оценку не попадал, при этом у него не находилось адекватных аргументов на этот счет, я убирал тимлида из команды в другую (где, может, он бы показал себя лучше). А так, с тимлидом обычно всегда получалось договориться. Конечно, вначале все было не очень. Но постепенно попадание выходило на 100%. Из того, что работало: 1. Не брать в оценку задачи, если есть открытые вопросы по вводным 2. Не давать оценку, если могут возникнуть непредвиденные обстоятельства (например риск сломать что-то рядом) 3. Если зеленый разработчик дает оценку, то делает это вместе с тимлидом. Тимлид задает наводящие вопросы, в процессе которых сам разработчик догадывается, где он ошибся с оценкой. 4. Если задача совсем непонятная, по сути - RnD, то дается оценка на исследование, где оговаривается, каких результатво по исследованию нужно достичь. И так, итеративно задача проясняется и можно уже дать более точную оценку. 5. Ключевое, если уж ты оценил, то старайся свое слово сдержать и не подвести команду. Это касаемо именно решения технических вопросов планирования. Ну и понятно анализ итогов спринта, закладывание времени на тестирование и прочие штуки, которые отнимают время, но почему-то не учитываются при планировании. Без тимлида ,наверное, никак. Даже формально если его нет, должен быть разработчик, который по компетенциям должен быть лидером проекта, отвечающим за техническую часть. Обычно за 2-3 месяца планирование удавалось выстроить
Jane
Паззл сошелся 🙂
Vladimir
Ну вот у меня конкретная проблема: Она длиться от спринта к спринту Вот на примере текущего: 4 разработчика оценили Задачи на спринт на 12.5 Стори поинтов в сумме (мы их считаем, как Число рабочих часов на неделе * на фокус фактор члена команды, т.е сколько процентов времени он эффективно выполняет задачи) Через 2 часа спринт заканчивается, выполнено 7 sp Добавлено задач на 7 sp в итоге как было 12.5 sp, так и осталось На данный момент проблемы в следующем (как мне кажется): 1. Команда не умеет находить проблемы и решать их Задача, запланированная на 1 час, выполняется больше 8. Когда спрашиваешь, в чем проблема, объяснить не могут, решить самостоятельно тоже не могут, помощи попросить не могут, потому что не могут объяснить. Это проблема некомпитентности разработчиков - или вопрос обучения? (Увольнять или учить?) 2. Никто не может планировать и составлять схемы Когда начинают делать одну задачу, выясняется, что сначала нужно сделать еще 2 и так в лес по дрова Я предполагаю, что может быть проблема в том, что Мы работаем на своем движке php и когда писали его, схемы его работы не было Но такое случается даже с простейшими задачами типа "Сверстать блок-слайдер" В общем, у меня два вопроа: 1. как научить людей планировать? 2. как научить людей находить и формулировать проблему? (я не говорю уже о решении)
Твоя ошибка, что ты используешь абсолютные оценки вместо относительных и называешь это sp ) Вторая проблема - команда работает всего месяц, ей еще месяц пристретиваться придется. В связи с этим вопрос - как ты поддерживаешь процесс пристреливания?
Vladimir
В процессе пристреливания команда должна понять что такое sp и понять свою производительность. Какие действия ты для этого предпринял?
Konstantin
+++
Yuriy
Вообще как работало у меня. Если в течение пары месяцев прогресс не наблюдался (с попаданием в оценку) и тимлид сам же в свою оценку не попадал, при этом у него не находилось адекватных аргументов на этот счет, я убирал тимлида из команды в другую (где, может, он бы показал себя лучше). А так, с тимлидом обычно всегда получалось договориться. Конечно, вначале все было не очень. Но постепенно попадание выходило на 100%. Из того, что работало: 1. Не брать в оценку задачи, если есть открытые вопросы по вводным 2. Не давать оценку, если могут возникнуть непредвиденные обстоятельства (например риск сломать что-то рядом) 3. Если зеленый разработчик дает оценку, то делает это вместе с тимлидом. Тимлид задает наводящие вопросы, в процессе которых сам разработчик догадывается, где он ошибся с оценкой. 4. Если задача совсем непонятная, по сути - RnD, то дается оценка на исследование, где оговаривается, каких результатво по исследованию нужно достичь. И так, итеративно задача проясняется и можно уже дать более точную оценку. 5. Ключевое, если уж ты оценил, то старайся свое слово сдержать и не подвести команду. Это касаемо именно решения технических вопросов планирования. Ну и понятно анализ итогов спринта, закладывание времени на тестирование и прочие штуки, которые отнимают время, но почему-то не учитываются при планировании. Без тимлида ,наверное, никак. Даже формально если его нет, должен быть разработчик, который по компетенциям должен быть лидером проекта, отвечающим за техническую часть. Обычно за 2-3 месяца планирование удавалось выстроить
Вот это очень полезно, спасибо
Yuriy
Твоя ошибка, что ты используешь абсолютные оценки вместо относительных и называешь это sp ) Вторая проблема - команда работает всего месяц, ей еще месяц пристретиваться придется. В связи с этим вопрос - как ты поддерживаешь процесс пристреливания?
Дело в том, что такую оценку использовали до меня и по сути я пристреливаюсь Выше уже писали, что нужно попробовать оценивать не в планируемых идеальных часах, а в настоящих (не наших xD) стори поинтах
Vladimir
Можно так сделать - взять средненькую задачу и дать ей скажем 3sp Дальше задачи сравнимать с ней и относительно нее уже давать 5, 8 , 13 или 1,2 sp
Yuriy
В процессе пристреливания команда должна понять что такое sp и понять свою производительность. Какие действия ты для этого предпринял?
По сути такая абсолютная оценка нужна была для расчета производителности Как ее считали: Выполнил задачу на 3 SP за 5 часов, значит, производительность 0.6 sp/час
Yuriy
мне понадобилось 3 недели, чтобы разбить команду из 12 человек на разные)
Vladimir
Оценка в часах в принципе не дает понимания о производительности команды.
Vasilii
Дело в том, что такую оценку использовали до меня и по сути я пристреливаюсь Выше уже писали, что нужно попробовать оценивать не в планируемых идеальных часах, а в настоящих (не наших xD) стори поинтах
в одной команде мы разделили поинты и часы. историю оцениваем в поинтах, потом бьем на задачи и их уже в часах. через 2 месяца оказалось, что мы набираем по часам всегда на сторипоинтов 55-60 а закрываем стабильно 35-40 после этого команда отказалась от часов
Vladimir
Производительность это объем работы (или разрешенная сложность, неопределенность) в единицу времени. А вы просто считали часы... и непонятно как из часов вытекает производительность.
Vladimir
Я к тому что вы изначально sp взяли как часы (да с учетом фокус фактора), но тем не менее. Это не объем+сложность+неопределенность. Это просто часы.
Vladimir
А вобще - успехов! Задача сложная но интересная )
Vladimir
Пиши по результатам еще :)
Yuriy
сегодня проведу ретро, посмотрим, что еще выяснится)
Vladimir
сегодня проведу ретро, посмотрим, что еще выяснится)
Кстати, на ретро говорят они или ты? :)
Vasilii
Я к тому что вы изначально sp взяли как часы (да с учетом фокус фактора), но тем не менее. Это не объем+сложность+неопределенность. Это просто часы.
+ от этого нужно уходить. но это происходит сложно. Был кейс, когда разработчик перешел в команду из другой команды. В его старой SP были привязаны к часам, а в новой - нет. Он долго пытался выведать у ребят, сколько же часов один SP, на что команда не могла ответить) было забавно наблюдать) Однажды он задал вопрос дизайнеру, сколько SP у нее в спринте. Дизайнер впла в ступор и вопросительно посмотрел на меня) Но сейчас все хорошо) чувак понял смысл этой оценки, но ушел месяц на это)
Yuriy
Кстати, на ретро говорят они или ты? :)
Ретроспектива начнется сразу после завершения Демо. До начала ретроспективы КАЖДЫЙ должен написать: STOP - действия, которые не приносят пользы LESS - действия, ценности от которых меньше, чем усилий KEEP - действия, которые мы делаем и хотим сохранить MORE - действия, которые нужно выполнять чаще START - действия или идеи, которые нужно привнести в команду Как будет проходить ретроспектива: 1. На доске нарисован круг, разбитый на 5 частей. 2. Спрашиваю КАЖДОГО, какие действия он записал в STOP. 3. Начинаем дискуссию на 5 минут - заполняем поле STOP 4. Переходим к LESS 5. Повторяем вот с прошлой недели так
Yuriy
А как все-таки определять, сколько SP закладывать на спринт?
Vasilii
А как все-таки определять, сколько SP закладывать на спринт?
Эмпирически. Возьмите на спринт 30. Успели - молодцы. В след раз берите больше. Не успели - сокращайте колиество. Потом ориентируйтесь на среднее за 3-5 спринтов.
Yuriy
проходит весело и активно
Vladimir
круто!
Vladimir
http://www.funretrospectives.com/
Yuriy
http://www.funretrospectives.com/
У нас много удаленщиков, с этим еще проблема)
Глебка
Тогда точно всех уволить)