Здравствуйте, SkyDance, Вы писали:

I>>Для того, что бы велосити давала внятный эффект, стори-поинты должны быть привязаны ко времени, эстимейты должны быть привязаны ко времени.

SD>Оно работает в обратном направлении.
SD>Оценки делаются в story points. Уже на основании сделанного в итерациях менеджмент может прогнозировать привязки ко времени. Во времена стародавние, когда мы еще Backlog вели в Excel'е, у нас была колонка "Estimated Sprint" для каждого сценария в бэклоге.

Да, я уже говорил про это — сначала "оценим в попугаях" а потом "таски должны быть два дня максимум"

Здравствуйте, SkyDance, Вы писали:

I>>Привязка ко времени должны быть унутре попугая, а её как раз и нет. Тут великие скрамщики выдают серьёзную идею — все задачи должны быть максимум на один день. Чудо — внезапно появилось время. Теперь не ясно, почему надо считать в попугаях, если можно оценить время и выяснить, требует ли каждая из задач времени больше чем день или нет.

SD>Вы случайно не спутали "сценарий" и "задачу"?
SD>В бэклоге нет "задач", там только сценарии. Задачи появляются только внутри спринта, и нужны для внутренней статистики (sprint burndown), чтобы было видно, где затыки, и все ли в порядке со здоровьем спринта.

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

Здравствуйте, gandjustas, Вы писали:

I>>Будешь смеяться, но за тот же период безо всяких итераций нормальная команда начинает выдавать относительно предсказуемый результат.

G>Предсказуемый != хороший. Предсказемость результата достигается очень сильным раздутием оценок для перекрытия рисков, причем причины раздутия оценок определить весьма непросто.

Предсказуемость может достигаться и раздутием оценок, а может и внятным учетом рисков и толковым проектированием.
Можешь внятно пояснить, почему в твоем случае только первый вариант ?

Здравствуйте, Ikemefula, Вы писали:


I>Будешь смеяться, но за тот же период безо всяких итераций нормальная команда начинает выдавать относительно предсказуемый результат.
Угу. Только вопрос не в результате на конец итерации, а в том, как распланировать поступившие юз-кейсы на итерацию.

Напомню контекст:

I>>Попугаи без привязки ко времени и есть сорта колбасы, потому что основной метод этой привязки это "палецвнебо"
S>Ну так это на первую пару итераций, со временем соотношение устаканивается само, без микроменеджмента. Вес попугая — не константа, это просто способ разделить конечное время (итерацию) на кучу задач, которые можно оценить только постфактум.
Будешь смеяться, но за тот же период безо всяких итераций нормальная команда начинает выдавать относительно предсказуемый результат.

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

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

I>То есть, если помогло — значит скрам. Не помогло — значит девелоперы плохие.
Да ладно)) Скрам как и любая методология — это просто инструмент. Обвинять инструмент в "мы плохо работаем" или "унас всё ок из-за скрама" — эт инфантилизм чистейшей воды. Если что-то не работает — чинить надо, а не ждать пока загнётся.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Будешь смеяться, но за тот же период безо всяких итераций нормальная команда начинает выдавать относительно предсказуемый результат.

G>>Предсказуемый != хороший. Предсказемость результата достигается очень сильным раздутием оценок для перекрытия рисков, причем причины раздутия оценок определить весьма непросто.

I>Предсказуемость может достигаться и раздутием оценок, а может и внятным учетом рисков и толковым проектированием.
I>Можешь внятно пояснить, почему в твоем случае только первый вариант ?

Потому что избежать раздутия оценок крайне сложно, если оценивается срок (напрямую или косвенно). А если оценки раздуты, то все остальное становится малозначительно.

Я наблюдал многократно как это происходит:
1) Есть небольшая команда, которая не гонится за сроками
2) Команда растет, к ней приставляют ПМа.
3) ПМ начинает сверять план\факт и выясняет сто есть серьезная недооценка
4) ПМ, как ты писал выше, начинает разбор полетов.
5) В 95% случаев разборы начинают напрягать програмиистов
6) Сроки раздуваются с целью избежать разборов

