Выдумали наверное

А у нас нормально работало, пока все каждый день списывали

Не видел ни одного босса который бы посмотрел в берндаун и сказал "как прозрачно стало" :)

Да ну? Не сгорает? Так пора рас#$@+онов вставить бездельникам. Скрам скрамом, а релизить то надо)

😂

и все гибко и прозрачно), и конечно же адаптивно

Всем привет! Приглашаю в субботу на конференцию+хакатон, Александра Баптизманская расскажет про Agile в маркетинге. http://adhack.muzis.ru/

#whois Ребята, всем привет! Меня зовут Александр Шпитонков, мне 25 лет, Москва Я работаю заместителем начальника управления проектов по внедрению и развитию IT-систем в Транскапиталбанке. Специализируюсь на проектах по автоматизации фронт-офиса. Хорошо знаком с классической проектной методологией (PMBOK, PRINCE2, etc.), но при этом разделяю ценности Agile. Я вижу преимущество Agile-фреймворков во многих областях, но, к сожалению, пока не могу полноценно внедрять их в текущей деятельности. Также немного участвую в волонтерских программах, связанных с реабилитацией и реинтродукцией хищных птиц, у меня дома живет сова:) Сообществу, вероятно, могу быть полезен опытом ведения проектов в достаточно крупном банке, опытом ошибок, возникающих в поиске способов сделать классические банковские процессы ближе к Agile В сообществе ищу информацию о трендах в области Agile, опыт успешных (и не очень) Agile-трансформаций, а также интересные мероприятия, в которых можно поучаствовать О сообществе узнал на тренинге по Agile/Scrum от компании Product.Vision Открыт к общению по теме сообщества P.S. В списке пунктов анкеты для представления есть опечатка в 4-м пункте

Подписка на #whois

👍

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

... а ему говорили, не, много, оцени меньше. Тогда виноват его начальник... Что ж он так духом то слаб? А если скажут прыгнуть 99 этажа? Эджайл классная вещь, но вот в этом вопросе гибкость вредна: свое мнение нужно обосновывать и отстаивать. Если пассажир будет настаивать чтоб таксист пробку по встречке объезжал, а таксист так и сделает - кто виноват?

начальник выше по рангу. это все равно что винить пешехода что от таксиста не увернулся

... а ему говорили, не, много, оцени меньше. Тогда виноват его начальник... Что ж он так духом то слаб? А если скажут прыгнуть 99 этажа? Эджайл классная вещь, но вот в этом вопросе гибкость вредна: свое мнение нужно обосновывать и отстаивать. Если пассажир будет настаивать чтоб таксист пробку по встречке объезжал, а таксист так и сделает - кто виноват?

Именно поэтому аджайл про командную работу

Дедушка Сазерленд 😃

Дед Денис

начальник выше по рангу. это все равно что винить пешехода что от таксиста не увернулся

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

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

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

Да ты Ярослав некропостер

Михаил, у вас с этим парнем разные картины мира. Вячеслав aka Slava, выше об этом упоминал. А ваши текущие трения это следствие. вам нужно с причиной поработать - прояснить что в ваших картинах так сильно расходится, что он так реагирует.

Да ты Ярослав некропостер

Прокрастопостер

Вебинар "Планирование в Scrum: принципы, уровни и инструменты" www.facebook.com/events/851651785012636

30 августа, в среду с утра

Вебинар "Планирование в Scrum: принципы, уровни и инструменты" www.facebook.com/events/851651785012636

Ты их реально будешь слушать?

А что есть информаци, что их не надо слушать?

