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

Текущая версия на 19:05, 18 октября 2011

Аннотация

Докладчик

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

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

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

Вы узнаете:

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

Видео

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

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

Презентация

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

• страничка доклада на сайте конференции

⚓

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

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

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

Ретроспективы необходимо делать интересными (см. книгу Agile Retrospectives) и полезными. После каждой ретроспективы должен быть результат, т. е. выполнены конкретные действия (пусть даже всего одно действие) направленные на улучшение процесса. Если в результате составляются огромные списки того, что необходимо сделать и что-то делать из этого списка никто не собирается, смысла в такой ретроспективе нет.

На ретроспективе команда должна быть полностью открыта и готова обсуждать любые проблемы. Для этого предлагается не приглашать на ретро руководителя (в случае скрама – product owner), возможны также варианты, когда руководитель присутствует только на некоторых ретроспективах. Крайне желательна неформальная и доброжелательная атмосфера.

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

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

AgileDays-2011: Отчет Гребнева Н.Ю./Ретроспективы. Настраиваем наш процесс разработки

⚓

• Пришел только на конец доклада (слушал про Code Review).
• Показалось интересным (рассказывали про то, как разнообразить ретро).
• Надо бы посмотреть видео.

AgileDays -2011:Отчет Заборова М.А./Сергей Дмитриев. Ретроспективы. Настраиваем наш процесс разработки

⚓

Хорошая, с картинками, вдохновляющая речь, заставила задуматься на тему «а как у нас?», и в результате этих размышлений упустил основную нить доклада. Что-то типа «почитать книжку Agile Retrospectives»?

AgileDays-2011:Отчет Цыганкова Д.А./Ретроспективы. Настраиваем наш процесс разработки

⚓

Рассказывал про ретро на примере своей команды. Очень жаль, что у докладчика было только полчаса. Некоторые идеи доклада:

• 1 неделя работы = +1 час на ретро;
• рекомендовал ретро в виде игр;
• в начале ретро просто собираются факты, не обсуждая их;
• факты оцениваются (+\-), оценки могут не совпадать у разных людей;
• определяем что конкретно сделаем в след итерацию + кто и как это будет мерить;
• ретро полезно проводить не только для команды, но и для заказчика;
• могут быть полезны модераторы для "внешних" ретро.

Очень понравился прием со спящим животным :)

Рекомендую посмотреть.

AgileDays-2011: Отчет Беликова Сергея/Ретроспективы. Настраиваем наш процесс разработки

⚓

Очень хороший доклад и в плане содержания, и в плане подачи материала. Очень понравился! Смотреть всем!

Его сайт http://www.agilecoach.ru

Основные мысли:

• Ретроспектива — «коллективное рассказывание историй»
• Доверяй своим подчиненным
• Менеджеры боятся доверять, но страх — это хорошо, это значит, что есть экперимент, проба что-то улучшить.
• Фокус ретроспективы должен быть обращен на то, чтобы что-то произошло — поменялось
• Ретро ~ 1 час на неделю работы

Структура:

• открытие 5 %
• сбор данных 30-50 %
  • у всех есть чувства
  • по списку красными и зелеными точками отмечают «за» и «против»
• приникновение в суть 20-20 %
  • анализ данных
• решение о дальнейших действиях 10 %
  • что реально можем сделать в ближайший спринт
• закрытие 10 %

• PO — гнать с ретро. Либо пускать хотя бы через раз.
• Если команда в отсутвии PO может «вывесить грязное белье», то это уже команда. Иначе — не команда.
• И здесь есть игры для ретроспектив — читать книгу Esther Derby, Diana Larsen «Agile retrospectives»
• Каждый обязательно должен что-то сказать
• Основная директива: ретроспектива — это не место, где мы ищем виновных. Мы ищем, что сделать, чтобы стало лучше.
• Рабочий уговор — внутренние правила поведения (например, никто никого не перебивает, никто за другого не говорит и т. п.)
• На ретро должен присутствовать модератор. Лучше не из команды.

Анекдот по теме ретро: Мужик пилит дерево, а оно пилится с трудом. К нему подходит другой и говорит: «Ты бы пилу поточил — сразу бы дело быстрее пошло!». «Да, что ты, — отвечает другой — некогда, пилить надо!» Зачастую мы похожи на первого мужика.

AgileDays-2011:Отчет Никитина В.В./Ретроспективы. Настраиваем наш процесс разработки

⚓

Я был недолго. Изложение не слишком системно, он не успел.

• Два вида ретроспектив: внутренние и внешние, большие. Внешние привязаны к релизам, но можно и без привязки, и даже через одну.
• На ретрах часто пропускают фазу анализа, бросаются сразу лечить.
• Выбирают нереалистичные большие шаги.
• Модераторы — должны быть и они — вне команды. Но только на ретрах, где есть внешние люди.

Максим Цепков - AgileDays-2011/Ретроспективы. Настраиваем наш процесс разработки