Материал из AgileWiki

Содержание 1 Описание 2 Статьи 2.1 Алексей Кривицкий. Ретроспектива 2.1.1 Ретроспективы. Формальность или польза? 2.1.2 Что не так с нашими ретроспективами? 2.1.3 Ретроспективы. Рекоммендуемая структура 2.2 Денис Миллер. Эволюция культуры команды - ретроспектива 2.3 Dmitry Zdanovich. Ретроспектива 2.4 Проведение ретроспективы. Асхат Уразбаев 2.5 Ретроспектива. Паттерн из Жизни 3 Ссылки

Описание

TODO: найти презенташки с АджайлРу

Статьи

Алексей Кривицкий. Ретроспектива

Ретроспективы. Формальность или польза?

Ретроспективы – как известно, являются обязательной практикой многих гибких методологий. В частности таких как XP, семейства Crystal, SCRUM.

Я буду рассматривать их с точки зрения SCRUM, так как имею с последним больше опыта. Но, как мне кажется, ретроспективы – эта практика, которая будет полезна любому проекту, даже тому, который не следуюет никакой из гибких методологий.

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

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

Почему же это так?

Давайте начнём с начала.

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

Одно но: завершённому проекту от этого уже было ни холодно ни жарко. Его команде тоже. Вскрытие же, как никак!

Прелесть итеративных-инкрементальных подходов (к которым относятся все Agile подходы) состоит как раз в том, что подобные ревью можно проводить по ходу проекта (и не раз), так как имеется объективная информация о статусе проекта и готовности продукта. Почему? Да просто потому, что каждая итерации такого проекта является сама мини-проектом, на выходе которой должен быть ощутимый результат. На основании которого можно сделать определённые выводы и таким образом повлиять на процесс разработки следующей итерации и, как следствие, на процесс всего проекта.

Звучит просто и логично.

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

• Книги по методологии, используемой командой, очень бегло описывают процедуру ретроспектив, и команда просто формально выполняет предписанные шаги («надо так надо, не будем спорить с гуру»).

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

Команда находится на раннем этапе становления, когда её члены боятся открыто выссказывать свои мысли и тем самым не решаются идти на потенциальный конфликт с коллегами («всё равно со мной никто не согласится, я лучше посижу молча, а потом сделаю, как хочу»).

• Команда не объединена единой целью и таким образом успех или неуспех предыдущей итерации субъективен и общий прогресс никого не интересует («я всё сделал хорошо, не вижу о чём тут ещё говорить»).

• Команда ещё не научилась конструктивному поиску решений и ретроспективы переростают в поиск частных решений для неважных проблем («раз у нас есть два часа, давайте поговорим про что-нибудь интересненькое»).

Несомненно есть и другие причины. Но перечисленные я лично видел и переживал. И с ними нужно бороться.

Кто и как должен с ними бороться?

Кто - конечно команда. Как – при помощи грамотного лидера-фасилитатора!

Алексей Кривицкий
http://www.scrum.com.ua/2008/02/retrospections-formality-or-usefulness.html

Что не так с нашими ретроспективами?

В первом посте на тему ретроспектив я попытался описать значение ретроспектив для проектов и проблемы, которые возникают в юных командах при их проведении.

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

И так. Как же проводить ретроспективы?

Базовые материалы по СКРАМ говорят, что после спринт ревью митинга (или проще говоря демонстрации результатов спринта) команда собирается на ретроспективный митинг, где обсуждаются следующие вопросы:

• Что в ходе спринта было хорошего?
• Что было не очень хорошо?
• Что можно улучшить в следующем спринте?

Это же касается ретроспективы по окончанию релиза или другой фазы проекта. Для простоты я рассматриваю ретроспективы, привязанные к окончанию спринта.

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

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

А что если ничего не будет сделано? В следующий раз команда cгенерирует очередной список, и так до тех пор, пока практика ретроспектив справедливо (для такого типа ретроспектив) не будет объявлена бесполезной.

Что же здесь не так?

Я думаю (и надеюсь это уже стало очевидно), что при таком подходе явно не хватает как минимум следующих вещей:

• Базы для разрешения конфликтов и избежания поиска виновных.
• Принятия ответственности и взаимного обещания членов команды об уделении идентифицированным проблемам внимания и времени в ходе следующего спринта.
• Как следствие чёткого плана действий (кто и что будет делать, что ему необходимо), который был бы учтён при планировании следующего спринта.

