Почему, как и что из ретроспективы Agile
В этом посте я расскажу вам, почему ваша команда должна проводить ретроспективы. Я объясню, как сделать это таким образом, чтобы показать его преимущества, и предоставлю краткий шаблон, чтобы вы могли легко начать работу.
- Часть 1. Почему вы должны это делать?
- Часть 2. Как добавить ретроспективы функций в существующий процесс разработки?
- Часть 3. Что вы делаете на ретроспективной встрече? Кого вы приглашаете?
- Часть 4. Шаблон ретроспективы функций
- Часть 5:резюме
Часть 1. Зачем это делать?
Начнем с Почему (это всегда хорошая идея, спасибо, Simon Sinek). Все мы знаем, что процесс разработки всегда длиннее, чем нам всем хотелось бы. Так почему вы должны добавить еще один шаг к этому? Что это значит для вас?
Поясню, почему это так важно.
Цель Agile-ретроспективы – постоянное совершенствование в команде.
Это наш способ регулярно делать небольшие шаги к улучшению. Эти небольшие шаги создадут культуру роста и повысят производительность всей команды разработчиков. Мы хотим иметь ретроспективную культуру, в которой люди постоянно хотят учиться и делать что-то лучше; быстрее, с меньшими усилиями, с меньшим количеством ошибок, с меньшими ресурсами и т. д. Небольшие (на первый взгляд незначительные) улучшения, если их делать последовательно в течение долгого времени, приводят к ПОТРЯСАЮЩИМ результатам (Робин Шарма)
Надеюсь, теперь вы убедились, что ретроспективы — это хорошая идея.
Давайте узнаем, как привести команду к «ретроспективной культуре».
Часть 2. Как добавить ретроспективы функций в существующий процесс разработки?
Вот в чем суть:
- Назначьте владельца функции для каждой функции. Это человек, отвечающий за общую доставку и реализацию функции — от этапа создания идеи до полного развертывания.
- Имейте slack канал для каждой функции — это позволяет всем коммуникациям происходить в одном месте, где все заинтересованные лица могут следить за ними. Это полезно для организационной памяти, помогает помнить, кто принимал решения, и, что более важно, помнить, ПОЧЕМУ эти решения были приняты и какие соображения учитывались при их принятии.
- Создайте документ Ретроспектива функций для каждой функции — используйте шаблон (я добавил его в конце этого блога).
- Проведите встречу, посвященную ретроспективе функций.
- Поделиться с группой
Какое место это занимает в существующем процессе разработки?
Наш процесс разработки выглядел так до того, как мы добавили ретроспективы функций:
Сначала я объясню каждый шаг на приведенной выше диаграмме. Затем я объясню, что изменилось в этом процессе для поддержки «ретроспективной культуры».
- Шаг 1: «Планирование продукта» — менеджер по продукту планирует функцию (мечту).
- Шаг 2. Откройте канал Slack для этой функции, чтобы все сообщения о ней хранились в одном месте.
- Шаг 3. Проведите совещание по началу работы над функцией, на котором менеджер по продукту расскажет о функции всем разработчикам, прежде чем они начнут работать над ней.
- Шаг 4. Ознакомьтесь со спецификацией функции (каковы требования?). Это предварительное условие, необходимое для того, чтобы разработчик подготовил дизайн функции.
- Шаг 5.Подготовьте дизайн функции и проведите совещание по обзору дизайна (это может быть отдельная запись в блоге).
- Шаг 6.Оцените временную шкалу функции — когда она будет готова? какие вехи у нас будут? У нас также есть собрание Планирование игры в покер, на котором мы вместе обсуждаем задачи и оцениваем, сколько времени займет каждая из них. Для этого есть несколько бесплатных онлайн-инструментов, вот один из них. Это снижает риск того, что задача не будет готова вовремя, так как позволяет большему количеству людей увидеть план и подумать, что может пойти не так и что мы забыли учесть.
- Шаг 7.Это основное блюдо — разработка функций — это когда вы на самом деле пишете код.
- Шаг 8.КК (необязательно) — после того, как функция будет готова, у нас будет КК, который ее протестирует.
- Шаг 9.Встреча по внедрению — как мы планируем выпустить эту функцию? Например, откройте эту функцию сначала для небольшой группы пользователей, а затем постепенно увеличивайте трафик, пока она не будет открыта для 100 % пользователей по всему миру. Рассмотрите все, что может пойти не так, спланируйте, как вы узнаете об этом и как вы будете решать проблему в случае ее возникновения (закрытие переключателя функций, откат и т. д.)
Как мы изменили существующий процесс?
Мы добавили еще 4 шага:
1. Прежде чем начать:
- Определите, кто является владельцем функции.
- Владелец функции должен открыть выделенный канал Slack для этой функции.
- Владелец функции должен планировать собрания синхронизации с подходящей периодичностью.
- Владелец функции должен создать новый ретроспективный документ с использованием шаблона. Храните его на видном месте, где вы сможете легко добавить ретроспективы новых функций в будущем. Например, на Confluence или общем диске.
2. В процессе разработки:
- Каждый член команды должен собирать индивидуальную информацию и записывать ее в документ ретро-функции.
3. После выхода функции:
- Проведите ретроспективную встречу с командой, занимающейся этой функцией.
4. Поделитесь своими выводами
Поделитесь своими выводами с остальными исследователями и разработками, чтобы все могли извлечь из этого уроки. Это изюминка 🍒 в топе всего процесса. Не пропустите! Вы можете поделиться им по электронной почте, на собрании или даже в слабом канале вашей команды. Поделиться — это заботиться!
Часть 3. Что вы делаете на ретроспективной встрече?
Создайте подходящую атмосферу для обсуждения
- Не переходи на личности, не принимай на свой счет
- Слушайте с открытым сердцем
- Опыт каждого действителен
- Сосредоточьтесь на улучшении, а не на обвинении
О чем следует поговорить на собрании?
- Что мы сделали хорошо?
- Что мы можем сделать лучше в следующий раз? Важно сформулировать этот вопрос в положительной форме. Не спрашивайте «Что мы сделали не так?», предполагайте, что у людей были самые лучшие намерения, они сделали все, что могли, учитывая время и знания, которые у них были на тот момент.
- Правильно ли мы оценили оценку времени?
А потом:
- Сгруппируйте похожие проблемы вместе, найдите идеи, как сделать это по-другому и лучше в следующей функции, кратко обсудите каждую проблему в команде.
- Определяйте действия, открывайте заявки (в вашем инструменте управления задачами, таком как Jira/Monday/Asana) + назначайте их + устанавливайте крайние сроки.
Кто приглашен на встречу?
Кто бы ни принимал участие в этой функции, это могут быть разработчики Backend и Frontend, QA, менеджеры по продукту, эксперты по пользовательскому опыту, авторы контента, аналитики и т. Д.
Кто еще?
Вы можете добавить модератора, который является нейтральным лицом, которое ведет дискуссию, задает наводящие вопросы, дает краткое изложение и направляет дискуссию в позитивный конструктивный разговор.
У каждой функции должна быть ретроспектива
Чтобы было проще, вот шаблон, который вы можете использовать:
Часть 4. Шаблон ретроспективы функций:
- Описание функции: несколько строк, объясняющих, зачем она нужна, о чем она.
- Команда: назовите людей, которые работают над этой функцией: менеджер по продукту, разработчик внешнего интерфейса, разработчик внутреннего интерфейса, QA и т. д. Кто бы ни принимал участие!
- Что мы сделали хорошо? Что мы можем сделать лучше в следующий раз? Подумайте об API, оценке времени, управлении, командной работе, синхронизации совещаний.
- Элементы действий: напишите, что нужно сделать, назначьте это соответствующим людям, установите срок выполнения задачи. если вы работаете с Jira/Asana/Monday/любой другой системой управления задачами — добавьте ее туда. Не оставляйте это в документе.
5. Резюме
Мы рассмотрели, почему вы должны проводить ретроспективы функций, как добавить их в существующий процесс разработки и как должна выглядеть ретро-встреча.
Ретроспективы функций — важная часть культуры разработки.
Если все сделано правильно, это должно вызвать у команды приятное теплое чувство приятного завершения работы над реализованной функцией и достаточную мотивацию для перехода к следующей функции с желанием реализовать новые идеи и улучшить следующую. время вокруг.
Как выразился знаменитый философ Софокл;
"У меня нет желания страдать дважды, на самом деле, а потом задним числом".
— Софокл, "Царь Эдип"
Не стесняйтесь комментировать и задавать вопросы!
