Reward the best ?

[Сабина]

Подводили итоги очередного спринта ( мне проще говорить итерации). И как обычно во всяких Jira-ах видно кто сколько часов вложил, багов починил, написал новых фич. Точнее это и так видно без джиры, но с ней на порядки нагляднее.
Сказала полу в шутку, полу всерьез что надо бы нам как то reward the best. Начальник тут же подскочил и сказал что он категорически против . Это при том что он у нас сам пашет как вол.
Интересно какой у вас взгляд на это дело ?

[Интеррапт]

Я тоже был бы против. Частенько бывает, что чинишь один, но очень противный баг за то время, за которое другой десяток мелких багов закроет. И ес-но твой график будет выглядеть жалко супротив его графика.

[Сабина]

Я тоже был бы против. Частенько бывает, что чинишь один, но очень противный баг за то время, за которое другой десяток мелких багов закроет. И ес-но твой график будет выглядеть жалко супротив его графика.

Не будет. На большой баг обычно дается большой time estimate, что обсуждается со всеми при планировании итерации

[Интеррапт]

Я тоже был бы против. Частенько бывает, что чинишь один, но очень противный баг за то время, за которое другой десяток мелких багов закроет. И ес-но твой график будет выглядеть жалко супротив его графика.

Не будет. На большой баг обычно дается большой time estimate, что обсуждается со всеми при планировании итерации

Баг может быть не большой, а зловредный и можно запросто не уложится во время, которое решили во время обсуждения. Случается сплошь и рядом. Есть еще очень большая вероятность того, что тебя довольно часто отвлекают с просьбой о помощи и твое время уходит на то, чтобы помочь кому-то, у которого в результате красивая картинка нарисуется в графике. Я не против reward the best, просто к этому нужно подходить несколько более "ширше", чем по результатам в jira.

[Boriskin]

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

ЗЫ Пример из реала - один чувак написал большую фичу, в которой нашли 900 багов, которые автором и были пофикшены. Другой написал тоже большую фичу, в которой нашли 90 багов, тоже пофикс. Кому давать печеньку - вот в чем вопрос...

[Medium-rare]

Вот, *слегка* радикально, и не совсем корректно, но про то же.

[АццкоМото]

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

+1
Мы много лет собирали тучи всяких разных метрик, наумелись по самое не хочу предсказывать очень многие вещи, но как оценить вклад человека даже по совокупности разных метрик так и не придумали. Хотя, например, было прекрасно видно, что качество с производительностью статистически находятся в обратной зависимости, что и ожидалось, но вот что с этим делать - не вполне понятно. Ну можно было дать какие-то рекомендации по, скажем, времени на инспекцию кода. Но никак не по тому, как выявить лучших

[IContentProvider]

Согласна, что идея "измерения производительности в багах" совершенно дурацкая, и вообще лишняя трата времени. Ну кроме как позагибать пальцы. Надо бы тогда еще считать кто сколько багов наделал и кто их фиксил, и вычитать для идеального пальцеуказательства и бухгалтерии.

Вообще, приоритеты в разное время и с разными вещами могут быть разные. Иногда - писать быстро-быстро. Иногда - потратить время на продумывание дизайна.

Но никак не по тому, как выявить лучших

И что делать с этими лучшими? Дать значок "пофиксен сотый баг"? Да и менеджера можно понять, развивать дух competitiveness в собственной команде отвратная идея.

[АццкоМото]

Но никак не по тому, как выявить лучших

И что делать с этими лучшими? Дать значок "пофиксен сотый баг"? Да и менеджера можно понять, развивать дух competitiveness в собственной команде отвратная идея.

Очевидно, все упирается в деньги. В той конторе, где мы собирали чудовищное количество разных метрик, мне каждый месяц приходилось начислять премии и два раза в год - пересматривать ставки. А это очень нелегко, доложу я вам, особенно когда под тобой работают и лучшие друзья, и люди, о которых, скажем так, не самого высокого мнения, а хочется быть объективным. Вполне резонно желание использовать какие-то метрики, и я их даже использовал. Но в качестве единственного вводного они никак не годятся - не на заводе дырки сверлим.
И, кстати, дух соревновательности, зависть и прочие пороки человечества разовьются сами в любом нестатическом коллективе. С этим ничего нельзя поделать

[X37WAL!^]

Я тоже был бы против. Частенько бывает, что чинишь один, но очень противный баг за то время, за которое другой десяток мелких багов закроет. И ес-но твой график будет выглядеть жалко супротив его графика.

Не будет. На большой баг обычно дается большой time estimate, что обсуждается со всеми при планировании итерации

