Successfully reported this slideshow.
Your SlideShare is downloading. ×

Эффективные ретроспективы

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 93 Ad

Эффективные ретроспективы

Download to read offline

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

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

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to Эффективные ретроспективы (20)

Advertisement
Advertisement

Эффективные ретроспективы

  1. 1. Эффективные ретроспективы: процесс непрерывного улучшения Вольфсон Борис
  2. 2. Вольфсон Борис Технический директор HeadHunter
  3. 3. «Совершенствоваться не обязательно. Выживание – дело добровольное» Э. Деминг
  4. 4. Содержание • Теория • Виды активностей на ретроспективах – Открытие – Сбор данных – Проникновение в суть – Принятие решение – Закрытие
  5. 5. Что такое ретроспектива? • Что такое ретроспектива? • Вы проводите ретроспективы? – Что обсуждаете? – Помогает совершенствованию процессов? – Как часто проводите? – Сколько длится?
  6. 6. Определение • Ретроспектива – процесс обсуждения работы с целью их улучшения результатов в будущем Не хочешь пропустить со мной по пиву? Не могу, я делаю список, в чем я могу усовершенствовать себя в следующем году Не- плохая идея, сделаю тоже самое Ничего. Совершенство достигнуто Мда, вот это конструк- тивность. Какая едкая зависть, тебе бы поработать над этим
  7. 7. Postmortem в водопадных процессах POSTMORTEM
  8. 8. Типичные проблемы Невозможность улучшить уже завершенный проект Низкая заинтересованность участников Формальность мероприятия
  9. 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. 10. Принципы Agile (1/2) 1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. 2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. 3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. 4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. 5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. 6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
  11. 11. Принципы Agile (2/2) 7. Работающий продукт — основной показатель прогресса. 8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. 9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. 10. Простота — искусство минимизации лишней работы — крайне необходима. 11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. 12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
  12. 12. Циклические ретроспективы
  13. 13. Ретроспектива в Scrum
  14. 14. Ретроспектива в Kanban 1. Визуализация потока 2. Ограничение кол-ва задач в работе 3. Управление потоком 4. Явные правила 5. Циклы обратной связи 6. Коллективные улучшения через эксперименты
  15. 15. Ретроспектива in the long run Время Эффективность Плато эффективности
  16. 16. Ретроспектива in the long run Рост эффективности • Быстрый рост • Решение проблем и устранение боли Плато эффективности • Нет проблем  • Нет роста Гиперэффективность • Медленный ступенчатый рост • Использование возможностей • Эксперименты
  17. 17. Что обсуждать, если «проблем нет» Скорость команды и ее изменение Нереализованные истории пользователей Дефекты и их причины Качество процессов Социальную атмосферу
  18. 18. Цикл Деминга-Шухарта Plan Do Check Act
  19. 19. A3 шаблон
  20. 20. Ретроспектива ретроспектив
  21. 21. Безопасность © The Improved Methods
  22. 22. Главное правило ретроспективы В независимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал всё, чтобы добиться успеха
  23. 23. Звать ли начальника/заказчика?
  24. 24. Структура ретроспективы Открытие – 5% Сбор данных – 30%-50% Проникновение в суть – 20%-30% Принятие решение – 10% Закрытие – 5%-10%
  25. 25. Длительность • Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависит от следующих факторов: – Длина спринта – Размер команды – Наличие проблем
  26. 26. Зачем взрослым играть? Позитивность Вовлеченность Креативность
  27. 27. Имитация улучшений
  28. 28. АКТИВНОСТИ ДЛЯ ОТКРЫТИЯ
  29. 29. Можно использовать айсбрекеры
  30. 30. Визуальный телефон Оригинальное предложение Рисунок Восстановленное предложение http://www.funretrospectives.com/visual-phone/
  31. 31. Пунктуальный Павел http://www.funretrospectives.com/punctual-paulo/
  32. 32. ESVP: как проводить? • Цели – Сфокусировать команду на ретроспективе – Понять отношение каждого члена команды к ретроспективе Каждый член команды определяет к какой роли на ретроспективе он себя относит: 1. Explorer – исследователь 2. Shopper – покупатель 3. Vacationers - отпускники 4. Prisoner – узники (с) Алексей Пикулев
  33. 33. ESVP http://www.funretrospectives.com/esvp-explorer-shopper-vacationer-prisoner/
  34. 34. Check In: как проводить? • Цели – Сфокусировать команду на ретроспективе – Услышать каждого члена команды Каждый член команды отвечает одним или двумя словами на вопрос скрам-мастера: 1. Опиши своё состояние одним словом? 2. Какие твои ожидания от ретро? Можно использовать и другие вопросы, например, с метафорами: «Какой машиной ты себя ощущаешь на ретро?»
  35. 35. Safety Check http://www.funretrospectives.com/safety-check/
  36. 36. Happiness radar http://www.funretrospectives.com/happiness-radar/
  37. 37. Happiness radar http://www.funretrospectives.com/happiness-radar-3-ls-dot-voting/
  38. 38. АКТИВНОСТИ ДЛЯ СБОРА ДАННЫХ
  39. 39. Hot-air Balloon http://www.funretrospectives.com/hot-air-balloon/
  40. 40. Speed Car http://www.funretrospectives.com/speed-car/
  41. 41. Speedboat © Mikhail Podurets
  42. 42. Worked well, kinda Worked, didn’t Work http://www.funretrospectives.com/www-activity-worked-well-kinda-worked- didnt-work/
  43. 43. KALM – Keep, Add, More, Less http://www.funretrospectives.com/kalm-keep-add-more-less/
  44. 44. Open the box http://www.funretrospectives.com/open-the-box/
  45. 45. Open the box http://www.funretrospectives.com/open-the-box/
  46. 46. Future direction, Lessons learned, Accomplishments and Problem areas http://www.funretrospectives.com/flap-activity-future-direction-lessons-learned-accomplishments- and-problem-areas/
  47. 47. Starfish http://www.funretrospectives.com/starfish/
  48. 48. Small starfish http://www.funretrospectives.com/small-starfish/
  49. 49. Timeline
  50. 50. Timeline: цели • Стимулировать воспоминания о прошедшем • Создать «картинку» с нескольких перспектив • Получить факты и/или ощущения участников
  51. 51. Как проводить
  52. 52. The story of a Story
  53. 53. Team Radar: цели • Измерение того, насколько команда удовлетворена по различным аспектам работы
  54. 54. Team Radar: как проводить?
  55. 55. Lessons learned quadrants http://www.funretrospectives.com/lessons-learned-quadrants-planning-vs-success/
  56. 56. Lessons learned quadrants http://www.funretrospectives.com/lessons-learned-quadrants-planning-vs-success/
  57. 57. АКТИВНОСТИ ДЛЯ ПРОНИКНОВЕНИЯ В СУТЬ
  58. 58. Hot-air Balloon -> Bad Weather http://www.funretrospectives.com/hot-air-balloon-bad-weather/
  59. 59. Speed Car – Abyss http://www.funretrospectives.com/speed-car-abyss/
  60. 60. Brainstorming/Filtering • Цель – сгенерировать большое кол-во идей • Проводим мозговой штурм – Free-for-all – Round-robin – С подготовкой • Создаем фильтры для идей • Пропускаем идея через фильтры
  61. 61. Value Stream Mapping
  62. 62. Value Stream Mapping
  63. 63. Пять «почему» Why?!
  64. 64. Пять почему • Цель – быстро понять глубинные причины • Делимся на небольшие группы 2-4 человека • По каждой проблеме спрашиваем пять раз «почему» • По каждому уровню выбираем решение
  65. 65. Пять «почему»: пример Симптом Действие На сайте выдается сообщение об ошибке подключения к БД • Проверить все ли в порядке с БД В конфиге прописана тестовая БД • Добавить в стандарт деплоймента проверку конфигов • Проверять работоспособность сайта после выноса • Сделать автоматические smoke- тесты Разработчик забыл поменять конфиг при выносе • Проинструктировать разработчиков по порядку выноса сайтов Недостаточная внимательность • Заменить ручную смену конфига на автоматическое определение окружения и выставления соответствующей БД
  66. 66. Root Cause Analysis http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf
  67. 67. Дерево дефектов
  68. 68. Контрольные карты Шухарта
  69. 69. Диаграмма Исикавы
  70. 70. АКТИВНОСТИ ДЛЯ ПРИНЯТИЯ РЕШЕНИЙ
  71. 71. SMART Буква Английский термин Русский термин S Specific Точные и конкретные M Measurable Измеримые A Achievable Достижимые R Relevant Релевантные T Time bound/framed Цели со сроком
  72. 72. Plus Minus Voting http://www.funretrospectives.com/plus-minus-voting/
  73. 73. Голосование точками http://www.funretrospectives.com/dot-voting/
  74. 74. © Alex Troshin
  75. 75. АКТИВНОСТИ ДЛЯ ЗАКРЫТИЯ
  76. 76. Цветной фидбек http://www.funretrospectives.com/qcon-quick-feedback-on-talks/
  77. 77. Learning Scale http://www.funretrospectives.com/learning-scale/
  78. 78. Who-What-When http://www.funretrospectives.com/the-who-what-when-steps-to-action/
  79. 79. Feedback and ROI http://www.funretrospectives.com/feedback-and-roi/
  80. 80. +/Delta
  81. 81. Благодарности • Цель – поблагодарить участников и закончить на позитивной ноте ретро • Члены команды выбирают кого поблагодарить за что-то очень конкретное • «Я хочу поблагодарить _________ за ___________»
  82. 82. ЗАВЕРШЕНИЕ
  83. 83. Структура ретроспективы Открытие – 5% Сбор данных – 30%-50% Проникновение в суть – 20%-30% Принятие решение – 10% Закрытие – 5%-10%
  84. 84. Как испортить ретроспективу? 1. Не подготавливаться 2. Не фокусироваться 3. Не собирать данные 4. Один или два человека доминируют на ретроспективе 5. Фокусироваться на обстоятельствах вне возможностей команды 6. Откусывать больше, чем команда может прожевать 7. Выбирать действия, для которых у команды недостаточно энергии 8. Держать план улучшений отдельно от беклога
  85. 85. Что почитать?
  86. 86. http://www.piter.com/collection/kariera-v-it-industrii/product/gibkoe-upravlenie- proektami-i-produktami
  87. 87. Что почитать в Интернете? • 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
  88. 88. Интересные презентации по ретроспективам • Правила хорошей ретроспективы или ключ к непрерывным улучшениям - http://www.slideshare.net/VLDCORP/ss- 29004309 • Первое правило распределенных самоорганизующихся систем - http://www.slideshare.net/tim.com.ua/agileb asecamp-15-2014
  89. 89. Генератор планов ретроспектив 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 turns 3. 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.

×