Ссылка на CMMI

То есть в доке идет ссылка на исследование CMMI

Скажу честно, читать исследование CMMI мне лень.

Ну мне тоже:)

Но в чем можно объективно измерить performance разработчика - я не представляю :)

Я просто обратил внимание что это писал Сазерленд

Вот это

Да я понял :)

Сазерленд конечно огого, глыба и все такое, но CMMI всеравно читать лень :)

))

Кому интересно интересные вещи выложены еще тут

https://www.quora.com/How-do-you-make-scrum-work/answer/Jeff-Sutherland-1

Три дока

да.

И я все равно не понимаю, как можно посчитать увеличение количества work done :)

В рамках Scrum :)

И я все равно не понимаю, как можно посчитать увеличение количества work done :)

В рамках Scrum производительность одного разработчика измерять некошерно, ибо нет такого понятия. Можно измерять скорость команды суммой SP, переведенных за спринт в Done.

Измерять можно, сравнивать нельзя

sp - значение, которым владеет команда и оно относительное

нельзя сравнивать команды по velocity, нельзя даже команду с самой собой сравнивать по velocity

Именно саму с собой. Только так ты видишь её прогресс как команды.

Не по sp

Даже если предположить, что команда не делает переклаибровку (что маловероятно), значение 1 sp поменяется существенно с прогрессом команды.

То, что раньше имело "неопредленность" в 5 sp, станет 1 sp, например.

velocity при этом может упасть.

Так в этом и будет прогресс. А команды между собой тоже можно сравнивать, если sp унифицировать.

Унифицированные sp живут ровно до следующего планирования :)

После этого значения 1 у команд начнут отличаться.

Так в этом и будет прогресс. А команды между собой тоже можно сравнивать, если sp унифицировать.

Да, только его в sp измерить не получится.

Унификация sp - это уже SAFe

Это, гм, не совсем так :)

Унифицированные sp в SAFe не подразумевают возможность сравнения команд :)

Они унифицированны на уровне программы так, чтобы команды могли между собой обсуждать сложность программных PBI

Но никто не говорил, что их нельзя для этого использовать

Их нельзя для этого использовать :)

Что мешает?

то, что значение единицы у команд отличается.

Потому что бэклог отличается.

То, что у команды А является story на 1 sp, у команды B может быть 40, потому что у команд разный контекст.

А унифицированы они на уровне feature, один раз в PI, на самом планинге.

Более того, даже в пределах одной команды, заданное значение sp для story 1 в спринт X не означает, что это же количество sp будет задано для story в sprint+1

Потому нельзя сравнивать velocity команды между спринтами и считать, выросло оно или нет.

Можно считать, как уменьшается знчение sp для отдельно взятой story, но для этого надо иметь эталонную story которую команда будет эстимировать, но не завершать.

Что, согласитесь, глупо :)

Помнится Joel Spolsky писал что разница в производительности между разработчиками может отличаться в 10 раз. Недавно вычитал что между командами отличие доходит до 2000 раз.

Де Марко, военные маневры, там еще есть, такой факт, что производительность одного чегловека может отличаться в 10 раз, в зависимости от внешних факторов

Производительность человека можно посчитать только на рутинных стандартизованных операциях.

Выточил 10 деталей в день - бенчмарк. Сосед твой выточил 15 - он производительней тебя

теперь рассажите мне, как в области применения scrum можно посчитать производительность?

Тот кто сдал экзамен у того Фреймворк, кто не сдал у того методология!

Кто читал скрам гайд у того фреймворк, кто не читал у того методология

Тот кто сдал экзамен у того Фреймворк, кто не сдал у того методология!

😂😂😂

шла вторая неделя спора, авторы скрама продолжали охреневать у себя в америках

😂🔥😂

теперь рассажите мне, как в области применения scrum можно посчитать производительность?

В Scrum считается производительность команды. Считается в story point, которые уникальны для каждой команды. Команда каждый спринт берет задачи, которые стоят столько-то story point. Команда должна стремиться к тому, чтобы каждый спринт делать больший объем story point. Производительность отслеживается как раз прогрессом в этом разрезе. Это если в общем. А вообще, зачем Вам считать производительность? Какая цель?

В Scrum считается производительность команды. Считается в story point, которые уникальны для каждой команды. Команда каждый спринт берет задачи, которые стоят столько-то story point. Команда должна стремиться к тому, чтобы каждый спринт делать больший объем story point. Производительность отслеживается как раз прогрессом в этом разрезе. Это если в общем. А вообще, зачем Вам считать производительность? Какая цель?