А что не так в ваших ретроспективах?

Обсуждения ретроспектив в группе дискуссий Agile Ukraine.

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

• Что если не всем членам команды комфортно на ретроспективе?
• Есть ли рекомендуемая структура ретроспектив, с которой стоит начать?
• Наши ретроспективы заканчиваются ничем, есть ли подходы получить план действий на выходе?
• Стоит ли привлекать представителей заказчиков на ретроспективы?
• Похоже нашему СкрамМастеру самому есть что сказать как участнику проекта. Кто в этом случае должен проводить ретроспективы?

Алексей Кривицкий
http://www.scrum.com.ua/2008/02/retrospectives-what-we-do-wrong.html

Ретроспективы. Рекоммендуемая структура

Проблемы, проблемы, проблемы

Прошлый пост на тему ретроспектив (или вернее того, чего не хватает чаще всего для их эффективного проведения), поднял активность дискуссий группы Agile Ukraine.

Выходит, ретроспективы, не завершающиеся чётким планом, или же ретроспективы с планом, в который никто не верит и не собирается что-то менять, встречаются не так уж редко.

Хорошо! (конечно, ничего хорошего в этом нет). Но хорошо уже то, что люди замечают, готовы признать и обсуждать проблемы, возникающие у них на проектах. Есть поговорка, утверждающая, что высказанная проблема – это наполовину решенная проблема. Хотелось бы в это верить.

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

Схема ретроспектив

И так. Для решения ряда проблем, которые были озвучены ранее, я предлагаю следующую схему проведения ретроспектив. Это не моё личное «ноу-хау», это наработки многих экспертов в области фасилитаций общения, генерации коллективного знания и прочих групповых методик (см. ссылки на ресурсы внизу поста):

1. Подготовка – 7 мин. 2. Сбор информации – 30 мин. 3. Выработка плана действий – 20 мин. 4. Завершение ретроспективы - 3 мин.

Звучит просто? Ничего нового? В этом и следующих постах я опишу в деталях рекомендации по проведению каждой из этих частей.

Длительность ретроспективы и её частей

В схеме время каждой части приведено для часовой ретроспективы. Соответственно для двухчасовой ретроспективы время каждой части удлинится приблизительно в два раза.

Рекомендуемая длительность ретроспектив – один час на каждую неделю работы команды в 5-9 человек. Таким образом для двухнедельных спринтов стоит уделить около двух часов.

Подготовка

В зависимости от зрелости вашей команды и аудитории во время подготовки следует уделить внимание как минимум следующим моментам:

1. Приветствия и опрос настроений. 2. Напоминание цели ретроспективы. 3. Настройка на конструктивизм. 4. Гарантия личной безопасности. 5. Представление структуры ретроспективы. 6. Выработка (либо напоминание) этики общения и правил принятия решений.

Приветствия и опрос настроений

Поприветствуйте всех.

Дайте возможность каждому сказать хотя бы одно слово. Как вариант спросите каждого по очереди о том, с каким настроением он (она) пришёл на ретроспективу или что он (она) думает, на счёт демонстрации. Достаточно коротких ответов: «всё ок», «нормально» или «так себе». Не вступайте в диалог и не подчёркивайте положительные или негативные ответы. Просто опросите всех по кругу. Это даёт возможность аудитории снять стресс начала дискуссий, ведь зачастую начать говорить тяжелее всего. Чем раньше к началу ретроспективы проведено это упражнение, тем оно эффективнее.

Плавно перейдите к цели.

Напоминание цели ретроспективы

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

Цель ретроспективы может звучать так:

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

Желательно, если цель будет доступна во время всей ретроспективы. Как вариант её можно написать на отдельном листе флипчарта и повесить в доступном месте.

Настройка на конструктивизм

Исходя из цели очевидно, что задачей ретроспективы ни в коем случае не является поиск виновных или прочие действия, явно не улучшающие процесс разработки. Но в командах, которые ещё не сработались стОит явно об этом напомнить. Работает следующая формулировка, предложенная Норманом Кёртом, которую он назвал «первичной директивой» или «prime directive» (см. список ссылок внизу):

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

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

Гарантия личной безопасности

