Я работаю над проектом Scrum, пишущим код прошивки в C для ASIC.
Каждый так часто нам очень трудно найти ошибки. Но как мне подсчитать эти ошибки?
Я всегда говорю мастеру Scrum. У меня нет компетенции оценивать их, потому что я действительно ненавижу оценку времени ошибок.
Как вы, ребята, справляетесь с этим в своих проектах Scrum?
Оценка ошибок - это очень тяжелая вещь. Если вы можете это сделать, то у вас, скорее всего, уже есть решение, и на самом деле это не ошибка. Итак, вместо того, чтобы пытаться оценить их один за другим, моим предпочтительным вариантом является выделение некоторого "времени исправления ошибок" во время Sprint и чтобы исправить наиболее важные ошибки за это время. Это стратегия лучших усилий, вы просто фиксируете как можно больше из них в течение выделенного времени.
Один подход, который сработал у меня, - это не иметь ошибок в первую очередь:)
Как это работает, при обнаружении ошибки исправление имеет приоритет над реализацией истории. Новые функции могут быть добавлены только после того, как уже существующая функциональность работает на 100%.
Конечно, мы классифицируем ошибки. Этот подход, основанный на методе stop-the-production-line, применяется только к критическим ошибкам. Меньше, чем критические ошибки, рассматриваются как истории улучшения характеристик, оцененные и запланированные в предстоящих спринтах, как и любые другие истории.
Распределение времени для критического исправления ошибок в конечном итоге находит отражение в скорости вашей команды.
"Трудно делать прогнозы, особенно о будущем".
Если вы не проанализировали ошибку и не выбрали решение, ее нельзя оценить. Это похоже на проведение собрания по планированию схваток, не зная, что это залог.
Вы можете использовать большие оценки для сообщения об неопределенности. Исторические данные имеют ограниченную ценность. Это не очень помогает для одной ошибки, даже когда распределение усилий одинаково для новых ошибок. Кроме того, новые ошибки могут быть проще или сложнее в среднем.
Я спросил Jeff Sutherland, и он сказал мне, что в PatientKeeper у них фиксированная оценка в полдня, чтобы исправить ошибку. Если характер ваших ошибок заключается в том, что они могут быть довольно предсказуемыми, так что вы можете найти приблизительное среднее значение, я думаю, это справедливая стратегия.
Однако на практике я не считаю, что это всегда нужно решать. Часто бывает трудно понять, что такое ошибка, и для ее анализа может потребоваться больше времени, чем для ее решения. Это часто делает ошибки очень непредсказуемыми и трудно оцениваемыми. Все задачи, которые вы включаете в свой спринт, должны анализироваться, а ошибки часто требуют большего анализа, чем другие задачи.
То, что мы делали в таких случаях с "непредсказуемыми" ошибками, - это выделить фиксированное время для выяснения проблемы. Например. мы выбираем потратить один день (или х баллов) на рытье в ошибку, пытаясь понять это, а затем планируем обратиться к фактическому исправлению для следующего спринта. Однако, если этого недостаточно, чтобы понять это, мы не хотим тратить на него больше времени в текущем спринте и придется пересмотреть его для следующего. В некоторых случаях ошибка может быть очень критической, и вы просто должны жить с неопределенной оценкой.
Оцените их в неделях вместо часов.
Если ваш Scrum-мастер не понимает проблему с оценкой ошибок с ошибкой, ваш проект, вероятно, выиграет от наличия Scrum-мастера с хотя бы небольшими знаниями в области программирования.
Мы можем классифицировать ошибку в "Я знаю, где это происходит, мне нужно его обновить", "Я знаю, что эта ошибка связана с этим модулем и любая отладка некоторых из этих файлов, которые я могу решить", "Я не знаю, почему эта ошибка появилась". Мы можем оценить в первых двух случаях, основываясь на нашем опыте в этом проекте. Но оценка для последнего случая очень тяжелая.
Как насчет оценки их на основе среднего времени, затраченного на исправление более ранних ошибок?
Я задал подобный вопрос раньше времени и получил некоторые хорошие ответы.
Вы должны быть abel, чтобы построить историю того, сколько сюжетных точек вы можете заполнить за неделю, основываясь на последовательной оценке точки. Это также будет включать время исправления ошибок.
Например, мы знаем, что мы можем завершить 20 историй в неделю, начиная с предыдущих спринтов. Разработка этих 20 баллов может быть завершена в течение 2 дней, однако тогда есть тестирование и исправление ошибок. Мы не оцениваем ошибки dev, поскольку каждая новая история должна иметь оценку, которая будет приблизительно включать время исправления ошибок. Живые ошибки должны быть исследованы до оценки, тогда это должно быть целесообразно оценить точно.
Мы оцениваем для каждой ошибки время анализа 4h. Также у нас есть приоритетность ошибок. Ошибки, которые являются блокировщиками или критическими, должны быть исправлены до того, как будет реализовано другое. Множество ошибок для исправления результатов в более низких рассказах. Но у нас есть такое надежное программное обеспечение для следующих функций.
Я нахожу, что на самом деле не так много пользы в попытке оценить ошибки. Просто предохраняйте их, найдите их, сделайте их видимыми (на вашей панели задач или тем, что вы используете), расставьте приоритеты и исправьте их. Время, которое вы потратите, повлияет на скорость. И это имеет значение. Это скорость, на которую указывает индикатор того, сколько прогресса вы можете ожидать в следующем спринте.
Если вас интересуют некоторые показатели, используйте количество ошибок в спринте.
Реальная цель - уменьшить риски, связанные с ошибками; т.е. не допускать выполнения графика. Очень часто команда сможет определить, какие истории, вероятно, создадут сложные ошибки раньше времени. Поэтому одна стратегия предотвращения состоит в том, чтобы сначала решить эти истории, дав команде как можно больше времени справиться с неожиданностью.
вы также можете подумать о том, чтобы выделить "контингент" для исправления ошибок во время Sprint (10-20% от установленного времени), чем использовать способ Kanban для их работы. Это означает, что вы можете поговорить с Владельцем продукта и объяснить ему, что затраты на исправление ошибок находятся под контролем (поскольку контингент - это ваш временной ящик), который эмпирически будет корректироваться на каждой новой итерации, исходя из того, что команда считает, что качество Продукта будет, Цель, конечно же, сократить время и повысить прозрачность. Владелец продукта может помочь в определении приоритетов Bug Backlog, накладывая на верх наиболее ценные ошибки - обычно значение Сохранения - так, что наивысший приоритет будет, вероятно, исправлен... чем выше, тем лучше.
Работа с KanBan означает, что команда сидит и смотрит на регулярный интервал (после того, как ежедневное время ожидания - хорошее время), что находится в очереди Bug, использует опыт всех членов команды, чтобы выяснить, где выглядят и что проверить, чем кто-то (обычно спаривание действительно хорош) берет ошибку. Когда контингент закончится, Команда поднимает руку и разговаривает с Владельцем Продукта, ему придется решить, есть ли еще ошибки, которые нужно исправить - ценой истории или более - или они могут ждать следующего Спринта.
В целом прозрачность должна позволить команде Scrum (включая PO и SM) выяснить, что такое стоимость исправлений, и выяснить, что делать, чтобы сбалансировать качество и скорость доставки. Обычно это хороший способ установить диалог с PO: -)
Я слышал об исправлении ошибок по сравнению с рыбалкой. Сколько времени вам понадобится, чтобы исправить загадочную ошибку? Сколько времени потребуется, чтобы поймать рыбу? Вы можете попробовать объяснить это владельцу продукта в этих условиях.
вполне согласен с ответом Паскаля Тивена. в нашем Sprint, как правило, мы выберем некоторые задачи, которые могут быть адаптированы, если есть другие более насущные задачи.
Когда появляется ошибка, мы расставляем приоритеты и устанавливаем для нее важность. если высокий приоритет или серьезность, мы пойдем, чтобы сделать это, и несущественная задача в этом Sprint вернется к отставанию.
Если ошибка или ошибка не являются срочными, мы выполним все задачи Sprint.
если было запущено много Спринтов, может быть статистика, показывающая, сколько усилий было потрачено на исправление ошибок, получить среднее усилие, поскольку эталонный тест для следующего спринта - это еще один вариант для вас.