LINUX.ORG.RU

Покер планирования, кто использует?

 , ,


1

1

Сегодня узнал, что такая штука существует. Кто не в теме - можете почитать в википедии. Может кто-то из тут присутствующих использует на практике? Расскажите, что думаете по этому поводу.

Deleted

Ответ на: комментарий от Deleted

Стал ненавидеть менеджеров ещё больше.

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

Deleted ()

Мы использовали один из вариантов и это работало очень хорошо.

Главное совсем в маразм не вдаваться и под себя адаптировать.

alexru ★★★★ ()
Ответ на: комментарий от Deleted

Помогает избегать авраалов. У команды есть производительность. Это примерно 0.7 - 0.8. Раз в 2 недели берём полное число доступных человек-часов и умножаем на этот коэффициент. Из доступных вычитаем отпуска и болезни, конечно. Получаем реально достуное число человек-часов.

До этого менеджеры выставляют приоритет всем задачам.

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

Как только доступные часы закончились, планирование заканчивается. Никаких новых задач за этот период не добавить, как бы начальству не хотелось.

alexru ★★★★ ()
Ответ на: комментарий от alexru

И каждый раз коэффициент обновляется по результатам фактического выполнения задач. Но когда все это на потоке идёт, то число так и остаётся в пределах 0.7-0.8.

alexru ★★★★ ()
Ответ на: комментарий от alexru

И это все требует реальной дисциплины от начальства. Они должны научиться не подсовывать задачи вне очереди и думать на 2 недели вперёд. Если это есть, то система работает отлично.

alexru ★★★★ ()

Может кто-то из тут присутствующих использует на практике? Расскажите, что думаете по этому поводу.

Отличная штука. Способствует командной работе, шарингу знаний и т.п.

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

anonymous ()
Ответ на: комментарий от anonymous

Да, люди ставящие приоритеты задачам на обсуждении ресурсов вообще не присутствовали у нас.

Если есть давление со стороны, то это все можно на свалку отправлять.

alexru ★★★★ ()
Ответ на: комментарий от alexru

И это все требует реальной дисциплины от начальства. Они должны научиться не подсовывать задачи вне очереди и думать на 2 недели вперёд.

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

anonymous ()
Ответ на: комментарий от alexru

Это называется focus factor.

Есть ещё понятия velocity команды, но это наибольший смысл имеет при переходе от человекочасов к относительным оценкам (story points)

anonymous ()

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

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

Не должно быть менеджеров и давления со стороны.

Должен быть ровно один человек(в скраме - владелец продукта), который будет объяснять команде фичи(сейчас любят фичи в виде user story описывать) и задавать между ними приоритет.

Оценка вслепую. При расхождении - обсуждение и переоценивание. Никакой демократии, только консенсус.

Если это сделать - команда сможет (при прочих равных) хорошо планировать и хорошо вместе достигать результата.

Если не обеспечить, то будет только хуже. И, как следствие, пойдет нытье про «agile не работает».

В идеале вообще обеспечить все требования scrum guide.

anonymous ()
Ответ на: комментарий от anonymous

Это называется focus factor.

Я в курсе, с мобилы много писать не удобно.

У всего этого есть 2 интересных побочных эффекта: 1. Реальная производительность команды будет на показ. Так что если хочется чай с печеньками пить и языком трепаться пол дня, то это будет видно. 2. Через несколько месяцев все члены команды учатся реалистично оценивать требуемые ресурсы. У нас значительных разночтений почти не было.

Разночтения были только вызванные не правильной трактовкой задачи. И этот метод позволяет такие задачи найти и уточнить еще до начала работы.

alexru ★★★★ ()

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

blexey ★★★★★ ()

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

Deleted ()
Ответ на: комментарий от alexru

не очень работает. story point != часам, а строится на способности оценивать продолжительность задач через некоторую единичную сложность.
p.s. аноны уже все толково расписали.

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Еще вброшу - должны быть груминги бэклога и ретроспективы.
Груминг - команда собирается раз в спринт и смотрит что там продукт/стекхолдеры набросали на ближайшие итерации.
Ретроспектива - команда собирается после спринта и ноет. На все проблемы стараются придумать решения и закрепляют ответственного. Следующую ретроспективу начинают с проверки удовлетворительности решения старых проблем.

Полноценный scrum требует достаточно много всяких неоправданных активностей и начинает работать только если выполняет основное условие «Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.» иначе это просто экономия на линейных менеджерах и перекладывание головной боли на программеров.

Deleted ()
Ответ на: комментарий от Deleted

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

alexru ★★★★ ()
Ответ на: комментарий от alexru

А сторипоинты вообще забавная мышеловка.
Вот коммитишься ты, что 1sp - «сделать зеленую кнопку», так сказать эталонная задача.
Потом приходит тебе задачка «сделать красную кнопку» и ты её оцениваешь в 8sp, а на планировании сидит продакт или либо ты на планировании слышишь ушат дерьма на тему «она жи просто другого цвета, как так», либо потом в кулуарах\на перфоманс ревью это всплывает.

Deleted ()
Ответ на: комментарий от anonymous

Ну обычно если нет желания добирать\перепланировать, то на первую итерацию берут (0.75 * все время комманды)sp. А потом уже и велосити появляется и реальная продолжительность итерации.

Deleted ()
Ответ на: комментарий от alexru

Удивительно крутое совпадение. Мы пока строили светлый скрам силами программистов все было достаточно удобно. Даже внешние коммуникации были норм. Единственное всех бесило, что мы целой коммандой сидели в отдельно трекере задач и синхронизировали его с общепринятым только по результатам спринта. А потом было решено построить правильный скрам силами менеджеров внешних консультантов и сертификации всех разрабов. Получилось слишком сухо. Ну и собственно это даже номинально был не аджайл, ибо отходить от постулатов было запрещено.

Deleted ()