В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
4. Содержание
• Теория
• Виды активностей на ретроспективах
– Открытие
– Сбор данных
– Проникновение в суть
– Принятие решение
– Закрытие
5. Что такое ретроспектива?
• Что такое ретроспектива?
• Вы проводите ретроспективы?
– Что обсуждаете?
– Помогает совершенствованию процессов?
– Как часто проводите?
– Сколько длится?
6. Определение
• Ретроспектива – процесс обсуждения
работы с целью их улучшения результатов в
будущем
Не хочешь пропустить со
мной по пиву?
Не могу, я делаю
список, в чем я
могу
усовершенствовать
себя в следующем
году
Не-
плохая
идея,
сделаю
тоже
самое
Ничего.
Совершенство достигнуто
Мда, вот
это
конструк-
тивность.
Какая едкая
зависть,
тебе бы
поработать
над этим
8. Типичные проблемы
Невозможность
улучшить уже
завершенный
проект
Низкая
заинтересованность
участников
Формальность
мероприятия
9. Agile-манифест разработки
программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе мы смогли осознать, что:
1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что
слева.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
10. Принципы Agile (1/2)
1. Наивысшим приоритетом для нас является удовлетворение
потребностей заказчика, благодаря регулярной и ранней поставке
ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях
разработки. Agile-процессы позволяют использовать изменения для
обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с
периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители
бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы.
Чтобы работа была сделана, создайте условия, обеспечьте
поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и
эффективным способом обмена информацией как с самой
командой, так и внутри команды.
11. Принципы Agile (2/2)
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь
возможность поддерживать постоянный ритм бесконечно.
Agile помогает наладить такой устойчивый процесс
разработки.
9. Постоянное внимание к техническому совершенству и
качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне
необходима.
11. Самые лучшие требования, архитектурные и технические
решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные
способы улучшения эффективности и соответственно
корректировать стиль своей работы.
14. Ретроспектива в Kanban
1. Визуализация потока
2. Ограничение кол-ва задач в работе
3. Управление потоком
4. Явные правила
5. Циклы обратной связи
6. Коллективные улучшения через
эксперименты
16. Ретроспектива in the long run
Рост эффективности
• Быстрый рост
• Решение проблем и
устранение боли
Плато эффективности
• Нет проблем
• Нет роста
Гиперэффективность
• Медленный ступенчатый
рост
• Использование
возможностей
• Эксперименты
17. Что обсуждать, если «проблем нет»
Скорость
команды и ее
изменение
Нереализованные
истории
пользователей
Дефекты и их
причины
Качество
процессов
Социальную
атмосферу
22. Главное правило ретроспективы
В независимости от того, что удастся
выяснить в результате ретроспективы,
каждый член команды сделал всё, чтобы
добиться успеха
24. Структура ретроспективы
Открытие – 5%
Сбор данных – 30%-50%
Проникновение в суть – 20%-30%
Принятие решение – 10%
Закрытие – 5%-10%
25. Длительность
• Обычно ретроспектива занимает от 30
минут до 4 часов и ее продолжительность
зависит от следующих факторов:
– Длина спринта
– Размер команды
– Наличие проблем
32. ESVP: как проводить?
• Цели
– Сфокусировать команду на ретроспективе
– Понять отношение каждого члена команды к
ретроспективе
Каждый член команды определяет к какой роли
на ретроспективе он себя относит:
1. Explorer – исследователь
2. Shopper – покупатель
3. Vacationers - отпускники
4. Prisoner – узники
(с) Алексей Пикулев
34. Check In: как проводить?
• Цели
– Сфокусировать команду на ретроспективе
– Услышать каждого члена команды
Каждый член команды отвечает одним или двумя словами
на вопрос скрам-мастера:
1. Опиши своё состояние одним словом?
2. Какие твои ожидания от ретро?
Можно использовать и другие вопросы, например, с
метафорами:
«Какой машиной ты себя ощущаешь на ретро?»
42. Worked well, kinda Worked, didn’t Work
http://www.funretrospectives.com/www-activity-worked-well-kinda-worked-
didnt-work/
43. KALM – Keep, Add, More, Less
http://www.funretrospectives.com/kalm-keep-add-more-less/
44. Open the box
http://www.funretrospectives.com/open-the-box/
45. Open the box
http://www.funretrospectives.com/open-the-box/
46. Future direction, Lessons learned,
Accomplishments and Problem areas
http://www.funretrospectives.com/flap-activity-future-direction-lessons-learned-accomplishments-
and-problem-areas/
59. Hot-air Balloon -> Bad Weather
http://www.funretrospectives.com/hot-air-balloon-bad-weather/
60. Speed Car – Abyss
http://www.funretrospectives.com/speed-car-abyss/
61. Brainstorming/Filtering
• Цель – сгенерировать большое кол-во идей
• Проводим мозговой штурм
– Free-for-all
– Round-robin
– С подготовкой
• Создаем фильтры для идей
• Пропускаем идея через фильтры
65. Пять почему
• Цель – быстро понять глубинные причины
• Делимся на небольшие группы 2-4 человека
• По каждой проблеме спрашиваем пять раз
«почему»
• По каждому уровню выбираем решение
66. Пять «почему»: пример
Симптом Действие
На сайте выдается сообщение об
ошибке подключения к БД
• Проверить все ли в порядке с БД
В конфиге прописана тестовая БД
• Добавить в стандарт деплоймента
проверку конфигов
• Проверять работоспособность сайта
после выноса
• Сделать автоматические smoke-
тесты
Разработчик забыл поменять конфиг
при выносе
• Проинструктировать разработчиков
по порядку выноса сайтов
Недостаточная внимательность
• Заменить ручную смену конфига на
автоматическое определение
окружения и выставления
соответствующей БД
67. Root Cause Analysis
http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf
74. SMART
Буква Английский термин Русский термин
S Specific Точные и конкретные
M Measurable Измеримые
A Achievable Достижимые
R Relevant Релевантные
T Time bound/framed Цели со сроком
75. Plus Minus Voting
http://www.funretrospectives.com/plus-minus-voting/
84. Благодарности
• Цель – поблагодарить участников и
закончить на позитивной ноте ретро
• Члены команды выбирают кого
поблагодарить за что-то очень конкретное
• «Я хочу поблагодарить _________ за
___________»
86. Структура ретроспективы
Открытие – 5%
Сбор данных – 30%-50%
Проникновение в суть – 20%-30%
Принятие решение – 10%
Закрытие – 5%-10%
87. Как испортить ретроспективу?
1. Не подготавливаться
2. Не фокусироваться
3. Не собирать данные
4. Один или два человека доминируют на ретроспективе
5. Фокусироваться на обстоятельствах вне возможностей
команды
6. Откусывать больше, чем команда может прожевать
7. Выбирать действия, для которых у команды
недостаточно энергии
8. Держать план улучшений отдельно от беклога
90. Что почитать в Интернете?
• http://agileretrospectivewiki.org/
• http://www.funretrospectives.com/
• http://blog.falkayn.com/2008/11/my-first-agile-
retrospective.html
• http://www.estherderby.com/2010/06/eight-reasons-
retrospectives-fail-and-what-you-can-do-
about-them.html
91. Интересные презентации по
ретроспективам
• Правила хорошей ретроспективы или ключ
к непрерывным улучшениям -
http://www.slideshare.net/VLDCORP/ss-
29004309
• Первое правило распределенных
самоорганизующихся систем -
http://www.slideshare.net/tim.com.ua/agileb
asecamp-15-2014
92. Генератор планов ретроспектив
www.plans-for-retrospectives.com
Retr-O-Mat contains 44 activities, allowing for
36867 combinations (9x8x8x8x8+3) and I'm
constantly adding more.
Editor's Notes
Visualize The workflow of knowledge work is inherently invisible. Visualising the flow of work and making it visible is core to understanding how work proceeds. Without understanding the workflow, making the right changes is harder. A common way to visualise the workflow is to use a card wall with cards and columns. The columns on the card wall representing the different states or steps in the workflow.
Limit WIP Limiting work-in-process implies that a pull system is implemented on parts or all of the workflow. The pull system will act as one of the main stimuli for continuous, incremental and evolutionary changes to your system. The pull system can be implemented as a kanban system, a CONWIP system, a DBR system, or some other variant. The critical elements are that work-in-process at each state in the workflow is limited and that new work is “pulled” into the new information discovery activity when there is available capacity within the local WIP limit.
Manage flow The flow of work through each state in the workflow should be monitored, measured and reported. By actively managing the flow the continuous, incremental and evolutionary changes to the system can be evaluated to have positive or negative effects on the system.
Make policies explicit Until the mechanism of a process is made explicit, it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.
Implement feedback loops Collaboration to review flow of work and demand versus capability measures, metrics and indicators coupled with anecdotal narrative explaining notable events is vital to enabling evolutionary change. Organizations that have not implemented the second level of feedback - the operations review - have generally not seen process improvements beyond a localized team level. As a result, they have not realized the full benefits of Kanban observed elsewhere.
Improve collaboratively, evolve experimentally (using models and the scientific method) The Kanban method encourages small continuous, incremental and evolutionary changes that stick. When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus. The Kanban method suggests that a scientific approach is used to implement continuous, incremental and evolutionary changes.
К паттернам можно отнести анализ сделанных улучшений за несколько прошлых спринтов. Такая «ретроспектива ретроспектив» может проводить раз в несколько спринтов и позволяет контролировать уровень сделанных улучшений
Для максимальной открытости и прозрачности обсуждения необходимо использовать основное правило ретроспективы, которое можно озвучивать в начале:
Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависит от следующих факторов:
Длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тем больше материала для обсуждения;
Размер команды: чем команда больше, тем больше надо времени, чтобы у каждого ее члена была возможность высказаться и тем больше функционала команда успевает сделать;
Наличие проблем: со временем команда решает проблемы и ретроспективы сокращаются по времени.
Break the large group into groups of three people (one or two groups can have four people)
Place three post it and a pen in front of each person
Ask everyone to write a sentence (on a post it), then place a blank post it on top of it (for now only the sentence author knows it)
Everyone pass the post it clockwise
Each person read the sentence from the post it in front of them, and then create a representative drawing for the sentence (on the blanket post it)
Everyone pass the post it clockwise.
On a new post it, each person write a sentence for the drawing in front of them, and place it on top of the post it set (now the set has 3 post its; the original sentence, the drawing, and the new sentence)
Everyone pass the post it set clockwise (for the groups of three people, the set should end in front of the original sentence writer)
Open the post it set so everyone can see the sentences and respective drawings.
1. Ask the participants to think about an adjective that begins with the same letter as their name.2. Form a circle and ask each participant to say their name with the adjective, in turns3. After all the participants speak, ask them to go clock-wise telling the name and adjective for the person at their side.4. After a few turns, ask the participants to repeat step 3 going anti clock-wise.
Running the activity
Ask participants to choose a number between 1 and 5 that indicates how
safe they feel within the group. Below is the meaning for each number.
5 – No Problem, I’ll talk about anything
4 – I’ll talk about almost anything; a few things might be hard
3 – I’ll talk about some things, but others will be hard to say
2 – I’m not going to say much, I’ll let others bring up issues
1 – I’ll smile, claim everything is great and agree with managers
The KALM (Keep, Add, More, less) divides the board into 4 areas:
Keep – something the team is doing well and you recognize the value on it.
Less – something already being done; but you rather do less of it.
More– something already being done; and you believe will bring more value if done even more.
Add – a new idea, or something you have seen working before that you would like to bring to the table.
Future Considerations: Please write down all future considerations with respect to the project/phase.
Lessons Learned: Please write down the key lessons and takeaways from the project/phase.
Accomplishments: Please write down the key accomplishments for the project/phase.
Problem Areas: Please write down the problem areas experienced throughout the specified project/phase.
Select a sample User Story (or a work item), describe it and write it down on the top left corner of the canvas.
Write down the major events on its execution path (from inception to completion)
Write down the good things to repeat
Write down the things to avoid, to be cautious about, or to consider changing
Group conversation and action items
Now, let’s look ahead, at the near future. Please, write notes and place them on the following two areas on both sides of the balloon: Storm and Sunny day.”*
- Looking Ahead – Storm: What is the storm ahead of us? What will have our trip turbulenta?
- Looking Ahead – Sunny day: What could we do to avoid the storm and turn towards sunny days? What shall we do to overcome the possible challenges ahead of us?
Looking Ahead – Abyss: What are the dangers ahead? What could take us down the role?
Looking Ahead – Abyss:Bridge: What could we build to overcome such challenges? What shall we do to overcome the abyss?
Each participant has 5 votes (each vote will be represented by a dot on the post it)Participants can place more that one vote on a card. Please vote on the items that you want to have a conversation about. The items with most votes will be picked up first.