В доповіді розглянуті найбільш поширені помилки ретроспектив, а також користь, яку багато хто втрачає, ігноруючи проведення даного ритуалу. Також розглядаємо декілька корисних методик як-от cause-effect diagrams, котрі допоможуть знаходити причини проблем максимально швидко

1. Ретроспектива:
Безболісно та ефективно

2. Адженда
Навіщо потрібні ретроспективи
Основні види
Як краще робити
Як краще НЕ робити
Корисні техніки проведення

3. Працюю в Very Good
Security
Організовую
GDG Lviv і DevFest Ukraine
Пишу в Medium

5. “Я не казав всієї цієї фігні”
(с) Лао Цзи, Лев Толстой,
Альберт Ейнштейн

6. Парадокс Анни Кареніної
Наш проект

7. Людьми керує бажання стати краще
¯_(ツ)_/¯
Навіщо?

9. Когнітивні упередження (cognitive biases)
“Заднім числом” все здається очевидним
Хибні спогади з позиції “теперішніх” себе
Пошук причинно-наслідкових зв’язків там, де їх немає

10. Види ретроспектив

11. Базова
Що було добре?
Що могло бути краще?
Що хотілось би змінити?

12. Фреймворк Стратоплану
Що погано?
В чому це виражається?
Чого хотілось би?

13. Можна використовувати таблиці
Що було добре?
Що могло бути
краще
Наступні кроки
Аліса
Демо фічі XX було
вражаючим
Темплейт для багів має
включати ітерацію
Оновити темплейт для
багів
Боб
Кооперація з командою
маркетингу над демо
Нестача внутрішньої
документації. Занадто
довгий процес code
review
Створити разом з Чарлі
діаграми архітектури
мікросервісу X.
Провести брейнштормінг
щодо процесу code review

14. Можна малювати Starfish
Почати робити Припинити робити
Продовжувати робити
Менше...
Більше...

15. Або просто писати на стікерах

16. Post mortem
Для дуже серйозних інцидентів
Потрібно показати, що з проблемою не просто розібрались, але й
знайшли причину, і не повторять в майбутньому

18. Корисно про інциденти
Atlassian incident handbook
https://www.atlassian.com/software/jira/ops/handbook
PagerDuty incident response
https://response.pagerduty.com/
Подкаст про інцидент-менеджмент
https://soundcloud.com/podlodka/podlodka-105-intsident-menedzhment

19. Але розробники ненавидять мітинги і
не хочуть ходити на ретро

20. Чому?
Їх там не слухають
В ретроспективі немає чіткої структури
Не відчувається користь (зміни не впроваджують)

21. Треш і угар
Взаємні звинувачення
Неконструктив (нема конкретики)
Самоприниження

22. Save the drama for your mama

23. Не працюйте з мудаками?
https://dou.ua/lenta/columns/thoughts-about-it/

24. Якщо навколо вас немає “мудаків”...

25. Треш і угар
Взаємні звинувачення
Неконструктив (нема конкретики)
Самоприниження

26. Критикуєте - пропонуйте рішення!

27. Не можете запропонувати рішення -
використовуйте техніки, згадані раніше

28. Треш і угар
Взаємні звинувачення
Неконструктив (нема конкретики)
Самоприниження (сама так робила багато разів)

29. Сумний приклад з особистого досвіду
не треба так

30. Як вирішили проблему
Розібрали причину
Описали кроки, як попередити подібні проблеми в майбутньому
Важливо подякувати розробникам, які самі все полагодили і
потестували фікс, коли я вже спала

31. Як зробити правильно?
✅ Дати слово кожному
✅ Готуватись наперед і зробити мітинг якомога коротшим
✅ Не шукати винних
✅ Вияснити найважливіші зміни => скоротити їх кількість!
✅ Подумати, як виміряти покращення

32. Забагато покращень теж погано

33. Забагато покращень теж погано
“Having the process improvement workshop every week was
rather intense, though;
we barely had time to execute the changes from one meeting
to the next.”
“Lean from the trenches”

34. Не забувайте подякувати іншим!

35. Виясняємо причини проблем

36. 5 “Чому?”
Корзина інтернет-магазину не працювала 3 год в продакшні
1. Чому корзина не працювала?
Останні зміни зламали стару фічу
2. Чому зміни зламали фічу?
Немає регресійних тестів

37. 5 “Чому?”
3. Чому немає тестів?
Не вистачає часу писати тести
4. Чому не вистачає часу?
Забагато тасків взяли в ітерацію
5. Чому взяли багато тасків?
Тиск з боку Product owner’а

38. Діаграми
причинно-наслідкового зв’язку

39. Баги в проді

40. Баги в проді
Злі
користувачі
Проблема

41. Баги в проді
Злі
користувачі
Релізи погано
протестовані
Проблема

42. Баги в проді
Злі
користувачі
Релізи погано
протестовані
Нестача
автоматизації
Хотфікси
Проблема

43. Баги в проді
Злі
користувачі
Релізи погано
протестовані
Нестача
автоматизації
Не вистачає
часу
Хотфікси
Команда
відволікається
Проблема

44. Баги в проді
Злі
користувачі
Релізи погано
протестовані
Нестача
автоматизації
Не вистачає
часу
Хотфікси
Команда
відволікається
Стрес
Проблема

45. Баги в проді
Злі
користувачі
Релізи погано
протестовані
Нестача
автоматизації
Не вистачає
часу
Хотфікси
Команда
відволікається
Стрес
Команда падає
духом
Люди йдуть
Проблема Проблема

46. Баги в проді
Злі
користувачі
Релізи погано
протестовані
Нестача
автоматизації
Не вистачає
часу
Хотфікси
Команда
відволікається
Стрес
Скоуп рабіт не
зменшується
Команда падає
духом
Люди йдуть
Нестача
інструментів та
навчання
Проблема Проблема
Причина Причина

47. Ніхто не хочу робити ретроспективу -
ініціюйте!

48. Ініціатива радує ініціатора
Йдемо до команди та задаємо запитання (що добре, що погано, що
змцнити)
Записуємо у вигляді коротких заміток
Публікуємо де-небудь (Slack, паперова замітка)
Намагаємось запровадити...

49. Навіщо?
Як тільки люди побачать користь -
самі приєднаються

50. Зміни - це складно
Люди бояться змін
Короткі експерименти, які можна “відмінити”
Починаємо з маленької команди
Невеликі кроки

51. “Нерозумно робити одне й те ж,
але очікувати різного результату”
(с) Джейсон Стетхем

52. Почитати

53. Дякую!
@diana_pinchuk