Как обработать несколько проектов в малочисленной [закрытой] команде
5 ответов
AFAIK, основа Scrum заключается в том, что команда одновременно участвует в одном проекте. Независимо от методологии, накладные расходы на переключение задач делают очень неэффективной работу над несколькими проектами «параллельно».
Что вы могли бы сделать, так это попытаться запланировать разные проекты в отдельные спринты, то есть сделать спринт, полностью посвященный проекту 1, затем следующий спринт полностью на проекте 2 и т. Д. длина спринтов, например сделайте трехнедельный спринт над большим проектом, а затем, возможно, недельный спринт над маленьким.
В чистом Скраме продолжительность спринтов действительно высечена в камне, но опять же, ИМО, суть не в том, чтобы получить значок «чистого разработчика Скрама», а в том, чтобы получить реальный рабочий процесс для вашей команды.
(отказ от ответственности: я не мастер Scrum: -)
Обновление на основе комментария: Я вижу вашу проблему. Вам нужно быстро реагировать на небольшие запросы на поддержку (улучшение / исправление ошибок) от клиентов других продуктов, при этом все еще нужно работать над более крупным проектом предсказуемым образом.
Одна из возможностей - спринт спринтов большого проекта в Scrum, но «ограничить время» вашего времени для входящих задач поддержки. Например. если в среднем вы тратите 5 дней в каждом ежемесячном спринте на поддержку других проектов, вы выделяете 5 дней ресурсов (как бы вы ни считали время) на поддержку в каждом спринте.
Другой вариант может заключаться в рассмотрении других методов, таких как Канбан , где нет спринта или планирования, вместо этого команда работает исключительно (или в основном) на основе спроса со стороны клиентов.
Если у вас много мелких работ, которые нужно выполнять быстро, то управление проектами - неправильная парадигма. То, с чем вы имеете дело, - это управление операциями, которое, как правило, включает в себя четко определенные, проверенные и проверенные стандартные рабочие процедуры. Поэтому я предлагаю вам разделить с точки зрения управления те виды деятельности, которые требуют управления проектами, и те, которые требуют управления операциями. Если у вас еще не определены рабочие процедуры (и не опробованы и не протестированы и т. Д.), Возможно, вам придется создать проект для их разработки (или систематизировать их, если вы хотите думать о них таким образом).
Существует большая разница между тем, как проекты по разработке программного обеспечения (или должны) выполняться, и тем, как, скажем, работает служба поддержки. Тот факт, что вы разработчик программного обеспечения, имеющий опыт работы в парадигме управления проектами (как я думаю, большинство из нас), не означает, что это правильный подход ко всему.
После того, как вы сделали переход, вы обнаружите, что можете продолжать сокращать (или как там этот термин) над своими 1 или 2 проектами и поворачивать ручки машины, чтобы выполнить остальное.
Сложно. Возможно, ваша ситуация не совсем подходит для Scrum, но я думаю, что в Scrum есть элементы, которые применимы к вашей ситуации.
Например, единственное, что я считаю наиболее полезным в Scrum, - это ретроспективы, поскольку именно на этих сессиях вы улучшаете то, как вы работаете. Однако для того, чтобы сделать ретроспективы полезными, вам нужно измерить работу, которую вы выполняете, по некоторому набору пунктов, которые вы поставили перед собой. Так почему бы не устроить нечто похожее на спринты и не заняться планированием спринтов для элементов, которые вы собираетесь сделать в ближайшие 1-2 недели (более короткие недели кажутся более подходящими для вашего случая). Проводите ежедневные встречи Scrum, чтобы все трое знали, чем занимаются остальные, и могли подменить друг друга по мере необходимости. Затем после спринта вы можете сесть и подумать о том, как можно улучшить работу. Если ничего другого не остается, результаты ретроспективы покажут вам, сработало ли это для вас или нет.
Я не верю в попытку адаптировать строгую схему проекта Scrum, если это означает параллельное проведение спринтов или проведение более коротких спринтов только с одним проектом за раз, оставляя остальные нетронутыми раз в две недели.
Как вы справляетесь с одновременным запуском нескольких проектов в модели схватки? В большинстве случаев у нас есть как основные проекты, так и небольшие. Как эффективно комбинировать несколько спринтов?
Один из вариантов - запускать несколько спринтов параллельно и, даже если это не идеально, быть частью нескольких команд (очевидно, не на 100% посвященных). Я не уверен, что это имело бы смысл в вашем контексте, хотя я не уверен, что запуск небольших проектов с использованием Scrum добавляет ценности.
Другой (возможно, более подходящий) вариант - включить в список невыполненных работ по продукту элемент для работы, необходимой для вспомогательных проектов / задач, и, таким образом, выделить для них некоторое время. Если вам нужно это время, сожгите его. А если нет, просто возьмите несколько дополнительных элементов невыполненной работы из основного проекта в конце спринта.
Вам нужны спринты на 1 неделю. Только 1 проект за спринт. Это заблуждение, что вы можете доставлять программное обеспечение быстрее, работая над несколькими проектами одновременно. Для разработки релиза более крупного проекта может потребоваться несколько спринтов, тогда как, как и в случае с вашими маленькими, вы можете выпускать его после каждого спринта.
Если ваши проекты предназначены для разных заказчиков / клиентов, еще более важно, чтобы вы работали только над одним за раз; иначе ваши приоритеты почти всегда будут противоречить друг другу.