Ретро agile что это
Ретро agile что это
Agile-коуч Марк Лоффлер уверен: ретроспектива — отличный инструмент для начала положительных изменений в команде или во всей компании. Эта практика учит смотреть в прошлое, чтобы извлекать уроки, не цепляться за старые решения и вовремя корректировать курс. Но как провести ее впервые? Вот детальный план из книги «Ретроспектива в Agile».
Подготовка
Определите агенду ретроспективы. Она может выглядеть так:
Обратите внимание: здесь нет одного из этапов — проверки гипотез. Дело в том, что наша агенда рассчитана на команды, которые используют практику впервые или не определили гипотезы в прошлый раз.
Так выглядит полная модель ретроспективы
Когда агенда будет готова, отправьте приглашение всем участникам. Запаситесь флипчартом, маркерами, ручками, стикерами. Не забудьте забронировать комнату, и прийти за 15-30 минут до начала, чтобы успеть подготовить пространство.
Открытие: сравнение с автомобилем
В начале ретроспективы поприветствуйте участников и кратко объясните агенду. Если у команды есть устав, напомните всем о правилах. При отсутствии устава пропустите этот шаг, но в будущем организуйте воркшоп по его созданию.
Попросите участников сравнить период, который обсуждаете, с автомобилем. Каждый должен в нескольких словах описать машину, о которой он подумал. Приведите пару примеров: «ржавый старый фольксваген пассат» или «первоклассный ламборджини мурселаго». Участникам не обязательно следовать фиксированному порядку, но высказаться должны все. Не комментируйте ответы. Поприветствуйте каждый вклад.
Сбор данных
Объясните участникам суть работы. Пусть каждый использует стикеры, чтобы записать все, что делало его раздраженным, грустным или довольным в течение рассматриваемого времени. Оставьте специальное поле, чтобы присутствующие могли сказать спасибо одному или нескольким членам команды.
Нарисуйте большой крест на доске или флипчарте и пометьте четыре области
Совет: пока участники пишут на стикерах, ваша задача — задавать вопросы о четырех категориях, чтобы предложить несколько идей. Это мотивирует других продолжать записи, когда вы почувствуете, что команда остановилась. Например:
Используйте последние 5 минут, чтобы прочитать заметки и получить разъяснения от авторов. Прекратить писать можно именно в это время. По мере чтения стикеров группируйте их по темам. В большинстве случаев это дает представление о насущных проблемах. Выбрать пару тем, которые будут в фокусе на оставшуюся часть ретроспективы, можно двумя способами:
Голосование стикерами или точками
Генерация идей: «5 почему»
Методу «5 почему» исполнилось более 100 лет. Его идея заключается в том, что большинство очевидных на первый взгляд причин проблем — лишь симптомы, а корень зла лежит гораздо глубже. Простой пример: предположим, вы разрабатываете автомобили, но их никто не покупает. Вот ряд вопросов, которые в связи с этим вы можете задать, и возможные ответы на них.
Найти единственный ответ на вопрос «Почему?» не всегда возможно. Иногда существует несколько причин, которые, в свою очередь, могут иметь свои основания. Это нормально.
Определение следующих экспериментов: мозговой штурм
На этом этапе у каждого участника есть 5 минут, чтобы придумать максимум три идеи, которые, по его мнению, имеют самый высокий потенциал для положительных изменений. Участники пишут свои идеи, придерживаясь правила «Один эксперимент на один стикер». Затем стикеры размещаются на открытом участке стены.
Когда время истекает, каждый кратко объясняет свою идею. Требуется рассказать, каким, по его мнению, будет эффект эксперимента. Участники должны попытаться сгруппировать идеи по мере их публикации. Используйте круглые стикеры, чтобы выбрать идею, которая имеет наибольший потенциал для успеха. Соглашайтесь лишь на одну идею. Это может показаться странным, учитывая, что теперь команда готова попробовать множество вариантов. Но если хотите убедиться, что работа действительно выполнена, важно выбрать что-то одно.
Дайте участникам понять, что идея, которую они выбрали, — это эксперимент. Вы способны лишь предположить, каким будет эффект, но никто не может быть в этом уверен. Сейчас важно добавить к выбранному эксперименту гипотезу. Убедитесь, что она поддается проверке. Так вы закладываете основу для следующей ретроспективы, где будете сравнивать исходную гипотезу с тем, что на самом деле произошло в эксперименте.
Совет: выбранные эксперименты должны быть конкретными, исполнимыми, измеримыми и достижимыми (выполняться в течение нескольких дней или недель). Убедитесь, что группа имеет право проводить их. Наконец, эксперимент должен быть ограничен по времени.
Теперь осталось определить, кто отвечает за проведение эксперимента и когда это произойдет. Объясните другим, что ответственный не обязательно должен делать все самостоятельно.
Закрытие: возврат на вложенное время (ROTI)
График, который поможет дать оценку ретроспективе
А теперь проведите ретроспективу о ретроспективе. Для этого часто используется график ROTI. Чтобы создать его, нарисуйте оси x и y, а затем диагональную линию, пронумерованную от одного до пяти. Единица означает: «эта встреча — пустая трата времени», тройка — «встреча стоила того времени, которое я на нее потратил», пятерка — «встреча замечательная, потраченное время полностью окупилось». Чтобы график принял завершенный вид, каждый участник ставит на нем крестик, отражающий его мнение. На рисунке выше видно, что команда довольна своей ретроспективой.
Поздравляем, вы провели свою первую ретроспективу! Пусть такие мероприятия станут регулярными, помогают учиться как на успехах, так и на неудачах, а хорошее делают еще лучше.
Завершение спринта в Scrum – демо и ретро
В этой, тринадцатой статье из серии «Менеджмент цифрового мира» я продолжу рассмотрение схемы скрам и буду говорить про завершение спринта – Демо, оно же Sprint Review и Ретроспективу. Она продолжает предыдущие статьи «Итерации Scrum – целостная схема, а не прикольная картинка», где мы рассмотрели переход к итеративной работе и планирование, и «Схема Scrum – ежедневная работа внутри спринта».
Назначение Демо – показ результатов, достигнутых командой, и их оценка стейкхолдерами. Именно получение оценки от стейкхолдеров является основной функцией демо: соответствует ли это их ожиданиям, решает ли поставленные задачи и приносит ли ценность. И официальное название в Scrum Guide – Sprint Review это подчеркивает. Но термин «Демо» является устоявшимся в сообществе, гораздо более коротким и я предпочитаю использовать именно его, тем более, что исторически именно это название я узнал первым, прочитав в 2007 книгу Хенрика Книберга «Скрам и XP: заметки с передовой», которую уже упоминал в предыдущей статье.
Если бы ценность задачи можно было бы обеспечить выполнением чек-листа, то никакой бы Agile был не нужен, с организацией IT-проектов хорошо бы справились методы классического менеджмента. Проблема состоит в высокой сложности социотехнических систем, в результате чего все представления о необходимых функциях и о работе пользователей – не более чем гипотезы, подлежащие проверки. А на бытовом уровне эта ситуация хорошо описывается словами «заказчик сам не знает, чего он хочет». Именно поэтому разработанный софт требует постоянной проверки: несет ли он ценность пользователям. Впрочем, тоже самое можно сказать о любых других продуктах – проверить, полезен ли продукт потребителям, нужен ли им можно только экспериментально.
Обычно Демо проводится в виде встречи, на которой присутствует команда и все заинтересованные стейкхолдеры: члены команды демонстрируют созданную ценность и получают обратную связь. Именно такую форму рекомендует Scrum Guide. Процедура кажется простой, однако практически с таким способом связано несколько проблем, которые мы обсудим далее.
Итак, какие же проблемы могут быть связаны с простой демонстрацией?
Во-первых, далеко не всегда на Демо удается обеспечить присутствие необходимых стейкхолдеров, среди них часто встречаются реально занятые люди.
Во-вторых, далеко не всегда стейкхолдеры в принципе могут оценить ценность сделанного на основе демонстрации. Например, если вы разрабатываете продукт, отдел из отдела маркетинга, который является внутренним заказчиком, поступают предложения о новых необходимых фичах, которые, однако носят статус гипотез, восприятие пользователями которых неизвестно, и в задачу команды входит не только разработка, но и оценка реакции пользователей, доработка по ней.
Да и при заказной разработке софта случается, что заказчиком является руководитель бизнес-подразделения, который приносит проблему не эффективного выполнения каких-либо операций, которую должен решить новый функционал, и, не выполняя операционную работу непосредственно, он часто не может оценить реализацию, а пользователям, которые могут это сделать, надо для оценки самим попробовать функционал на реальных данных…
В-третьих, далеко не всегда получается организовать продуктивную коммуникацию на демо, вовлекающую и членов команды и стейкхолдеров из-за культурных различий. Впрочем, тут работает легкий метод: часть коммуникации со стейкхолдерами ведет аналитик, владеющий их языком. Часть, а не всю: полезно, чтобы показ выполнял не он, а те, кто разрабатывал, комментируя свои действия и получая обратную связь, ощущение ценности собственной работы важно.
Отметим, что далеко не всегда эти проблему могут быть в конкретно вашем проекте. Наоборот, в большинстве проектов демонстрации стейкхолдерам достаточно, иначе бы в Scrum Guide не было бы рекомендованного способа. Ну или так было, когда Scrum формировался. Отметим, кстати, что переход от функциональных требований к user story отчасти проблемы демонстрации решал: мы вместо выполнения функций описывали цели пользователей, и демонстрация, как пользователи будут их достигать, работая используя разработанный софт, должна быть достаточна.
Однако, что делать, если проблема в вашем проекте существует? Правильный способ решения этих проблем – придумать альтернативные механизмы получения релевантной обратной связи и встроить в процесс именно их, чтобы обеспечить выполнение основной функции демо. Например, в цикл выполнения задачи может быть включено не только тестирование, но выкатка на боевые сервера и A/B тестирование на пользователях. Или установка его на тестовые сервера заказчика с приближенными к боевым данными, и проведение обучения и демонстрации конечным пользователям. Таким образом, есть различные варианты.
Но на практике вместо разработки механизмов часто просто назначают формального ответственного «ты будешь смотреть и оценишь результат». И в результате команда идет по неверному пути, а выясняется это только на внедрении функционала. Я слышал истории, когда эти проблемы возникали даже когда таким ответственным стейкхолдером был руководитель проекта от заказчика: он был на демо, был очень доволен, команда была вдохновленной. А потом оказалось, что он не слишком давно работает у заказчика, и его представления о процессе были основаны на опыте работы в другом месте. Поэтому, когда функционал принесли конечным пользователям, то выяснили его слабую пригодность для реального процесса. Заметим, что техническая выкатка изменений на боевые сервера не спасает, так как пользователи, не зная о новых функциях им просто не пользуются. А вот изменение работы пользователей в любом случае надо отдельно организовывать.
Отмечу, что примерно те же проблемы возникают и при применении Scrum для не IT-проектов: новые продукты или новые материалы недостаточно просто сделать и предъявить, могут быть необходимы испытания, тестирование на пользователях или у заказчиков. Типичный пример – маркетинг, конечным результатом маркетинговой компании тут являются привлеченные пользователи или покупатели, а вовсе не публикация рекламы, и именно по ним можно определить ценность.
Как было отмечено выше, в ряде случаев получение релевантной обратной связи подразумевает долгий по времени процесс. И далеко не всегда это может решено внутри спринта по объективным причинам. Если такие задачи встречаются изредка, то можно получение обратной связи выделять в отдельный поток, при этом может быть допустим перенос их в следующий спринт. Если же такие задачи составляют большинство, то надо придумывать другие механизмы.
Другой вариант – вынести получение обратной связи от пользователей за пределы Scrum в отдельный Kanban-процесс. Он целесообразен в том случае, если с ним связаны длительные временные лаги, не укладывающиеся в короткий Scrum-цикл.
Отметим, что оба этих механизма могут применяться так же для предварительной подготовке бэклога к разработке, об этом я буду рассказывать в следующей статье.
Независимо от выбранного способа, должны быть сделаны механизмы, реализующие еще одну функцию демо: обратная связь по ценности результата должна быть не только получена, но и донесена до всей команды. И не только отрицательная, но и положительная. Об этом часто забывают, успех очередной фичи маркетинг празднует у себя, а на команду транслирует только проблемы. Важно, чтобы команда тоже ощущала успех.
То же касается и механизмов, описанных ранее, например, когда выделенные сотрудники из команды обучают новому функционалу пользователей заказчика – обратную связь надо донести до команды. В том числе положительную эмоциональную обратную связь, чтобы люди ощутили ценность сделанного, а не просто приняли это к сведению.
Отметим, что бывают очень тяжелые ситуации, когда реальная обратная связь может запаздывать на месяц-другой из-за реально длительного процесса, включающего, например, производство конечного продукта на основе того проекта, который разрабатывает Scrum-команда. В этом случае все равно надо заботиться о механизмах обратной связи, хотя готовых рецептов у меня тут нет…
Помимо описанной выше задачи получения обратной связи от стейкхолдеров о ценности созданного продукта, Демо решает еще пару задач.
Во-первых, на демо идет оценка достижения целей спринта со стороны стейкхолдеров. И связанное с этим позиционирование достигнутого результата как часть более крупных циклов планирования или целеполагания: вклад спринта в разработку релиза, в продвижение к квартальным или годовым целям. Подробнее о цикле релизного планирования я буду говорить в следующей статье, рассказывая полную схему Scrum. А вот работа с квартальными и годовыми целями находится за пределами обеспечиваемого Scrum, для этого можно применять OKR (Objectives and Key Results). До OKR я тоже доберусь в будущих статьях, хотя, наверное, без подробностей. Но независимо от метода, в демо полезно включить оценку продвижения к целям по мнению стейкхолдеров.
Во-вторых, на Демо стоит получить обратную связь от стейкхолдеров по работе и восприятию команды в целом. Не по созданной ценности, а по характеру коммуникаций и другим аспектам взаимодействия.
Впрочем, обе этих задачи следует ставить только в том случае, если стейкхолдеры достаточно квалифицированы в высказывании такой публичной обратной связи, а команда – достаточно зрелая, чтобы ее принять. В противном случае вместо конструктива можно получить негатив и демотивацию команды.
Однако, как и в случае оценки ценности, если эти виды обратной связи на Демо получить нельзя, необходимо обеспечить другие механизмы ее получения. Ответственным за получение и донесение до команды обратной связи по целям является Product Owner, а по взаимодействию – они делят эту ответственность со скрам-мастером. Почему делят? Потому что к части стейкхолдеров Product Owner все равно пойдет по первому вопросу, и может заодно выяснить второй, нет смысла в двойной коммуникации. В то же время, взаимодействие Команды со стейкхолдерами может не ограничиваться теми, кто получает ценность от созданного продукта, это могут быть смежные и обслуживающие подразделения и команды, и задача взаимодействия с ними в целом лежит на скрам-мастере.
Всю обратную связь полезно получить до Ретро, чтобы на нем команда могла это обсудить. Впрочем, эти циклы обратной связи можно делать и более редкими, не обсуждая это каждый спринт, а проводя большие внешние ретроспективы с участием стейкхолдеров и оценкой ими достижений команды. Это – тоже работающая практика.
И в заключении стоит поговорить о том, что происходит, когда спринт окончился неудачно, и команда сильно не успела сделать запланированные работы. Тут следует явно сформулировать принцип, который я в свое время услышал от Хенрика Книберга: не бывает медленной скорости, бывает неверное планирование.
В моменте необходимо решить, что делать с задачами незавершенного спринта. Вернее, необходимо сделать заранее, когда Product Owner явно увидит из Burndown Chart и доски, что в спринте не будет завершено существенное количество задач. Это может быть видно уже в середине спринта, и точно становится явным за два-три дня до окончания. Product Owner должен оценить масштаб проблемы, и провести коммуникацию со стейкхолдерами и командой, выработать решение – на каких задачах делаем фокус, а какие – оставляем на будущие спринты. В некоторых случаях спринт может быть продлен на один-два дня, если такое решение может существенно повысить создаваемую ценность за целостности набора решенных задач.
Но в целом это – исключительная ситуация. О том, как проводить планирование и оценку, что именно поместится в спринт я буду говорить в следующей статье.
А в заключении этой статьи я буду говорить про Ретроспективу – встречу, на которой команда сама оценивает прошедший спринт и достижение целей и работает над улучшением процесса. Непрерывный процесс улучшений – неотъемлемая часть любого Agile-метода. Отсутствие реального ретро часто означает, что команда погрязла в самодовольстве. О проведении ретроспективы есть достаточно много книг и докладов, но в ней, наверное, наиболее сильно проявляются особенности культуры команды и компании, а я никогда на ней не фокусировался, поэтому я не готов рекомендовать конкретные книги и доклады.
Однако, я немного расскажу о полезных практиках, которые, на мой взгляд, не являются тривиальными.
Первое – это позитивное мышление им нацеленность на улучшения. Не «что было хорошо, а что плохо», а «что было хорошо, что нам мешало и как это устранить, и что можно улучшить».
Второе – вовлеченность всех членов команды. Но не стоит побуждать всех высказаться, или директивно требовать этого, люди стесняются, у них могут быть разные другие причины молчать. Так что лучше применять косвенные методы. Можно предложить каждому написать тезисы о том, что было хорошо, препятствия и идеи улучшений на стикерах и вывесить. Стикеры можно использовать разных цветов, в зависимости от вида тезиса и эмоционального отношения к ней: для позитива оценивать его вид – счастье, сюрприз и так далее; для препятствий – силу возмущения, для улучшений – накал желания. А уже потом объединить близкие идеи и обсудить по порядку: что хорошо, какие препятствия и как можно устранить, что можно улучшить. Обсуждение тоже можно начать не всем вместе, а в парах – это стимулировать высказаться всем, а не самым активным.
Третье – в результате должен быть план улучшений, в котором выделены те, которые считаем наиболее важными и берем в работу на следующий спринт. Важность стоит определять не в обсуждении, а голосованием точками. Можно оценивать не только рациональную важность, но и эмоциональное отношение к идеям, тоже какими-то смайликами.
Четвертое – идея изменений может быть сложной, и предполагать несколько шагов, как и в любой задаче, в том числе включать взаимодействие со стейкхолдерами для получения одобрения действий. А реализация может быть достаточно длительной. Их можно включать в общий список задач, или вести на отдельной Kanban-доске со своими фазами.
В случае отдельной доски препятствия и идеи можно вешать на нее не только на ретро, но и течении спринта, немедленно, как оно обнаружено. Но даже если доски нет, полезной является список, который в течении спринта все могут дополнить, или личные списки. Но все равно, это не должно быть единственным входом для ретроспективы.
Ретроспектива требует выйти из основного потока работ и перейти из позиции специалиста, который делает работу, в позицию наблюдателя, который эту работу оценивает. И это – отдельное мыслительное усилие и действие.
Шестое. Реализация идей требует ресурсов команды, и тут может быть различная политика взаимодействия со стейкхолдерами: может быть договоренность о некоторой квоте на улучшения на каждый спринт, или политика, отличающая мелкие улучшения, которые может делать команда и крупные, о которых надо договариваться. Для взаимодействия со стейкхолдерами часто необходимо сформулировать идеи на их языке: в виде измеримого препятствия для скорости команды, или возможности повышения ее скорости, потенциальных рисков, которые несет ситуация.
В IT частным случаем работы с препятствиями является работа с техническим долгом. Очень часто при реализации принимаются решение о том, что необходимо быстрое частичное решение по ситуации (костыль), а полноценное будет сделано позднее. А потом сделать хорошо забывают. Об этом есть даже сленговая шутка «IT- единственное место, где на костылях быстрее, чем без них». И полноценные решения не делают, но скрытые в коде костыли несут риск. И важно уметь донести проблемы стейкхолдерам в том виде, в котором они покажутся нестерпимыми. То же относится и к другим идеям.
Ну и в заключении я хочу сказать, что ретро – внутреннее собрание команды. На нем не должно быть стейкхолдеров для открытого разговора. Однако, помимо внутреннего ретро можно проводить внешнее, со стейкхолдерами, оценивающими работу команды – я писал о нем ранее, рассказывая о дополнительных задачах демо.
Однако, несмотря на то, что на ретро есть только члены команды, не все вопросы могут быть подняты. Если какие-то претензии и препятствия носят личный характер, люди могут их не высказывать. И вот тут начинается ответственность скрам-мастера: поговорить с людьми индивидуально, выявить проблему, а потом решить, что делать – выносить ли в какой-либо форме на ретро, или работать через индивидуальную коммуникацию.
На этом я завершаю очередную статью про схему Scrum, продолжение следует…
Всё отлично, но этот жирны мелькающий шрифт. Ребят, кто вас этому научил? Неудобно читать, глаз начинает дергаться.
Где скриншоты, полотно текста.
Так хотел прочитать про Scrum, но это почти не реально.
Поставлю в закладки и создам задачу на понедельник.))
Жирный выделяет важное, но, наверное, его здесь действительно многовато получилось. Спасибо за обратную связь. Надеюсь, статья окажется полезной.
есть пара вопросов.
В целом я не пишу учебник, а рассказываю про Agile на практике. Учебников и так много, и они не удовлетворяют людей. Люди видят описание Sprint Review, повестку на 4-часовую встречу, понимают не реализуемость в их условиях и говорят «ну Scrum нам не подходит, и вообще он настолько жесткий, что убиться можно».
Ретроспектива: проводим быстро и результативно с помощью funretro
Если ваши ретро не приносят результата, а только тратят время и раздражают команду разработки есть два выхода — отказаться от ретро вообще или сделать нормально. Знакомая боль и выбираете второй вариант? Тогда статья для вас
Советы для проведения продуктивной ретроспективы:
Не углубляясь в Scrum/Agile — ретроспективу проводим в конце каждого спринта (так говорит теория) для того чтобы найти боли команды/блокеры в проекте. На практике можно придерживаться более экономичного подхода — проводим, когда чувствуем что нужно/объединяем несколько спринтов в одно ретро (например, ретро раз в 2-3 спринта)
За несколько лет работы в командах разработки я выделил для себя топ-5 болей ретро, которые превращают его из эффективного инструмента в бессмысленную трату времени, демотивирующую команду:
Давайте посмотрим как убрать эти боли и начать жить счастливо. В любом деле выбор правильного инструмента — половина успеха, поэтому начнем с него
Funretro — сервис создан специально для проведения ретро. Плюсы — решает проблему анонимности, есть механизм голосования, много шаблонов ретро и тд. Из минусов — только 3 доски в бесплатной версии.
Попробовав несколько вариантов, остановился на funretro, он решил почти все боли. Инструмент выбран — начинаем подготовку к ретро
Подготовка — половина успеха в любом деле, ретро не исключение.
Настроили доску? Стартуем
Расскажите о цели ретро, проговорите базовые правила — говорить/писать честно, не винить в ошибках людей и тд
Первый раздел ретро обычно вызывает самые большие затруднения. Чем он проще, тем быстрее команда включится в работу. Например, это может быть описание спринта/проекта/настроения одним словом. Вообщем что угодно, но очень коротко. Ограничение времени — 1 минута. Ставьте таймер и не давайте выйти за лимит.
Когда время закончилось/все участники отписались — откройте карточки и зачитайте их. Поступайте так в конце каждого раздела ретро
Не забываем озвучивать хорошее, но без фанатизма, 3-4 минуты должно хватить
Сделали, зачитали, обрадовались и поехали дальше, к главным разделам
То ради чего все собрались — где можно стать лучше. Самый сложный и важный этап. Все любят говорить о хорошем, а вот о том что не получилось или идет плохо — возникают психологические барьеры. На этом этапе важно:
Анонимность, самостоятельная работа и установленные в начале правила успешно решают эти задачи
Наверняка проблем будет больше пяти. Вероятней всего все сразу решать не нужно, нет смысла их обсуждать. Приоритизация важна, поэтому голосуем за самые важные проблемы.
Не забывайте мержить карточки с одинаковыми проблемами (а они точно будут), иначе голоса размажутся. В funtretro для этого есть механизм drag’n’drop тикетов
Что нам нужно для объективного голосования?
Когда все проголосовали — выбираем топ-3(±1) проблем и начинаем заключительный этап
Переходим от самостоятельного заполнения тикетов к обсуждению голосом. Поочередно берем проблемы из топа и начинаем искать решение
Типичная ошибка формулировки решения:
Проблема — заказчик недоволен скоростью работы команды
Решение — давайте работать быстрее!
Это не конкретное действие, а лозунг. Не надо так
Выделите на этот раздел 35-50% процентов всего времени ретро. Он самый важный для достижения результатов и требует повышенного внимания модератора встречи, так как здесь участники общаются голосом, а не самостоятельно заполняют тикеты
Благодарим участников встречи, проговариваем что нужно сделать и примерные даты следующего ретро.
В идеале можно собрать фидбэк о ретро у команды и попробовать провести его еще лучше в следующий раз
Все перечисленное применялось в проектах, связанных с разработкой, однако ретроспектива — это универсальный инструмент, актуальный в любых проектах
Тратьте время ретро с умом и приносите пользу своей команде
PS если статья получит положительный отклик — я подготовлю аналогичный материал про проведение демо спринта