Должна ли отдельная пользовательская история содержать оценки для каждой участвующей гильдии в команде разработчиков полного стека

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

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

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

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

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

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

Использование таких терминов, как «гильдия», заставляет меня думать, что ваша организация похожа на модель Spotify. Однако то, что вы описываете как «гильдию», похоже, не соответствует этому. В модели Spotify работа выполняется межфункциональной командой, которую они называют «отрядом». Гильдия — это межотрядовая (а также межплеменная) организация, которая работает над определенным типом сквозной проблемы для распространения знаний по всей организации.

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

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

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