Чем обзор спринта отличается от ретроспективы

Ретроспектива по шагам. Рецепт

Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, «обучающих» материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.

Кто присутствует

Ретроспектива это в первую очередь мероприятие, направленное внутрь команды. Его решения — это решения для самой команды, и вырабатываться они должны внутри. Вполне допустимо на ретроспективу принести те самые две пиццы, использовать нецензурные выражения (но не друг на друга!), принести куклу большого начальника и/или заказчика. Важно, чтобы каждый член команды чувствовал, что он может высказать своё мнение, и это не то что не приведёт к какому-нибудь негативу, а ровно наоборот — будет использовано для пользы команде.

Поэтому на ретроспективе должны быть, с одной стороны, все члены команды, с другой — никаких больших начальников, секретарей, представителей заказчика и соседних команд. Ретроспектива — это не отчёт! Это не презентация! Это не спектакль, который команда играет для заказчика (в отличие от обзора спринта). Это внутреннее мероприятие команды, которое, в принципе, иногда можно даже заменять тим-билдингом. И возможно от этого даже будет больше пользы, чем от ретро.

Очень желательно на первых двух-трёх ретро присутствие профессионального скрам-мастера. Причём не сертифицированного, а именно профессионального, который не просто прошёл сертификацию и обучение, а применял свои навыки проведения ретроспектив на практике хотя бы год. При кажущейся простоте мероприятие очень просто сваливается в «не туда», и по его итогам даже не понятно, а почему и как это исправить.

В будущем проведение (фасилитацию) ретро можно передать члену команды, а через некоторое время выбирать нового фасилитатора для каждого нового ретро.

Когда

Ретроспектива должна проводиться регулярно. Вообще всё в Scrum должно делаться регулярно. И планирование, и обзор, и ретро. «Сила» методологии именно в том, чтобы превратить непредсказуемый творческий процесс разработки в предсказуемый и планируемый.

Ретро должно проводиться после обзора спринта. Чтобы на ретро команда могла обсудить в том числе и то, как результаты команды были представлены (успешно или нет) заказчикам. Ретро должно проводиться до планирования следующего спринта. Во-первых потому, что планирование следующего спринта, это уже следующий спринт, а во-вторых, потому что в числе результатов могут быть какие-то задачи, которые команда поставит самой себе. И они должны будут войти в следующий спринт.

Что нужно для ретро?

Если ретро проводится в «реальном мире», потребуются стикеры/листочки (по 6-10 штук на человека), ручки и доска с маркером.

В «виртуальном» мире достаточно обойтись расшаренным экраном с двумя/тремя блокнотами, либо одним экраном Confluence / MS Word с тремя полями. Условно их пока можно назвать «плюсы», «минусы» и «действия».

Для целей геймификации можно использовать онлайн-инструменты типа fun retro / easy retro, но пока что ни один из этих инструментов не вписался в тот рецепт, который будет описан ниже.

Будучи хорошим начальником (или планируя им стать) — принесите на ретро орешков, конфет, печенек (*закадровое узнаваемое дыхание*), запланируйте общий ланч с пиццей без отрыва от «производства».

Начало ретро

В начале всем участникам команды раздаётся задание. Нужно придумать и записать (пока что в тайне от других членов команды — это важно):

(+) Не менее N таких вещей, которые им понравились в текущем спринте, и которые они не хотели бы терять в процессе предлагаемых в рамках ретро изменений.

(-) Не более N таких вещей, которые не нравятся, и хотелось бы поменять.

Не нужно пытаться «оптимизировать» процесс и просить членов команды записать эти пункты заранее в качестве домашнего задания. Всё равно им придётся на это тратить время, верно? Пусть лучше потратят его все сразу в одном месте, не мучаясь угрызениями совести за несделанную домашнюю работу и без смущающих взглядов коллег, которые были такими замечательными, что сделали заранее (читай — за 5 минут до встречи, отвлекаясь от какой-нибудь скучной еженедельной встречи).

Сначала про «плюсы». Этот пункт важен, хотя бы для закрепления того, что команда сделала хорошо. Похвалить самих себя — тоже важно. Наверное это подтвердит любой психолог. Граница снизу здесь нужна, чтобы каждый член команды заставил себя, во-первых, вспомнить прошедший спринт, а, во-вторых, включился таким образом в ретроспективу. «Не хотим терять» — это важная подсказка. Например она сразу отекает такие вещи, которые не зависят от команды. Нет смысла обсуждать возможность удалённой работы, если не команда решает этот вопрос. Или есть смысл упомянуть, как нравится текущий CI и быстрое прохождение ревью, ведь именно от команды (обычно) он и зависит.

