Как оценивать в agile определенный тип задач?
Нужна консультация в вопросе оценки определенных задач в SP.
Наша команда пытается перейти с классической разработки на agile - разработка продукта ведётся более 10 лет.
В связи с этим, трудностей в оценке доработок в виде user story у нас нет.
Но есть отдельные типы задач: рефакторинг и внутренние улучшения. Например:переработать логирование, перенести методы в другое место, добавить метрики с возможностью вывода в какую-нибудь подсистему мониторинга.
Поэтому возникает вопрос. Стоит ли оценивать такие задачи? Как их оценивать? Ведь если закладывать много неопределенности - будет снижен темп разработки. Если недооценить, а окажется, что пришлось много ресерчить - будет невыполнения часть работы на спринте.
Или есть смысл брать их в качестве дополнительной работы, если на спринте появилось время, без оценки?
Сейчас мы их никак не оцениваем.
Очень буду благодарна за помощь.
Дополнительно:
Ответы:
Я видел два варианта:
1й: Продолжать оценивать их в поинтах, обсуждайте на ретро, какие возникли сложности, почему ошиблись в оценке.
Со временем:
1. Сама по себе команда сможет точнее оценивать подобные задачи
2. Выработается механизм по преданалитике инженерных задач.
2й: вынести все инженерные задачи на канбан-доску и выделять разработчикам какое-то время на разгребание задач с неё.
Обсудите со своей командой оба варианта, дайте возможность предложить свои, проведите эксперимент.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
В agile методологии оценка задач играет важную роль для планирования и управления проектом. Существует несколько способов оценки задач в agile, одним из наиболее популярных является методика Story Points.
Story Points - это относительная оценка сложности задачи, которая не зависит от времени, а основана на количестве работы, необходимой для её выполнения. Для оценки задач с помощью Story Points используется шкала, обычно от 1 до 13 или даже выше, где каждая цифра соответствует определенной сложности задачи.
Для оценки задач с помощью Story Points необходимо провести специальное собрание команды, изучить задачи, определить сложность каждой из них и присвоить им Story Points. Во время собрания обычно используется техника Planning Poker, при которой каждый участник команды дает свою оценку задачи, затем обсуждается разница между оценками и принимается решение о конечной оценке.
Оценка задач с помощью Story Points позволяет команде более точно планировать свою работу, учитывая сложность задач и способности каждого участника команды. Кроме того, такой подход позволяет избежать привязки к конкретному времени, что делает планирование более гибким и адаптивным к изменениям.
Таким образом, оценка задач в agile с использованием Story Points помогает команде более эффективно планировать свою работу, учитывая сложность задач и способности участников команды, что в конечном итоге способствует успешному выполнению проекта.