Поделиться через

Scrum и рекомендации

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Собрания по планированию спринта

Большая часть планирования спринта включает в себя переговоры между владельцем продукта и командой, чтобы определить, на чем сосредоточиться и какую работу выполнить в предстоящем спринте. Удобно планировать собрание по времени, ограничивая его до 4 часов или меньше.

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

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

Кроме того, установка цели спринта в рамках ваших планирований может помочь команде сосредоточиться на самом важном в каждом спринте.

После планирования спринта вы можете поделиться планом с ключевыми заинтересованными лицами.

Дополнительные сведения см. в следующих ресурсах:

Установка целей спринта

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

Советы из траншей: определение целей спринта

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

Цели sprint могут быть ориентированы на функции, но могут также иметь большой компонент процесса, например автоматизацию развертывания или автоматизацию тестирования.

Рассмотрим пример.

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

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

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

внес Джесси Хоулинг, Visual Studio DevOps Ranger и старший консультант, работающий в Avanade в Нидерландах.

Советы по успешному проведению совещаний по сортировке

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

  • Определите критерии команды для оценки ошибок, которые необходимо исправить, и как назначить приоритет и серьезность. Ошибки, связанные с функциями высокой значимости, значительной упущенной выгодой из-за задержки или другими рисками проекта, должны быть присвоены более высокий уровень приоритета и серьезности. Сохраните критерии сортировки с другими документами команды и обновите их по мере необходимости.
  • Используйте критерии для определения ошибок, которые необходимо исправить и как задать их состояние, приоритет, серьезность и другие поля.
  • Настройте критерии сортировки на основе того, где вы находитесь в цикле разработки. На начальном этапе вы можете решить устранить большинство ошибок, которые вы отсортировали. Однако позже в цикле можно вызвать критерии триажа, чтобы уменьшить количество ошибок, которые необходимо исправить.
  • После того как вы провели сортировку ошибки, назначьте её разработчику. Затем разработчик может исследовать и определить, как реализовать исправление.

Управление техническим долгом

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

Советы из практики: управление ошибками

гибкое управление ошибками: не Оксюморон
Gregg Boer, главный руководитель программы, облачные службы Visual Studio в Microsoft

Устраняйте все известные технические задолженности по ошибкам в каждом спринте

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

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

Управление задолженностью по ошибкам на предприятии

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

Например, рассмотрим ограничение ошибки из трех ошибок на инженера. Таким образом, команда из 10 человек не должна иметь более 30 ошибок в ее списке ошибок. Если команда превышает свой лимит, ожидается, что она приостановит работу над новыми функциями и войдёт в предел ошибок. Ожидается, что команда всегда будет оставаться в установленном пределе, но она сама решает, как это сделать. Ограничение количества ошибок обеспечивает, что команды не несут задолженность по ошибкам слишком долго. Команда может научиться на ошибках, которые приводят к внедрению багов в первую очередь.

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

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

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

Отслеживайте работу по устранению технического долга в виде элементов бэклога продукта (PBIs), пользовательских историй или ошибок. Чтобы отслеживать прогресс команды в борьбе с техническим долгом, необходимо рассмотреть вопрос о классификации рабочего элемента и подробных сведений, которые вы хотите отслеживать. Вы можете добавить теги в любой рабочий элемент, чтобы сгруппировать его в категорию выбранного.

Роль мастера scrum

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

Основные обязанности мастеров Scrum включают:

  • Поддержка команды для внедрения и выполнения процессов Scrum. Например, вы не должны позволить ежедневному собранию Scrum стать открытым обсуждением, которое длится 45 минут.

  • Защита от добавления работы владельцем продукта или участниками команды после начала спринта.

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

  • Помогите команде решать конфликты и проблемы, которые возникают, и извлекать уроки из процесса.

  • Задавайте вопросы, которые выявляют скрытые проблемы и подтверждают, что то, о чем говорят люди, хорошо понято всей командой.

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

  • Запретить команде представлять неполные истории пользователей во время собрания спринта.

  • Сбор, анализ и презентация данных заинтересованным лицам для бизнеса, чтобы продемонстрировать, как команда улучшается и растет. Например, если ваша команда увеличила объем ценности, которую она предоставила, создавая меньше ошибок, сделайте ценность видимой посредством регулярных сообщений бизнес-заинтересованным лицам.

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

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

Ежедневные собрания Scrum

Ежедневные собрания Scrum помогают держать команду сосредоточенной на том, что он должен сделать на следующий день. Сосредоточенность помогает команде максимально увеличить способность выполнять обязательства по спринту. Мастер scrum должен применить структуру собрания и убедиться, что он начинается вовремя и завершается в течение 15 минут или меньше.

Ниже приведены три аспекта успешных собраний Scrum:

  • Все встают. Стояние помогает держать собрания сосредоточенными и короткими.
  • Они начинаются и заканчиваются вовремя и проводятся в одно и то же время в одном и том же месте каждый день.
  • Каждый участник команды участвует. Каждый член команды отвечает на три вопроса по Scrum:
    • Чего я сделал с последнего Scrum?
    • Что я могу достичь до следующего Scrum?
    • Какие проблемы или препятствия могут повлиять на мою работу?

Примечание.

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

Участники группы должны стремиться быстро и кратко ответить на свои вопросы. Рассмотрим пример.

Вчера я обновил класс, чтобы отразить новый элемент данных, который мы извлекаем из базы данных, и сделал так, чтобы он появился в интерфейсе. Эта задача завершена. Сегодня я гарантирую правильность вычисления нового элемента данных с помощью хранимой процедуры и других элементов данных в таблице. Я верю, что сегодня я могу выполнить эту задачу. Мне нужен кто-то, чтобы проверить мои вычисления. У меня нет препятствий или блокирующих проблем".

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

Посмотрите на следующий пример для контраста.

"Вчера я работал над классом, и он работает. Сегодня я работаю над интерфейсом. Нет блокирующих проблем".

Член команды не предоставляет достаточно подробных сведений о том, над каким классом он работал, и о компонентах интерфейса, которые он завершит. На самом деле, слово "accomplished" никогда не упоминалось.

Важно, чтобы никто не прерывал во время отчетного выступления. Каждый человек должен иметь достаточно времени, чтобы ответить на три вопроса.

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

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

Собрания спринт-ревью

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

На основе этого собрания некоторые истории пользователей принимаются как полные. Незавершенные пользовательские истории остаются в бэклоге продукта. Новые истории пользователей добавляются в невыполненную работу. Оба набора историй получают рейтинг и оцениваются или переоценены в следующем собрании по планированию спринта.

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

Спринт ретроспективные собрания

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

Ретроспектива спринта обычно происходит в последний день спринта, после обзора спринта. В этом собрании ваша команда изучает выполнение Scrum и что может потребоваться настроить.

На основе обсуждений ваша команда может изменить один или несколько процессов, чтобы повысить эффективность, производительность, качество и удовлетворенность. Это собрание и полученные улучшения критически важны для гибкого принципа самоорганизационности.

Примечание.

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

Обратите внимание на эти области в ходе ретроспективы спринта команды:

  • Проблемы, которые повлияли на общую эффективность, производительность и качество вашей команды.

  • Элементы, которые повлияли на общую удовлетворенность вашей команды и поток проектов.

  • Что привело к неполным элементам невыполненной работы? Какие действия могут предпринять команда, чтобы предотвратить эти проблемы в будущем?

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

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

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