Как фасилитатор объясните всем вашу роль – вы помощник команды, фасилитатор. Во время ретроспективы вы соберёте мнения и сделаете их доступными, с тем, чтобы команда смогла принять адекватные решения.

Не все себя могут чувствовать одинаково комфортно. Не стоит давить на людей, которые по тем или иным причинам не хотят высказываться. Это несомненно проблема, но не стоит её решать на ретроспективе.

Объясните всем, что если кто-то предпочитает молчать, то это его дело, но он должен понимать, что тем самым лишаем команду своего мнения. Пару раз за время ретроспективы между прочим спросите у «молчунов», есть ли им что добавить. Убедившись, что на них никто не давит, они ещё могут разговориться.

Если среди членов команды есть те, кто не готов открыто высказывать своё мнение, или же в команде есть личности, которые обычно перекрикивают своих коллег, «задавливия их интеллектом», попробуйте применять во время брейнстормов работы в небольших группах или парах с тем, чтобы в итоге мнения всех были выслушаны и учтены.

Представление структуры ретроспективы

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

Для достижения данной цели достаточно прочитать вслух с листа флипчарта шаги ретроспективы, предназначение каждого шага и время, которое вы предполагаете отвести на каждый шаг. Убедитесь, что все понимают, почему структура именно такова. Уделите пару минут разъяснениям, если есть вопросы. Важно, чтобы в итоге участники чувствовали что это «их ретроспектива» и что они управляют её ходом.

Выработка (либо напоминание) этики общения и правил принятия решений

Если вы проводите уже не первую ретроспективу, стоит уделить буквально минуту напоминаю правил, которые использует ваша команда на митингах. Это могут быть от банальных: «телефоны на бесшумный режим» и «никаких компьютеров» до более продвинутых правил общения и принятия решений «мы выслушиваем всех по очереди» и «когда все высказались, мы голосуем».

Если у вас нет формально выписанных правил, стоит посвятить 10-15 минут на их генерацию. Эти правила команда потом будет использовать на последующих ретроспективах и других групповых сессиях.

Как ведущий помните, что эти правила определяет команда, и она 100% владеет ими. Ваша же задача напоминать во время ретроспективы (когда страсти накаляются) о соблюдении этих правил. Либо же инициировать их пересмотр: «Мне кажется наши правила не работают, мы хотим их пересмотреть?»

Итог подготовки

Во время подготовки можно использовать и другие техники. Экспериментируйте. Но не вырождайте эту часть в пустое приветствие!

Чем лучше вы подготовите команду и настроите на работу, тем плодотворнее будет ретроспектива.

Дальше...

После того, как вы напомнили всем о цели ретроспективы, настроили команду на конструктивный поиск решений, гарантировали личную безопасность, оговорили структуру и правила поведения - самое время перейти к тому, что нужно для принятия тех самых решений – нужно собрать информацию.

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

Комментарии как всегда приветствуются. Присоединяйтесь к дискуссиям Agile Ukraine.

Алексей Кривицкий http://www.scrum.com.ua/2008/02/retrospections-proposed-structure.html

Денис Миллер. Эволюция культуры команды - ретроспектива

Как я отличаю аджайл команду от не-аджайл? По наличию одной лишь практики - "Ретроспектива". Мне не достаточно сказать - у нас есть она. Я должен увидеть как происходит это таинство. У меня в загашнике есть ряд критериев по которым определяю качество "ретроспективы". Может быть когда-нибудь напишу :)

Сегодня хотел чуток о другом. Я просто несказанно рад, что Дмитрий у себя на блоге описал эту штучку (ссылка). И этот пост воодушевил закончить находящийся в черновике пост про ретроспективу. Асхат подхватил эстафету про ретро. Рекомендую зайти - ссылка.

Продолжать чтение моего поста нужно после чтения поста Дмитрия.

Я привык использовать облегчённый вариант ретроспективы. Я за упрощение во всем её многообразии. Мои ретроспективы просты по структуре

1. ХОРОШО
2. УЛУЧШИТЬ
3. ИДЕИ
4. ПЛАН ДЕЙСТВИЯ

Народ интересуется, почему же есть пункты "Хорошо", "Улучшить" и "Идеи", но нет "Плохо" ) Весь сыр бор вокруг пункта 2. Он показывать отличие в психологии проведения ретроспективы. Готовы ли на свершения (которые оформляются Action-планом, который я забыл упомянуть), или просто "вздыхатели" :)