Я не знаю, как это вы делаете, но у нас при планировании уже давно никто не пытается size defects. Ибо на практике любой дефект занимает либо "5 минут" либо "хрен знает сколько дней".

[scorpion]

Интересно какой у вас взгляд на это дело ?

Больше половины тех исправленных "багов", возможно, из-за написаных в предыдущий спринт "фич". Руки отбивать, а не награждать...

[Zorkus]

Я тоже был бы против.

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

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

и так далее. Нет, не надо такого.

[Сабина]

Я тоже был бы против.

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

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

и так далее. Нет, не надо такого.

Это просто лишний раз доказывает что плохо используете скрам и его возможности . При хорошо организованной деле учитывается вся работа и точно. Для помощи другим заводится спец ишью - technical debt и против него списываются часы. Если баг занял на порядки больше времени - просто меняется estimate или remaining hours. Тем более видно что не так в академии когда такие вещи правильно tracked

[Zorkus]

Я тоже был бы против.

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

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

и так далее. Нет, не надо такого.

Это просто лишний раз доказывает что плохо используете скрам и его возможности . При хорошо организованной деле учитывается вся работа и точно. Для помощи другим заводится спец ишью - technical debt и против него списываются часы. Если баг занял на порядки больше времени - просто меняется estimate или remaining hours. Тем более видно что не так в академии когда такие вещи правильно tracked

Такое делал один раз, когда это был длинный тренинг, но в целом, зачем мне списанные часы? Или вклад будем мерить в залогенных часах?

Кстати, интересно, а в местах с "хорошо организованной работой" трекится в отдельной джире время, потраченное на трекинг джир ? Например, когда мы переходили на новую систему тайм репортинга на моей позапрошлой работе, в Самаре еще, у нас тимлиды регулярно отдельным айтемом писали - "2 hours - timesheet/billing report preparation". Благо я комметерии к джирам, их редактирование, перетаскивание из спринта в спринт, выставление fixed versions (по которым у нас генерятся build release notes) не в свободное время делаю.

[X37WAL!^]

Я тоже был бы против.

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

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

и так далее. Нет, не надо такого.

Это просто лишний раз доказывает что плохо используете скрам и его возможности . При хорошо организованной деле учитывается вся работа и точно. Для помощи другим заводится спец ишью - technical debt и против него списываются часы. Если баг занял на порядки больше времени - просто меняется estimate или remaining hours. Тем более видно что не так в академии когда такие вещи правильно tracked

Если менять estimate задним числом, вы никогда не обнаружите факта, что items, над которыми работает Вася постоянно оказываются "недооценены", а петины - "переоценены". Т.е. вы убиваете возможность подсчитать скольким "estimated story points" соответствует реально потраченное количество спринтов. Именно по этой причине классический скрам рекомендует пытаться оценивать время/story points только для тех вещей, которые таковой оценке более-менее поддаются. А остальное должно уходить в overhead. Если у вас очень болтливый начальник, и приходится тратить на него время, вы за спринт сделаете например 7 story points вместо 9. Но это не повод в каждый спринт пытаться вбрасывать item "болтовня с начальником - 2 sp", правда?

[Zorkus]

Если начальник и сам понимает что митинги с ним отнимают время (но может полезны для чего-то), то все нормально и отлично. Если он сам отнимает время, а потом предъявляет что мало сделано - завести джиру типа "meetings with boss", и каждую неделю в нее чаржить определенное число часов. Раз в месяц показывать начальнику (а лучше его начальнику), сколько его болтовня стоит компании

[Zorkus]

Estimates / logged hours на джирах нужны для того, чтобы по ним генерить burndown charts и воинственно размахивать им на скраме. Для собственно трекинга багов они не нужны, как и другие 500 полей в джировских темплейтах.

С эстимейстами подход такой, на моей памяти основная (хотя и надуманная) проблема с изменением эстимейта была, когда по какой-то причине в изначальный таск добавляли еще кучу всего, или меняли смысл таска на более глобальный после того, как он уже был проэстимейчен, вместо того, чтобы открыть еще несколько. Например, у нас был такое, когда был таск "проверить, что данная фича работает в таком-то environment", на что был разумный эстимейт 12 часов, и потом его зачем то переименовали в "сделать так, чтоб работало в этой среде", после чего эстимейт (тоже разумно!) вырос до 60 часов, и потом такие скачки выглядят не очень для менеджмента.

[Boriskin]

Это просто лишний раз доказывает что плохо используете скрам и его возможности . При хорошо организованной деле учитывается вся работа и точно. Для помощи другим заводится спец ишью - technical debt и против него списываются часы. Если баг занял на порядки больше времени - просто меняется estimate или remaining hours. Тем более видно что не так в академии когда такие вещи правильно tracked

