Комментарии 9
Как заметил, главная проблема любого ретро - люди, которые думают что они(или другие члены команды) сделали все идеально и максимально(в данных условиях) круто и эффективно.
Как только приходит осознание того, что все мы говно и код наш говно, ретро сразу генерирует реально рабочие и нужные AI и WA.
Вариант 2, доведенный до абсолюта - сходу предлагаются решения, забыв сформулировать проблему и, тем более, разобрать ее причины.
Ещё одна особенность многих ретро - в качестве проблем для разбора берутся сиюминутные конфликты последних двух дней, а не "почему мы не достигли цели спринта".
И ещё, извините за флуд. Решения предыдущих ретро не проверяются, исполнялись ли они, и что помешало.
Это да, знакомая ситуация. Если нужно просто разово что-то делать, то тут чуть проще - делается задача, закидывается на доску, можно не забыть и проконтролировать. А вот если результат обсуждения, грубо говоря, состоит в идее о том, что "если произойдет такая фигня, то в следующий раз надо делать вот так", то тут сложнее..
Понятно, что это все можно тоже фиксировать в разных правилах работы, итогах ретро и т.д. и т.п.... но проблема в том, что со временем таких идей накапливается очень много, а "такая фигня" происходит редко.. и со временем такие решения просто забываются... и как это бывает в жизни, когда "фигня" произойдет, то никто уже про этот пункт и не вспомнит.
Для себя в одной из команд решили отдельно фиксировать подобные идеи, которые реально могут быть важными, и просматривать их перед каждым ретро.. как только убеждаемся, что идея уже несколько раз применялась на практике, и мы про нее точно не забудем - удаляем с доски.
Часто всё упирается во внешние факторы. Причина-то понятна, но что с ней делать - не ясно. Особенно на уровне команды. В итоге на ретроспективе обсуждается одно и то же, без каких либо результатов. Максимум - назначат ответственного, у которого нет полномочий решить эту проблему. Пусть софт-скиллы тренирует, ага.
А еще бывает человеческий фактор, который обязательно присутствует и полностью избавиться нельзя.
Ну назначать ответственного без полномочий - по большому счету, это самообман.. да и закрывать проблему только за счет софт-скиллов (т.е. частных договоренностей) тоже в какой-то мере самообман (проблема остается на уровне организации, просто отдельная команда ее сумела обойти), но это уже философский вопрос:)
в этом случае, если решение проблемы зависит не от команды, или у команды нету возможностей/полномочий на нее повлиять, или перепробовали все возможное, и не работает, то честнее будет признать эту проблему как ограничение, с которым надо жить. и вместе придумывать, как его обходить, минимизировать влияние и т.д. и т.п.
это в любом случае лучше формальных "решений" с формальными "ответственными"
5 способов борьбы с унылыми ретроспективами