¶ Azure Boards: user story, статусы и оценки
¶ Назначение
Azure Boards используется как внутренний контур разработки: здесь разработчики видят backlog, user story, задачи, баги, оценки, связанные work items, ветки, коммиты и пайплайны. Заказчики при этом остаются в Битрикс24, поэтому Azure не заменяет HelpDesk, а дополняет его техническим слоем.[1]
¶ Что смотреть в backlog
- Открыть Azure DevOps / TFS → нужный проект →
Boards→Backlogs. - Проверить, какой список открыт: общий backlog или конкретная итерация.
- Смотреть колонки
Work Item Type,State,Assigned To,Story Points,Iteration Path. - Если задача ниже условной рабочей зоны или не готова к разработке, она не должна попадать в рабочую статистику как полноценная задача.
- Если задача уже в работе, у нее должны быть исполнитель, состояние и актуальная итерация.
¶ Типы элементов
| Тип | Для чего используется | Как читать |
|---|---|---|
User Story |
Основная единица бизнес-задачи / пользовательской истории. | Описывает цель и ожидаемый результат для бизнеса или пользователя. |
Task |
Техническая часть внутри user story. | Разбивает работу на шаги разработки; может иметь часы Original Estimate, Remaining, Completed. |
Bug |
Дефект, найденный при тестировании или эксплуатации. | Должен быть связан с user story или задачей, если это дефект конкретной доработки. |
¶ Как завести или уточнить user story
- В backlog нажать
New Work Item. - Выбрать тип
User Story. - Заполнить короткое название: оно должно позволять понять суть без открытия карточки.
- В
Descriptionописать, что нужно сделать и зачем. - Добавить скриншоты, схемы, файлы или ссылки, если без них разработчик не поймет контекст.
- При необходимости заполнить
Acceptance Criteria: что должно быть выполнено, чтобы задачу можно было принять.[2] - В
Discussionвести переписку с разработчиком, тестировщиком или аналитиком. - В
PlanningуказатьStory Points, если задача уже оценена. - Проверить
Bitrix link: должна быть ссылка на задачу Битрикс24, если задача имеет внешний контур.
¶ Оценка в Story Points
В классическом Scrum story points - относительная сложность, а не часы. В текущем рабочем процессе поле Story Points используется как понятная бизнесу оценка в часах: сколько примерно пройдет от старта разработки до готового результата.[3]
Как оценивать:
- Не считать только чистое написание кода.
- Добавлять время на тестирование.
- Учитывать доработки после тестирования.
- Закладывать риск неизвестных деталей, если задача связана с ТС, обменами, внешним API или чужими данными.
- Если рефайнмент не проводится командой, оценка может ставиться руководителем/аналитиком экспертно, но ее нужно воспринимать как прогноз, а не точное обязательство.
Пример: если кодирование выглядит как 8 часов, итоговая оценка может быть 12-14, потому что после разработки почти всегда появляются проверка, уточнения и мелкие исправления.
¶ Backlog refinement
Раньше оценка проходила через backlog refinement:
- Берется список неоцененных user story.
- Участвуют руководитель/аналитик, тестировщик и несколько разработчиков.
- Команда читает описание и задает вопросы.
- User story при необходимости разбивается на
Task. - Task оцениваются в часах.
- Сама user story получает общую оценку.
Сейчас процесс упрощен: команду часто не отвлекают на полный refinement, а оценка ставится экспертно. Поэтому особенно важно писать описание так, чтобы разработчику не приходилось восстанавливать смысл по созвонам и личным сообщениям.[4]
¶ Статусы Azure
| Статус | Что означает | Что делать руководителю |
|---|---|---|
Draft |
Черновик, задача еще не готова для разработки. | Не считать полноценной задачей в отчетности и планировании. |
New |
Задача описана и может ждать оценки/планирования. | Проверить описание, оценку, Bitrix link, приоритет. |
Active |
Задача взята в работу. | Проверить исполнителя, итерацию и наличие движения. |
Paused |
Работа остановлена. | Понять причину паузы и нужно ли вернуть задачу в фокус. |
Resolved |
Разработчик считает работу законченной и отдал на тест. | Подключить тестирование и проверить связанные баги. |
Tested |
Проверка пройдена или задача готова к закрытию. | Сверить с Битрикс24 и подготовить закрытие / демо. |
Closed |
Задача закрыта в Azure. | Убедиться, что внешний контур в Битрикс24 тоже закрыт или обновлен. |
Removed |
Задача убрана из рабочего потока. | Проверить, не нужна ли история или комментарий в Битрикс24. |
¶ Связанные work items
В правом блоке карточки смотреть Related Work:
- дочерние
Task, если user story разбита на технические шаги; Bug, если тестировщик нашел дефекты;- parent/child-связи, если задача является частью крупной работы;
- ссылки на репозиторий, branch, commit или pull request, если разработчик привязал код.
Если связанных task/bug нет, это не всегда ошибка: сейчас разработчики часто сами добавляют технические задачи по ходу работы. Но для крупных задач лучше заранее попросить разбивку, иначе оценка будет слишком грубой.
¶ Проверка перед планированием
Перед тем как брать задачу в итерацию:
- Есть понятное описание.
- Есть ссылка на Битрикс24 или явное решение, что задача внутренняя.
- Заполнен
Story Points, если задача идет в план. - Статус не
Draftи не случайный старыйNewбез контекста. - Понятно, кто будет делать и кто сможет ответить на вопросы.
- Для крупной задачи есть связанные task/bug или хотя бы план разбивки.
¶ Частые ошибки
- Перепутать backlog Azure с HelpDesk-доской: это разные контуры.
- Оставить задачу в
New, хотя это черновик без описания. - Поставить оценку только по разработке, забыв тестирование и исправления.
- Не заполнить
Bitrix link, из-за чего задача пропадает из внешней отчетности. - Назначить задачу на разработчика до того, как она готова к работе.
- Считать
Resolvedокончательным закрытием: это только сигнал, что разработчик отдал результат на проверку.
Битрикс24 нужен заказчикам и статусам наружу, Azure нужен разработке и технической детализации. ↩︎
Acceptance Criteria можно не заполнять для каждой мелкой задачи, но для крупных доработок это снижает риск споров при приемке. ↩︎
Это локальная договоренность процесса из видео. В других командах story points могут означать относительную сложность, а не часы. ↩︎
В видео отдельно отмечено, что полноценный refinement с разработчиками раньше проводился, но сейчас чаще используется упрощенная экспертная оценка, чтобы не отвлекать команду. ↩︎