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

Должна, но ей в этом надо помочь. Как минимум чтобы не скатываться в защитную реакцию и отказ от восприятия содержания фидбека из-за формы :)

пусть стейкхолдер на стикерах фидбек пишет, а потом читает вслух )

хехе :)

так хотя бы и ему тоже плохо будет )

Должна, но ей в этом надо помочь. Как минимум чтобы не скатываться в защитную реакцию и отказ от восприятия содержания фидбека из-за формы :)

и как в этом помогает ретро по средам?) когда они остывают от фидбека 😄 и вроде бы хреновый фидбек уже не проблема

и как в этом помогает ретро по средам?) когда они остывают от фидбека 😄 и вроде бы хреновый фидбек уже не проблема

Не знаю. Ретро отдельно - это другая команда, с которой я не знаком и с коучем которой я вчера полтора часа общался :)

как по мне это побег от проблем прост

С "забыванием" есть много сопособов бороться :)

Пож поподробнее)

Пож поподробнее)

Мой "любимый" способ это флипчарт с бумажками. Каждый раз, когда кто-то в команде встречается с проблемой, он записывает ее на стикере и вешает на флипчарт.

Перед ретро команда через dot voting голосует за темы для ретроспективы с этого флипчарта.

А

В книжке про ретроспективу, из серии руководства по фасилитации, есть такой инструмен

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

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

Он вроде как чисто в ретро использовался для сбора данных. Линия спринта кажется называется, берёшь чертишь линию, разбиваешь по дням, и каждый вспоминает что в какой день его взволновало)

это не совсем то

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

Но я вешал его на постоянно, и любой могу навестить стикер сразу после того как захотел, сработало на 1-2 спринта, потом линия постоянно пустая, и появлялась проблема: "не ну вроде все норм, я не знаю что вешать")

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

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

Парковка тоже есть, и она тоже часто пустая)

Парковка тоже есть, и она тоже часто пустая)

значит в команде нет courage, чтобы говорить о проблемах

Парковка тоже есть, и она тоже часто пустая)

Значит скрам-мастеру надо ходить на стендап, слушать разговоры, задавать вопросы и заполнять парковку самому.

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

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

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

так нет личных вещей есть командные ток 😄

Но так не бывает)

Но так не бывает)

Два чаю этому джентельмену :)

бывает

Все, что происходит в рабочее время - вопросы команды. Иногда это очень раздражает.

Все, что происходит в рабочее время - вопросы команды. Иногда это очень раздражает.

правильнее сказать всё что влияет на работу - вопросы команды. так как есть еще пачка вещей которые происходят вне рабочее время

Хех. А тут мы подходим к серой зоне этических конфликтов :)

Вот например, член команды рассказывает про боль, ты слушаешь его, и понимаешь что это команды не касается, это его личная боль, но пока он с ней не разобрался, он не может идти дальше и обсуждать следующие вещи. Ты спрашиваешь у него: чувак, мне кажется это не касается всей команды, если ты согласен, давай запаркуем, и обсудим после ретро

Вот например, член команды рассказывает про боль, ты слушаешь его, и понимаешь что это команды не касается, это его личная боль, но пока он с ней не разобрался, он не может идти дальше и обсуждать следующие вещи. Ты спрашиваешь у него: чувак, мне кажется это не касается всей команды, если ты согласен, давай запаркуем, и обсудим после ретро

а по поводу у него боль?

Я не уверен, что коучи и скрам мастера достаточно подготовлены для работы с личными болями и проблемами. Все-таки это больше для councelling и психотерапии :)

В рамках работы естественно)

это примерно звучит сейчас так - чувак приходит и говорит у меня болит от того что “какие то процессы говно”, ты ему говоришь ну чел это твоя боль или ты думаешь что это боль команды?

если этот чувак будет весьма себе интровертом без друзей как он узнает что процессы задолбали не только его?

Я перебрал в голове все что вспомнил, вы правы, любая херня влияет на ttm

