Исходные оценки в Azure DevOps — максимальное значение?

#azure #azure-devops #estimation

#azure #azure-devops #оценка

Вопрос:

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

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

Я полагаю, что я хочу понять, можно ли было бы сделать это каким-то образом? Могу ли я что-то сделать с существующим полем «Первоначальная оценка» или мне придется создать новое настраиваемое поле, чтобы иметь хоть какой-то шанс помешать людям тратить 100 часов на то, что на самом деле больше похоже на 2?

Комментарии:

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

2. Спасибо, Алекс, мне нравится, как это звучит. Полностью понимаю, о чем вы говорите, и я думаю, что есть больше людей, которые искажают цифры в том виде, в каком они есть, по целому ряду причин — плохая подготовка, плохие процессы и / или лень. Я нахожу немного странным, что группа людей, которые считают себя прогрессивными, не могут правильно понять основы. Выделение кажется действительно хорошей идеей. Это означает, что у них нет оправдания, чтобы сказать, что они сделали что-то глупое, а также сообщить об этом Проектной команде и, возможно, даже старшим менеджерам. Нужно будет попробовать выделить и посмотреть, что я могу с этим сделать

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

Ответ №1:

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

https://docs.microsoft.com/en-us/azure/devops/boards/boards/customize-cards?view=azure-devops
пример конфигурации

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

Ответ №2:

Есть ли способ настроить наши рабочие элементы DevOps так, чтобы они принимали только максимальное значение?

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

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

введите описание изображения здесь

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

Комментарии:

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