Далее два варианта:
7а) ПМ получает разрешение руководителя прогибать команду, команда начинает выстраивать барьеры с менеджером, получается перманентны конфликт
7б) Рентабельность падает, развитие продукта останавливается\новые проекты не приходят, и программисты начинают заниматься УГ

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, SkyDance, Вы писали:

I>>>Привязка ко времени должны быть унутре попугая, а её как раз и нет. Тут великие скрамщики выдают серьёзную идею — все задачи должны быть максимум на один день. Чудо — внезапно появилось время. Теперь не ясно, почему надо считать в попугаях, если можно оценить время и выяснить, требует ли каждая из задач времени больше чем день или нет.

SD>>Вы случайно не спутали "сценарий" и "задачу"?
SD>>В бэклоге нет "задач", там только сценарии. Задачи появляются только внутри спринта, и нужны для внутренней статистики (sprint burndown), чтобы было видно, где затыки, и все ли в порядке со здоровьем спринта.

I>Нет, не попутал. Покажи, как можно вывести время для задачи и объясни, почему это нельзя сделать для сценария.
Время для задачи выводится при планировании спринта с помощью коллективной оценки.
Это легко сделать потому что:
1) Сценарий уже достаточно хорошо проработан на этот момент разбиения на подзадачи.
2) Есть уже есть продукт и затраты можно довольно точно оценить, не только в часах, но и строках кода.

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

Здравствуйте, Sinix, Вы писали:

I>>Будешь смеяться, но за тот же период безо всяких итераций нормальная команда начинает выдавать относительно предсказуемый результат.
S>Угу. Только вопрос не в результате на конец итерации, а в том, как распланировать поступившие юз-кейсы на итерацию.

Так ты расскажи, как увязываются попугаи и задачи со временем. Откуда берутся задачи, время и почему это время нельзя прикрутить к сценариям.

I>>То есть, если помогло — значит скрам. Не помогло — значит девелоперы плохие.
S>Да ладно)) Скрам как и любая методология — это просто инструмент. Обвинять инструмент в "мы плохо работаем" или "унас всё ок из-за скрама" — эт инфантилизм чистейшей воды. Если что-то не работает — чинить надо, а не ждать пока загнётся.

У меня сильное ощущение, что скрам годится там, где легко и предсказуемо безо всякого напряга.

Здравствуйте, gandjustas, Вы писали:

G>5) В 95% случаев разборы начинают напрягать програмиистов

Это смотря кто будет разбор проводить и какие цели преследовать. Если в твоём любимом ключе — разбор как вид кнута, то неудивительно

I>Я и говорю — когда всё хорошо, это скрам. А если сдохли, то квалификация не та или менеджмент подкачал.

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

I>Нет, не попутал. Покажи, как можно вывести время для задачи и объясни, почему это нельзя сделать для сценария.

Потому что "задача" — маленькая сущность. Это некий атомарный элемент прогресса. Дробление на мЕньшие единицы не происходит. Один сценарий включает несколько задач. Разбиение сценария на задачи происходит при входе в спринт.

Можно постфактум пересчитать цену "попугая" в дни работы команды. Но полученный результат будет средней скоростью (velocity). Его можно применять для прогнозирования — но только на горизонтах заметной длины, размера не меньше 1 спринта (а на самом деле ~3). Если же просто перемножить velocity на оценку единичного сценария в SP, получится ровно то же "пальцемвнебо".

I>Так ты расскажи, как увязываются попугаи и задачи со временем. Откуда берутся задачи, время и почему это время нельзя прикрутить к сценариям.

Задачи — атомарные сущности. Вроде как "написать тест вот по этому пути", или "добавить такой-то параметр в сигнатуру этого метода". Сами по себе задачи не несут бизнес-ценности. Для реализации одного сценария может потребоваться выполнить одну или несколько задач. Задачи должны быть маленькими, и уже на этапе их постановки и оценки должно быть ясно, что _КОНКРЕТНО_ придется сделать для завершения задачи. По сути, постановка задачи — это уже половина решения. Поэтому нетрудно оценить и время, требуемое для решения задачи.
Задачи нужны для того, чтобы:
1. Дать возможность параллельной работы нескольких человек над одним сценарием (к примеру, один пишет тесты, другой меняет API, третий кодит собственно функционал).
2. Легко отслеживать прогресс внутри спринта (sprint burndown chart)
3. Быстро обнаруживать и устранять затыки (impediments).

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

