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

40

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

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

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

Shadin
источник
1
Сначала расставьте приоритеты и исправьте критическую ошибку, а затем возобновите нормальную разработку. Оба одновременно просят допустить ошибку.
Марк Роджерс

Ответы:

60

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

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

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

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

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

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

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

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

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

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

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

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

Ewan
источник
5
как долго твой спринт? Я бы пошел на одну неделю
Ewan
3
Вы можете сойти с рук, не делая обзор и ретро, ​​возможно, делать их один раз в месяц. Дизайн (UI design?) Как отдельная команда / спринт - это хорошая идея, я думаю. Надеемся, что большую часть времени дизайн будет сделан до того, как начнется разработка, и он не сильно изменится
Ewan
3
Владелец продукта хочет, чтобы разработчики отбросили все и работали над ошибками в работе, остановили текущий спринт, исправили ошибку и запустили другой спринт, когда это будет сделано. Эти решения имеют последствия, и это заставит владельца продукта понять влияние на немедленные исправления ошибок. Им придется проявлять больше осмотрительности, когда вещи считаются неотложными. Или вы можете подождать и обратиться к ним во время следующего вставания. Таким образом, вы можете видеть, у кого есть какая-либо дополнительная полоса пропускания, и вы не прерываете поток разработки.
JeffO
5
Если вы пропустите обзор и ретро и сделаете дизайн в отдельном спринте, то на самом деле Scrum не останется ...
Эрик
6
Ваше решение: «получить высший авторитет в компании, а затем потратить много денег, создав три совершенно новые команды»?
Легкость гонки с Моникой
25

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

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

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

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

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

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

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

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

изогнутый
источник
3
Я думал о том же - поверните одного разработчика, чтобы выполнить «рутинную работу» (производственные проблемы), и, поскольку он не собирается выполнять большую часть реальной работы, пусть он также занимается исследованиями / исследованиями / другими нерегулярными вещами. И проведите хороший анализ первопричин каждой производственной проблемы, чтобы их число уменьшилось.
RemcoGerlich
1
Это на самом деле очень хорошая идея! Мне нужно будет нанять еще одного или двух разработчиков, но я считаю, что это того стоит. Большое спасибо!
Шадин
1
В нашем проекте мы в некоторой степени формализовали эту позицию. У нас есть старший разработчик в каждой команде, который назначен техническим руководителем команды Scrum. TL делает несколько вещей (наставник младший разработчик, делает «планы 4 + 1» перед производством, решает проблемы для других разработчиков по мере их появления и т. Д.), Но TL имеет дело с проблемами производства горячего картофеля и дефекты высокого приоритета. Очевидно, что LOT зависит от вашей производственной системы / философии, но TL может вмешаться, чтобы «защитить» остальную часть команды и позволить им сосредоточиться на пользовательских историях.
JBiggs
14

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

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

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

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

StuperUser
источник
Очень интересный подход, и я считаю, что он применим в нашей ситуации сейчас! Большое спасибо!
Шадин