Толпа: хороший метод только для подходит “к полному рабочему дню на спринтах” разработчики? [закрытый]

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

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

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

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

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

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

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

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

Я думаю, вам стоит попробовать scrum и посмотреть, стоит ли оно того.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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