- PVSM.RU - https://www.pvsm.ru -
Основной принцип agile-разработки – быстрые циклы получения обратной связи: вы демонстрируете что-нибудь пользователям так быстро, как это возможно, и таким образом видите, насколько изменения отвечают их потребностям. Обзор пройденного с целью исправить обнаруженные недостатки – метод, который мы применяем к нашим собственным командам, чтобы выяснить, что работает, а что нет, так, чтобы команда могла постоянно совершенствоваться.
Ретроспектива – это собрание в конце спринта, на котором у вашей команды есть возможность высказать, что прошло хорошо, а что – плохо, и принять какие либо-меры по улучшению ситуации. Это мероприятие может охватывать и больший временной отрезок – например, вы можете провести собрание по итогам всего проекта.
Ретроспектива состоит из следующих этапов:
Это – возможность для каждого члена вашей команды поучаствовать в улучшении процесса/повышении продуктивности.
Ретроспектива – собрание, которым нужно руководить. Роль ведущего заключается в том, чтобы каждому дать шанс высказать свою точку зрения на происходящее и дать положительную ответную реакцию.
Вместе с тем, ведущие отвечают за то, чтобы встреча оставалась структурированной, продуктивной, и настрой в ходе обсуждения не становился чересчур негативным. В идеале, если ведущим будет кто-либо не из вашей команды, она сможет участвовать в собрании в полном составе, но это несущественно.
Ведущему необходимо:
Ретроспектива подразумевает некоторые рабочие договоренности. При необходимости они могут быть зафиксированы, например, в ходе первой ретроспективы вашей команды.
Суть рабочих договоренностей состоит в том что:
Во время обсуждения вы сможете обсудить и свои успехи, и проблемы, которые вы можете устранить, а также то, что вы можете усовершенствовать.
По каждому их этих вопросов составьте список действий. Стремитесь выполнить эти действия не позднее следующего спринта или итерации. Для решения некоторых проблем нужно больше времени: в этом случае постарайтесь предпринять хотя бы какие-то действия по их устранению к следующей ретроспективе.
Действия должны:
Ретроспектива должна сопровождаться обсуждением того, что было сделано по результатам предыдущего собрания. Если поставленные задачи регулярно не выполняются, их накопится слишком много.
Вы можете использовать шаблон для проведения ретроспективы. Этот шаблон подходит команде из 8-10 человек, работающей в рамках 2-х недельных спринтов.
Подходящая длительность собрания для такого количества участников и объема работ – 90 минут. Каждое из действий продолжается в течение установленного времени, следить за этим – работа вашего ведущего.
Выделите около 10% времени на то, чтобы переключаться с одного действия на другое и держать под контролем лимит времени.
Подготовка: от 00:00 до 00:05 (5 минут)
Объясните объем задач, и если это необходимо, цель собрания. Если участники команды не знакомы друг с другом, и/или смущаются, кратко представьте их.
Работа, выполненная по результатам предыдущей ретроспективы: от 00:05 до 00:10 (5 минут)
Убедитесь, что она завершена. Если нет, спросите:
Достижения: от 00:10 до 00:20 (10 минут)
Дайте вашей команде около 10 минут, чтобы записать все то хорошее, что было сделано за предыдущие 2 недели на клейких листках.
Если, чтобы выражать мысли свободнее, членам команды нужна анонимность, сначала соберите листки у всех, а потом самостоятельно приклейте их на стену. В противном случае пусть сами члены команды прикрепляют к стене записи, и, по возможности, говорят несколько слов о каждом участнике проекта.
Не позволяйте дискуссии развиться на этом этапе – сейчас вы просто собираете информацию.
Обсуждение: от 00:20 до 00:30 (10 минут)
Сгруппируйте стикеры по общим темам. Если тем слишком много, чтобы обсудить все сразу, попросите команду выбрать наиболее приоритетные, например, путем голосования.
Обсудите каждую из выбранных тем по следующим направлениям:
Провалы: от 00:30 до 00:45 (15 минут)
Дайте команде 15 минут, чтобы написать все то, что пошло не так.
Обсуждение: от 00:45 до 01:05 (20 минут)
Снова сгруппируйте стикеры, расположите их по приоритетам, если необходимо, и обсудите основные направления:
Действия: от 01:05 до 01:20 (15 минут)
Потратьте немного времени, оценивая предложенные действия; назначьте задачи присутствующим и укажите реалистичные сроки для их завершения.
Всего: 80 минут + 10% на переключение между задачами.
Хорошо завершать собрание чуть раньше заданного срока, если все за это время успевают высказаться. Плохо, когда установленные сроки превышены – если команде нужно слишком много времени, чтобы обсудить все темы, попросите расставить вопросы в порядке приоритетности и обсудите наиболее важные из них, и/или в следующий раз выделите на ретроспективу больше времени.
Регулярные ретроспективы означают, что вы можете:
Методы гибкой разработки помогут вам работать лучше, а ретроспективы позволят лучше подстроить процесс и условия работы под ваши потребности.
Эти ресурсы могут быть вам полезны:
Мы обсудили данный материал с рядом стартапов 4-го и 5-го наборов Акселератора ФРИИ и сотрудниками Акселератора:
Слава Архаров, трекер Акселератора ФРИИ:
Во время ретроспективной сессии всегда будет балаган, и зафасилитировать его почти невозможно. Поэтому не надо думать, что если вы жестко выделите 5 минут на сессию ретроспективы и 5 минут на обратную связь – то команда за 5 минут расскажет про свои проблемы, а потом слушатели по очереди и не перебивая выскажут свое мнение. Так не будет.
Все будут болтать, препираться, вставлять свое мнение посреди фразы и т.п. ровно потому, что у людей рождаются идеи в момент, когда другой человек говорит – а не по расписанию. Но если запретить людям высказывать мысли сразу, то они перестанут думать в принципе, перестанут высказывать идеи и начнут со всем соглашаться – и сессия ретроспективы потеряет результативность и смысл.
Принцип борьбы с этим такой: надо всегда иметь короткий список финальных вопросов, на которые надо получить ответ по итогам обсуждения ретроспективы. Например «как нам улучшить продажи на следующей неделе». И ведущий должен дать высказаться многим, необязательно по графику и строго по теме – но должен постоянно возвращать всех к этому вопросу и в конце сессии общими усилиями сформулировать общий ответ на него.
К сессиям ретроспективы надо готовиться очень хорошо. Данные, материалы, выводы должны быть корректными – и их надо проверить с экспертами до начала ретроспективного обсуждения. Иначе работа по ретроспективе превратится в работу поиску ошибок в презентации, и это также снизит ее эффективность.
Нужно всегда фиксировать ретроспективные договоренности с прошлого спринта и рассматривать их и их результаты на следующих сессиях ретроспективы. Например: «На прошлой неделе договорились, что ты будешь делать по пять звонков клиенту в день, а ты делаешь два. Почему?» Иначе у людей не сложится серьезного отношения к этому инструменту – потому что многие из них склонны не делать то, о чем договорились, и работать по-старому. Поэтому надо им постоянно показывать, что цель ретроспективной сессии – это улучшение, а не просто обсуждение того, как все плохо.
1. Используете ли вы методику обсуждения проделанной работы в формате ретроспективы или это излишняя трата времени?
2. Если вы используете такой подход: сколько времени традиционно занимает обсуждение? Ведете ли вы жесткий тайминг таких встреч? Может быть, у вас есть собственные приемы и «фишки» при организации ретроспективы?
Потом количество программистов уменьшилось, и ретроспективы занимали всё меньше времени и сводились к короткому обсуждению некоторых проблем, с которыми команде пришлось столкнуться во время спринта. Такие обсуждения отнимали минут 15-20. В продуктовых же спринтах ретроспектива не утратила своей актуальности. Она помогает увеличивать эффективность и позволяет «бежать быстрее».
Резюмируя, если у вас в команде несколько программистов, разводить обсуждения на полдня не стоит, лучше просто зафиксировать проблемы в процессе работы и двигаться дальше. Если у вас большая команда, то ретроспективы обязательны. Главное на ретроспективе не уходить в обсуждения новых фич и не заниматься планированием, а вещи, о которых договорились по итогам ретроспективы, соблюдать и внедрять в последующие спринты.
Не могу сказать, что это моя собственная «фишка», но каждый день и/или каждые 2-4 часа я уточняю статус хода работ по задачам. Это занимает 1-2 минуты, но позволяет быстро реагировать на «вылетания» и корректировать ход выполнения задач. К счастью, мы работаем в неопределенности и не можем себе позволить слишком долго исследовать эту неопределенность. Нужно быстро двигаться, ошибаться, придумывать новые решения и идти дальше, иначе мы обречены на провал.
Наши публикации на основе материалов Gov.uk:
Автор: frii_fond
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/84102
Ссылки в тексте:
[1] Image: http://megamozg.ru/company/friifond/blog/10870/
[2] «The Agile Retrospective Wiki»: http://retrospectivewiki.org/index.php?title=Agile_Retrospective_Resource_Wiki
[3] планы: http://retrospectivewiki.org/index.php?title=Retrospective_Plans
[4] Книга: https://pragprog.com/book/dlret/agile-retrospectives
[5] электронная книга: https://leanpub.com/gettingvalueoutofagileretrospectives
[6] Работаем с User stories: Руководство Gov.uk: http://megamozg.ru/company/friifond/blog/8686/
[7] Gov.uk: базовые аспекты методологии agile: http://habrahabr.ru/company/friifond/blog/243723/
[8] Проектирование продукта с ориентацией на пользователя: http://habrahabr.ru/company/friifond/blog/243099/
[9] Источник: http://megamozg.ru/post/10870/
Нажмите здесь для печати.