Друзья, очень здорово, что вы интересуетесь этой темой, это очень круто. Но давайте, всё де, прочитаем 20 страниц и не будем делать такие однозначные выводы. Всё что написано в Scrum Guide есть, всё что там не написано - это не часть фреймворка и его можно использовать только если оно не вредит. Поэтому в Scrum Guide ничего про оценку и подсчет производительности нет. А вот про прозрачность и предсказуемость есть. Давайте не вплетать в Scrum Story Points, User Story и другие популярные практики.

Очень хорошее замечание, верное. Спасибо за него.

нужно все же поставлять ценность для клиентов), иначе мы можем очень производительно делать бесполезные вещи 😄

В Scrum считается производительность команды. Считается в story point, которые уникальны для каждой команды. Команда каждый спринт берет задачи, которые стоят столько-то story point. Команда должна стремиться к тому, чтобы каждый спринт делать больший объем story point. Производительность отслеживается как раз прогрессом в этом разрезе. Это если в общем. А вообще, зачем Вам считать производительность? Какая цель?

В таком виде сразу видится закладка под девальвацию сторипойнтов, хотя бы и вида "4 пишем, 3 в уме". Даже если неосознанно

В таком виде сразу видится закладка под девальвацию сторипойнтов, хотя бы и вида "4 пишем, 3 в уме". Даже если неосознанно

SP, User story, это инструменты которые нужны исключительно команде. SP чтобы понимать сколько можем и делаем ли мы что то сложное быстрее. Но если на эту метрику пытаются навесить KPI разного рода менеджеры тейлоровской орг парадигмы инструмент SP обесценивается.

В таком виде сразу видится закладка под девальвацию сторипойнтов, хотя бы и вида "4 пишем, 3 в уме". Даже если неосознанно

Тогда те кто закладывпют не разделяют ценности Scrum. Зачем команде обманывать себя и owner'а?

Тогда те кто закладывпют не разделяют ценности Scrum. Зачем команде обманывать себя и owner'а?

Команда не обманывает. Это совершенно нормальное поведение - улучшать показатели, по которым тебя оценивают. Проблема с sp для оценки в том, что sp - относительно. Это не оценка длительности или трудоемкости. Это оценка, упрощенно, уверенности команды в уровне сложности задачи относительно других задач

И velocity это индикация кумулятивной уверенности :)

Тогда те кто закладывпют не разделяют ценности Scrum. Зачем команде обманывать себя и owner'а?

Вообще-то, это делают те, кто сторипойнты превращают в KPI и ставят их рост целью.

Если оценивать команду по этому вот уровню уверенности - команда будет его демонстрировать

К реальной продуктивности это не имеет вообще никакого отношения

Впрочем, идея превращать индикатор/оценку в цель не нова. Как и последующая оптимизация работ строго под индикатор - в ущерб результатам.

Потому, ещё раз, оставьте sp команде. Это их внутренний индикатор, он не предназначен для сравнения команд, определения роста продуктивности команды и уж точно не является KPI

SP, User story, это инструменты которые нужны исключительно команде. SP чтобы понимать сколько можем и делаем ли мы что то сложное быстрее. Но если на эту метрику пытаются навесить KPI разного рода менеджеры тейлоровской орг парадигмы инструмент SP обесценивается.

Какой парадигмы?

Причём команде они нужны в первую очередь для оценки правильности оценки. Сегодня 5 СП, на другой спринт та же задача уже 4 - оценку по опыту исправили, эффективность повысили. И как KPI это покажет что команда стада "хуже".

Потому, ещё раз, оставьте sp команде. Это их внутренний индикатор, он не предназначен для сравнения команд, определения роста продуктивности команды и уж точно не является KPI

Павел, я поддерживаю Вашу точку зрения по этому вопросу. Но есть нестыковка относительно использования sp только как внутреннего индикатора команды - в relaible scrum статистика через sp и ведётся же?! А предсказание реальной готовности - это уже за пределами команды разработки..

Так Reliable Scrum это тоже инструмент команды. Наружу отдаётся кумулятивная оценка.

Построенная на основе sp

И инструментом исключительно команды я бы не назвал это..

Какой парадигмы?

Тейлоровская организационная парадигма

Построенная на основе sp

Частично построенная. СП в ней именно внутренние единицы оценки.

Можно, конечно, и через единицы заказчика впечатлять.

В чем проблема с обычным скрамом? Для чего эти reliable, double strack скрамы?

У Pavel насколько я понял скрам, который можно было и в double track оформить

Рилайбл, насколько я понял, для возможности сказать заказчику "когда готово будет". Базовый скрам этого в принципе не может.

В чем проблема с обычным скрамом? Для чего эти reliable, double strack скрамы?

У обычного скрама нет проблем. Reliable - это же не замена, это add-on