Несколько скрам-команд переходят в одно отставание

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

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

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

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

Мы управляем примерно полдюжины проектов с использованием одного отставания. Я говорю «о», потому что это зависит от того, как вы хотите дифференцировать проекты.

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

Нам не нужно было объединять резервы, но это кажется простой задачей на вашей стороне.

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

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

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

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

• Как правило, мы используем два метода, чтобы пометить, к какому продукту относится элемент бэклога продукта. Мы используем оба просто потому, что это облегчает уход и другие задачи.

  1. Мы предваряем название PBI названием продукта или сокращенной версией.
  2. У нас есть отдельное поле, которое указывает на общий продукт, и оно также должно быть заполнено.

• Мы должны приложить сознательные усилия к перекрестному обучению и быть уверенными, что каждый получит помощь в различных областях. У нас очень большая кодовая база по отношению к нашей команде разработчиков. Часть кода, который мы делаем, также очень специализирована. Наш руководитель команды в этом отношении великолепен, и он понизит наш уровень приверженности на ступеньку выше, чтобы мы могли позволить себе неэффективность, связанную с перекрестным обучением. В этом отношении очень важно иметь сильное командное руководство.

• Мы делаем все возможное, чтобы сохранить наши временные рамки спринта. Сложные проекты с новыми членами команды превращаются в нередкое кровотечение с обязательствами. Процесс вокруг вашего ветвления действительно поможет здесь. Вся наша работа выполняется с веткой, которая затем сливается обратно в выпуск ствола. У нас также есть сервер сборки, который работает по ночам в дополнение к специальным триггерам. Разработчики, которые ломают сборку, знают и решают проблему в течение 24 часов. Период. Неспособность решить в течение 24 часов означает, что ваш коммит откатывается и старшие разработчики испытывают к ним горе. И старшие разработчики являются самыми трудными для себя, когда дело доходит до поддержания сборки.

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

• Точно так же в ежедневной работе участвуют все разработчики и наши сотрудники. Мы находимся на грани полезного совместного общения и неэффективности со стороны слишком многих людей. Но мы держим время ожидания менее 15 минут и быстро уйдем от сторонних обсуждений. Обычно мы заканчиваем за 5-10 минут.

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

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

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

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

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

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

Правильный ответ Scrum - «Спроси команду (и)». Это принцип самоорганизации, при котором они должны быть в состоянии перестроиться, чтобы выполнить работу быстро. Вы видите, что многие люди в командах обладают большим контекстным знанием, чем посторонние, и они знают, что лучше. Это также включает владельца продукта.

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

Владелец продукта

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

Если есть несколько PO, то вам определенно нужно несколько резервов, так как команды должны быть выделены в спринте для одного PO и backlog. Причина в том, что команде не нужно управлять конфликтами между приоритетами владельцев продуктов.

Разработка продукта против обслуживания

Группы обслуживания работают над множеством мелких улучшений, ошибок в нескольких разных продуктах и, возможно, с несколькими владельцами продуктов. Этим командам BAU нужна поддержка управления ИТ, чтобы планировать и управлять конфликтами между несколькими владельцами продуктов.

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

Переключение контекста

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

Хорошее ПО попытается использовать групповые функции и тип работы, чтобы помочь командам делать меньше переключения контекста, тем самым улучшая свою производительность.

риск

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

Примеры

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

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

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

Профессионализм

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

Осмотреть и адаптировать

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

Нижняя граница

В конечном счете, управление отставанием является выбором ПО. Как он / она хочет управлять очередью работы, зависит от них. Единственная мысль - они ДОЛЖНЫ поддерживать работоспособность ВСЕХ команд здоровыми и в хорошем состоянии. Таким образом, решение должен принимать ПО.

Контракт

На сессиях по планированию спринта команда должна ожидать список готовых товаров, которые должны быть четкими, однозначными и упорядоченными. После короткого разговора с ПО команда должна точно знать, чего хочет ПО; ЧТО . Затем команда сосредоточится на том, как они собираются строить.

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

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

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

Вместо этого начните с того, чтобы обе команды работали над тем, над чем они работали раньше; единственная разница в том, что все находится в одном и том же отставании.

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

Если вы выполните все обучение заранее, это приведет к значительным потерям производительности. Кто-то в высшем руководстве наверняка заметит, и вы будете вынуждены поглотить отставание другой команды в надежде, что новая команда сможет компенсировать неудовлетворительные результаты ... :) Шутки в сторону, однако, это была бы моя рекомендация.

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

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

Таким образом, единственный способ добиться этого - разбить две команды и объединить их в две смешанные команды. Только тогда есть шанс, что вы быстро освоите всех разработчиков в «важной» системе.

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

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

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

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