Pavel
Практически коллеги в таком случае
Pavel
Я к PSPO II/PSM III готовлюсь.
Sergey
Я PSPO 1 прошел. Они похожи с PSM1. А вот PSM3 это посложнее тема, мне еще не скоро светит. Непочатый край. Интересно будет услышать советы после сдачи.
Sergey
PSPO2 похож на PSM2?
Pavel
PSPO2 на PSM3 похоже
Sergey
Практически коллеги в таком случае
А есть что-нибудь более полезное для сдачи PSM2 чем https://www.thescrummaster.co.uk/scrum/how-to-pass-the-professional-scrum-master-ii-psm-ii-assessment-from-scrum-org/ Как лучше готовиться?
Dmitry
Pavel
У PSPO только два уровня.
Pavel
А есть что-нибудь более полезное для сдачи PSM2 чем https://www.thescrummaster.co.uk/scrum/how-to-pass-the-professional-scrum-master-ii-psm-ii-assessment-from-scrum-org/ Как лучше готовиться?
Я не уверен, что вообще есть что-то полезное для подготовки.
Pavel
Есть хорошие материалы по самому scrum, есть case studies
Sergey
Для PSM1 полно всего ...
Pavel
PSM1 можно сдать без подготовки.
Pavel
https://www.scrum.org/resources
Pavel
Во первых, вот это.
Sergey
Это уже штудирую.
Pavel
Во вторых есть очень хорошая книга the scrum master way
Alexey
Ребят, а как вы в скраме работаете с багфиксом? Возвращаете задачу или каждый баг - новая задача? И куда новая задача? В текущий спринт (что странно) или в новый?
Если 1 вариант, то как Команда относится к возврату? Тонкая душевная организация разработчиков не принимает это как личное оскорбление?
Если 2 вариант, не страдает ли от этого релиз?
Если работа сделана её нельзя сделать заново. Новый баг новый заказ на работу. В этом или новом спринте.
Pavel
+ все прочее от этого автора (коуч кейсбук и product owner way)
Pavel
Ребят, а как вы в скраме работаете с багфиксом? Возвращаете задачу или каждый баг - новая задача? И куда новая задача? В текущий спринт (что странно) или в новый?
Если 1 вариант, то как Команда относится к возврату? Тонкая душевная организация разработчиков не принимает это как личное оскорбление?
Если 2 вариант, не страдает ли от этого релиз?
Я обычно рекомендую двухуровневую систему (дальше на примере жиры):
1. Бага для PBI, которая поймана в спринте превращается в сабтаску, а PBI остается в in progressю КОманда не может сказать, что задача done, пока в ней есть баги.
2. Бага из регрессии или очень кросс-функциональные идут в бэклог
3. На планинге команда должна в первую очередь брать баги, потом уже функциональные PBI
Pavel
Секунду, сейчас скину правильную
Pavel
Автор Geoff Watts. Книги Scrum Mastery и Product Mastery
Pavel
+ его же The Coach Casebook
Pavel
Не уверен, что эти книги переводили на русский.
Sergey
Секунду, сейчас скину правильную
Угу, а то я тут уже в этой книге про делегивание ответственности прочитал на пробных страницах. Ужаснулся ...
Pavel
НУ и Адкинс, разумеется :)
Pavel
Угу, а то я тут уже в этой книге про делегивание ответственности прочитал на пробных страницах. Ужаснулся ...
А что там не так с делегированием ответственности?
Pavel
Я просто книгу в список для чтения добавил, но еще не читал
Alexandra
Я обычно рекомендую двухуровневую систему (дальше на примере жиры):
1. Бага для PBI, которая поймана в спринте превращается в сабтаску, а PBI остается в in progressю КОманда не может сказать, что задача done, пока в ней есть баги.
2. Бага из регрессии или очень кросс-функциональные идут в бэклог
3. На планинге команда должна в первую очередь брать баги, потом уже функциональные PBI
У нас примерно также было, правда мы баги брали по приоритетам
Критичные - идут в спринт взамен текущих задач
Менее критичные, high, но ждут - идут в след спринт
Но если делать спринт с багфиксами только, демо хреновое выходит, поэтому как минимум 2-3 ценных изменения показать надо. Брали задачи «результат виден, делать не очень тяжело» для этого
Alexandra
Хотя конечно в нормальном продукте просто не бывает столько багов high сколько наша платформа генерила)))
Sergey
А что там не так с делегированием ответственности?
А она не делегируется при делегировании полномочий. А там автор предлагала делегировать ответственность на команду. Сильно не вчитывался.
Pavel
В системе, в которой техддолг выплачивается быстро, багов на полный спринт обычно не накапливается :)
Pavel
А она не делегируется при делегировании полномочий. А там автор предлагала делегировать ответственность на команду. Сильно не вчитывался.
Ну в scrum это все довольно tricky.
Pavel
У скрам-мастера нет _полномочий_ которые он может именно _делегировать_
Sergey
Сейчас найду эту цитату
Pavel
У скрам-мастера, по сути, вообще полномочий в классическом менеджерском понимании нет.
Pavel
он не менеджер, не босс и не контролер.
Pavel
Ну а ответственность за результат нельзя делегировать команде, потому что это и так ответственность команды
Sergey
"Однако scrum-мастер – это ведь не просто административная должность, поэтому устранение препятствий должно сопровождаться делегированием ответственности, активности и вовлеченности команде, дабы она сама могла решать свои проблемы."
Sergey
Это та самая цитата
Pavel
Я что-то подозреваю, что это фиговый перевод :)
Sergey
Смысл понятен, обороты корявые.
Sergey
Видимо так
Pavel
Смысл правильный, просто "делегирование" не к месту.
Pavel
Т.е. цель скрам-мастера - стать не нужным в команде.
Pavel
Слегка взрывает мозг, но именно так и есть :)
Sergey
Слегка взрывает мозг, но именно так и есть :)
По идее, когда команда прошла кристалищацию скрам мастер ей не нужен
Sergey
Слегка взрывает мозг, но именно так и есть :)
Стдругой стороны, если скрам мастер нужен коианде, он не выполнил свою функцию?
Pavel
По идее, когда команда прошла кристалищацию скрам мастер ей не нужен
Я обычно формулирую по другому: когда скрам-мастер помог команде перейти через Шу и Ха к Ри - он уже не нужен
Pavel
Стдругой стороны, если скрам мастер нужен коианде, он не выполнил свою функцию?
Нет, он в процессе выполнения своей функции.
Sergey
Я обычно формулирую по другому: когда скрам-мастер помог команде перейти через Шу и Ха к Ри - он уже не нужен
+1 за твою формулировку, она более полная
Sergey
Вспомнил мультик про КунгФу Панду. Там шикарно эта тема раскрыта, когда учитель уходил.
Grigory
Скрам мастер всегда нужен.. Процесс улучшения бесконечен.
Pavel
Скрам мастер всегда нужен.. Процесс улучшения бесконечен.
Процесс улучшения - да. Необходимость участия скрам-мастера в этом процессе - нет.
Grigory
Желательно участие такой роли, не хорошо "размазывать".. Хотя, если команда решила изгнать, то да..
Pavel
Вопрос не в "изгнать". Самоорганизация команды не ограничивается каким-то одним аспектом. Если это полноценная самоорганизация, разумеется.
Pavel
Соответственно в какой-то момент команда умеет сама справлятсья с изменениями.
Grigory
На любую команду найдётся свой скрам мастер)
Pavel
Возможно.
Pavel
Не все скрам-мастера одинаково полезны :)
Pavel
Опять же, про "стать бесполезным" надо правильно понимать уровень этой бесполезности
Pavel
Это и стремление к тому, чтобы команда могла обходиться без тебя, и одновременно способность тебе признать, что ты этой команде уже никак полезным быть не сможешь.
Pavel
Вот вторая часть понимания часто вызывает защитную реакцию :)
Sergey
Всем привет.
Кейсы:
1. SM работает с одной командой.
2. SM работает с 2-3 командами, которые делают разные продукты (направлении одно) и у команд разные kpi.
Вопрос: как правильнее померить эффективность работы SM в этих кейсах?
Цель: утвердить корректный и справедливый kpi, который и SM не обидет, и компанию
Vladimir
А что будет зависеть от kpi?
Sergey
Премия :)
Vladimir
Эх :)
Vladimir
У Сазерлэнда в книге есть раздел про счастье, где он сетует (не уверен, что верное слово подобрал) на то, что людей хвалят за результат, а не за процесс.
Глава не большая, прочитайте, может быть решите отказаться от kpi )
Vladimir
Тут выше Павел писал, что задача скрам мастера сделать так чтобы он был ненужен. Вот какой kpi в таком случае прикрутить? Количество косяков, которые скрам мастер позволил команде совершить? 😂