Для русского менталитета пункт 2 должен быть "ПЛОХО". Для европейского - "УЛУЧШИТЬ".

Разница грандиозна. Во-первых, описать "ПЛОХО" нужно 1 мозго-силу. Констатируем факт и мы в шоколаде. Для описания "УЛУЧШИТЬ" нужно 2 мозго-силы. Первая для описания "плохой" ситуации, а вторая мозго-сила для предложения пути как исправить. Вот и получается пункт "УЛУЧШИТЬ" это посложнее, чем "ПЛОХО.

Во-вторых, "ПЛОХО" характеризует натуру, которая больше любит жаловаться, а не решать проблемы. "УЛУЧШАЮТ" в эффективных коллективах, когда идентифицируют неэффективное поведение, ситуацию и ставят задачи по улучшению. Игра слов. Но все же обращу внимания: жалуются - решают, проблемы - задачи. Можете подумать на досуге к какому поведению приводят две эти стратегии, если ими руководствоваться по жизни.

В общем народ можно разбить на две большие группы по этому критерию. Первая - кто ищет оправдания (для них в ретро нужен пункт ПЛОХО) и другая группа, кто ищет возможности (для этих нужен пункт УЛУЧШИТЬ).

А если получается много "УЛУЧШИТЬ" и улучшения достигаются. Это развивает команду. Команда за счёт "УЛУЧШЕНИЙ" изменяется, изменяется её культура.

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

• любого митинга
• во время конфликта
• после обсуждений
• после любой презентации
• после тренинга, и даже после каждого дня тренинга
• после встречи с заказчиком
• когда вы сделали что-то значимое, как способ поделиться
• и много других

Ретроспектива решает конфликты

В предыдущем посте я говорил, что инструмент ретроспективы может быть заимствован и развит до немыслимых высот. Если вы хорошо владеете этим инструментом, ваша зрелость растёт гигантскими шагами.

Пару слов о конфликте. Конфликт - это когда точки зрения не совпадают и мы начинаем подключать эмоции, а по сути никуда не двигаемся. Если посмотрите мои посты про эмоции - то знайте - это вы подключили своё подсознательное. Теперь вы стали сильнее и мудрее, когда включили эмоции. Единственное нужно уметь управлять подсознательным (эмоциями). Это умение управлять эмоциональным интеллектом. Подсознательное через эмоции подсказывает - работаем неэффективно. Теперь понятно, что работаем неэффективно, то есть обсуждения зашли в тупик. И это можно оценить по уровню эмоций.

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

Упрощёная схема:

1. Конфликтная ситуация.
2. Остановится
3. Понять свои эмоции.
4. Найти причину (см. технику)
5. Провести ретроспективу на то КАК вы обсуждаете, а не ЧТО вы обсуждали.

Секретная техника действует! Люди меняются и культура разработки растёт! Приятной ретроспективы!

Dmitry Zdanovich. Ретроспектива

После Agile Practitioners Gathering я стал более широко воспринимать тему ретроспективы.

Ретроспектива – одна из наиболее игнорируемых практик. Почему же ее не используют? В основном потому, что видят трудности с ее внедрением, но не видят особых преимуществ.

Понятно, что использовать практику, не дающую никакой пользы, нет смысла. Но некоторые практики могут приносить долгосрочную пользу – что не всегда принимается во внимание.

Очевидные цели ретроспективы:

   * Собрать информацию, получить обратную связь
   * Что-то улучшить на основе полученной информации

Звучит красиво, но на практике это не так легко. Основными проблемами являются:

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

Чтобы немного сгладить впечатление, что ретроспектива это что-то из области теоретической фантастики, приведу некоторые не совсем явные преимущества:

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

В данной статье я в основном остановлюсь на проведении ретроспектив:

   * Преимущества с разных точек зрения
   * Как проводить
   * Различные инструменты и подходы
   * Ретроспектива на более высоком уровне

Преимущества с различных точек зрения

С точки зрения компании:

   * Получение информации и обратной связи
   * Обучение и улучшение
   * Создание открытой атмосферы (хотя не для всех компаний это преимущество)
   * Поощрение людей к действию и активности

