Я заметил, что разработчики часто дают реалистичные оценки на истории. Однако даже довольно простые истории требуют больших усилий для настройки, настройки сторонних компонентов, тестирования и окончательной сборки, и система накопила довольно большой технический долг, поэтому оценки часто кажутся слишком высокими для владельца продукта или руководства.
ОП часто пытается опровергнуть такие оценки, например: «Что, вы хотите 13 сюжетных баллов [4 дня] для этой истории, этого не может быть! Я не могу объяснить это руководству, кто-то должен иметь возможность закодировать это» с 3 SP [через 4 часа]! ". В результате разработчики изо всех сил стараются дать оценку 5 или 8 баллов [1,5–2 дня] (оценки Scrum по-прежнему принимаются как обязательства, а не просто как прогнозы).
Конечно, без какого-либо плана по снижению ожиданий (в основном по тестированию и качеству) эти спринты часто терпят неудачу. Оценка разработчиков является честной, реалистичной, и снижение оценки не умаляет фактическую работу, которая должна быть сделана.
Можно сказать: «Вы не должны брать на себя невозможное обязательство, просто потому, что кто-то подталкивает вас к выполнению!» Но, на мой взгляд, работа разработчика заключается в разработке программного обеспечения и кодировании, а не в торгах или противостоянии давлению! Могут быть гнезда на все руки, обычно те, которые имеют дело непосредственно с внешними клиентами, но это не большинство офисных разработчиков!
Для меня эта практика просто делает программистов похожими на рывки, вызывает постоянные сбои спринта и предотвращает реалистичные оценки, а также ищет реальные улучшения.
Что говорится в Scrum-руководствах на эту тему, или они что-то говорят по этому поводу?
РЕДАКТИРОВАТЬ: заменил время на очки истории. Я имел в виду начальную фазу оценки с Planning Poker и сюжетными очками, а не подробное планирование задачи. Я просто поместил дни / часы там, потому что иногда это был типичный диалог, также со временем вместо очков. Извините за путаницу! Примеры сюжетных моментов представляют более длительные периоды времени, чем примеры времени.
РЕДАКТИРОВАТЬ 2 В настоящее время нет выделенного мастера схватки, и ПО берет на себя эту роль, когда речь идет об оценочных собраниях. Так что, вероятно, конфликт ролей усугубляет этот неуместный торг, поскольку он выглядит как авторитет, а не как нейтральный владелец или разработчик. Возможно, это можно исправить, приняв его за предвзятого участника вместо «мастера», если ни один из них не доступен.