Здравствуйте, 0x7be, Вы писали:
0>Логично. Однако получается такая штука: если оценивающий не знает кода, в котором придется копаться, то он попадет пальцем в небо.
Все правильно. Но давайте вернемся немного назад и попробуем понять назначение этого инструмента вообще. На самом деле это не экзотический способ голосования и даже не метод экспертной оценки. Это способ договорится. Именно так покер и нужно применять.
ПМ высказывает свою точку зрения. Владелец кода высказывает свою точку зрения и дает оценку трудозатрат. Команда голосует верю/не верю. Ведущий может попросить скептиков обосновать свою точку зрения. Владелец кода дает дополнительные пояснения или пересматривает свою точку зрения. Снова голосуем. И так пока все не согласятся.
Зачем это вообще нужно. а) Таким образом владельцы кода делятся информацией о том что творится в их огородах б) способ разрешить конфликт если ПМ и разработчик не сходятся в оценках в) приучает команду к конструктивной дискуссии.
Если не достигается хотя бы одна из этих целей, на мой взгляд, ценность применения методики сомнительна.
есть такая модная штука — planning poker. Вопрос к тем, кто имеет опыт работы с ним: когда, по-вашему, он работает, а когда — нет?
Мое личное наблюдение: он удовлетворительно работает пока задействованные люди хорошо представляют код, с которым им придется иметь дело.
Чуть только код начинает забываться командой, так начинается занижение сроков, а на матером legacy он вообще сбоит.
Ваши мнения?
>Ваши мнения?
Это просто еще один способ договориться. А вот что из этого выйдет, определяют конечно же не карты, а люди которые участвуют в разговоре. Если у команды сложности с оценкой сроков по задачам поддержки старого кода, надо это как-то компенсировать, не правда ли?
Здравствуйте, kolam, Вы писали:
K>Это просто еще один способ договориться. А вот что из этого выйдет, определяют конечно же не карты, а люди которые участвуют в разговоре. Если у команды сложности с оценкой сроков по задачам поддержки старого кода, надо это как-то компенсировать, не правда ли?
Логично. Однако получается такая штука: если оценивающий не знает кода, в котором придется копаться, то он попадет пальцем в небо.
Если же изучать код перед планированием, получается такая бяка: если это делать всем, то будет потрачено очень много времени.
Если же делегировать эту работу одному сотруднику, то теряется вся фишка покера, т.к. нет смысла "смешивать" оценки компетентного и некомпетентных людей и все равно придется доверять этому человеку.
Здравствуйте, 0x7be, Вы писали:
0>есть такая модная штука — planning poker. Вопрос к тем, кто имеет опыт работы с ним: когда, по-вашему, он работает, а когда — нет? 0>Мое личное наблюдение: он удовлетворительно работает пока задействованные люди хорошо представляют код, с которым им придется иметь дело. 0>Чуть только код начинает забываться командой, так начинается занижение сроков, а на матером legacy он вообще сбоит. 0>Ваши мнения?
Здравствуйте, 0x7be, Вы писали:
0>Коллеги,
0>есть такая модная штука — planning poker. Вопрос к тем, кто имеет опыт работы с ним: когда, по-вашему, он работает, а когда — нет? 0>Мое личное наблюдение: он удовлетворительно работает пока задействованные люди хорошо представляют код, с которым им придется иметь дело. 0>Чуть только код начинает забываться командой, так начинается занижение сроков, а на матером legacy он вообще сбоит. 0>Ваши мнения?
Есть такое дело.
Чем меньше команда знает о предмете, тем менее точны оценки.
Но на самом деле это не страшно.
Для единичных задач можно это проигнорировать.
Ну а если подобных задач станет много, то команда
набьет руку и оценки со временем станут точнее.
Кстати, занижение сроков — это скрее всего особенность вашей команды.
У нас в точности наоборот. Народ перестраховывается с очень большим запасом
Мы, кстати еще практикуем оценивать нижний и верхний предел.
Если разница существенная, то это обычно означает риск, или неуверенность команды.
Здравствуйте, GarryIV, Вы писали:
GIV>Надо еще измерять velocity и делать поправку.
Т.е. менять фокус-фактор. Проблема в том, что эта ошибка оценки возникает только на ряде задач, те, которые связаны с вмешательством в подзабытый код. Те задачи, которые не требуют такого оцениваются адекватно. И ещё, вроде как нас учили, что по мере работы команды фокус-фактор должен увеличиваться, а тут будет наблюдаться его постепенно снижение.
Все там написано:
1. На этапе планирования все истории получают оценку в баллах
2. Считаем скорость (баллов в день, в неделю, в итерацию) за последние три (или N) итерации
3. Считаем сколько баллов влазит в следующую итерацию (тут как раз и поправка происходит)
4. Набираем историй в итерацию пока хватает баллов
если итерация не по времени а по фичам
3а. Считаем сколько времени заемет выполнение набора фич
Здравствуйте, GarryIV, Вы писали:
GIV>Подробнее в книжках и на спец ресурсах.
Ну не серьезно...
Где про поправки то?
У автора топика проблема что переодически возникают задачи,
которые они неверно оценивают.
Ни велосити, ни покер по позволят избежать ситуации, когда в итарацию запихнули больше
чем смогли в итоге сделать.
Но это и не проблема на самом деле.
Просто велосити снизится и на следующих итерациях автоматом возьмут меньше задач.
Если таких задач по поддержки легаси кода будет много, то народ набьет руку,
велосити повыситься и будут опять брать больше в спринт.
Если таких задач мало, то и фиг с ними. Точные оценки все равно фикция.
Никаких поправок вводить не надо.
Так что по книжкам все отрегулируется само собой.
Кстати, в последнее время стали больше говорить не об оценках и обязательствах (commitment), а о прогнозах.
Технически почти то же но акцент немного другой.
Типа команда не дает обещаний, а делает прогноз.
Очень полезно для нервного менеджмента, который нелюбит ситуаций,
когда команда не справилась с тем, что напланировали на начале итерации.
P.S.
Если что, то я типа сертифицированный скрам мастер
Так что базовая теория мне известна.
Здравствуйте, kolam, Вы писали:
>>Ваши мнения? K>Это просто еще один способ договориться. А вот что из этого выйдет, определяют конечно же не карты, а люди которые участвуют в разговоре. Если у команды сложности с оценкой сроков по задачам поддержки старого кода, надо это как-то компенсировать, не правда ли?
Скорее всего вы не правильно бьете на задачи. И нет понимания почему та или иная задача проваливается по срокам. Какой средний срок оценки задачи? Как часто делаете переоценку и на каком этапе?
