Оптимизация и оценка невыполненной работы

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

Этот раздел продолжает учебник о членах группы вымышленной компании Fabrikam Fiber, так как она создает список невыполненных работ по продукту и выполняет цикл спринта в соответствии с гибкими методами работы.Команда использует страницы доски задач и невыполненную работу Team Web Access.

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

Примечание

Если используется шаблон процессов Visual Studio Scrum 2.0, то будет создан элемент невыполненной работы по продукту для описания функциональности пользователя, требований или некоторой части конечных результатов проекта.При использовании MSF для гибкой разработки программного обеспечения будет создано описание функциональности пользователя.При использовании MSF для улучшения процессов CMMI будет создано требование.

Содержание раздела

• Обзор критериев приемлемости и оценки усилий

• Захват пиков или работы, отличной от описаний, в невыполненной работе

• Дополнительные ресурсы для поддержки оценки усилий

Требования

Для соответствия описанным в этом разделе процедурам требуются следующее:

• Visual Studio Premium, Visual Studio Ultimate или Visual Studio Test Professional.

• Необходимо быть членом рабочей группы и необходимо иметь набор разрешений Изменить рабочие элементы на этом узле как Разрешить.По умолчанию все члены группы имеют это разрешение, поскольку группа команды является членом группы Участники командного проекта.

• Для просмотра страницы Невыполненная работа нужно принадлежать к группе доступа Полный в Team Web Access.

Дополнительные сведения см. в разделах Управление профилем и просмотр разрешений и Доступ к функциям Team Web Access.

Обзор критериев приемлемости и оценки усилий

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

1. Откройте Team Web Access, перейдите на домашнюю страницу для командного проекта или команды и выберите Просмотреть невыполненную работу.

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

3. Проверьте и обновите поля Описание и Критерии принятия с консенсусом команды для элемента или ошибки невыполненной работы.

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

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

4. На основе используемых командой методов оценки введите значение для Работа.В начале проекта необходимо учитывать только грубую оценку.

   Примечание

   Имена этих полей могут быть другими, основанными на шаблоне процесса, используемого для создания командного проекта, например, Работа для Scrum, Баллы описания для гибкой разработки и Размер для CMMI. Об оценках описания: В своей книге Agile Estimation and Planning Майк Кон (Mike Cohn) определяет баллы описания функциональности следующим образом: "Баллы описания функциональности — это единицы измерения для выражения общего размера описания функциональности, компонента или другого элемента работы". Кон (Cohn) объясняет, что баллы описания функциональности представляют собой относительные значения, которые невозможно сразу перевести в определенное количество часов.Баллы описаний лишь помогают команде определить общий размер описания функциональности пользователя.Эти относительные оценки являются менее точными, поэтому для их определения требуется меньше усилий. Со временем оценки будут уточняться.Благодаря определению баллов описаний функциональности команда получает общий размер описаний функциональности пользователей на начальном этапе и в дальнейшем, когда участники команды приступают к реализации описаний, разрабатывает более детальную оценку трудозатрат.Для получения дополнительной информации см. Оценка.

5. Нажмите кнопку Сохранить и закрыть.

Захват пиков или работы, отличной от описаний, в невыполненной работе

Иногда команде приходится выполнять работы, не направленные непосредственно на реализацию описания функциональности пользователя или требований продуктов.Эти работы называются пиками.Три распространенных типа пиков — исследование, задолженность по ошибкам и улучшения процесса или инженерные улучшения.Для создания пика в Team Foundation создайте элемент невыполненной работы или описание функциональности пользователя, опционально включите "Spike" в название, а затем назначьте ему приоритет в списке невыполненных работ вместе с другими описаниями функциональности.

1. На панели добавления на странице "Невыполненная работа по продукту" введите описание в поле Название для пика или работы, отличной от описаний, которой требуется компиляция, а затем нажмите кнопку Добавить.

   Совет
   Если панель не отображается, то выберите ссылку Добавить элементы, чтобы включить ее отображение.

   Рекомендуется определить работу, отличную от описаний, для следующих действий:

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

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

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

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

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

Дополнительные ресурсы для поддержки оценки

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

• Оценка

• Создание и управление ими список невыполненных работ по продукту

• Определения приоритетов

• Гибкие методы оценки: Обеспечивает представление гибких методов оценки из веб-сайта Майка Коха.

Связанные разделы в данном руководстве

Главная | Создайте невыполненную работу | Просмотр и управление невыполненной работой с доской канбана | Планирование итераций | Выполнение итерации | Завершение итерации

См. также

Основные понятия

Гибкое планирование и итерации