Так что касается команды

Вопрос только в том, насколько должна быть зрелой команды, что 5 человек слушали как у 1 были проблемы с развертыванием на локальной машине?)

Вопрос только в том, насколько должна быть зрелой команды, что 5 человек слушали как у 1 были проблемы с развертыванием на локальной машине?)

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

Это да

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

Ретро то не резиновое

слона надо есть по кусочкам. как варик можно вывесить проблемы на флипчарт и пусть сами выбирают какие будем чинить на текущем ретро. например через multivoting

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

Или запаркуй что бы не забыть 😊

парковка не всегда хорошо, есть траблы которые до ретро не терпят

Ну дык парковку надо оперативно разбирать, в моем понимании этого инструмента

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

а спринты какой длины, когда начинаются?

а спринты какой длины, когда начинаются?

Изменения, принятые на реттро, надо как минимум в бэклог класть, вне зависимости от длинны спринта :)

И длинна спринта на расписание в этом контексте не влияет :)

Изменения, принятые на реттро, надо как минимум в бэклог класть, вне зависимости от длинны спринта :)

Почему? Разве им там место?

Почему? Разве им там место?

каким то да место, некоторые штуки можно вполне трансформировать во внутреннюю стори

А как по их оценит? Бизнес ценность

так это внутренняя оптимизация - ее бизнес ценность в том что теперь задачи например будут выполнятся быстрее.

Беклог или беклог спринта?

Беклог или беклог спринта?

ситуативно, может оказаться что это огромное изменение в команде - например они поняли внезапно что нужен CI и чтобы там автотесты запускались - это не факт что можно будет реализовать сразу же на спринте.

Почему? Разве им там место?

Скрам Гайд говорит что ... в бэклоге Спринта им место.

Почему? Разве им там место?

Многим - да. То, что сразу не рефлектится в изменениях Team Rules, DoR или DoD стоит поместить в бэклог.

ситуативно, может оказаться что это огромное изменение в команде - например они поняли внезапно что нужен CI и чтобы там автотесты запускались - это не факт что можно будет реализовать сразу же на спринте.

Я учу формулировать решение соответствующие критериям SMART. Пусть это будет небольшое изменение, но оно должно быть сделано в следующем Спринте.

Скрам Гайд говорит что ... в бэклоге Спринта им место.

Как минимум одному самому важному, а лучше всем

Скрам Гайд говорит что ... в бэклоге Спринта им место.

враки ничего он такого не говорит

:)

пруф: To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

Опять же, некоторые решения требуют технической имплементации: команде мало решить "Мы будем использовать feature toggles и TDD", ей надо еще и подготовить инфраструктуру и изучить связанные практики. А это технические стори и спайки :)

The purpose of the Sprint Retrospective is to: • Inspect how the last Sprint went with regards to people, relationships, process, and tools; • Identify and order the major items that went well and potential improvements; and, • Create a plan for implementing improvements to the way the Scrum Team does its work.

враки ничего он такого не говорит

Вот и я не помню такого)))

пруф: To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

так и что? куда остальные записываются то?

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

я прям представил команду с хреновой тучей импрувментов и офигенским SBL где половина это userstory только 😄

Мне кажется это сильно, искать готовое решение проблемы в формулировке фреймворка

так и что? куда остальные записываются то?

неизвестно), я думал вопрос куда вносить))

Фреймворк лишь задает один возможный способ

Мне кажется, отказываться от решения из-за отсутсвия формулировки в описании фреймоврка - еще сильней :)

Просто слона надо есть сфокусированно

неизвестно), я думал вопрос куда вносить))

ну SBL это скорее не про “вносить” а про “взять” 😄

Брать на борт кучу импрувментов — как потом трекать успешность?

ну SBL это скорее не про “вносить” а про “взять” 😄

ок)

Мы командные в команды выносим. А все что не может решить команда выносим на Общую ретроспективу

Ну там не сказано: "закончили ретро, положите в беклог спринта то что наретрили"