Comments 20
Отличная статья! Хоть сам и не сторонник расово-scrum-верных подходов, но все равно возьму на вооружение некоторые вещи.
Самый подходящий для меня формат ретроспективы когда обзор своей работы каждый пишет сам, при подготовке к спринту
Да, "домашка", ничего не поделаешь, но зато никто не торопит во время митинга, ты легко вспоминаешь все самое хорошее и самое не очень и спокойно фиксируешь .. и приносишь на ревью спринта. Проводить ретро в формате "вспомнить что вы делали последние две недели за 10 минут" - для меня так себе идея. Пара месяцев в команде понадобилось добавлять отдельные задачи в спринт на подготовку, зато потом стало все гораздо легче (и задачи кстати тоже ушли, привычка - дело такое). Все приходят с уже готовыми мыслями и идеями, не взятыми с потолка во время "минутки", как вы предлагаете.
С подготовленными селф ревью гораздо легче проводить ревью спринта.
А ретроспективу в общем то и необязательно проводить если команда не видит проблем которые ей мешают. Но в команде должен быть тот, кто занимается анализом ревью, чтобы отсекать случаи типа "Вася уже несколько спринтов выполняет только 50% взятых задач но пишет что проблем нет" и выносить их в список проблем. Это, как и у вас , должен быть или член команды - не менеджер, или же менеджер но такой, который в работе ставит себя на одном уровне с другими в команде, дополнительно выполняя менеджерские функции. Как раз чтобы не давить авторитетом "я начальник - ты дурак"
Про план действий:
у любого действия должен быть "владелец". Это человек который вынесет с ретроспективы действие и обеспечит его выполнение. Если это задача внутри команды - то можно договариваться сразу кто будет выполнять.
Каждое действие должно быть сформулировано в виде действия, приносящего конкретный результат, а не просто "благие намерения" (в вашем списке последние два - как раз благие намерения). Но, опять же, в случае "Ответственно подходить к ревью pull request'ов" у вас в правой колонке тоже написаны какие-то пожелания. Я бы предложил "сформулировать и описать на вики правила ревью пул реквестов" - договоренность, кото
рая формируется внутри команды и которой члены команды обещают следовать, зафиксированная и живая - то есть ее можно и нужно править со временем, если она будет вызывать проблемы
Уточнение: не все action point'ы являются конкретными действиями. Это может быть изменение в процессе -- тогда оно просто принимается всеми членами команды. Или это может быть задача на уменьшение тех. долга в следующий спринт (в резерв мощности, которая команда себе на это оставляет). В этих случаях нет "владельца".
И не обязательно в этом случае описывать это на вики. Описывать правила проведения pull request'ов иногда это просто лишняя бюрократия. Ведь и так эти правила все помнят (пока что), а в случае сомнений можно посмотреть на список action point'ов. Разумеется, это только для маленькой команды со своими правилами.
"изменение в процессе" - это вполне себе конкретный экшен, "внести изменение в процесс", он же где то описан, не на словах договариваемся
то же с уменьшением техдолга - кто-то будет его уменьшать. Если конкретные технические задачи будут определены на ближайшем планировании то кто-то с ретро должен выйти с задачей "довести до планирования", но опять же "уменьшение техдолга с целью" - тогда должно быть определено на ретроспективе
На моем опыте очень плохая практика делать экшенами пожелания. Экшен должен быть экшенабл (простите за англицизмы, по русски оно как то не звучит)
Процесс может быть и описан, а может быть и на словах. В последних двух командах он был "на словах и в скриптах". До этого было формальное описание, общее для десятка команд... на которое команды забивали и всё равно делали по своему.
Уменьшение тех. долга -- имеется ввиду добавление конкретной задачи, в которой по итогам ретроспективы уже понятно, что сделать. Тут в принципе можно сказать, что ответственным является тот, кто сформулирует задачу в Jira и добавит в следующий спринт. Но это может быть и не тот человек, который потом в спринте эту задачу будет делать.
то есть на несоблюдение процесса мы на ретро записываем "Коля мы же тебе уже сто раз говорили" ?
Я не сторонник формализации всего и вся, но в определенных ситуациях от обилия информации начинаешь теряться и в голове ее не удержать, поэтому важные соглашения надо фиксировать. Хотя тут скорее культура работы в команде, конечно.
А про техдолг, судя по всему, я вас убедил :D
Исходно обсуждалась не проблема, что не соблюдается процесс, а проблема, что слишком мягко/строго проводится ревью, потому что это вообще не было формализовано. То есть надо было выработать подход, как должно проходить ревью (сколько человек, как быстро, кто). У нас это вылилось не в формализацию в вики, а в написание скрипта, который часть этого процесса автоматизировал. Оставшуюся пока что помним в голове.
А вот если процесс не будет соблюдаться (когда процесс уже есть), тогда да, первый шаг -- его куда-нибудь записать. Но у нас такой проблемы пока не было.
А ретроспективу в общем то и необязательно проводить если команда не видит проблем которые ей мешают
При кажущейся очевидности этой мысли, я склонен считать, что так не бывает, и скорее всего команда просто не видит смысла высказывать свои проблемы в том формате, в котором у вас проходит ретро.
Вот именно поэтому должен быть кто-то кто увидит в такой ситуации проблему, даже если команда ее не видит. Я про это упомянул.
И, поверьте, бывают такие случаи. как-то
6 спринтов без проблем работали, незабываемое ощущение у всей команды - это очень поднимает дух (и это заметно)
Очень многие команды попадают в эту логическую ловушку:
1) У нас есть проблемы, что нужно чтобы их решить?
2) Ретроспективы!
3) Ок, мы решили наши проблемы, зачем теперь нам ретроспективы?
Именно поэтому важно акцентировать внимание на том, что ретроспектива - не способ решения проблем, а инструмент непрерывного процесса совершенствования работы команды: "Мы работали 6 спринтов без проблем, а как нам работать еще лучше/эффективнее?".
И задача фасилитатора тут донести этот акцент до команды, чтобы она сама начала генерировать идеи, что можно улучшить.
Тк альтернатива - это "злой начальник", который придет и создаст проблемы сам: "6 спринтов проблем не было? Ок, в ближайший спринт сделайте вдвое больше". И не потому, что злой, а потому что видит, что команда может лучше, но сама над этим не работает.
проблемы есть и всегда будут, идеально работать никогда не получится - никто не работает в изолированном пространстве и не строит сферического коня в вакууме.
Здесь, да и у @vlsergey в общем то так и написано - главное понять что проблема есть
. Ваш пример с развитием - это уже анализ процессов внутри команды, на них тоже кто-то должен обращать внимание.
Есть замечательная книга по Agile от Боба Мартина, так вот он когда описывает инструменты, то отталкивается от того зачем и почему они его придумали, вместо "понадобятся листочки". Мне видится это важным
Потеряли самое главное - проверку "а помогло/сделали ли то, что мы решили на прошлой ретроспективе", иначе это реально тусовка ради тусовки.
Ну и я так и не увидел, а кто по вашему должен то присутствовать? PO является частью команды, но считается, что его присутствие на ретро вредит по причине конфликта интересов.
Валидация action point'ов как отдельный шаг не нужен. Потому что ретроспектива это не отчёт. Если у нас какой-то action point не решил проблему (и не важно -- потому что не был выполнен, или потому что не помог), мы заново вписываем проблему в список, и, если она по прежнему актуальна, ищем новые решения. Разумеется, если будет предложено то, что уже предлагалось ранее, то стоит обращать на это внимание и уточнять, а чем текущее предложение лучше несработавшего старого.
Присутствие PO это штука спорная. Очень много зависит от того, а кого вы называете владельцем продукта, и кем он сам себя считает. Если этот человек участвует в написании кода и ревью -- его 100% надо включать. Если человек что-то делает внутри команды (закрывает таски в Jira) -- тоже надо. Если же он только таски создаёт... будет зависеть от самого человека, в том числе его адекватности. Ну и загруженности. Если человек даже Jira не видит и только раздаёт ЦУ -- ему на ретро точно делать нечего.
Если каждый раз говорится одно и то же -- это явный признак проблем. Но вот где -- вопрос.
исходя из своего опыта - есть несколько вариантов:
решаете не ту проблему - может быть неверно сформулировали, или слишком поверхностно анализировали и не докопались до первопричины. Судя по вашим словам о похожести проблем - наиболее вероятно, с моей точки зрения (это такой gut feeling, с похожим сталкивались)
решение проблемы, несмотря ни на что, - от вас не зависит.
это на самом деле не проблема, но в список она попала из за молчаливого согласия что "Васе неудобно, да, наверное надо как то решить"
Ретроспектива по шагам. Рецепт