Аннотация
- Докладчик
- Сергей Дмитриев
Одним из наиболее важных навыков, которым должны обладать Ваши команды, является проведение ретроспективы (оценки) проектов. Мы обязаны уделять время на то, чтобы заглянуть в прошлое и немного поразмыслить над полученными знаниями и пройденными уроками, чтобы найти способ улучшить нашу совместную работу в будущем.
Подавляющее большинство организаций не применяют ретроспективу. А если и применяют, то обычно, это случается лишь в самом конце процесса, и, в лучшем случае, все уходит в архивы офиса управления проектами (PMO), где, в большинстве случаев, и остается навеки. В данном выступлении вы познакомитесь с ключевыми моментами проведения ретроспектив, поймете как правильно и эффективно применять этот сильнейший инструмент, повышения эффективности ваших команд.
Вы узнаете:
- что такое «ретроспектива»
- какова основная цель ретроспективы
- существующие «правила игры»
- как сделать ретроспективы интересным и как часто и как долго проводить ретроспективы
- конкретные упражнения, которые вы можете попробовать на своей следующей ретроспективе
Видео
Видео в HD-качестве, смотрите в полноэкранном режиме.
HTML-код включения <iframe src="http://player.vimeo.com/video/23262458?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
Сергей Дмитриев
Интересный доклад.
Единственная претензия к нему – плохая презентация, на слайдах были только фотки (не имеющие отношения к делу), слайдов мало и информации они не содержали, лучше слайдов бы не было вообще.
Доклад был посвящен тому, как надо проводить ретроспективы и зачем. Сергей считает, что ретроспективы нужны обязательно, причем как ретроспективы по командам в конце итерации, так и всего проекта (когда собираются все люди, имеющие какое-либо отношение к проекту) после его завершения.
Ретроспективы необходимо делать интересными (см. книгу 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»
- Каждый обязательно должен что-то сказать
- Основная директива: ретроспектива — это не место, где мы ищем виновных. Мы ищем, что сделать, чтобы стало лучше.
- Рабочий уговор — внутренние правила поведения (например, никто никого не перебивает, никто за другого не говорит и т. п.)
- На ретро должен присутствовать модератор. Лучше не из команды.
Анекдот по теме ретро: Мужик пилит дерево, а оно пилится с трудом. К нему подходит другой и говорит: «Ты бы пилу поточил — сразу бы дело быстрее пошло!». «Да, что ты, — отвечает другой — некогда, пилить надо!» Зачастую мы похожи на первого мужика.
Я был недолго. Изложение не слишком системно, он не успел.
- Два вида ретроспектив: внутренние и внешние, большие. Внешние привязаны к релизам, но можно и без привязки, и даже через одну.
- На ретрах часто пропускают фазу анализа, бросаются сразу лечить.
- Выбирают нереалистичные большие шаги.
- Модераторы — должны быть и они — вне команды. Но только на ретрах, где есть внешние люди.
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
