Бөлісу құралы:

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

  • Мақала

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

Внесли свой вклад Джесси Houwing, Visual Studio devops Ranger и старший консультант, работающий в Avanade Нидерланды.

Советы для успешных собраний

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

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

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

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

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

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

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

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

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

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

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

Например, рассмотрим ограничение ошибки из трех ошибок на инженера. Таким образом, команда из 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 уделяется состоянию работы, которую необходимо передать от одного участника команды другому участнику команды.

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

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

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

Контрастирует с этим следующим примером:

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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