Вы считаете часы проведенными на исправления ошибок к толпе? [закрытый]
5 ответов
Моя команда поддерживает много приложений прежней версии, таким образом, существует довольно мало незапланированного устранения ошибки, которое происходит во время каждого спринта. Мы приняли следующую практику:
- , Если ошибку легко/быстро исправить (один лайнер, и т.д.), то просто фиксируют его.
- , Если ошибка не тривиальна, и не блокировщик, то добавьте его к отставанию.
- , Если ошибка является блокировщиком затем, добавляют задачу (к текущему спринту) для получения работы, требуемой зафиксировать его и начать работать над ним. Это требует, чтобы что-то еще было перемещено (от текущего спринта) к отставанию для учета в течение новых часов, потому что общие доступные часы не изменились.
, Когда мы добавляем новые задачи ошибки, мы отметим их по-другому по сравнению с запланированными задачами, так сделайте их легкими видеть во время обзора спринта. Иногда незапланированная работа заканчивает тем, что была> 50% нашего спринта, но потому что мы продвигаем запланированные объекты к отставанию, мы знаем очень рано, что мы не поставляем этому спринту, который мы запланировали.
Это, оказалось, было очень полезно для нашей команды имея дело с приложениями прежней версии, где ни один из нас не так знаком или уверен относительно систем, как мы хотели бы быть.
Ошибки, раскрытые во время спринта, принадлежа тому спринту, должны быть исправлены автоматически, как будто задача/история не была сделана для начала. Ошибки, появляющиеся из предыдущих спринтов, могли быть введены в отставание ошибки и расположены по приоритетам точно так же, как нормальное отставание.
РЕДАКТИРОВАНИЕ: Просто реализованный, что путем упоминания "отставания ошибки" я открываюсь для "нескольких отставаний", который является плохой идеей. Лучший путь мог состоять в том, чтобы отметить запись в отставании с ошибкой, отмечают или просто принимают его как любую другую историю в отставании.
количество серьезных ошибок, появляющихся в спринте, должно быть минимальным, поскольку все уже тестируется, прежде чем принято и поставлено владельцу проекта в конце спринта.
В действительности это не должно влиять на график, так как Вы примете на себя обязательство фиксировать определенное количество ошибок (выбором ПО - некоторые ошибки имеют более низкий приоритет, чем новая функциональность), и когда ошибки появляются из самого спринта, хорошо задача действительно не была сделана так, нормально понимать, что и проводят время, фиксируя его.
РЕДАКТИРОВАНИЕ: Реализованный что-то еще - иногда работающий над командой толпы будет не всегда защищать Вас от действительности необходимости поддержать другие приложения, поддержку, и т.д. В то время как это действительно сосет и делает всю эту мысль быть в команде с единственным отставанием, и фокус не действительно работают, действительность часто, что необходимо зарезервировать постоянное число часов, которые поддерживает/поддерживает неделя для. Не поощряйте это, но если это - действительность, пытаются присвоить единственному человеку (на вращении, таким образом, он не становится грустным), каждую неделю постоянное число часов, выделенных упомянутой роли поддержки. Таким образом, Вы знаете, что ожидать, так как скорость относительна - она будет так или иначе походить на меньшее влияние на спринты.
В каждом спринте у меня есть две 'задачи' - один для ошибок, найденных в текущем спринте (т.е. на непоставленном коде), и один для проблем, найденных в чем-либо еще (любой поставленный выпуск). Это помогает мне отслеживать то, сколько времени потеряно (на разработчика) исправление ошибок.
Любое время вошло в систему, последняя категория рассматривается как отходы, и это - главная цель для сокращения. Время вошло в систему, первый рассматривается для того, как оно может быть более тесно связано с функциями и изменениями, которые вызвали его.
не помещают оценки против ошибок, вместо этого пытаются добавить, что время к оценкам для единицы/функционального тестирования против функций Вы продолжаете работать.
Не стесняются адаптировать любую модель, чтобы подойти, как Ваша команда работает - должна быть культура непрерывного improvment в любой команде Толпы, и devs должен смочь предложить и испытать улучшения, поскольку они изучают Толпу.
Я думаю, что трудно оценить усилие для исправлений ошибок перед диагностированием проблемы, и диагноз часто является львиной долей проведенного времени.
, Если бы Ваш объем ошибки довольно последователен, я просто позволил бы ему "проявиться" против скорости. Это - то, что я обычно делаю для производственных дефектов, которые влияют на итеративные цели команды.
, Если Вы понимаете середину повторения, от которого Вы отстаете (например, Вы видите диаграмму выгорания, это не похоже на него, пересечется с Вашей строкой объема к концу повторения), из-за проблем ошибки, затем можно адаптироваться, объем (опустите самую низкую приоритетную историю) размещать дополнительную работу.
Путем я склонен обрабатывать, это должно переместить устранение ошибки за пределами спринта. Таким образом, трехнедельный спринт мог бы сопровождаться устранением ошибки недели перед демонстрацией / выпуск.
Это не идеальное решение, поскольку никакая попытка не предпринята для оценки количества ошибок, которые будут исправлены в фазе устранения ошибки все же. Таким образом, я с нетерпением жду других, дающих лучшее решение, чем я.