Как скрам-мастер должен справляться с большим временем цикла отдельных членов команды?

Во-первых, посмотрите, можете ли вы больше разделить свои истории .

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

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

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

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

Попробуйте объединить более быстрых инженеров с более медленными (и в целом поощряйте сотрудничество) — они оба могут учиться, работая вместе.

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

Конечно, сначала работа должна быть достаточно заметной. Простая доска с делами и делами не поможет. Вам нужно смоделировать фактический рабочий процесс, чтобы определить узкое место. Вероятный рабочий процесс — Backlog-Ready-In Progress-Review-QA-Ready to Deploy-Done. Если что-то накапливается в QA, попросите помощи разработчиков. Если что-то нужно пересмотреть быстрее, выясните, как это сделать. Развертывание занимает несколько часов? Автоматизируйте их. И т.д.

Как упоминалось другими, другой рычаг, который вы должны нажать, — это предел WIP. Уменьшите лимит WIP и сред. Время цикла должно уменьшиться.

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

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

Изучив его, мы выявили следующие проблемы (и решения, которые мы реализовали):

• Элементы невыполненных работ не были ясны. Много времени было потрачено на изучение историй во время спринта => мы делим истории на Спайки (исследования), Истории, Задачи/Подзадачи, Баги. Теперь вы могли четко видеть, сколько времени заняло исследование истории и сколько времени заняло фактическое кодирование. Я также работал с PO, чтобы провести больше исследований, прежде чем помещать истории в бэклог.
• Следующая проблема заключалась в том, что истории (после реализации предыдущего пункта) не разделялись должным образом. Мы разделяем историю на спринты или короче, если это возможно. Я поднял этот вопрос с Майком Коном на его недавнем тренинге по пользовательским историям; его рекомендация состоит в том, чтобы разделить истории настолько, насколько это имеет смысл для разработчиков, не тратьте много времени на то, чтобы разделить их на минимально возможные, но определенно короче, чем спринт.
• Затем мы рассмотрели проблему, о которой вы упомянули: некоторые разработчики медленнее других? Конечно, но в нашем случае это было не потому, что быстрые были среди ярлыков, это было вызвано старшинством и знанием бизнеса и продукта. Поэтому мы выбрали парное программирование: старший программист объединяется с младшим для распространения знаний и обучения.

Вышеупомянутое работало очень хорошо. Мы увеличили нашу скорость как минимум на 30% всего за 4 спринта. Но я понимаю, что увеличение может быть связано с тем, что мы изначально не оценивали истории должным образом, поэтому мы продолжаем работать и отслеживать.

TL;DR все начинается с планирования, с того, как вы разделяете и оцениваете истории. Начните оттуда.