Это в теории, а на практике такой подход может привести к тому, что девелопер будет заниматься "бумажной волокитой" не 10-20% времени, а все 50%. К тому же, если постоянно сдвигать delivery estimate, то рано или поздно возникнет закономерный вопрос "а не зря ли получают деньги те, кто постоянно выдает неправильные estimates, и стоит ли их простимулировать скипидаром аль горячим утюгом или просто уволить нахрен".

[X37WAL!^]

Если начальник и сам понимает что митинги с ним отнимают время (но может полезны для чего-то), то все нормально и отлично. Если он сам отнимает время, а потом предъявляет что мало сделано - завести джиру типа "meetings with boss", и каждую неделю в нее чаржить определенное число часов. Раз в месяц показывать начальнику (а лучше его начальнику), сколько его болтовня стоит компании

По моему опыту, в скраме оперировать часами вместо story points - занятие опасное и неблагодарное. Я не знаю, как в стартапах, а в крупных компаниях overhead часто может достигать диких значений типа 40-50%. Одно дело, когда ваша команда делает "20 story points per 2 week sprint" (оверхед учтён при item sizing), другое дело, когда она же делает "250 hours per 2 week sprint". Любой умник, что умеет 250 разделить на 5 девелоперов, заключает, что один девелопер "работает" 5 часов в день. Значит есть резервы. Далее, если этот же умник видит item с estimation=10 hours, считает, что если очень надо, ему ЭТО сделают за один рабочий день. Просто надо на один день весь оверхед задвинуть. И так повторить 10 раз. Профит.

[Zorkus]

Если начальник и сам понимает что митинги с ним отнимают время (но может полезны для чего-то), то все нормально и отлично. Если он сам отнимает время, а потом предъявляет что мало сделано - завести джиру типа "meetings with boss", и каждую неделю в нее чаржить определенное число часов. Раз в месяц показывать начальнику (а лучше его начальнику), сколько его болтовня стоит компании

По моему опыту, в скраме оперировать часами вместо story points - занятие опасное и неблагодарное. Я не знаю, как в стартапах, а в крупных компаниях overhead часто может достигать диких значений типа 40-50%. Одно дело, когда ваша команда делает "20 story points per 2 week sprint" (оверхед учтён при item sizing), другое дело, когда она же делает "250 hours per 2 week sprint". Любой умник, что умеет 250 разделить на 5 девелоперов, заключает, что один девелопер "работает" 5 часов в день. Значит есть резервы. Далее, если этот же умник видит item с estimation=10 hours, считает, что если очень надо, ему ЭТО сделают за один рабочий день. Просто надо на один день весь оверхед задвинуть. И так повторить 10 раз. Профит.

Напомнило отличную аналогию АццкоМото про марафон - "если разделить марафон на 422 спринта и экстраполировать, окажется, что его можно на самом деле пробежать за час, а не за два"

У нас эстимейтят все в часах, но с всем известной оговоркой, что сотрудник "работает" 6 часов в день (остальное - оверхед). Пока нормально.

[rzen]

Подводили итоги очередного спринта ( мне проще говорить итерации).

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

имхо оценивать кодера по количеству строк (или жир или любой другой количественной метрике) это то же самое что называть фрикции любовью. да, какой то смысл в этом есть, но вообще то суть в другом.

имхо без benevolent dictator'а не обойтись. причем такого кто может оценить способности кодеров, подтянуть тех кто отстаёт, отметить отличившихся и избавиться от безнадёжных в нужный момент.

[X37WAL!^]

Если начальник и сам понимает что митинги с ним отнимают время (но может полезны для чего-то), то все нормально и отлично. Если он сам отнимает время, а потом предъявляет что мало сделано - завести джиру типа "meetings with boss", и каждую неделю в нее чаржить определенное число часов. Раз в месяц показывать начальнику (а лучше его начальнику), сколько его болтовня стоит компании

По моему опыту, в скраме оперировать часами вместо story points - занятие опасное и неблагодарное. Я не знаю, как в стартапах, а в крупных компаниях overhead часто может достигать диких значений типа 40-50%. Одно дело, когда ваша команда делает "20 story points per 2 week sprint" (оверхед учтён при item sizing), другое дело, когда она же делает "250 hours per 2 week sprint". Любой умник, что умеет 250 разделить на 5 девелоперов, заключает, что один девелопер "работает" 5 часов в день. Значит есть резервы. Далее, если этот же умник видит item с estimation=10 hours, считает, что если очень надо, ему ЭТО сделают за один рабочий день. Просто надо на один день весь оверхед задвинуть. И так повторить 10 раз. Профит.

