7 Способы проведения ретроспектив для анализа и улучшения процессаMagneta AI
Ретроспектива играет большую роль в развитии команд, работающих в Agile проектах. В большинстве случаев, успех проекта зависит от того, насколько команда умеет совместно выявлять проблемы и улучшать свою работу от итерации к итерации.
Мы рассмотрим различные практики проведения ретроспектив, обсудим часто возникающие вопросы в организации работы команды и коллективного принятия решения.
Зачем нужны ретроспективы и как их проводить? Основные отличия ретроспектив в различных фреймворках, например, Scrum или Kanban, рекомендации по продолжительности, наполнению, советы по каждому этапу ретроспективы.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
6 ScrumMaster — работа с возражениями и конфликтами в командеMagneta AI
Секция предназначена для начинающих и опытных скрам-мастеров, тимлидов и менеджеров проектов. В ее основе лежат ответы на вопросы, которые рано или поздно возникают у любого участника Agile команды: как создать хорошую команду и как внедрять новые практики, как «продать» Agile заказчику и как бороться с внутренними конфликтами, как эффективно проводить митинги и как обеспечить в команде ответственность за результат.
7 Способы проведения ретроспектив для анализа и улучшения процессаMagneta AI
Ретроспектива играет большую роль в развитии команд, работающих в Agile проектах. В большинстве случаев, успех проекта зависит от того, насколько команда умеет совместно выявлять проблемы и улучшать свою работу от итерации к итерации.
Мы рассмотрим различные практики проведения ретроспектив, обсудим часто возникающие вопросы в организации работы команды и коллективного принятия решения.
Зачем нужны ретроспективы и как их проводить? Основные отличия ретроспектив в различных фреймворках, например, Scrum или Kanban, рекомендации по продолжительности, наполнению, советы по каждому этапу ретроспективы.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
6 ScrumMaster — работа с возражениями и конфликтами в командеMagneta AI
Секция предназначена для начинающих и опытных скрам-мастеров, тимлидов и менеджеров проектов. В ее основе лежат ответы на вопросы, которые рано или поздно возникают у любого участника Agile команды: как создать хорошую команду и как внедрять новые практики, как «продать» Agile заказчику и как бороться с внутренними конфликтами, как эффективно проводить митинги и как обеспечить в команде ответственность за результат.
Денис Тучин - Проверка гипотез Kanban Method с помощью имитационной моделиDenis Tuchin
Видео: https://www.youtube.com/watch?v=79Joxx6gTeU
Используя имитационную модель на докладе мы проверим, что лучше работает:
- Что делать если команда не сбалансирована
- Может ли сбалансированная команда работать без ограничения WIP
- Как подобрать оптимальные ограничения WIP
- Помогает ли приоритезация бизнесу
Денис Тучин - Лучшие практики внедрения изменений на уровне командDenis Tuchin
1. Правильная постановка цели (Больше чем SMART)
2. Взвешиваем все за и против
3. Ищем единомышленников
4. Создаём атмосферу безотлагательности действий
5. ADKAR
6. Инструменты, процессы, борьба с бюрократией
7. Маленькие победы (планируем, осуществляем и распространяем)
8. Другие поощрения изменений
9. Кадровые перестановки
10. Институционализация
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Denis Tuchin
Видео выступления: https://www.youtube.com/watch?v=vOMSRSTl1Xo
Хотим мы этого или нет, но часто приходится работать с удалёнными командами, а иногда и с полностью распределёнными, когда все участники сидят в разных местах. На докладе разберём некоторые паттерны организации взаимодействия распределённых Agile команд, какие из них работают лучше, какие хуже и почему, а также посмотрим, что можно изменить, чтобы получился всё же Agile. Рассмотрим такие паттерны как:
- передача изолированных User Story удалённой команде
- Индивидуальные User stories
- Scrum of Remote Scrums
- Функциональные распределённые команды
- Scrum in spite of distributed team
В докладе я расскажу, какие ошибки допускали мы на своих проектах и какие допускали наши коллеги из других компаний, внедряя методологию. Конечно, поделюсь тем, как мы их исправили, и какие выводы мы сделали, чтобы не допускать их в будущих проектах.
Обязательные практики Agile-проекта и правило ПППPavel Gabriel
Презентация для конференции "Деловой интернет 2009". В презентации рассматриваются обязательные практики для agile-проекта, причины их использования и правило, позволяющее добиваться большей эффективности.
Итак, вы работаете по Scrum или хотя бы просто разделяете Agile философию. Скорее всего у вас как минимум есть ежедневные встречи, ведь сама по себе практика ежедневных встреч очень популярна вне зависимости от вашего процесса. А вы уверены, что со стороны это не похоже на сползающихся зомби? Насколько эта встреча ценна для вашей команды? Я расскажу чуть подробнее зачем проводится эта встреча и как максимально полезно использовать это время всей команды. Несколько примеров типичных ошибок и несколько практических советов, как все исправить.
Денис Тучин - Как не завалить Ретро: практические советы, как готовится и как...Denis Tuchin
Подготовка к Ретроспективе
1.1. Карта фасилитации
1.2. Нейро-карта фасилитации
1.3. Какие практики выбрать именно для этого ретро?
Что-то пошло не так, что делать?
2.1. Цикл вмешательства (Intervention Cycle)
2.2. Всегда ли применим цикл вмешательства
2.3. Кейсы!
Асхат Уразбаев. Agile Coach и Scrum Master как руководители нового типаScrumTrek
Мир меняется. Высокая скорость изменений трансформирует бизнес-модели и сами организации. В новом мире решения надо принимать быстро и уметь синхронизировать работу большого количества людей. Важность по-настоящему командной работы растет. Появляются роли, главной задачей которых является построение эффективной команды.
Речь идет о роли Scrum Master/Agile Coach. В докладе мы ответим на вопросы:
— Какое место они занимают в организации?
— Какими они должны быть?
— Что входит в их обязанности?
— Что они должны знать и уметь?
Гибкие подходы перестали работать! По крайне мере, если судить по многочисленным публикациям, которые все чаще и чаще стали появляться. У кого-то не работает Scrum, у кого-то не прижился Канбан и, вообще, Agile не работает. В своем докладе я также приведу несколько примеров критики Agile в виде статей и докладов, разберу типичные заблуждения и ошибки, которыми оперируют критики.
Если использовать модель жизненного цикла принятия инноваций, можно спрогнозировать, что число такого негатива будет расти, потому что в России Agile начинают использовать не только инноваторы и ранние последователи, но и раннее большинство, которому трудно грамотно внедрить Agile и стать действительно гибкими.
Опытные управленцы, которые владеют гибкими подходами, обычно посмеиваются над этим негативом и пересказывают друг другу как анекдоты, а это как раз и есть та пропасть, которую Джеффри Мур описал в своей книге. Дополнительно мы обсудим, где сейчас находится Agile с точки зрения цикла зрелости технологий, так как эта модель тоже объясняет неудачный опыт использования Agile.
Agile-сообществу важно дальше вовлекать и помогать развиваться тем, кто пытается сделать свою команды, отдел или целую компанию гибкой.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
Денис Тучин - Проверка гипотез Kanban Method с помощью имитационной моделиDenis Tuchin
Видео: https://www.youtube.com/watch?v=79Joxx6gTeU
Используя имитационную модель на докладе мы проверим, что лучше работает:
- Что делать если команда не сбалансирована
- Может ли сбалансированная команда работать без ограничения WIP
- Как подобрать оптимальные ограничения WIP
- Помогает ли приоритезация бизнесу
Денис Тучин - Лучшие практики внедрения изменений на уровне командDenis Tuchin
1. Правильная постановка цели (Больше чем SMART)
2. Взвешиваем все за и против
3. Ищем единомышленников
4. Создаём атмосферу безотлагательности действий
5. ADKAR
6. Инструменты, процессы, борьба с бюрократией
7. Маленькие победы (планируем, осуществляем и распространяем)
8. Другие поощрения изменений
9. Кадровые перестановки
10. Институционализация
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
Денис Тучин - Удачные и неудачные паттерны распределённого Agile (Agile Days ...Denis Tuchin
Видео выступления: https://www.youtube.com/watch?v=vOMSRSTl1Xo
Хотим мы этого или нет, но часто приходится работать с удалёнными командами, а иногда и с полностью распределёнными, когда все участники сидят в разных местах. На докладе разберём некоторые паттерны организации взаимодействия распределённых Agile команд, какие из них работают лучше, какие хуже и почему, а также посмотрим, что можно изменить, чтобы получился всё же Agile. Рассмотрим такие паттерны как:
- передача изолированных User Story удалённой команде
- Индивидуальные User stories
- Scrum of Remote Scrums
- Функциональные распределённые команды
- Scrum in spite of distributed team
В докладе я расскажу, какие ошибки допускали мы на своих проектах и какие допускали наши коллеги из других компаний, внедряя методологию. Конечно, поделюсь тем, как мы их исправили, и какие выводы мы сделали, чтобы не допускать их в будущих проектах.
Обязательные практики Agile-проекта и правило ПППPavel Gabriel
Презентация для конференции "Деловой интернет 2009". В презентации рассматриваются обязательные практики для agile-проекта, причины их использования и правило, позволяющее добиваться большей эффективности.
Итак, вы работаете по Scrum или хотя бы просто разделяете Agile философию. Скорее всего у вас как минимум есть ежедневные встречи, ведь сама по себе практика ежедневных встреч очень популярна вне зависимости от вашего процесса. А вы уверены, что со стороны это не похоже на сползающихся зомби? Насколько эта встреча ценна для вашей команды? Я расскажу чуть подробнее зачем проводится эта встреча и как максимально полезно использовать это время всей команды. Несколько примеров типичных ошибок и несколько практических советов, как все исправить.
Денис Тучин - Как не завалить Ретро: практические советы, как готовится и как...Denis Tuchin
Подготовка к Ретроспективе
1.1. Карта фасилитации
1.2. Нейро-карта фасилитации
1.3. Какие практики выбрать именно для этого ретро?
Что-то пошло не так, что делать?
2.1. Цикл вмешательства (Intervention Cycle)
2.2. Всегда ли применим цикл вмешательства
2.3. Кейсы!
Асхат Уразбаев. Agile Coach и Scrum Master как руководители нового типаScrumTrek
Мир меняется. Высокая скорость изменений трансформирует бизнес-модели и сами организации. В новом мире решения надо принимать быстро и уметь синхронизировать работу большого количества людей. Важность по-настоящему командной работы растет. Появляются роли, главной задачей которых является построение эффективной команды.
Речь идет о роли Scrum Master/Agile Coach. В докладе мы ответим на вопросы:
— Какое место они занимают в организации?
— Какими они должны быть?
— Что входит в их обязанности?
— Что они должны знать и уметь?
Гибкие подходы перестали работать! По крайне мере, если судить по многочисленным публикациям, которые все чаще и чаще стали появляться. У кого-то не работает Scrum, у кого-то не прижился Канбан и, вообще, Agile не работает. В своем докладе я также приведу несколько примеров критики Agile в виде статей и докладов, разберу типичные заблуждения и ошибки, которыми оперируют критики.
Если использовать модель жизненного цикла принятия инноваций, можно спрогнозировать, что число такого негатива будет расти, потому что в России Agile начинают использовать не только инноваторы и ранние последователи, но и раннее большинство, которому трудно грамотно внедрить Agile и стать действительно гибкими.
Опытные управленцы, которые владеют гибкими подходами, обычно посмеиваются над этим негативом и пересказывают друг другу как анекдоты, а это как раз и есть та пропасть, которую Джеффри Мур описал в своей книге. Дополнительно мы обсудим, где сейчас находится Agile с точки зрения цикла зрелости технологий, так как эта модель тоже объясняет неудачный опыт использования Agile.
Agile-сообществу важно дальше вовлекать и помогать развиваться тем, кто пытается сделать свою команды, отдел или целую компанию гибкой.
Как UX-специалист делился своими инструментами с agile-командамиNikita Efimov
Прошло 2 года. Семен повзрослел и возмужал (в профессиональном и жизненном плане). За это время он успел поработать с несколькими agile-командами и насмотреться разного скрама и срама, набить очередных шишек при внедрении процесса проектирования в гибкие процессы разработки. Но во всех случаях он видел, что некоторые инструменты проектировщика могут пригодиться и другим участникам процесса, командам, которые не имеют проектировщиков интерфейса у себя в штате. Ведь эти инструменты просты в понимании и не требуют много времени на проработку.
И Семен решил попробовать Сначала на своей команде, а потом и на кошках, т.е. на знакомых командах.
Каких тем коснулся Семён, куда и какие инструменты UX-специалиста он попытался внедрить:
- как ещё (кроме привычных инструментов) можно собирать и фиксировать требования касаемо планируемых фич;
- как можно проапгрейдить user story в сторону большей эмпатии пользователям и какие инструменты в этом могут помочь;
- как можно с большей эффективностью разбивать крупные user story на более мелкие (опять же, с большей эмпатией);
- как фиксировать общий опыт взаимодействия пользователя, чтобы в следующей итерации не наломать дров при реализации новых фич. Ведь всегда сложно держать в голове всю картину взаимодействия человека с продуктом. А когда ты добавляешь все новые и новые фичи, часто вместо помощи вставляются палки в колёса;
как можно использовать любимый многими impact map для проработки целей пользователя;
- как можно проверить необходимость фич (а точнее, ожидаемую удовлетворенность от наличия/отсутствия) перед тем, как их поместить в бэклог.
JS Lab2017_Алексей Зеленюк_Сбалансированное окружение для вашей продуктивностиGeeksLab Odessa
JS Lab2017, 25 марта, Одесса
Алексей Зеленюк (Application Architect at Eleks Software)
Сбалансированное окружение для вашей продуктивности
Для построения больших веб-приложений необходим хороший фундамент: процесс сборки, тестирования и интеграции, анализа качества кода и отладки. Новые технологии и безнес-требования создают новые требования к окружению, усложняя его. Как построить надежное окружение, сохранив при этом его гибкость и простоту?
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
DUMP-2015: «Как размножаются программисты» Николай Ясинский, Сигнал, Казань it-people
Выступление на DUMP-2015.
Видео доклада: https://youtu.be/j1tJ9m3ypIM?list=PLRdS-n5seLRrR2gBuM7Kt1yIizNGIrnM9
Организатор конференции: IT-People.ru
Сайт конференции: www.dump-conf.ru
Как подружить команду админов с N командами разработки / Денис Яковлев (2ГИС)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 12:00
Тезисы:
http://rootconf.ru/2017/abstracts/2750.html
Web-отдел 2ГИС - это 5 команд разработки и более 20 проектов разного калибра. Это означает множество релизов каждый день и постоянные изменения.
Что мы имели раньше? Команда - bottleneck из нервных админов, работающих часто сверхурочно.
Что сейчас - команда инфраструктурных инженеров, предоставляющая сервисы для команд разработки.
В своем докладе я расскажу, чем первое отличается от второго, как мы к этому пришли, и почему теперь нервов стало меньше.
QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного ...QAFest
В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик.
Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества.
В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика
•Как безболезненно добавить практики XP и Kanban в Scrum процесс
•Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход
Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования
•Быстрое создание и поддержка тестовой документации, миф или реальность?
•Быстрое внедрение автоматизации
•Тестирование нефункциональных требований
Ключевые навыки успешной Agile-команды / Дмитрий Лобасев (lobasev.ru)Ontico
Динамика изменений со стороны бизнеса (наших заказчиков) сейчас настолько велика, что впереди оказываются компании, процесс разработки в которых непрерывно эволюционирует.
Эволюционный процесс позволяет научиться делать более быстрые поставки, принимать более качественные решения, а главное, поставлять с первого раза именно то, что нужно бизнесу.
Необходимый минимум для построения современных процессов разработки - это три ключевых, обязательных для освоения навыка, которым просто обязан научиться каждый участник проектной команды:
1. как можно раньше узнавать то, чего мы еще не знаем;
2. вовремя видеть, анализировать и решать возникающие проблем;
3. помогать бизнесу добиваться лучших из возможных результатов.
Во время доклада я расскажу подробно, какие инструменты вы можете использовать, чтобы выработать в своей команде эти три навыка и тем самым научиться постоянно улучшаться.
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.Anton Stoliar
1. Цель презентации:
• Побудить аудиторию пользоваться описанными техниками, которые могут помочь уменьшить количество «фейлов» со стороны QA команды в Agile-based проектах.
• Сфокусировать внимание на «фишках» которые особенно пропагандируются в Agile, которые помогают выпускать более качественный продукт
2. Какова практическая ценность презентации для аудитории:
• Поделиться конкретным опытом использования всяческих Agile-техник : Sprint Planning на основе QA оценок, Создание командного Vision-a на основе Product Canvas, First Release Baseline
• Поделиться некоторыми hint-ами когда ты вроде бы test team lead, но по факту менеджишь еще и команду разработки.
3. Для кого предназначена:
• QA которые уже работали по Agile (Scrum в частности)
• Начинающие ПМs и QA Team Leads
• Ребята которым скоро придется лидать Agile-проекты
4. Короткий план презентации по шагам:
• Чего могут жать от работы QA команды к зависимости от специфики проекта\компании
• Чего ожидают от QA в Agile
• Какие техники могут помочь выпустить более правильный\успешный\ качественный продукт
o Как формировать у команды общий Vision и как это помогает снижать дефекты в продукте
o Как планировать спринт отталкиваясь от QA-команды чтобы снизить овертаймы
o Как First Release Baseline помогает спланировать регрессию, когда совсем не осталось на нее времени
В рамках доклада будут рассмотрены основы Теории ограничений, применимость Теории ограничений при разработке ПО, а также будут рассмотрены практические примеры оптимизации процесса разработки.
You probably know what is iteration Zero.
Everybody uses this term but a few can define it clearly. Some use it to designate a special time for building infractructure, others as an iteration for assembling a team and sharing a product vision or elaborating initial requirements. Still, you can hardly get a clear explanation how to do your iteration Zero.
We in ScrumTrek have been helping organizations to adopt Agile for more that 5 years. Our understanding of iteration Zero has evolved over time and now we understand it as a time for a team, bussiness and other stakeholders to investigate collaboratively a product that they are going to build.
Join our session to learn about our experience and practices for iteration Zero. You will see how we do product/project analysis and create product vision and backlog. We will be talking about practices for helping a team to start their first iterations and discuss how to involve stakeholders into collaborative work.
And, what is more important, how to box it into just one iteration.
What kind of team we can call a good team? Good team (incl P.O.) delivers right features to their customers. If features are wrong, or they are delivered too early you can failure your product or project.
PDA Newton has been released to the market too early and failed. Market was not ready for it. There are some other typical mistakes. For example, sometimes we are not able to understand our customer or hit wrong segment of the market.
This workshop will show how to use Innovation Games ® play with customers to understand their value, and use this information to effectively prioritize and release the feature they want and when they want.
2. Зачем
мы
проводим
ретроспективы?
• Проект
еще
не
закончен
–
мы
можем
улучшить
процесс
работы
нашей
команды
• Scrum
–
эмпирический
framework,
сфокусированный
на
постоянном
выявлении
проблем
и
трудностей,
с
последующим
их
решением
3. Главное
Правило
Ретроспективы
• Вне
зависимости
от
того,
что
мы
выясним
на
ретроспективе,
мы
твердо
верим,
что
• каждый
делал
все,
что
было
в
его
силах
для
успеха,
• принимая
во
внимание
те
знания,
возможности,
навыки
и
ресурсы
которые
у
него
на
тот
момент
были.
4. Общий
план
проведения
• Создать
рабочую
атмосферу
– Каждый
говорит
что-‐то
хорошее
или
благодарит
кого-‐
нибудь
из
команды
• Собрать
данные
– «+»
и
«–»,
данные
метрик
• Придумать
идеи
• Сформировать
план
– Используя
«5
Почему?»
– SMART
• Закрыть
ретроспективу
– Обсудить
эффективность
ретроспективы
– Вывесить
план
на
доску
задач
5. Инструмент
«5
Почему?»
Выявляем
корневую
проблему
Системно
ее
решаем
• Сайт
не
работает
1. Поднять
сайты
– Процессоры
загружены
на
2. Удалить
плохой
код
100%
• Почему
такая
загрузка?
3. Объяснить
Сергею
– Бесконечный
цикл
в
новом
почему
код
не
коде
работает
• Почему
такой
код
написали?
4. Обучить
Сергея
TDD
– Сергей
сделал
ошибку
5. Включить
в
обучение
• Почему
эту
ошибку
зачекинили?
каждого
разработчика
– Он
не
написал
юнит-‐тесты
TDD
• Почему
он
не
написал
юнит-‐
тесты?
– Он
новый
разработчик
и
не
использует
TDD
8. 2.
Классическая
ретроспектива
• Что
было
хорошо?
• Что
было
плохо?
• Какие
есть
идеи
по
улучшению?
• План
улучшений
и
решения
проблем
9. Какие
бывают
проблемы
при
проведении
ретроспектив?
• Все
молчат,
никто
ничего
не
говорит
– Давит
присутствие
руководства
– Ретроспектива
«сверху»
• Невыполнимый
план
улучшений
– Абстрактные
пункты
плана
– Слишком
много
пунктов
плана
• Нет
мотивации
для
улучшений
– Решения
не
назначаются
– Решения
не
выполняются
10. 3.
SpeedBoat
• Мы
–
движущаяся
лодка
• Ветер
–
наши
сильные
стороны
• Якоря
–
наши
проблемы
– Чем
глубже
якорь,
тем
сильнее
он
цепляет
нас
за
рифы