в команде бэкенд разработчик, фронтенд разработчик и тестировщик. Оценивается ведь стори, а не ее сабтаски, которые как раз идут разработчикам или тестировщикам? И тут если в стори есть 4 сабтаски: фронт, бэк и 2 таски тестировщика, то как оценивать стори? Даже если разработка ведется параллельно, кто то может свою работу сделать быстрее.
А вы с какой целью оценки делаете? Считать нагрузку и FTE, или капасити всей команды?
Пока не делаю. Пока пытаюсь разобраться как это должно быть. Желательно что бы никто особо не просиживал долго, ожидая другого разработчика.
О, тогда вот этот видос смотреть и зубрить https://m.youtube.com/watch?v=CostXs2p6r0
Оцениваются User Story. Оценивает вся команд. Для того чтобы оценка была корректной стори предварительно прорабатывается всей командой, дробится на тех.таски и обсуждаются возможные риски на каждом этапе. Не стоит заводить отдельных тасок на тестирование или аналитику, так как это этап для любой тех.задачи
В оценке сторей может ли некомпетентная масса тех кто считает что изи, перевесить тех кто считает что сложно?
Ну почему же не стоит заводить сабтаски на этапы? Если у них в спринте 3 классические Скрам колонки (ту ду, ин прогресс и дан), то как раз сабтасками и делятся этапы
Может. И это нормально. И не только поэтому может быть перевес. Вопрос в том, а что с этим делать дальше? :)
Разбирать на ретро когда не уложатся в срок. Но если конечно нужно такой урок преподать.
Нет, после голосования в покере, обязательно обсуждаются крайне оценки. Почему кто-то считает, что это легко или наоборот слишком сложно. Это вовлекает всю команду в обсуждение каждого этапа. И с итоговой оценкой, как правило согласны все
Ну а можно прямо на рефайнменте спросить, зачем тянуть. Если видно, что кто-то в команде выдал экстремальную оценку, то это звоночек обсудить это здесь сейчас, ведь это признак, что команда не выровнена в понимании задачи
Давно просто не видел трёх колонок)) Современный Scrum уже прочно втянул в себя различные инструменты XP и Kanban ( и колонка Review уже скорее норма, чем исключение). Но раньше такси в InPr просто передавались от участника к команды к другому, то есть на них просто менялся ответственный. На мой взгляд сильное дробление по компетенциям мешает командной сплочённости. И как раз возникают риски утилизации ресурсов. Ну и у меня была команда с мобильной разработкой, представляете, какое количество саб-таск там бы возникло?))
Я тут лишь к тому, что важно, давая детальные рекомендации, не переносить свою практику на кейс менти :)
Не зная деталей кейса, мы только и можем что опираться на примеры своей практики )
Но ведь на самом деле там при увеличении resource utilization какое-то время throughput будет расти, и только потом падать. Вот в этой точке максимального throughput и стоит остановиться. Flow Time может вырасти конечно. Если у вас не слишком много фидбека от факта релиза, то почему бы не затрейдить flow time на throughput?
Я за любой подход с головой к цифрам, адаптацию и настройку подходов исходя из специфики команды, задач, компании и фазы луны. То есть да на все :) Но я против стандартной мысли "надо следить, чтобы люди без работы не простаивали, это всегда плохо, и только 100% загрузка это хорошо"
Обсуждают сегодня