С точки зрения менеджера проекта:

   * Получение информации и обратной связи
   * Подстройка процесса под проект и команду
   * Создание открытой атмосферы (опять-таки, не для всех это плюс)
   * Поощрение людей к действию и активности

И, наконец, преимущества с точки зрения команды:

   * Возможность быть услышанным
   * Подстройка процесса под реальные нужды, устранение лишних вещей

Как проводить

Для ретроспективы нужна хорошо продуманная организация. Я бы выделил 3 области:

   * Подготовка
   * Проведение
   * Реализация решений

Подготовка

На этом этапе одной из наиболее важных вещей является четкое и понятное объяснение всем, зачем это надо и как это поможет конкретным людям.

Установите четкое расписание для ретроспективы. Проводить ретроспективу не в комнате команды – хорошая идея, так как изменение обстановки позволит взглянуть снаружи на свою деятельность, немного ослабить привычные шаблоны мышления. Проведение

Для ретроспективы обязательно нужен ведущий (фасилитатор). Это может быть член команды, Scrum master, человек из другой команды или даже профессиональный ведущий. Периодически можно менять фасилитатора.

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

Если это не первая ретроспектива на проекте, то необходимо проанализировать результаты выполнения решений предыдущей ретроспективы – что сделано, что нет, почему. Возможно, некоторые элементы уже неактуальны.

Затем необходимо определить, что работает хорошо, а что является проблемой. После определения проблем предлагаются решения. На практике выявление проблем и решения для них предлагаются часто одновременно.

По итогам составляется action log. Стоит быть реалистичным, и не включать в action log так много элементов, что они заведомо не будет сделаны за следующий спринт.

В результате ретроспективы у нас есть:

   * Список работающих практик
   * Список проблем
   * Action log с конкретными действиями и ответственными людьми

Реализация решений

Ретроспектива без реальных изменений – это просто трата времени. Action log помогает сконцентрироваться именно на действиях, а не просто на разговорах.

Имеет смысл сделать action log наглядным и заметным. Например, распечатать и повесить в комнате команды. Когда какой-нибудь элемент завершен, можно сразу отмечать это на распечатке (например, перечеркнуть или поставить галочку). Когда команда видит, что что-то реально улучшается, энтузиазм в отношении ретроспективы повышается. Различные инструменты и подходы

Существует большое количество инструментов и форматов для проведения ретроспективы. Рассмотрим только некоторые:

   * What went well/What could be improved
   * Keep this/Ongoing problems/Try this/
   * Bug fix analysis/Knowledge sharing/Fix process/Roles/Practices
   * Starfish
   * Timeline

What went well/What could be improved

Это один из самых простых форматов. Вопрос “What went well?” помогает выявить хорошо работающие элементы. А второй вопрос направлен на выявление проблем. Ответами на второй вопрос являются проблемы, но формулировка подчеркивает конструктивный подход. Keep this/Ongoing problems/Try this

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

Этот набор вопросов основан на starfish диаграмме. Starfish diagram

Starfish diagram

• Start doing – что нужно начать делать (например, регулярный peer code review)
• Stop doing – что нужно прекратить делать (например, собирать бесполезные метрики)
• Continue doing – это хорошо работает, нужно сохранить
• More – этим вещам нужно уделять больше внимания (времени)
• Less – этим вещам нужно уделять меньше внимания (времени)

Bug fix analysis/Knowledge sharing/Fix process/Roles/Practices

Этот вариант предложил Владимир Лешкевич.

Во время bug fix analysis исследуются допущенные ошибки и как их не повторять. Knowledge sharing – knowledge sharing :-). В рамках фазы Fix process анализируется процесс – убираются или добавляются роли и практики. Timeline

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

Есть несколько подходов к построению timeline – в течение спринта или в начале ретроспективы. Первый позволяет не забыть события, но второй подход проще.

Борис Лебеда предложил вариант с black box’ом – в комнате команды ставится ящик, в который можно бросать заметки с событиями. На ретроспективе все эти заметки достаются, сортируются, выкидываются малозначительные – и получаем набор фактов. Ретроспектива на более высоком уровне

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

