Artem
А, который выше по? Да не, зачем, он именно управленец
Artem
Технарей надо научить свои техстори, про которые я как раз и спросил, нормально доносить до бизнеса и тогда ИТ руководитель будет только управлением заниматься.
Artem
Нет там от
Pavel
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
Pavel
Тут есть :)
Artem
Это имхо про релизы уже
Pavel
Это правильное имхо, но спринты тоже про релизы
Artem
Но ни одно и то же )
Pavel
Я к тому, что если сильно хочется докопаться до мышей, то спринты от недели начинаются :)
Андрей
Это, кстати, не правило скрама. Неизменна только длинна текущего спринта :)
Ну, хмммм, в русском переводе «желательно сохранять неизменную продолжительность Спринта», а в оригинале и вовсе «Sprints have consistent durations throughout a development effort.» Точно не правило? :)
Pavel
Точно не правило. Consistent не равно equal :)
Artem
Я к тому, что если сильно хочется докопаться до мышей, то спринты от недели начинаются :)
В прямом указании про спринты - нет. The heart of Scrum is a Sprint, a time-box of one month or less
Pavel
В прямом указании про спринты - нет. The heart of Scrum is a Sprint, a time-box of one month or less
Ну да, но тут такая философская дискуссия, что обратиться к манифесту не зазорно. ЕМНИП раньше в гайде как раз было про от недели до месяца.
Pavel
А про длинну итерации: это best practice и все такое, но поменять ее длительность у команды возможность есть. Теоретически - хоть каждый спринт менять.
Mikhail
Daria
это моя история, как раз. У меня нет тех бекграунда, мне это не мешает жить и управлять проектами при наличии как минимум вменяемого лида разработки. А если аналитик есть — это вообще шикардос. =) но это мой личный опыт
Pavel
Вот кстати, про канбан-метод практически нет коротких обучающих видео и нет аудиокниг.
Pavel
В дороге не хватает.
Mikhail
Вот кстати, про канбан-метод практически нет коротких обучающих видео и нет аудиокниг.
Много чего у них нет. Ты их тренинги видел?) тяжело очень, хоть и дичайше полезно
Андрей
А про длинну итерации: это best practice и все такое, но поменять ее длительность у команды возможность есть. Теоретически - хоть каждый спринт менять.
Вот «каждый спринт менять» это будет very bad practice. Чуйкой чую, но цитатой из гайда не подкреплю ;) кроме той, что выше, про consistent (пусть и не equal).
Pavel
Вот «каждый спринт менять» это будет very bad practice. Чуйкой чую, но цитатой из гайда не подкреплю ;) кроме той, что выше, про consistent (пусть и не equal).
Ну да, все верно. Но прямого запрета брать новую длинну спринта - нет. И надо помнить, что команда может поменять длинну спринта, но лучше этого не делать либо иметь очень-очень серьезные причины.
Pavel
А вот в SAFe команда не может длинну спринта поменять, к слову об отличиях.
Андрей
А вот в SAFe команда не может длинну спринта поменять, к слову об отличиях.
Ну и понятно почему - команд много и все на общий release train завязаны.
Андрей
Ну да, все верно. Но прямого запрета брать новую длинну спринта - нет. И надо помнить, что команда может поменять длинну спринта, но лучше этого не делать либо иметь очень-очень серьезные причины.
И вот тут есть моя любимая тема: если что-то убрать из Скрама - это не будет Скрамом. Если добавить что-то, что напрямую конфликтует с гайдом - тоже. А если сделать что-то «формально разрешённое», но кривое с точки зрения здравого смысла и духа Скрама?
Pavel
Ну и понятно почему - команд много и все на общий release train завязаны.
Ну да. SAFe с этим аргументом очень много свободы и самоорганизации у скрам-команд забрал :)
Андрей
Ну да. SAFe с этим аргументом очень много свободы и самоорганизации у скрам-команд забрал :)
Это вообще свойство человека и систем человеков - чем больше народу, тем больше регуляции и меньше свободы у каждого. Главное, опять же, не выкинуть здравый смысл и не зарегулировать всё до упора :)
ulyana
#whois Всем привет, я Ульяна, работаю в Праге. Айти компания резко разрослась от 10 до >50 человек и меня наняли it prosecc manager, чтобы наладить имеющиеся айти процессы. До них я работала только в 1С проектах, поэтому опыт для меня новый. Пока то, что я у них вижу похоже на канбан (судя по моему скудному теоритическому опыту). Группу порекомендовали в Чешском эммигрантском чатике подсказали этот чат, чтобы было, где попросить совета у более опытных людей.
Mikhail
Канбан это к нам, да ^_^
Pavel
Канбан это к нам, да ^_^
михаил, а можешь провести ликбез по канбан-методу? В виде вебинара или просто текстом в канале?
Artem
Похожа на канбан обычно доска ) начало неплохое
ulyana
нет, доски у них еще нет. Вот как раз насчет доски - может кто посоветует - ищу сейчас плагин для редмайна - чтобы колонки на доске делал не только для статусов, но для связки статус+трекер. т.к. сейчас задачи делятся по трекерам, согласно скорее отделу (программисты, тех.писатели, тестеры и т.д.). и есть отдельно статус (новый, в работе, готов и т.д.). Я не хотела бы им сильно рушить сложившуюся систему - но тот плагин, что у них есть сейчас (и не используется) рисует колонки по статусам, а трекер указывается только на самом "листочке" это не удобно(
Mikhail
михаил, а можешь провести ликбез по канбан-методу? В виде вебинара или просто текстом в канале?
как вариант можно в FeatureBan поиграть онлайн. Надо подумать как это организовать. Недавно знакомый делал
Mikhail
можно после 17го числа к этой теме вернуться, там время появится :)
Pavel
ОК :)
ulyana
ага, его как раз сейчас смотрю
Yuriy
Там, в принципе, все просто)
Artem
Так что, по техсторям ни у кого ничего нет? (
Pavel
Можно, пожалуйста, подробнее про значение SP?
В safe размером сторипоинта владеет весь ART, соответственно команда должна использовать его, но не определять, что для них 1 или 8 :)
Pavel
В том, что с элементами бэклога работает не ART, а конкретная команда.
Artem
В лесс тоже как-то к этому все тянет
Artem
Беклог-то один
Pavel
Из--за тогО, что у конкретной команды нет собственного значения sp, они не могут реально сравнивать сложность элементов бэклога, над которыми они работают.
Pavel
А из-за метода калибровки общего бэклога, это выливается либо в использование sp как прокси для времени, либо использованя sp просто как элемента длительности против спрогнозированной velocity.
Pavel
И то, и другое не дает команде никаких преимуществ по сравнению с использованием времени, зато дает все недостатки, ключевой из которых - эстимейт превращается в commitment :)
Damir
Тут смотря что выбрать методом калибровки. Можно использовать "пристрелочную карту", сравнивать по ней элементы. У команд вполне может быть разный велосити, это очень индивидуально. Что оценка превращается в обещание - это уж как внедрить. SAFe говорит о прогнозе, ровно как и Scrum
Pavel
Да что бы ни выбрать, пока значением сторипоинта владеет ART, команда никак не может сравнивать элементы своего бэклога между собой, только использовать sp как элемент размера.
Pavel
И да, при этом конкретный элемент бэлога для одной команды 1, для другой - 5, сугубо из-за разницы в скилах и контексте, но выбрать придется только какое-то одно значение.
Pavel
А из-за этого команды могут управлять размером бэклога спринта только через velocity.
Pavel
Которое, в свою очередь, становится сравнимым между командами, так как значение sp - одинаковое.
Dinara
Смотря что в его обязанностях, только ли управление проектом и в какой части
Pavel
А из-за этого оно становится прокси для длительности :)
Pavel
И да, команда теряет возможность нормально отвечать на вопрос "почему у вас velocity меньше, чем у соседей"
Damir
Вообще, у каждой команды на PI формируется свой командный бэклог, и он не общий. Команды сами на PI-планировании оценивают истории, и нет какой-то проблемы что оценки по "одинаковым" историями будут разные у разных команд. В своей практике я такой проблемы с SP не вижу. И вопросов про сравнение команд по велосити у нас пока не возникает.
Pavel
Разумеется они сами оценивают истории. И вполне возможновы пропустили калибровку значения SP, потому у вас не возникает проблем.
Pavel
Везде, где этот шаг не пропускали и команды использовали метод калибровки, предложенный SAFe Inc - везде была описанная мной проблема :)
Pavel
И, кстати, они убрали трэшак с нормализацией через часы из глоссария, но он вполне себе до сих пор есть в материалах тренингов :)
Pavel
А нет, не убрали
Pavel
1. Normalize story point estimation: Find a small story that would take about a half-day to develop and a half-day to test and validate, and call it a “one” Estimate every other story relative to that “one” Copyright © Scaled Agile, Inc. The copyright notice above must be included. For further information on the use of SAFe content and trademarks go here: https://www.scaledagile.com/about/about-us/permissions-faq/ Explore Training at: https://www.scaledagile.com/training/calendar/
Pavel
https://www.scaledagileframework.com/iteration-planning/
Pavel
2. Establish velocity before historical data exists: For every full-time developer and tester on the team, give the team 8 points (adjust for part-timers) Subtract one point for every team member vacation day and holiday in the iteration
Damir
Разумеется они сами оценивают истории. И вполне возможновы пропустили калибровку значения SP, потому у вас не возникает проблем.
Да, действительно, мы не синхронизировали размер SP. Я, кажется, начинаю понимать кейс. Спасибо за разъяснения!
Pavel
Вот как после такого не получить sp которые будут прокси для часов?:)
Damir
Сделать это только для одной истории, а остальные оценивать сравнением. ) Но соблазн, конечно, большой соскочить)
Damir
#whois Я скрам-мастер в Ак Барс Банке. Два года назад у нас открылась цифровая лаборатория (Ак Барс Цифровые Технологии), в рамках которой у нас создавались команды, которые занимаются развитием цифровых каналов. Чуть менее полугода назад мы сделали шаг в сторону интеграции новых подходов в банк. В качестве фреймворка был выбран Essential SAFe, сейчас у нас три АРТа.
Алекс
🚅🚃🚃🚃🚃🚃🚃 :)
Konstantin
Вот как после такого не получить sp которые будут прокси для часов?:)
Да так и получается, а если на планировании ещё бить задачи на мелкие то вообще смысл в оценки Теряется так как в среднем все задачи делаются за 2 условных часа
Sergey
Так что, по техсторям ни у кого ничего нет? (
У нас сообщества практик их формируют. Оценивают, сплитят чтобы в Спринт можно было сделать, в общем обычный PBR, только узким кругом компонентного сообщества. Потом продают РО. Он их ставит в общий Бэклог и они уходят на Планирование.