Напомнило отличную аналогию АццкоМото про марафон - "если разделить марафон на 422 спринта и экстраполировать, окажется, что его можно на самом деле пробежать за час, а не за два"

У нас эстимейтят все в часах, но с всем известной оговоркой, что сотрудник "работает" 6 часов в день (остальное - оверхед). Пока нормально.

Если реальный оверхед действительно меньше 2-3 часов в день, то не вижу проблем. В противном случае получается, что чем больше оверхеда, тем больше сотрудник работает овертайм, а эстимейты и отработанные часы по собственно проекту показывают, что всё шоколадно...

[Tatyank]

Подводили итоги очередного спринта ( мне проще говорить итерации). И как обычно во всяких Jira-ах видно кто сколько часов вложил, багов починил, написал новых фич. Точнее это и так видно без джиры, но с ней на порядки нагляднее.
Сказала полу в шутку, полу всерьез что надо бы нам как то reward the best. Начальник тут же подскочил и сказал что он категорически против . Это при том что он у нас сам пашет как вол.
Интересно какой у вас взгляд на это дело ?

Начальник, скорее всего сразу просек, что при таком подходе ему отнюдь не лучших придеться награждать. У меня в группе, например, тем, кто послабее и задания давались попроще: типа " бери больше, бросай дальше". И они, конечно, их делали их "на автомате" десятками в день. Большинство получало задания обычной сложности и делало их десяток-другой. А парочке сильных специалистов доставались каверзные, сложные, кем-то запоротые задания. Иной день они только 1-2 могли закончить. Но кроме них с этими заданиями не справился бы никто другой. А они любые другие задания могли без проблем сделать. "Дак кто ж им даст?"(с) Потому как их помощь со сложными заданиями была важнее. Угадайте с 3-х раз, кого при раздаче слонов я за " best" считала?

P.S. Кстати, подходил ко мне как-то один из " высокопроизводительных" работников с претензией "а почему Джону, который только пару заданий в день делает, дали нечто, а ему, с 25-ю заданиями - нет". Я предложила ему местами с Джоном поменяться. А он говорит: " не-а, у Дюона задания трудные". Ну я ему и сказала: "Вот потому Джону премию и дали". Больше он мне таких вопросов не задавал...

[X37WAL!^]

Подводили итоги очередного спринта ( мне проще говорить итерации). И как обычно во всяких Jira-ах видно кто сколько часов вложил, багов починил, написал новых фич. Точнее это и так видно без джиры, но с ней на порядки нагляднее.
Сказала полу в шутку, полу всерьез что надо бы нам как то reward the best. Начальник тут же подскочил и сказал что он категорически против . Это при том что он у нас сам пашет как вол.
Интересно какой у вас взгляд на это дело ?

Начальник, скорее всего сразу просек, что при таком подходе ему отнюдь не лучших придеться награждать. У меня в группе, например, тем, кто послабее и задания давались попроще: типа " бери больше, бросай дальше". И они, конечно, их делали их "на автомате" десятками в день. Большинство получало задания обычной сложности и делало их десяток-другой. А парочке сильных специалистов доставались каверзные, сложные, кем-то запоротые задания. Иной день они только 1-2 могли закончить. Но кроме них с этими заданиями не справился бы никто другой. А они любые другие задания могли без проблем сделать. "Дак кто ж им даст?"(с) Потому как их помощь со сложными заданиями была важнее. Угадайте с 3-х раз, кого при раздаче слонов я за " best" считала?

P.S. Кстати, подходил ко мне как-то один из " высокопроизводительных" работников с претензией "а почему Джону, который только пару заданий в день делает, дали нечто, а ему, с 25-ю заданиями - нет". Я предложила ему местами с Джоном поменяться. А он говорит: " не-а, у Дюона задания трудные". Ну я ему и сказала: "Вот потому Джону премию и дали". Больше он мне таких вопросов не задавал...

Вау. Что это за "трудные задания", которые можно делать по два в день? Если считать (из предыдущих реплик), что мы работаем 6 часов, то это 3 часа работы? А "лёгкие задания", по полчаса на каждое, от начала до конца? Не очень ли мелко вы их нарезаете?

[scorpion]

Это просто лишний раз доказывает что плохо используете скрам и его возможности .

Какие такие возможности? Уже много раз здесь умные люди писали, что он проще пареной репы, но всеобщая любовь, а точнее "мода" довела его до того, что применяют где надо и где не надо. Все более или менее работает, если требуется копать "от забора и до обеда", а когда приходится разбрасываться мозгами, уже далеко все не так весело, ну, а если работа еще и на кучу команд завязана, когда у каждой "свой стадион для забегов", то вообще труба...