Scrum: хороший метод только для команд с разработчиками "full time on sprints"?

Ответ 1

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

В Планировании Спринта планируйте только то, что может быть достигнуто в соответствии с этим фокус-фактором: если у команды 600 часов на 80%, вы планируете только 480 часов.

Начальное значение может быть определено произвольно или на основе того, что было достигнуто во время предыдущего Sprint: запланировано 60 дней и 45 дней, дает коэффициент фокуса 75%.

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

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

Ответ 2

Я работаю в компании, где это тоже проблема. Мы пытаемся использовать Scrum, но имеем проблемы со следующим:

• Если есть важная проблема с поддержкой, мы должны отбросить все, что мы делаем, чтобы решить эту проблему, разрушая спринт.
• Менеджмент напрямую связан с некоторыми разработчиками с конкретными задачами, которые они хотели бы выполнить.
• У некоторых разработчиков есть определенные задачи, которые им нужно делать время от времени (называть его поддержкой для определенных старых продуктов).
• Иногда один из разработчиков удаляется из спринта, чтобы выполнить важную установку.
• Команды часто менялись, основываясь на идеях улучшения управления.

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

Тем не менее, я обнаружил, что вы получаете некоторые преимущества:

• Люди работают как команда и получают вдохновение и наделены этим.
• Задачи, которые все еще проходят через спринт, лучше, чем если Scrum/sprinting вообще не используется, поскольку цикл обратной связи намного короче, чем когда не выполняются спринты. Конкуренция заключается в том, что две недели - хорошее время.
• В течение долгого времени скорость, по-видимому, в среднем завышена, давая, по крайней мере, способность руководства иметь представление о том, как много работы можно сделать в течение более длительного периода времени.

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

Ответ 3

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

Ответ 4

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

Я думаю, вы должны попробовать схватку и посмотреть, стоит ли это.

Ответ 5

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

Мы еще не пробовали SCRUM, но я сделал несколько опытов здесь по многим способам его реализации, и лучшие результаты были тогда, когда в команду вошли люди из многих отделов (Test, QA, Implementation, Dev, Architecture, Маркетинг). Это подразумевает, что эти люди не имеют полного времени в команде, но тот факт, что у них есть задачи, возложенные на них в рамках текущего проекта, означает, что они обычно более охотно тратят на это время.

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

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

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

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

До сих пор этот процесс естественным образом развивался по типу scrum-XP-agile-TDD и медленно заставлял их избегать ужасного каскада, к которому они так прониклись. Надеюсь, со временем они поймут, что трава гораздо более зеленые на моей стороне забора: -)

Ответ 6

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

Поддержка по своей сути неплатежа для большинства мест. Обучение и предпродажная подготовка, как правило, несколько временны, так как в "Mr X проводит N дней с клиентом".

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

Мы видели хорошие результаты с этим.

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

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

Ответ 7

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

Ответ 8

Очень хороший вопрос. Я видел это выражение: "все члены должны быть полностью заняты" почти в каждой статье, статье, книге и т.д. У меня есть красный цвет на Scrum, но я не видел никаких аргументов в пользу того, почему это должно быть так. В крупных организациях я бы ожидал, что у вас будут разработчики, которые ничего не делают, но в небольших организациях должно быть очень распространено иметь разработчиков, которые не могут совершить 100% спринтов, а Scrum предназначен для небольших команд! Фокус-фактор должен иметь возможность справиться с этим, как и все остальное.

Ответ 9

Где я работаю, у нас есть разработчики, которые затягивают проект за такие вещи, как запросы поддержки, или команда ведет встречи о других проектах, поэтому есть моменты, когда кто-то может сказать "Non-project", поэтому сообщается, что это человек в настоящее время не участвует в Sprint.