Я был назначен ответственным за внедрение Scrum в моей команде разработчиков. К сожалению, компания, с которой я работаю, имеет довольно устаревшую структуру, которая плохо сочетается с этим фреймворком. Команда работает над проектом, который используют/зависят несколько других команд. Помимо наших собственных целей, у нас есть неожиданные запросы на функции, интеграцию, поддержку или исправление ошибок. Некоторые из них можно занести в Бэклог и ждать своей очереди, а некоторые необходимо обрабатывать как можно скорее, или «в режиме реального времени», как выразился один из наших клиентов.
Ситуация далека от идеальной, и я, как скрам-мастер, не в силах защитить команду от такой работы. Я пытаюсь извлечь максимальную пользу из ситуации, в которой мы оказались, и извлечь из Scrum как можно больше.
Мой первый вопрос: как обрабатывать такие запросы в рамках Scrum?
Я не сторонник создания отдельной пользовательской истории «ведро запросов» — она либо скрывает объем проделанной работы, либо искусственно увеличивает скорость.
Имеет ли смысл манипулировать Бэклогом Спринта в таком широком масштабе? Иногда нам приходилось перемещать более половины нашего текущего Бэклога Спринта обратно в Бэклог Продукта, чтобы освободить место для всех запросов по требованию.
Возможно, мой первоначальный вопрос следует заменить на - есть ли способ справиться с такой ситуацией в рамках Scrum?
Если нет возможности сделать это разумным образом — есть ли другие Agile-фреймворки, которые могли бы помочь?
Ретроспектива, ретроспектива и еще раз ретроспектива. Хотя проблема, которую вы описываете, существует в той или иной степени в большинстве скрам-команд, не соглашайтесь на временное решение. Сначала поймите, дайте количественную оценку и сделайте прозрачным влияние на вашу скрам-команду. Иногда лучше обойтись без обезболивающих...
Создание резерва, будь то с помощью планирования на основе скорости или мощности, не является истинным решением, а просто реакцией / болеутоляющим средством для уменьшения проблемы, которая поначалу может показаться слишком внешней для решения.
Как скрам-мастер, вы должны чувствовать себя способным решать глубокие и/или долгосрочные организационные проблемы за пределами непосредственной команды (команд), в которой вы работаете. Почему поступает так много специальных запросов? Есть ли шаблон, организационная структура (структуры) или определенные люди, которые агитируют за этот вопрос? Используйте ретроспективы с вашей командой в сочетании с вашим временем, потраченным на навигацию и понимание организации, чтобы добраться до реальных основных причин возникновения проблемы.
Ашок предлагает одно решение более глубокой проблемы, которая звучит как отсутствие планирования и координации между командами на более высоком уровне. То, как вы решите эту проблему, будет зависеть от вашей организационной структуры и основных причин, которые вы определите.
Недавно у меня была точно такая же ситуация, которую вы описываете. Хотя я не являюсь Скрам-мастером в своей команде, я был единственным человеком в команде, который ранее использовал какие-либо методы Скрама. Чтобы решить проблему срыва плана Спринта, мы приняли метод, который мы называем «Бэтмен», который после некоторой настройки действительно сработал для нас.
Каждую неделю один разработчик — «Бэтмен». Они не выполняют никаких задач Sprint, а вместо этого доступны для выполнения «любой работы», всех этих исправлений ошибок, внезапных запросов и «вещей, которые должны быть выполнены сейчас, пожалуйста». Хотя человек, который является Бэтменом, меняется каждую неделю, всегда есть «Бэтмен», доступный для общих запросов. Наша небольшая команда меняет список так, что каждый разработчик проводит одну неделю в роли Бэтмена, а затем две недели занимается задачами спринта. Мы идентифицируем Бэтмена, буквально помещая фигурку Бэтмена на стол человека, исполняющего роль. Это позволяет коллегам очень легко правильно определить, кто может им помочь. Любой человек может подойти к Бэтмену и описать свою проблему или просьбу.
В (маловероятном) случае, когда таких запросов не существует, Бэтмен может взять из бэклога небольшие задачи или заняться очисткой кода/документацией/другими вещами, которыми обычно пренебрегают. Любые задачи, которые выполняет Бэтмен, по-прежнему приводят к созданию заявок в нашей системе заявок и «втягиваются в Sprint», чтобы мы могли отслеживать работу, однако мы присваиваем всем заявкам «Бэтмен» нулевое значение сюжетных баллов. Это связано с тем, что мы не учитываем задачи Бэтмена в наших оценках спринта. Мы используем JIRA для нашей системы продажи билетов, и хотя наша диаграмма «Изменение объема» показывает неутешительно высокие значения, в конечном итоге это не оказывает негативного влияния на нашу оценку или планирование спринта. Поставив ярлык на «BatTasks» и назначив им ноль очков истории,
Наши Спринты длятся две недели, поэтому в случае, если Бэтмен является особенно плодовитым разработчиком, мы не навредим Спринту, сделав их недоступными на весь Спринт. Мы также обнаружили, что целая неделя обработки случайных быстрых запросов — это примерно столько, сколько мы можем обработать за раз, прежде чем вернуться к комфорту и структуре работы Sprint. Также очень важно, когда время Бэтмена истекло, он должен прекратить работу над своими задачами Бэтмена и передать полное описание любых незавершенных задач. То же самое относится и к работнику Sprint, переходящему на Batman — ему нужно иметь возможность быстро передавать любые задачи, над которыми он работал. Критически важно иметь хорошую документацию по вашей работе, когда вы работаете, и я думаю, что как команда наши навыки документирования в задаче и способность быстро передавать задачи другому разработчику улучшаются. Это отличное умение также для тех, кто собирается в отпуск, неожиданно заболел и т. д.
Еще одно преимущество, которое мы обнаружили, заключается в том, что коллеги теперь прерывают только одного человека, а не отвлекают разработчиков, сосредоточенных на задачах Sprint.
Мы также попробовали несколько неудачных вариантов этого подхода. Мы пробовали иметь одного «Бэтмена» один день в неделю (это было недостаточно) и пробовали, чтобы вся команда разработчиков выступала в роли «Бэтмена» один день в неделю (тоже недостаточно). Из-за частоты поступающих запросов мы обнаружили, что постоянное присутствие «Бэтмена» на связи хорошо работает для нашей команды. Важно то, что мы пробовали каждую попытку и продолжали настраивать процесс в соответствии с нашими потребностями, прежде чем сдаться.
Идея, которую мы рассмотрели, заключалась в том, чтобы назначить «Робин», который будет работать над задачами спринта, но при необходимости Бэтмен может вызвать его на помощь, если нагрузка станет слишком большой. Мы еще не пробовали этот подход, но мне нравится его идея.
Один интересный побочный эффект этого подхода заключается в том, что Бэтмен в конечном итоге подвергается воздействию многих различных аспектов нашей системы. Как команда, это значительно расширило общие знания о кодовой базе и помогает всем нам лучше познакомиться с областями нашего кода, с которыми мы раньше не сталкивались.
Если такого рода перерывы действительно неизбежны, мой совет — составить план команды и выделить на них время. Во время совещания по планированию спринта каждый член команды должен рассчитать свои возможности (в часах) для нового спринта. Если вы знаете или можете рассчитать количество времени, которое команда тратит на другую работу, вычтите это из емкости. Или вместо того, чтобы планировать на 100 %, попробуйте планировать на меньшую мощность (может быть разной для каждого члена команды в зависимости от того, как часто они отвлекаются на другую работу), зная, что, если перерывов не будет, команда всегда может привлечь дополнительные ресурсы. пользовательские истории.
Некоторые виды работ, такие как производственные ошибки, нельзя планировать, и их можно обрабатывать только так, как предложил @JillSanderson.
Однако у вас, похоже, есть и другие срочные дела:
Команда работает над проектом, который используют/зависят несколько других команд.
Этот вид работ можно планировать. Просто ваша команда не будет в курсе до конца цикла. Ваш владелец продукта (PO) должен постоянно работать с другими командами, чтобы определить любую работу, которую они планируют отправить вам. Со временем он/она должен попытаться убедить другие команды выполнить скользящее опережающее планирование :
Хотя почти все способы решения вашей проблемы уже были описаны, я решил написать свой ответ, чтобы добавить немного организации и ссылок.
Хенрик Книберг в своей книге «Scrum and XP from the Trenches» описывает четыре типичных действия для решения вашей проблемы:
«Слишком много внешних помех»
Типичные действия:
попросите команду уменьшить фактор фокусировки в следующем спринте, чтобы у них был более реалистичный план.
попросите команду лучше записывать нарушения в следующем спринте. Кто мешал, сколько времени это заняло. Позже будет легче решить проблему.
попросите команду попытаться направить все беспокойства скрам-мастеру или владельцу продукта.
попросите команду назначить одного человека «вратарем», все помехи перенаправляются на него, чтобы остальная часть команды могла сосредоточиться. Это может быть Scrum-мастер или ротационная позиция.
Давайте рассмотрим эти варианты:
Попросите команду уменьшить фокус-фактор в следующем спринте, чтобы у них был более реалистичный план.
Это то же самое, что и ответ @JillSanderson . Но, на мой взгляд, лучше использовать фокус-фактор, а не уменьшать мощность. Дает абсолютно тот же эффект (уменьшение скорости), но более логично.
«Фактор фокуса — это оценка того, насколько сосредоточена команда». Более неожиданные «внешние» задачи означают меньший фокус-фактор. Таким образом, вы должны учитывать фактор фокуса в прогнозе спринта.
Этот подход имеет одно ограничение. Фокус-фактор (количество «внешних» задач) должен быть примерно одинаковым . В противном случае прогноз количества задач в Sprint становится бессмысленным.
Попросите команду лучше записывать нарушения в следующем спринте. Кто мешал, сколько времени это заняло. Позже будет легче решить проблему.
Это почти то же самое, что и ответ @WBW . Соберите всю необходимую информацию во время спринтов, проанализируйте ее во время ретроспектив, найдите корень проблем и постарайтесь их устранить. Возможно, стоит повысить качество кода специальными инженерными приемами (или улучшить тестирование), чтобы не тратить столько времени на исправление ошибок. Или, возможно, вам следует делегировать часть работы другой команде. Или улучшите планирование, чтобы уменьшить количество неожиданных функций от клиента. Или что-то другое. Трудно дать конкретный совет, потому что это зависит от многих факторов. Ваша задача как руководителя группы — найти и устранить эти проблемы.
Основным ограничением этого подхода является то, что устранение корней некоторых проблем не всегда возможно. В теории все хорошо, но в реальном мире нам часто не хватает сил, чтобы все исправить.
Попросите команду попытаться направить все беспокойства мастеру схватки или владельцу продукта.
Что ж, это правда, что Владелец Продукта и (особенно) Скрам-мастер должны быть «щитом» для Команды Разработки.
Ограниченность такого подхода очевидна. Как мне уже говорили, у Скрам-мастера может не хватить полномочий, чтобы хорошо защитить Команду Разработки от непредвиденных задач по требованию. С другой стороны, требования бизнеса всегда гораздо важнее для Владельца Продукта, чем правила Scrum.
Попросите команду назначить одного человека «вратарем», все помехи перенаправляются на него, чтобы остальная часть команды могла сосредоточиться. Это может быть Scrum-мастер или ротационная позиция.
Это ответ «Бэтмен» , предоставленный @Aurora.
Хорошее решение с двумя ограничениями. 1) Количество неизбежных задач должно быть не слишком большим для "Бэтмена". 2) В команде разработчиков должно быть более 3 человек, иначе вместимость (в процентах) сильно уменьшится.
В любом случае наличие посторонних задач в Sprint противоречит Scrum. Это будет ScrumBut (не чистый Scrum).
Также вы можете ознакомиться с другими методологиями:
Экстремальное программирование . Согласно этой методологии, заказчик может менять задачи во время итерации без каких-либо ограничений (правда, есть одно ограничение: если заказчик хочет добавить новую задачу в текущую итерацию, он должен удалить задачу (или задачи) с тем же объем).
Хитрость в том, что в экстремальном программировании стоимость изменений фиксирована. Эта методология предписывает множество методов, как это обеспечить. В свое время я пытался реализовать эту методику, но для нас это было слишком экстремально :-)
Канбан . Эта методология вообще не имеет итераций. Когда в вашем WIP (Work In Progress) есть свободное место, вы можете немедленно взяться за другую задачу. Если вам не нужны итерации, эта методология может быть лучшим выбором для вас.
Мне нравится история Бэтмена. Я просто добавлю, что вы должны быть строги в отношении того, что представляет собой настоящая чрезвычайная ситуация. Это могло быть срочно для пользователя, но если бы это было предсказуемо, они должны были поднять это через обычный процесс запроса.
Если вы небрежно относитесь к этому, они скоро схватятся и будут использовать это как способ ускорить процесс «приятно иметь».
Реальный пример. Однажды утром в понедельник мне позвонили из зарубежного офиса и попросили изменить их почтовый адрес. Я сказал им поднять тикет и спросил, когда это вступит в силу, чтобы я мог запустить его в производство в нужное время. Ответ: "О, сейчас. Мы уже переехали".
Это коротко и мило, но по моему опыту работы с фреймворком Scrum:
Преднамеренным следствием этого является то, что команда может (будет?) допускать задержку работы, если владелец продукта согласится отказаться от части работы в обмен на освобождение места.
Все хорошо, когда вся работа принадлежит одному и тому же PO, так как он / она просто должен решить, каков их приоритет. В случае, если работа принадлежит двум разным РО, то эти РО должны решить между собой, каков приоритет, и результат этого обсуждения решит, состоится ли обмен или нет.
Наконец, один из принципов Agile — приветствовать поздние изменения требований. Это не совсем та ситуация, которую вы описываете, но я думаю, что принятие поздних изменений приоритета также соответствует духу гибкости.
TLDR: да, люди могут прийти к вам с поздней высокоприоритетной работой, но бизнес должен признать, что для того, чтобы его можно было взять на себя, нужно отказаться от чего-то другого . Если ваш бизнес особенно склонен к этому, то, как только у PO были сорваны их спринты или их просроченные требования были отклонены несколько раз, они по необходимости улучшат управление своим невыполненным заданием!
(Полное раскрытие: я очень партийный и кровожадный кодер. :-))
Выйдите из коробки, есть альтернативы Scrum. Возможно, природа спроса не совсем подходит для Scrum-фреймворка. Вместо того, чтобы избивать свою команду до смерти обходными путями, просто попробуйте найти то, что работает для вас.
Например, в Канбане вы начинаете с того места, где вы есть, и постепенно совершенствуетесь. Вы можете получить зрелую настройку Канбана с планированием, партиями и так далее.
Нильс ван Реймерсдал