Добрый день! Есть вопрос, связанный с использованием Канбана, в частности по его метрикам. Контекст такой: у меня несколько команд, все работаем по SCRUM. В одной из команд заметили, что не получается в более-менее стабильном состоянии оставлять состав спринта, постоянно что-то прилетает извне и приходится вносить изменения в скоп спринта. Не то, чтобы это большая проблема, но осадок есть, на каждом ретро люди высказываются, что это никому не нравится. Я подумал - по большому счету, у нас на этой команде большая доля срочной текучки, которую сложно запланировать, поэтому, почему не попробовать Канбан? Вот, пробуем. Но есть засада с тем, что люди уже привыкли к оценкам задач, есть границы - итерация, они знают, сколько "попугаев" надо за две недели выдать и это всем понятно. В Канбане же у нас нет оценок, соответственно, как я из описаний понял, мы меряем только среднее время прохождения задачи от анализа до деплоя + количество задач, которое "влетело" и "вылетело". Но, честно говоря, пока что-то не складывается. Вот за месяц у команды среднее время выполнения - 4 дня, правильно ли я понимаю, что если эта длительность не увеличивается, то все хорошо и команда набрала свою скорость? И если получили 5 часов - то была проблема какая-то? Кто что меряет при использовании Канбан?

Среднее время никто не меряет

как вы измеряете скорость команды?

Средняя время здесь - это синяя черта, а крайняя правая это 85% задач за какой промежуток времени делаются - вот это более правильная метрика.

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

А все хорошо или не хорошо не зависит от 4-х дней, а зависит от того, заказчик(и) считает что его это устраивает или нет.

Спасибо за ответ! А как вы работы планируете? Грубо говоря, накидали юзерсторей, по скраму - их оценили и учитывая скорость команды, понятно когда примерно сделаем. А в Канбан как?

На уровни разработки - разработчик тянет следующую задачу из очереди когда освобождается

Как тянуть задачу из очереди - есть конкретные договоренности.

т.е. у вас PO не интересует когда, грубо говоря, его 10 задач будут сделаны, хотя бы примерно?

а еще есть каденции

я ж вам график показал, там есть ответ на этот вопрос

ему не надо это спрашивать каждый раз

если у вас ПО интересуют задачи, которые за 4 дня делаются

то возможно он слишком низко в техническом уровне живет

хм. непонятно. к примеру, я PO. мы набросали 10 историй. правильно ли я понимаю, по вашей статистике с вероятностью 85% эти 10 историй будут сделаны за 22 дня?

фундаментально скрам - это набрать работы и сделать

а Канбан - это брать минимум работы и выровнять поток

то есть люди не будут брать 10 историй, они будут их делать последовательно

ПО будет видеть что релизы происходят часто и перестанет ходить за сроками.

но время выполнения каждой истории среднее - 22 дня?

:)

от 0 до 22 дней

посмотрите на пик, он в единице

перекладывая на вас, это значит что много историй делается за день,но если смотреть за длительный прожмуток времени, то есть такие, которые делаются и 100 дней, но 85% историй делается в промежутке от 0 до 22 дней.

оценивать и декомпозировать то истории никто не запрещает)

наш график как раз по таким.

график бизнесовых задач выглядит по-другому

Сергей вот вам простая истина, если ПО фокусируется на сроке 10 историй, то он не бизнес развивает

а в технику лезет

ну это пример был :)

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

Ну хороший пример че, я это у многих наблюдаю :) когда не говорим о ценности поставок, говорим всегда о сроках :)

поэтому, 10 ценных историй - вполне реально

так а что значит ценная поставка? мы релизимся почти каждый день, почти каждый день что-то полезное выходит

а продукт один?

реально - нет

ценная поставка это значит что она повлияла на бизнесовую метрику, так-то все релизятся часто у кого процесс более менее выстрен

но задачи 90% по одному

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

так ведь так и есть, релизы частые, но при этом - заказчик хочет знать КОГДА будет та или инач фича, а учитывая нашу очередь задач, иногда это сложно сказать

ну то есть посчитать можно и без попугаев :)

https://blog-ru.kaiten.io/Kanban-как-команда-из-четырех-человек-развивает-и-поддерживает-девять-проектов/

тут все есть

на пальцах не готов в чате объяснять :) спросите потом, если будут вопросы

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

хорошо, почитаю, спасибо! если что, я вас в личке помучаю, ладно? :)

помучайте

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

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

то есть если лимит поставить по велосити :)

интересный хак)

:]

если есть уже рабочий процесс по Скраму, можно дополнить его планированием и работой с потоком от Канбана и получите Скрамбан ;)

скрамбат скорее

скрамбат, батяня, батяня, скрамбат