Можно проводить вертикальную ретроспективу (спасибо Юре Шиляеву за идею), включающую заинтересованных лиц с разных уровней (например, команда + division manager, или менеджеры проектов + несколько разработчиков + division manager + CEO). Это облегчает общение между уровнями. Но стоит учитывать психологический аспект – если команда на уровне «performing», она сможет достаточно эффективно проводить такие ретроспективы, члены менее «зрелой» команды могут просто замолчать проблемы. В случае многоуровневых ретроспектив правильная организация обсуждения еще более важна.

Ретроспективы уровня проекта – это сложная практика. А многоуровневые – еще сложнее. Но эффект достаточно заманчивый: всесторонняя обратная связь, прозрачный обмен информацией между уровнями, общее понимание задач и целей. Это долговременный инструмент

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

Источник: http://www.agile.by/2009/05/26/retrospektiva.html

Проведение ретроспективы. Асхат Уразбаев

Заодно хочу поделиться нашим опытом проведения ретроспектив.

Мы довольно долго искали более или менее "устойчивую" форму проведения ретроспектив. Наш формат ретроспектив исходит из наиболее серьезных проблем их проведения. Из-за этих проблем команды забрасывают проводение ретро на начальном этапе их внедрения:

• Проведение ретроспективы "из книжки" требует некоторых навыков фасилитации. А для многих само слово "фасилитация" звучит пугающе
• Ретроспективы превращаются в ППР (пришли, поговорили, разошлись :-). Никаких реальных действий по результатам не принимается. Это очень демотивирует команду.
• Команда берется улучшать сразу все. Многое не получается. Проблема тут в том, что нет обратной связи по результатам предпринятых улучшений. Это тоже сильно демотивирует
• Ретроспектива исходит только из анализа проблем. Как только мы порешали основные проблемы, ретроспектива вырождается.

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

Это как высокоточное и технологичное оружие. С таким оружием нужно уметь обращаться. Оно требует от бойца серьезных навыков и знаний. К примеру, винтовка М-16 обладает высокой кучностью и убойной силой. Однако, самое массовое штурмовое оружие в мире - Автомат Калашникова. Он прост, надежен, им может пользоваться даже ребенок. Идеальная практика должна быть именно такой. Минимум сложных правил. Максимум ценности.

Формат ретроспективы

Итак. Ведущий разделяет доску или флипчарт на 4 части:

• Плюсы. Что шло хорошо в прошлой итерации
• Минусы. Какие проблемы были в прошлой итерации
• Идеи. Какие идеи появились по ходу ретроспективы
• План. Какие улучшения мы запланируем на следующую итерацию

Задача команды - просто заполнить таблицу. Конечной целью является План. Все остальное - средства по его созданию.

Несколько общих правил проведения

• Все высказываются по очереди и вспоминают плюсы и минусы прошлой итерации
• Очень полезно держать перед глазами Burn Down Chart и доску задач и обращаться к ней в случае необходимости
• Удобнее всего отдельные айтемы записывать на клейких листочках. Тогда их можно при необходимости сгруппировать в один пункт, выкинуть или переписать.
• Нет смысла спорить, является ли важным или даже релевантным предложенный кем-то плюс, минус или идея. Если айтем кому-то не нравится, он просто не попадет в план
• План удобнее отложить на потом. Сначала заполнить плюсы, минусы и идеи
• В любой момент можно вернуться назад к плюсам, идеям или минусам и что-то добавить
• В план должны попадать конкретные вещи, которые вы точно планируете сделать в следующей итерации. Тут главное не планировать никаких "будем работать еще усерднее". Только конкретные действия

* Пункты плана бывают двух типов:

• • Задача. Она должна встать в план следующей итерации. Примеры:
    • Прикрутить рассылку уведомлений по почте к билд-серверу
    • Обсудить дизайн нового модуля
    • Выработать соглашения по кодированию (Coding Styles)
  • Правило. Процессный регламент. Примеры:
    • Парное программирование для задач, которые будут отмечены при планировании итерации
    • В план итерации попадают задачи, длительность которых не более двух дней
    • Добавить в Definition Of Done ревью кода
