Завершение спринта в Scrum – демо и ретро
В этой, тринадцатой статье из серии «Менеджмент цифрового мира» я продолжу рассмотрение схемы скрам и буду говорить про завершение спринта – Демо, оно же Sprint Review и Ретроспективу. Она продолжает предыдущие статьи «Итерации Scrum – целостная схема, а не прикольная картинка», где мы рассмотрели переход к итеративной работе и планирование, и «Схе…
привет! ретра - очень крутой инструмент! мы у себя в командах проводим два вида ретры, одна - внутренняя, чисто на нашу проектную команду, обсуждаем, по сути, то, о чем написано выше, что можем сделать лучше и каким образом, кто нам может в этом помочь, какие есть ресурсы для улучшений и что нам может помешать, и внешняя - когда проектная команда вместе с командой заказчика обсуждают результаты какого-то этапа работ.
самая важная (для меня) цель ретры - это возможность раскопать проблемы, которые, как правило, не видны, ну и, конечно, как следствие - составить список задач, осмартовать и взяться за улучшения! однако, тут есть и косяки
самый косяк этого инструмента (опять же, для меня) - это то, что из людей порой и клещами не вытянуть проблемы, и так, и эдак, и с бубном поплясал, не делятся, а потом обижаются, что менеджеры мысли не читают и не помогают)) если у коллег есть способы "разговорить" команды - поделитесь. пожалуйста!
спасибо за статью!
Я слышал несколько интересных приемчиков, которые укладываются в общую схему: сначала приводишь к признанию, что проблем нет, а потом ставишь вызов. И или команда его принимает, или начинает выкладывать проблемы. Например, "а, вот есть у нас фича, очень нужная заказчику, хоть и прилетела в середине спринта - что надо изменить, чтобы мы срочные вещи могли брать?" или "а вот у нас же косяк вылез из-за нестандартного использования софта, которое мы не закрыли, и мы его много часов разгребали - что надо сделать, чтобы мы гарантировали, что такое не повторилось"? Примеры надо подбирать соответствующие тому, куда мы хотим команду сдвинуть, то есть если проблема в скорости - то одни, а если в качестве - то другие.
Вообще в идеальном agile менеджеры - не должны помогать, команда сама организуется и решает проблемы. Все, и внешние и внутренние. И поэтому ретро считается внутренним мероприятием.
Дальше есть два направления.
1) Можно посмотреть доклады про ретро (я слушал много на AgileDays, SQAdays, AnalystDays и других), и в части из них еще и список литературы хороший. Про ретро много книг (я знаю, но сам - не читал, увы). Или, кстати, из смежных областей, потому что ретро - частный случай post mortem analysis, это одна из практик управления знаниями.
2) Можно копать методы выяснения проблем с погружением по системным уровням. Для начала берем статистику, каждый конкретный случай - случайность, но надо менять систему. И дальше - root cause analysis или системный анализ с погружением на уровни. А со статистикой есть интересная работа в Канбан - строишь спектральную диаграмму выполнения задач и, например, видишь длинный хвост (в среднем с багом справляемся за пару часов, максимум день, но есть которые неделю требуют) - и именно с ними разбираешься, анализ применяется не только к багам.
Очень рад, что статья вызвала отклик, пишите!