Время работы над задачей оценивается тогда же, когда сценарий разбивается на задачи: во время sprint entry.


Сценарий — собственно, сценарий. То, что будет делать пользователь системы. К примеру, "отсортировать заказы по дате доставки". Чтобы прикрутить такие оценки времени к сценариям, потребуется... правильно, разбить сценарии на задачи Но с этим есть проблема: если мы попытаемся делать это заранее (за 4-5 спринтов, например), все эти оценки будут катастрофически неверными. В первую очередь потому, что за 4-5 спринтов codebase может сильно убежать вперед (или в сторону). Может поменяться парадигма, фреймворк, Definition Of Done. Поэтому разбиение на задачи происходит тогда и только тогда, когда сценарий берется в работу. И разбиение на задачи осуществляется с учётом _ТЕКУЩИХ_ особенностей — состава команды, покрытия тестами, известных залежей костылей и подпорок в коде.

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

Здравствуйте, gandjustas, Вы писали:

G>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

А в чем же тогда оценивать?
Проект ведь все равно планировать надо

Здравствуйте, es3000, Вы писали:

E>Здравствуйте, gandjustas, Вы писали:

G>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

E>А в чем же тогда оценивать?
E>Проект ведь все равно планировать надо


Оценивать можно в условных попугаях, а продуктивность "условные попугаи в день\месяц\год" надо измерять. Причем измерять не по отдельному сотруднику, а по команде. И мерить не отдельные задачи (разработка тестирование итп), а фичи — целостные куски функционала, имеющие ценность для пользователя.

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

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, es3000, Вы писали:

E>>Здравствуйте, gandjustas, Вы писали:

G>>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.

E>>А в чем же тогда оценивать?
E>>Проект ведь все равно планировать надо


G>Оценивать можно в условных попугаях, а продуктивность "условные попугаи в день\месяц\год" надо измерять. Причем измерять не по отдельному сотруднику, а по команде. И мерить не отдельные задачи (разработка тестирование итп), а фичи — целостные куски функционала, имеющие ценность для пользователя.

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

В каком ПО по управлению проектами можно использовать такой способ оценки и отслеживания проекта7

Моё видение идеальной ситуации, как программиста.

Сроков нет. При этом задачу делать надо, т.е. не так, что проект не нужен. Нужен и может быть даже очень. Но тебя никто не ограничивает. Делаешь столько, сколько считаешь нужным.

При этом ты понимаешь ожидаемую степень качества того или иного компонента. Что-то нужно в первую очередь, что-то во вторую.

Ну и задача не совсем отвратительная, т.е. есть хоть какой то интерес её делать.

Сравнивая со всеми остальными альтернативами в данном случае у меня получается работать наиболее плодотворно.

Когда есть сроки, они давят. Хорошо, если они ставятся "сверху", они давят не так, потому что всегда можно сказать, что ваши сроки нереальные. Если сроки поставил ты, это очень неприятно. Потому что от самого себя тяжело отговариваться. Давит вдвойне. Очень неприятно работать в таком режиме. Результат получается хуже, удовлетворённость от работы хуже, а скорость выполнения, зачастую, тоже хуже, чем в первом варианте. Потому что вместо того, чтобы думать, как сделать задачу, ты начинаешь думать, как успеть её сделать. Это смещение фокуса и оно только вредит.

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

Здравствуйте, es3000, Вы писали:

G>>Оценивать можно в условных попугаях, а продуктивность "условные попугаи в день\месяц\год" надо измерять. Причем измерять не по отдельному сотруднику, а по команде. И мерить не отдельные задачи (разработка тестирование итп), а фичи — целостные куски функционала, имеющие ценность для пользователя.

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

E>В каком ПО по управлению проектами можно использовать такой способ оценки и отслеживания проекта7

Excel