• После ретроспективы задача должна попасть на планирование и затем на доску задач в разделе To Do. Тогда ее кто-то подберет и сделает. За попадание листочка на планирование отвечает скрам-мастер
• За соблюдение правила отвечает команда. Скрам-мастер следит за тем, что команда исполняет принятые ею правила
• Ретроспектива начинается с того, что скрам-мастер вытаскивает листочки с планом прошлой ретроспективы. Команда решает, перевешивать листочки в минусы или плюсы.
• Идеи следуют из минусов, но ими не ограничиваются. Можно предложить идею, которая не связана ни с какими проблемами. Например "давайте в следующей итерации попробуем парное программирование!"
• Совершенно необязательно и даже, пожалуй, вредно пытаться внедрить все улучшения за один раз. Имеет смысл заниматься столько теми, которые вы осилите. 3-6 пунктов в разделе План вполне достаточно.

Жирным шрифтом я выделил пункты, которые считаю критичными для успеха ретроспективы.

И наконец, по поводу поднятого Денисом Миллером вопроса. Как лучше назвать минусы - "что можно улучшить" или "проблема"? С моей точки зрения, использование слова "проблема" только тогда является демотиватором, когда вы проблемами не занимаетесь и их не решаете. В конце концов мы все тут инженеры и наша задача - решение проблем, не так ли? Так что я не вижу смысла пользоваться эвфемизмами и иносказаниями. С другой стороны, решенная проблема - это хороший мотиватор. Мне кажется, использование формулы "что нужно улучшить" отбирает у команды успех, если проблема действительно решена!

Источник: http://blog.scrumtrek.ru/2009/05/blog-post_27.html

Ретроспектива. Паттерн из Жизни

• http://community.livejournal.com/ru_agile/15360.html

"Наши проблемы в разработке программного обеспечения, не столько имеют технологический характер, сколько социальный"
(с) Дао Прожект Менеджера

Когда я говорю слово Ретроспектива, я говорю о неком собрании, работающих в команде людей, в конце некой декады, итерации, периода работы. Для чего мы это делаем? Ретроспектива зачастую направлена на изучении проведенной работы, мы стараемся обсудить что и как происходило и что можно сделать для комфортной и эффективной работы.Ретроспектива проводиться в конце этапа проекта, не важно какой это проект Agile или Линейный(Waterfall). В отличии от типичных Аудит работ, проводимых в конце любой стадии проектов, Ретроспектива затрагивает не только вопросы разработки, но и стараеться решать проблемы команды.

Как проводиться Ретроспектива?

В первую очередь собираем всю команду "по поводу" :

"Мы здесь собрались что бы поговорить как мы провели последнюю итерацию и что можно сделать, что бы увеличить нашу эффективность и улучшить командную работу"

Что бы первые Ретроспективы не прошли негативно важно соблюдать первую Директиву Ретроспективы:

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

1. Настройтесь (Около 5 минут)

Предложите каждому из команды вспомнить одну вещь за которую стоит по благодарить своего колегу, например:

"Спасибо, что помог мне с задачей Х"

2. Мозго-Штурм (Брейн-Штормин) (5 минут)

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

3. Брейн Шторминг всех проблем. (10 минут)

Все выписанные проблемы обсуждаются более глубоко, каждый погружается в проблемы всей команды. Добиваемся понимания всех членом команды

4. Находим сходства (5 минут)

Распределяем проблемы по группам: Вопросы качества, Репутация, Командная работа - для понимания какого характера проблемы присутствуют в команде

5. Голосование (5 минут)

Попросите свою команду взглянуть на сформировавшиеся хорошие и плохие события и спросите:

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

6. Принимаем решения (20 минут)

Время принимать решения, задайте команде вопрос:"Что делать с задачами и как будем решать вопросы, выбранные на голосовании?" Запишите решения, проблем и договоритесь следовать этим решениям в течение следующей итерации

7. Закрываем Ретроспективу

• Очень важно что бы в конце ретроспективы все члены команды приняли решение о выполнении принятых обязательствах. Таким образом от итерации к итерации у Вас и у вашей команды будет возможность изучать и адаптироваться в условиях постоянных изменений ведя свою команду к успеху.
• Делаем ретроспективу на ретроспективу

Ссылки

• Обсуждения ретроспектив в группе дискуссий Agile Ukraine
• Статья Rachel Davies. “How To: Live and Learn with Retrospectives”
• Статья Boris Gloger’s blog and presentation. “Heartbeat Retrospectives”
• Книга Norman Kerth. ”Project Retrospectives: a handbook for team reviews”
• Книга Esther Derby, Diana Larsen. ”Agile Retrospectives: Making Good Teams Great”
• Книга Jean Tabaka. “Collaboration Explained”