Улучшение работы команды

Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
Улучшение работы команды создатель Mind Map: Улучшение работы команды

1. Starfish

1.1. Stop doing – что нужно прекратить делать (например, собирать бесполезные метрики)

1.2. Less – этим вещам нужно уделять меньше внимания (времени)

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

3. цель

4. список работающих практик

5. backbox

6. Keep this/Ongoing problems/Try this

7. Continue doing – это хорошо работает, нужно сохранить

8. Timeline помогает построить ретроспективу на реальных фактах. Timeline – это область на доске (или стене), которая представляет прошедший спринт, и набор стикеров, представляющих произошедшие события. События расположены согласно дате (хотя не обязательно точная привязка). События могут иметь различные цвета – например, в зависимости от последствий (позитивное, негативное, нейтральное), компонента (процесс, код, тестирование и т.д.) или приоритета. Есть несколько подходов к построению timeline – в течение спринта или в начале ретроспективы. Первый позволяет не забыть события, но второй подход проще. Борис Лебеда предложил вариант с black box’ом – в комнате команды ставится ящик, в который можно бросать заметки с событиями. На ретроспективе все эти заметки достаются, сортируются, выкидываются малозначительные – и получаем набор фактов.

9. Фасилитатор

9.1. вместо "вопросы есть?"

9.1.1. "что, Вася, думаешь по этому поводу?"

10. Перед началом - напомнить

10.1. процедуру

10.2. ожидаемые результаты

10.3. action plan

10.3.1. Распечатать и помечать галочками

11. Проанализировать результаты предыдущей

12. Определить что работает хорошо, а что является проблемой

13. Результаты

13.1. список проблем

14. Различные инструменты и подходы

14.1. What went well/What could be improved

14.2. Во время bug fix analysis исследуются допущенные ошибки и как их не повторять.

14.3. Bug fix analysis/Knowledge sharing/Fix process:Roles&Practices

14.4. В рамках фазы Fix process анализируется процесс – убираются или добавляются роли и практики.

14.5. Start doing – что нужно начать делать (например, регулярный peer code review)

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

14.6. More – этим вещам нужно уделять больше внимания (времени)

14.7. Timeline

14.8. Вертикальная ретроспектива

15. периодически менять тип ретроспективы

15.1. 1