SCRUM - Соответствующий уровень ресурсов, не связанных с развитием?

Question

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

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

Текущая ситуация:

• Владелец продукта является командой из 5 людей, половина из которых через Атлантику от команды разработчиков (что лучше, чем в предыдущей ситуации, в которой не было ни владельцем вообще)
• владелец продукта «команда» только встречается, практически, два раза в месяце
• Там нет выделенного тестирования пользователя или QA ресурс
• Лучшего времени для завершения тестирования пользователя был 3 прошли недели, в течение примерно 2 человеко-дней тестирования
• Мы работаем на ежемесячный спринт

Конкретных вопросы:

• Сколько раз в неделю должен владелец продукта (если бы они были одним человеком) тратить на их владелец роли продукта?
• Ожидаете ли вы, что владелец продукта будет доступен «весь день каждый день»?
• Сколько выделенного ресурса тестирования/QA вы ожидаете получить в месяц?

Я пробовал Google для «авторитетных» ответов или просто сообщений о уровнях ресурсов команды, но ничего не смог найти.

Кто-нибудь знает что-нибудь подобное, поэтому мое деловое дело будет не просто «я думаю ...», но может иметь ссылки на мнение экспертов и статистику реального мира?

Answer 1

Сколько раз в неделю владелец продукта (если бы он был одним человеком) тратил на свою роль владельца продукта?

Я бы сказал, что примерно один день в неделю должно быть в порядке в зависимости от моего опыта работы с командой из 15 DEV + QA и одного владельца продукта. Я также настоятельно рекомендую следовать за владельцем прокси-сервера или создать требованиям архитектора (архитектор требований Google Dean Leffingwell). Это, по сути, то, что мы сделали, так как у нашего Владельца Продукта не было полосы пропускания, чтобы потратить это время на проект.

Вы ожидаете, что владелец продукта будет доступен «весь день каждый день»?

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

Какое количество ресурсов для тестирования/QA вы ожидаете получить в месяц?

Как уже было сказано выше, это зависит от типа проекта и количества разработчиков/BAS в команде. Я бы предположил наличие по крайней мере отношения 1: 1 между BAS и тестировщиками, по логике, что требуемое количество QA является сильной функцией от количества указанных требований. Поскольку вы говорите о онлайн-приложении, я предполагаю, что существует не очень длинный цикл регрессии/интеграции, поэтому может быть достаточно отношения 1: 3 к разработчикам. Я считаю, что тестеров важно влиять на требования и удобство использования, а не только на исправление ошибок. Другим фактором является то, собираетесь ли вы принять гибкие инженерные практики, например. TDD, модульное тестирование, непрерывная интеграция и т. Д. Если это так, ресурсы тестирования будут гораздо более ориентированы на определение тестов, удобство использования, тестирование производительности/нагрузки, а не регрессию.

Одним из способов увидеть, что является узким местом, является принятие какой-либо платы Kanban, которая визуализирует рабочий процесс. На этой доске вы можете увидеть, где узкое место. Будь то это в ПО, разработке или тестировании. Если вы используете одну командную группу с обычной таблицей Task Board, вы можете легко получить эту информацию, добавив столбец для «In Testing» и «In specification» (так что в целом у вас есть - Pending -> In specification -> In DEV Прогресс -> В тестировании -> Ожидание утверждения ПО -> СОВЕРШЕННО). Если вы видите, что слишком много ваших липких заметок застряли в определенной колонке/стадии, вы знаете, где искать проблему. Покажите это руководству, его эмпирическому и намного лучше, чем любая информация/эмпирические правила, увиденные в других проектах, или, по крайней мере, очень хорошее дополнение к этому ...

Answer 2

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

Что касается ваших вопросов:

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

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

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

Answer 3

Я сертифицированный SCRUM Master и Ниже мой анализ ситуация:

Очки Чтобы быть примечание:

• SCRUM не позволяет сценариям «получаса разработчика», разработчики должны работать специальными по проекту.
• Несколько владельцев продукта - это плохая ситуация, когда вы находитесь. Существует человек, который должен иметь четкое представление о проекте. Вы рассматриваете клиентов как владельцев продуктов?
• Если вы настраиваете SCRUM, то u не делает SCRUM и не делает SCRUM-BUT.

Суггестивных Ответы:

Сколько раз в неделю должен владелец продукта (если бы они были одним людей) тратить на их продукт владельца роли?

У вас может быть владелец прокси-сервера внутри команды, который несет ответственность за разработку продукта и создание надлежащего коммуникационного моста между владельцами оригинальных продуктов и командой.

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

Ожидаете ли вы, что владелец продукта будет быть доступным «весь день каждый день»?

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

Сколько посвященный тестирования/QA ресурсов можно было бы ожидать, чтобы быть доступны в месяц?

Весь весь спринт. В SCRUM все называются «разработчиками» и должны присутствовать на спринте, что в перспективе увеличивает обмен знаниями и повышает общую производительность команды.

НТН

Answer 4

Вы не можете иметь владельца проекта, что это команда, как вы находите это просто doens't работу. У вас есть пара вариантов, мой любимый - объявить независимость - они не хотят ответственности за то, чтобы быть владельцем - вы сами берете на себя ответственность. Вы четко понимаете проблему, пытаетесь захватить контроль, отправляете несколько полезных писем, описывающих новую структуру - НЕ просите разрешения, просто сделайте это, чтобы немного встряхнуть их.

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

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

BTW - ответы на основе более 50 проектов в 20 организациях.