Являются ли переговоры и попытки сбить оценки Scrum законными частями процесса?

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

ОП часто пытается опровергнуть такие оценки, например: «Что, вы хотите 13 сюжетных баллов [4 дня] для этой истории, этого не может быть! Я не могу объяснить это руководству, кто-то должен иметь возможность закодировать это» с 3 SP [через 4 часа]! ". В результате разработчики изо всех сил стараются дать оценку 5 или 8 баллов [1,5–2 дня] (оценки Scrum по-прежнему принимаются как обязательства, а не просто как прогнозы).

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

Можно сказать: «Вы не должны брать на себя невозможное обязательство, просто потому, что кто-то подталкивает вас к выполнению!» Но, на мой взгляд, работа разработчика заключается в разработке программного обеспечения и кодировании, а не в торгах или противостоянии давлению! Могут быть гнезда на все руки, обычно те, которые имеют дело непосредственно с внешними клиентами, но это не большинство офисных разработчиков!

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

Что говорится в Scrum-руководствах на эту тему, или они что-то говорят по этому поводу?

РЕДАКТИРОВАТЬ: заменил время на очки истории. Я имел в виду начальную фазу оценки с Planning Poker и сюжетными очками, а не подробное планирование задачи. Я просто поместил дни / часы там, потому что иногда это был типичный диалог, также со временем вместо очков. Извините за путаницу! Примеры сюжетных моментов представляют более длительные периоды времени, чем примеры времени.

РЕДАКТИРОВАТЬ 2 В настоящее время нет выделенного мастера схватки, и ПО берет на себя эту роль, когда речь идет об оценочных собраниях. Так что, вероятно, конфликт ролей усугубляет этот неуместный торг, поскольку он выглядит как авторитет, а не как нейтральный владелец или разработчик. Возможно, это можно исправить, приняв его за предвзятого участника вместо «мастера», если ни один из них не доступен.

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

Если вы хотите указать город http://www.scrumguides.org/scrum-guide.html в качестве органа, я бы выделил:

Только команда разработчиков может оценить, чего она может достичь в предстоящем спринте.

а также

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

Владелец вашего продукта может пожелать, чтобы задача стала возможной всего за 4 часа. Это может быть даже разумной целью. Хорошая реакция может заключаться в том, чтобы принять оценку команды, измерить ее, если она точна, и спросить: «Что нам нужно изменить, чтобы мы могли быстрее выполнить эту задачу?» Согласование объема работ, связанных с задачей, также может быть разумным и подчеркнуть важное различие в том, как разработчики и владелец продукта понимают эту работу под рукой. Требование, чтобы команда изменила свои оценки без новой информации, обеспечивает только неточные оценки.

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

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

Если бы я был разработчиком, и меня заставляли называть историю из 13 пунктов историей из 8 пунктов, я бы с радостью согласился. Свои возможности оценки они влияют. Я просто масштабирую все свои трудности, чтобы соответствовать. Со временем скорость команды будет уменьшаться с точки зрения сюжетных пунктов в неделю, чтобы соответствовать готовности руководства «раздавать» сюжетные пункты. Цифры, предоставленные руководству, должны совпадать: «Мы успешно сократили количество основных моментов работы, необходимых для достижения рубежа, на 50%. Однако мы увидели соответствующее снижение скорости на 50%, поэтому мы получаем чистый эффект. мы собираемся выполнить именно то, что мы собирались выполнить, за то количество времени, которое нам потребовалось ». Концепция скорости существует для борьбы с желаемым мышлением высшего руководства.

Теперь есть две крайности, на которые, я думаю, стоит обратить внимание. Один из них - полный провал управления, а другой - очень серьезная забота для руководства. Первый случай - это смертный приговор для SCRUM, когда разработчики говорят: «Вы недостаточно продуктивны. Вам нужно создать больше историй, достойных работы». Если это произойдет, вы на самом деле не используете SCRUM, вы - Cookoo, который выгнал SCRUM из гнезда и пытается накормить птицу-мать, которая возвращается к следующему.

Сейчас есть один случай, когда я думаю, что руководство должнобыть в состоянии заниматься скручиванием руки, как это. Для клиента должно быть разумным сказать: «Я не могу позволить себе 50 баллов за выполнение этой задачи, если ваша скорость составляет 20 баллов в неделю. Мне нужно, чтобы вы выполнили ее за 30 баллов», если этот клиент готов пересмотреть содержание этих историй, чтобы уменьшить их охват на 40%. SCRUM - это не бесплатный билет для разработчиков, чтобы делать все, что они хотят, а инструмент коммуникации, помогающий им и руководству открыто говорить о том, что необходимо сделать. Это также справедливо для клиента, чтобы он давил на разработчика и говорил: «Выполняй задачу за 30 баллов», если он готов принять риск, связанный с тем, что работа просто не будет выполнена вовремя. Когда срок пропущен, если разработчики могут сказать: а затем принять то, что на самом деле сделано. Я думаю, что есть лучшие способы измерить производительность команды, но я должен признать, что это процесс, который работает. а затем принять то, что на самом деле сделано. Я думаю, что есть лучшие способы измерить производительность команды, но я должен признать, что это процесс, который работает.

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

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

Нельзя сказать, что оценки иногда не могут быть подвергнуты сомнению. Если это так, это должно произойти в позитивном ключе. Например, «считали ли вы, что мы уже выполнили половину работы для« x »», или «вы не забыли включить время, чтобы выполнить Y?».

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

Что говорится в Scrum-руководствах на эту тему, или они что-то говорят по этому поводу?

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

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

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

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

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

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

Да и нет.

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

Нет, владелец продукта не может сказать, сколько времени это займет. Вы эксперты, а не они.

Слушай, тебе не нужно иметь дело с подобным мусором - твой менеджер или руководитель группы помогут тебе добиться успеха. Это значит иметь дело с премьер-министром (или его начальником), чтобы вы были успешными. Тем не менее, это не так сложно.

«Нет.»

Что они собираются делать? Сам пишешь код?

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

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

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

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

Или они могут следовать за процессом, который внешне напоминает проворный процесс.

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

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

Я бы сказал, что здесь многое зависит от мотивации. Главная цель оценки - получить представление о том, чего может достичь команда в течение любого спринта, что затем позволяет прогнозировать будущую работу на основе этой скорости. Например, если команда набирает 30 сюжетных баллов за каждый спринт и на 60 секунд опережает пункт X в бэклоге, владелец продукта может разумно сказать, что пункт X будет завершен примерно через 6 недель (на основе стандартный двухнедельный спринт).

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

В принципе, так работает планирование покера. Каждый выкладывает свою оценку. Затем Scrum Master берет оценку максимума и минимума и спрашивает, почему член команды считает, что она должна быть такой высокой / минимальной. Это дает команде возможность услышать альтернативные перспективы вовлеченной работы и получить лучшее представление о том, насколько сложна задача на самом деле. После обсуждения каждый снова выставляет свои оценки. Этот процесс промывается и повторяется до тех пор, пока не будет достигнуто общее согласие относительно сложности.

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