Другое важное назначение «+»-пунктов, это возможность позже, когда будут предлагаться действия по решению проблем (action point’ы), выбирать те из них, которые минимальным образом будут влиять на то, что команда не хочет потерять.

Важно, чтобы плюсы и минусы записывались на листочках независимо друг от друга. Тем самым мы избавляемся от «проблемы +1», когда люди вместо раздумывания над проблемой просто присоединяются к чужому ответу (аналогичная ситуация происходит, например, при планировании, от чёго защищает «слепое» покер-планирование).

Минусы. В идеале нужно, чтобы участники сразу записали что им не нравится. Не action point, не то, что они предлагают сделать, а то, что им непосредственно мешает в работе. Но в принципе на первые 4-6 ретроспектив достаточно, чтобы участники хоть что-нибудь записали. А далее ведущий уже вытянет из них всю правду (*дьявольский смех за кадром*).

Вполне можно и допустимо сюда писать что-то, что на первый взгляд кажется «внешним» по отношению к команде. Потому что потом на детальном разборе может оказаться, что при внешней причине мы можем что-то поправить в процессе внутри команды.

Анализ

Начинаем с плюсов. Тут можно просто выписать их в первую колонку (наклеить стикеры), при возможности сгруппировав их для удобства наблюдения и красивого представления вышестоящему начальству. Просто пока помните, что эти плюсы — это что ваша команда хочет сохранить хотя бы на следующий спринт и не потерять при выполнении action point’ов.

Минусы. Самый сложный этап. Игра в доктора «наоборот».

Берём каждый стикер (присланный нам в персональные предложения пункт) и. не записываем его. А проверяем, что данный пункт описывает симптом, а не болезнь. Почему? Потому что потом мы должны будем предложить такое решение, которое будет наиболее эффективным способом избавиться от симптома. И «лечение» самой болезни может быть одним из, но не самым эффективным (с точки зрения усилий и времени) способом. Кроме того, данный симптом может быть вызван несколькими причинами, и возможно только одну из них нужно будет убрать, и это вовсе не та, которую изначально назвал член команды.

Ещё раз. Каждый пункт надо записать в виде симптома, а не болезни (и точно не в виде action point’а). Например. Член команды записывает на стикере «у нас неоптимальный CI-скрипт«. Если оставить как есть, единственным возможными способом решения данной проблемы будет, очевидно, переписать CI-скрипт. Но нужно ли?

Уточняем у члена команды, «[Олег], на что в твоей работе влияет то, что CI-скрипт не оптимален»? Внезапно оказывается, что:

• скрипт медленно работает
  • медленная работа приводит к медленному прохождению pull request’ов
    • невозможность распарраллелить работу приводит к простою
      • это приводит к медленной работе члена команды
      • это приводит к необходимости ручного перезапуска CI
        • это приводит к медленной работе члена команды

        На каком шаге остановиться — сказать сложно. Но в любом случае каждый следующий шаг описывает более общую проблему. В целом все пункты так или иначе сводятся к одному конкретному — «замедление работы команды». Поэтому тут важно остановиться где-то за 1-2 пункта до этого.

        Но зато для каждого следующего более общего уровня можно предложить самые разные варианты решения проблем:

        • поставить больше CI-агентов для сборки и распараллелить его работу / сборку / разрешить параллельную работу нескольких сборок одновременно
        • поставить посильнее машину для CI
        • выкинуть часть действий из CI-скрипта, не переписывая его кардинально
        • полностью переписать CI-скрипт
        • научить пользователя переключаться между ветками в git, позволив ему распараллелить работу и не ждать CI
        • сделать простой скрипт для перезапуска failed-сценариев 2-3 раза

        Но пока что возможный список даже не озвучиваем. Но мы должны (из своего опыта) как-то понять, что именно та формулировка, которая будет записана, может, хотя бы в теории, быть решена несколькими разными способами. И вот именно эту формулировку и надо записать в «минусы».

        Кроме того, более обще записанная формулировка имеет больше шансов пересечься с «минусом» от другого участника. А это хорошо — значит у нас не 30 разных проблем, а, скажем, 7-10 (сгруппированных). К этому и надо стремиться.

        Очень важно при попытке вытащить из члена команды более общую проблему не задавить его авторитетом и не подложить свою проблему вместо его. Все мы люди, все мы субъективны, и можем увидеть в чужой проблеме вовсе не то, что беспокоит члена команды, а что беспокоит нас самих. Уметь оставлять свои проблемы в стороне и слушать (и слышать) другого человека, наверное, самое важное для того, кто собирается в IT работать с людьми. Но это очень и очень сложно. Ничего страшного, если Вас по началу будут поправлять и говорить, «нет, это вовсе не то, что меня беспокоит, меня беспокоит другое». Замечательно, если Вам будут это говорить. Гораздо хуже, если с Вами молча согласятся, чтобы не спорить и побыстрее закончить.

        Голосование

        Изначально считаем, что за каждый пункт подано столько голосов, сколько изначальных «минусов» было сгруппировано в него. Далее я предлагаю членам команды проголосовать дополнительно за 1 или 2 пункта (из сгруппированных 7-10), Но только за те, в которых нет пунктов, которые они формулировали сами (или в которые были переформулированы их «минусы»).

        В результате формируется отсортированный «по голосам» список проблем.

        Блиц-этап

        На данном этапе включаем секундомер и предлагаем по 60 секунд на решение каждой проблемы, кроме Top3 (в любом порядке). В рамках этих 60 секунд можно предложить «быстрое» решение проблемы. Не важно, насколько сильно оно решает проблему, главное, чтобы хоть как-то решало. Если никто из членов команды не против предложенного решения, оно записывается в action point’ы. Если против — решение сразу же откидывается без обсуждения (время на обсуждение не тратится).

        60 секунд это скорее ориентир. На то, что не нужно тратить много времени на блиц-проблемы, которые не являются самыми больными местами в процессе.

        Перерыв на кофе

        Перед перерывом на кофе окончательно формулируем top3 проблем, которые нужно обсудить, и предлагаем членам команды пойти покурить/попить/выпить/отойти проверить почту.

        Обсуждение. Action Points

        Итак, у нас есть top3 проблем. Самые больные, самые серьёзные, самые мешающие команде. На каждую проблему хоть час обсуждения (поэтому ретро и занимает от 3-х часов). Как придумать возможные решения — не знаю. Однако, знаю, что делать с возможными решениями.

        Во-первых, не надо отбрасывать решения, которые не решают проблему целиком. Нас вполне устроят решения, которые решают проблему хотя бы частично. Хоть на 20%, но облегчают жизнь команды. Кто знает, может именно этих 20% хватит, чтобы в следующий раз проблему не включили в top3?

        Во-вторых, решения должны проходить валидацию у тех, чьи проблемы были изначально сгруппированы в единый «пункт симптомов болезни». Хотя бы один из них должен подтвердить, что предложенное решение действительно сделает его жизнь проще.

        В-третьих, формулировка. Формулировка должна быть такой, чтобы у команды был минимальный шанс не выполнить пункт.

        Плохой вариант

        Вариант получше

        Нужно устроить встречу и обсудить розовых единорогов

        [Олег] устраивает встречу во-вторник в 15 часов по обсуждению проблемы питания розовых единорогов

        Ответственно подходить к ревью pull request’ов

        — (или) при отклонении pull request’а оставлять комментарий
        — (или) настроить бота, назначающего PR на ревью на членов команды
        — (или) добавить в CI-скрипт автоматический линтер, а все проблемы в оформлении, которые им не покрываются не считать проблемами

        заранее формулировать тикеты в jira до планирования

        [Олег] заведёт в outlook еженедельный backlog grooming до планирования с участием владельца backlog’а, представителя аналитиков и solution-архитекторов смежных систем

        Полученные шаги записываются в action point’ы.

        Почему ретро может не помочь

        Может так случиться, что сделали всё по рецепту, а огонёк в глазах команды всё тусклее и тусклее, а производительность команды падает. Потому что автор этого текста ни хрена не знает. Ретроспектива в этом случае позволяет найти часть этих причин, и задуматься, почему эти причины до сих пор не исправлены.

        Признаками проблем являются:

        • Ретроспектива проводится за полчаса. Это не ретроспектива, это отчёт-доклад команды «как у нас всё хорошо, как здорово и дружно мы живём, дорогой дедушка Ленин«. Явный признак того, что мероприятие проводится для галочки, без той пользы, которую могло бы принести полноценное ретро.
        • Повторяющиеся в две-три ретроспективы похожие описания проблем. Команда предполагает, что теоретически эти проблемы можно было бы попытаться решить какими-то действиями внутри команды. Может быть даже предлагает action point’ы.Но в какой-то момент эти проблемы просто исчезают из анализа, потому что команда уже привыкла к тому, что высказывать их бесполезно. Но сами проблемы-то никуда не делись!
        • Если таких проблем много, то в какой-то момент появляются фразы «слишком много времени тратится на ретроспективы». Это прямо-таки прямой сигнал о том, что с ретроспективой всё плохо. И да, без изменения формата ретро далее проводить бессмысленно.
        • Невыполненные action point’ы (при том, что проблема не ушла). Возможно они были очень неудачно сформулированы. А возможно тот, кто должен был их выполнить, забыл/забил/не захотел их делать.

        Самой большой проблемой является понять, что у нас вас проблемы. Вы можете спокойно смотреть на красивые отчёты о ретроспективах в confluence, показывать начальству, а члены команды почему-то не хотят на них ходить. Моя рекомендация — приглашайте на ретро раз в полгода кого-то со стороны. Не начальника, а методолога, коллегу из параллельной (или далёкой) команды. Возможно пригласить даже его сразу как фасилитатора — попробуйте формат ретроспективы от другой команды. Пусть её проведёт тот, кто не привык к вашему формату.

        • scrum
        • agile
        • ретроспектива
        • управление проектами и командой
        • Управление проектами
        • Agile
        • Управление продуктом

        Обзор спринта и ретроспектива спринта

        

        Обзор спринта — это неформальная встреча, на которой присутствуют команда разработчиков, скрам-мастер , владелец продукта и заинтересованные стороны. Команда проводит демонстрацию продукта и определяет, что готово, а что нет. Цель встречи по обзору спринта состоит в том, чтобы команда показала клиентам и заинтересованным сторонам работу, которую они выполнили в течение спринта , и сравнила ее с обязательством, данным в начале спринта.

        Обзор спринта и ретроспектива спринта

        Каждый спринт заканчивается совещанием по обзору спринта, состоящим из двух частей. Такая встреча начинается с обзора и демонстрации клиентам и заканчивается ретроспективой команды . Оба этих компонента происходят в последний день спринта.

        Обзор спринта фокусируется на «проверке» и «адаптации» инкремента (потенциально подлежащего отправке), в то время как ретроспектива спринта уделяет больше внимания «проверке» и «адаптации» процесса спринта.

        

        Обзор приращения спринта

        Скрам — команды будут просить клиентов проверить, соответствует ли продемонстрированная работа (потенциально подлежащая отправке) определению выполненной на данный момент, или иногда некоторым клиентам может потребоваться некоторое время, чтобы использовать приложение в течение некоторого времени до принятия. Цель встречи — прозрачно рассмотреть и определить статус работы, выполненной в спринте:

        • было сделано
        • не было сделано
        • работа, которая была добавлена
        • И работу убрали из спринта

        Он предлагает время, чтобы задать вопросы, сделать наблюдения или предоставить отзывы и предложения, а также обсудить, как лучше всего двигаться вперед в данных текущих реалиях.

        Продолжительность обзора спринта

        Обзор спринта может длиться до 4 часов в 4-недельных спринтах. Общее правило состоит в том, что обзор спринта должен занимать не более одного часа в неделю продолжительности спринта. Следующая таблица иллюстрирует это правило.

        Общая продолжительность спринтаПродолжительность обзора спринта1 неделя1 час2 неделя2 часа3 неделя3 часа4 неделя4 часа

        Шаблон совещания по обзору спринта

        Существует множество способов проведения обзора спринта. В приведенной ниже повестке дня собрания по обзору спринта описываются действия в рамках типичного собрания по обзору спринта:

        1. Старт — Начинается обзорная встреча по спринту
        2. Приветствуем заинтересованные стороны — Владелец продукта приглашает заинтересованные стороны принять участие в обзоре.
        3. Представить повестку обзора — Владелец продукта представляет повестку дня обзора спринта.
        4. Представление обновлений продукта — команда разработчиков представляет демонстрацию продукта, реализованного в спринте.
        5. Получите обратную связь — Владелец продукта запрашивает у заинтересованных лиц отзывы о выпущенном продукте.
        6. Представление бэклога продукта — Владелец продукта представляет верхнюю часть бэклога продукта заинтересованным сторонам, чтобы получить отзывы о предстоящих спринтах и ​​запросить отзывы заинтересованных сторон, связанные с бэклогом.
        7. Встреча завершена

        использованная литература

        • Что такое обзор спринта?
        • Что такое ретроспектива спринта в Scrum?

        Ретроспектива Спринта (Sprint Retrospective)

        Ретроспектива Спринта — это одно из 5 Мероприятий Скрама, дающее Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием следующего спринта. В нем принимает участие вся Скрам-команда.

        Руководство по Scrum 2020 следующим образом описывает цель и содержание Ретроспективы:

        1. Цель — запланировать повышение качества и эффективности.
        2. Скрам-команда инспектирует то, как прошел последний Спринт в отношении людей, взаимодействий, процессов, инструментов и Критериев Готовности. Инспектируемые элементы зависят от характера выполняемой работы и могут быть очень разными.
        3. Выявляются предположения, которые сбили команду с пути, и исследуются их причины. Скрам-команда обсуждает, что прошло хорошо во время Спринта, с какими проблемами она столкнулась, и как эти проблемы были (или не были) решены.
        4. Скрам-команда определяет улучшения в процессе своей работы, наиболее полезные для повышения эффективности. Такие улучшения затем реализуются в кратчайшие сроки. Они могут даже быть
           добавлены в Бэклог следующего Спринта.

        Для Спринта длиной в месяц эта встреча ограничивается 3 часами. Для более коротких Спринтов она обычно короче.

        Ретроспектива Спринта — командообразующая встреча, весьма непростая для проведения. Поэтому ее обычно фасилитирует Скрам-мастер. На Ретроспективе ведутся откровенные разговоры, в том числе, о неприятных вещах; проходят сложные мозговые штурмы. Если из раза в раз встреча будет оставлять чувство неудовлетворенности у команды, а ее результаты не будут реализовываться в следующих Спринтах, команда будет демотивироваться.

        Типичная Ретроспектива включает ответы участников Скрам-команды на следующие вопросы:

        • Что за прошедшую прошедший спринт было хорошо и помогало тебе работать?
        • Что тебе мешало работать?
        • Что или кто может тебе помочь работать лучше?

        Эти ответы так или иначе визуализируются, а далее служат основой для генерации новых практик и правил, влияющих на процесс работы команды.

        Однако если каждый раз Ретроспектива будет проходить в одном и том же формате, это быстро наскучит людям. Кроме того, далеко не всегда такие прямолинейные вопросы позволяют получать откровенные ответы и вскрывать реальные проблемы. По этим причинам Скрам-мастера стараются разнообразить формат обсуждений на Ретроспективе, используя десятки различных техник.

        Варианты проведения каждого из 5 этапов ретроспективы вы можете посмотреть в этих видео:

        Больше по теме «События и активности»:

        Одно из 5 Мероприятий Скрама. Эта встреча длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. В нем принимают участие все разработчики. На нем озвучивается информация для оценки прогресса и отмечаются препятствия. В результате разработчики могут прийти к необходимости перепланирования работы внутри Спринта.

        Одно из 5 Мероприятий Скрама. Проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Скрам-команда, при необходимости, сделала адаптацию Бэклога Продукта. Для Спринта длиной в месяц Обзор Спринта длится не более 4 часов.

        Одно из 5 Мероприятий Скрама. На этой встрече Скрам-команды происходит планирование работы на следующий Спринт. Для Спринта длиной в месяц встреча длится не более 8 часов. Она завершается созданием Бэклога Спринта и включает обсуждение 3-х тем:

        • Почему этот Спринт ценен?
        • Что может быть сделано в этом Спринте?
        • Как будет выполняться выбранная работа?

        Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.

        Активность, которая проводится Владельцем Продукта при участии всех членов команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
        Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
        Уточнение бэклога обычно занимает не более 10% времени Скрам-команды в Спринте.

        Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

        • Что мы делаем
        • Наша команда
        • Блог
        • Контакты
        • Расписание тренингов
        • Карта тренингов
        • Сертификации
        • Обучение Scrum Master
        • Обучение Product Owner
        • Обучение Kanban
        • Услуги для компаний
        • Тренинги для групп от 10 чел.
        • Кейсы клиентов

        Обзор Спринта (Sprint Review)

        Обзор Спринта — это одно из 5 Мероприятий Скрама, которое проводится в конце Спринта, перед Ретроспективой. В нем принимает участие вся Скрам-команда и лица, заинтересованные в продукте.

        Заинтересованные лица проводят инспекцию Инкремента продукта и дают обратную связь по нему, а Скрам-команда, при необходимости, делает адаптацию Бэклога Продукта.

        Руководство по Scrum 2020 следующим образом описывает цель и содержание Обзора Спринта:

        1. Цель — инспекция результата Спринта и выявление возможностей для адаптации.
        2. Скрам-команда демонстрирует результаты своей работы ключевым заинтересованным лицам, и
           обсуждает прогресс в достижении Цели Продукта.
        3. Скрам-команда и заинтересованные лица анализируют, что было достигнуто по итогам
           Спринта, и что изменилось в окружении, влияющем на продукт. На основе этой информации участники совместно решают, что делать дальше.
        4. Бэклог Продукта может быть скорректирован с учетом новых возможностей и обнаруженных препятствий.
        5. Обзор Спринта — это рабочая сессия, которая НЕ сводится к презентации.

        Обзор является предпоследним мероприятием Спринта и ограничен по времени максимум
        четырьмя часами для одномесячного Спринта. Для более коротких Спринтов эта встреча обычно короче.

        Эта встреча — своеобразная проверка: правильно ли Скрам-команда поняла, что заказывали заинтересованные лица и правильно ли они сами определили, что ему надо. Второе определяется гораздо лучше, когда команда показывает им Инкремент продукта, в идеале — дает возможность попользоваться им в режиме реального времени.

        Рекомендуется, чтобы демонстрацию Инкремента проводили все или многие разработчики (а не один человек, выделенный командой для этого), чтобы повысить уровень командной ответственности, а также избежать искаженного понимания Инкремента заинтересованными лицами.

        Обзор Спринта — это не отчетное мероприятие, а конструктивный и откровенный партнерский диалог между Разработчиками, Владельцем Продукта и заинтересованными лицами.

        Например, Целью Спринта была форма регистрации.

        • В этом случае (после краткого напоминания всем Бэклога Спринта, которое обычно делает Владелец Продукта) несложно попросить самих заинтересованных лиц зарегистрироваться/войти через новую форму и высказать свои впечатления.
        • Если что-то не удобно (например, незаметна возможность восстановить забытый пароль) или чего-то не хватает (например, нет регистрации через ту социальную сеть, которая важна для целевой аудитории продукта), то Скрам-команда при активном участии Владельца Продукта предлагает, как можно отразить в Бэклоге Продукта изменения, необходимые для устранения важных замечаний.
        • На эти предложения от заинтересованных лиц поступает обратная связь, обычно с указанием приоритетов: что важно (и почему важно), а что не является критичным.
        • Владелец Продукта может учесть эту обратную связь добавлением в Бэклог Продукта новых элементов, а также перемещением в верхушку Бэклога важных/срочных элементов (например, интеграцию с нужной соцсетью), чтобы точно рассмотреть их на ближайшем Планировании Спринта.

        Больше по теме «События и активности»:

        Одно из 5 Мероприятий Скрама. Эта встреча длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. В нем принимают участие все разработчики. На нем озвучивается информация для оценки прогресса и отмечаются препятствия. В результате разработчики могут прийти к необходимости перепланирования работы внутри Спринта.

        Одно из 5 Мероприятий Скрама. На этой встрече Скрам-команды происходит планирование работы на следующий Спринт. Для Спринта длиной в месяц встреча длится не более 8 часов. Она завершается созданием Бэклога Спринта и включает обсуждение 3-х тем:

        • Почему этот Спринт ценен?
        • Что может быть сделано в этом Спринте?
        • Как будет выполняться выбранная работа?

        Одно из 5 Мероприятий Скрама. Ретроспектива Спринта дает Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием Спринта. Для Спринта длиной в месяц эта встреча ограничивается 3 часами.

        Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.

        Активность, которая проводится Владельцем Продукта при участии всех членов команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
        Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
        Уточнение бэклога обычно занимает не более 10% времени Скрам-команды в Спринте.

        Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

        • Что мы делаем
        • Наша команда
        • Блог
        • Контакты
        • Расписание тренингов
        • Карта тренингов
        • Сертификации
        • Обучение Scrum Master
        • Обучение Product Owner
        • Обучение Kanban
        • Услуги для компаний
        • Тренинги для групп от 10 чел.
        • Кейсы клиентов
        Похожие публикации:

        1. Бот максим как пользоваться
        2. Как поставить русификатор на игру в стиме
        3. Кто такой крок
        4. Синтезатор речи google что это за программа и нужна ли она