Персональные инструменты
 

Ретроспективы. Настраиваем наш процесс разработки (Сергей Дмитриев, AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчик
Сергей Дмитриев

Одним из наиболее важных навыков, которым должны обладать Ваши команды, является проведение ретроспективы (оценки) проектов. Мы обязаны уделять время на то, чтобы заглянуть в прошлое и немного поразмыслить над полученными знаниями и пройденными уроками, чтобы найти способ улучшить нашу совместную работу в будущем.

Подавляющее большинство организаций не применяют ретроспективу. А если и применяют, то обычно, это случается лишь в самом конце процесса, и, в лучшем случае, все уходит в архивы офиса управления проектами (PMO), где, в большинстве случаев, и остается навеки. В данном выступлении вы познакомитесь с ключевыми моментами проведения ретроспектив, поймете как правильно и эффективно применять этот сильнейший инструмент, повышения эффективности ваших команд.

Вы узнаете:

  • что такое «ретроспектива»
  • какова основная цель ретроспективы
  • существующие «правила игры»
  • как сделать ретроспективы интересным и как часто и как долго проводить ретроспективы
  • конкретные упражнения, которые вы можете попробовать на своей следующей ретроспективе

Видео


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).


Презентация

Ретроспективы. Настраиваем наш процесс разработки (Сергей Дмитриев, AgileDays-2011).pdf


Примечания и отзывы

Сергей Дмитриев

EstherDerbyAgileRetrospectives.jpg

Интересный доклад. Единственная претензия к нему – плохая презентация, на слайдах были только фотки (не имеющие отношения к делу), слайдов мало и информации они не содержали, лучше слайдов бы не было вообще.

Доклад был посвящен тому, как надо проводить ретроспективы и зачем. Сергей считает, что ретроспективы нужны обязательно, причем как ретроспективы по командам в конце итерации, так и всего проекта (когда собираются все люди, имеющие какое-либо отношение к проекту) после его завершения.

Ретроспективы необходимо делать интересными (см. книгу 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».

Репликация: База Знаний «Заказных Информ Систем» → «Ретроспективы. Настраиваем наш процесс разработки (Сергей Дмитриев, AgileDays-2011)»