Как согласовать время разработчиков между двумя разными проектами в Scrum?

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

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

Я попытался выделить% времени разработчика для операционной работы, но, видимо, это не решает проблему. Мне интересно услышать от мастеров схваток, которые сталкивались с этой ситуацией раньше, как вам это удалось и каковы ваши рекомендации?

Эта проблема так же стара, как разборки. Есть решение, но оно тебе не понравится.

• Положите новые задачи в отставание.
• Не перебивайте разработчиков.
• Ждите следующего спринта.

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

Если вы попробуете подобные вещи, вы в основном вернетесь к методологиям разработки 'хаос' или 'JFDI' со всеми сопутствующими проблемами, например

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

Конечно, обычный ответ на этот совет: «Но я не могу этого сделать! Бизнес нуждается в исправлении этих производственных ошибок как можно скорее!»

Но это не совсем так.

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

Что более вероятно, хотя одно из следующего:

• Ошибки - операционные проблемы, нехватка места на диске, отсутствие аварийного восстановления, резервное копирование, отказоустойчивость и т. Д. Получите команду OPS.

• Ошибки - это пользователи, которые не понимают, как должна работать система «Это случилось! Это ошибка?». Получить справочную службу и обучить своих пользователей, написать документацию.

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

Просто пытаюсь мыслить нестандартно здесь.

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

Почему бы не попытаться предвидеть это и использовать это в своих интересах?

Вам понадобится команда из 5+, чтобы она была реалистичной, возможно.

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

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

• Выполнение тестов для выявления узких мест производительности или проблем масштабируемости
• Поддержание системы сборки
• Встречи с клиентами
• Исследование новых фреймворков / библиотек
• Изучение языковых функций, которые вы хотели бы использовать
• Читая по вопросам безопасности
• Обслуживание базы данных
• Обслуживание сервера

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

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

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

Купив команду, создайте список членов команды и прокрутите его так, чтобы каждый день новый человек объявлялся «Бэтменом» на совещании в режиме ожидания и отвечал на важные производственные проблемы в этот день. Остальная часть команды может оставаться сосредоточенной на разработке без необходимости переключения контекста, и каждый имеет свою долю поддержки. С командой из 5 человек, это один день в неделю, когда разработчик может быть прерван, и 4 дня непрерывного, предсказуемого времени разработки.

Это дает преимущество в том, что знания / опыт делятся между командами, поэтому у вас нет одного человека, ответственного за исправление конкретных проблем и превращения в единую точку отказа и справедливого разделения вопросов поддержки.