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

Почитал. Стал ненавидеть менеджеров ещё больше. Это просто песец вселенского масштаба.

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

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

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

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

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

Ну и ежедневные 15 минутные митинги тоже более полезны, чем вредны.

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

Онлайн или вживую?

Ну и ежедневные 15 минутные митинги тоже более полезны, чем вредны.

Эвридэйные фифтин минутсные митинги?

В живую, раз в 2 недели.

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

В живую, раз в 2 недели.

А можешь чуть подробнее рассказать, в чём суть? И как оно помогает?

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

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

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

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

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

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

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

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

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

Пробовал, профита не увидел. Сейчас этим не пользуюсь - в другой команде, да и в другой конторе.

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

Так менеджеров нет в agile.

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

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

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

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

компенсацией -> компетенцией

Вообще для начала лучше прочти про agile (agilemanifesto.org) и scrum (scrumguides.org).

Покер планирования наиболее часто как раз в скраме применяют.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для начала лучше http://macode.ru/

а уже пора что-то доложить наверх.

Кому «на верху» есть хоть какое-то дело до задач на 2 недели вперед?

Манифест говнокодеров, ага.

уже пора что-то доложить наверх

В нормальном agile никакого «наверх» уже не будет.

Делали на моей предыдущей работе, ещё в эрэфии. Дерьмо полнейшее.

Эта хрень к игре покер имеет ровно ноль отношений

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

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

Была практика, в общем и целом было скорее полезно чем нет. Позволяет быстрее сформировать общие веса попугаев.

Мы планировали в обычных часах и у нас все работало. Мы особо не заморачивались на идеологию и делали так как нам удобно было.

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

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

Практику притащили сами программисты или менеджеры наелись хипстоты?

сейчас бы сидеть и сторипоинты калькулятором на часы маппить

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

Я без понятия зачем стори поинты вообще нужны. Я работаю в часах и планирую в часах. Все просто.

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

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

Для Ъ будет?

а в том, что ты все это время жуешь сопли и не можешь объяснить почему тут 8 а там 1, виноват аджайл и сторипоинты, конечно же

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

уровень твоего понимания мы уже знаем, можешь своё «обычно» засунуть себе в бэклог

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

Открой для себя Microsoft project, например, вернее, подход. И митинги не нужны. И даже манифестации и парады.

Годный способ оценки сложности задач.

Что только ни придумают, лишь бы не работать.

если команда не может объяснить свою оценку даже в сторипоинтах — её и слушать не обязательно.