Аннотация
- Докладчик
- Сергей Дмитриев
Одним из наиболее важных навыков, которым должны обладать Ваши команды, является проведение ретроспективы (оценки) проектов. Мы обязаны уделять время на то, чтобы заглянуть в прошлое и немного поразмыслить над полученными знаниями и пройденными уроками, чтобы найти способ улучшить нашу совместную работу в будущем.
Подавляющее большинство организаций не применяют ретроспективу. А если и применяют, то обычно, это случается лишь в самом конце процесса, и, в лучшем случае, все уходит в архивы офиса управления проектами (PMO), где, в большинстве случаев, и остается навеки. В данном выступлении вы познакомитесь с ключевыми моментами проведения ретроспектив, поймете как правильно и эффективно применять этот сильнейший инструмент, повышения эффективности ваших команд.
Вы узнаете:
- что такое «ретроспектива»
- какова основная цель ретроспективы
- существующие «правила игры»
- как сделать ретроспективы интересным и как часто и как долго проводить ретроспективы
- конкретные упражнения, которые вы можете попробовать на своей следующей ретроспективе
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
Сергей Дмитриев
Интересный доклад.
Единственная претензия к нему – плохая презентация, на слайдах были только фотки (не имеющие отношения к делу), слайдов мало и информации они не содержали, лучше слайдов бы не было вообще.
Доклад был посвящен тому, как надо проводить ретроспективы и зачем. Сергей считает, что ретроспективы нужны обязательно, причем как ретроспективы по командам в конце итерации, так и всего проекта (когда собираются все люди, имеющие какое-либо отношение к проекту) после его завершения.
Ретроспективы необходимо делать интересными (см. книгу Agile Retrospectives) и полезными. После каждой ретроспективы должен быть результат, т. е. выполнены конкретные действия (пусть даже всего одно действие) направленные на улучшение процесса. Если в результате составляются огромные списки того, что необходимо сделать и что-то делать из этого списка никто не собирается, смысла в такой ретроспективе нет.
На ретроспективе команда должна быть полностью открыта и готова обсуждать любые проблемы. Для этого предлагается не приглашать на ретро руководителя (в случае скрама – product owner), возможны также варианты, когда руководитель присутствует только на некоторых ретроспективах. Крайне желательна неформальная и доброжелательная атмосфера.
На ретроспективе необходимо собирать не только факты, но и эмоции участников команды. В частности к одним и тем же фактам у разных людей может быть совершенно разное отношение. В качестве примера Сергей приводит ситуации, когда после составления списка фактов он просил участников отметить, к каким фактам они относятся положительно, а к каким отрицательно. В результате оказалось, что есть несколько вещей, к которым одни члены команды относятся положительно, а другие отрицательно.
Сергей утверждает, что на любых собраниях (и в частности ретроспективе) присутствие модератора (facilitator) существенно увеличивает результативность совещания. Причем будет оптимально, если этот человек является внешним и не разбирает в обсуждаемой теме, тогда он сможет провести обсуждение в рамках намеченного плана и не даст дискуссии уйти в сторону.
- Пришел только на конец доклада (слушал про Code Review).
- Показалось интересным (рассказывали про то, как разнообразить ретро).
- Надо бы посмотреть видео.
Хорошая, с картинками, вдохновляющая речь, заставила задуматься на тему «а как у нас?», и в результате этих размышлений упустил основную нить доклада. Что-то типа «почитать книжку Agile Retrospectives»?
Рассказывал про ретро на примере своей команды. Очень жаль, что у докладчика было только полчаса. Некоторые идеи доклада:
- 1 неделя работы = +1 час на ретро;
- рекомендовал ретро в виде игр;
- в начале ретро просто собираются факты, не обсуждая их;
- факты оцениваются (+\-), оценки могут не совпадать у разных людей;
- определяем что конкретно сделаем в след итерацию + кто и как это будет мерить;
- ретро полезно проводить не только для команды, но и для заказчика;
- могут быть полезны модераторы для "внешних" ретро.
Очень понравился прием со спящим животным :)
Рекомендую посмотреть.
Очень хороший доклад и в плане содержания, и в плане подачи материала. Очень понравился! Смотреть всем!
Его сайт http://www.agilecoach.ru
Основные мысли:
- Ретроспектива — «коллективное рассказывание историй»
- Доверяй своим подчиненным
- Менеджеры боятся доверять, но страх — это хорошо, это значит, что есть экперимент, проба что-то улучшить.
- Фокус ретроспективы должен быть обращен на то, чтобы что-то произошло — поменялось
- Ретро ~ 1 час на неделю работы
Структура:
- открытие 5 %
- сбор данных 30-50 %
- у всех есть чувства
- по списку красными и зелеными точками отмечают «за» и «против»
- приникновение в суть 20-20 %
- решение о дальнейших действиях 10 %
- что реально можем сделать в ближайший спринт
- закрытие 10 %
- PO — гнать с ретро. Либо пускать хотя бы через раз.
- Если команда в отсутвии PO может «вывесить грязное белье», то это уже команда. Иначе — не команда.
- И здесь есть игры для ретроспектив — читать книгу Esther Derby, Diana Larsen «Agile retrospectives»
- Каждый обязательно должен что-то сказать
- Основная директива: ретроспектива — это не место, где мы ищем виновных. Мы ищем, что сделать, чтобы стало лучше.
- Рабочий уговор — внутренние правила поведения (например, никто никого не перебивает, никто за другого не говорит и т. п.)
- На ретро должен присутствовать модератор. Лучше не из команды.
Анекдот по теме ретро: Мужик пилит дерево, а оно пилится с трудом. К нему подходит другой и говорит: «Ты бы пилу поточил — сразу бы дело быстрее пошло!». «Да, что ты, — отвечает другой — некогда, пилить надо!» Зачастую мы похожи на первого мужика.
Я был недолго. Изложение не слишком системно, он не успел.
- Два вида ретроспектив: внутренние и внешние, большие. Внешние привязаны к релизам, но можно и без привязки, и даже через одну.
- На ретрах часто пропускают фазу анализа, бросаются сразу лечить.
- Выбирают нереалистичные большие шаги.
- Модераторы — должны быть и они — вне команды. Но только на ретрах, где есть внешние люди.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
