Как учесть итерацию исправления ошибок?

За последние 5 месяцев мы успешно внедрили Scrum. Тем не менее, мы находимся в 3-х неделях от PROD, не проведя ни одного сквозного интеграционного теста. ОЙ! Мне нужна помощь. Без устранения причин этого (в ЭТОМ пункте) нам теперь нужно спланировать текущую итерацию, которая состоит из незначительных улучшений и МНОГО еще неизвестных исправлений ошибок. Как вы учитываете этот сценарий? Как вы планируете свою итерацию, чтобы исправить ошибки, которые еще не найдены?

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

• Начните тестирование немедленно, без предварительной оценки, когда это будет сделано.
• Когда вы обнаружите каждую ошибку, проведите первоначальный анализ до такой степени, чтобы вы могли ее оценить.
• Оцените ошибку и решите, должна ли она быть исправлена ​​и должна ли она быть исправлена ​​для первоначального выпуска.
• Если это нужно исправить, добавьте его в итерацию.
• Постройте график выгорания. В какой-то момент он начнет уменьшаться, а это означает, что вы больше не находите ошибки быстрее, чем вам удается их исправить. В этот момент вы сможете дать приблизительную оценку (и постепенно более точную), когда можно будет сделать релиз.

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

Оценка и исправление ошибок хорошо освещены Джоэлем Спольски в Evidence Based Scheduling и Hard-asse Bug Fixin ' . Это не связано со Scrum, но я думаю, что это достаточно общее, что многое из этого применимо.

Как учесть итерацию исправления ошибок? Как вы планируете свою итерацию, чтобы исправить ошибки, которые еще не найдены?

Относительно "итерации исправления ошибок". Обнаруженные ошибки должны рассматриваться не иначе, как истории. Работайте с командой, чтобы оценить усилия (основные моменты), чтобы исправить каждую ошибку, и работайте с владельцем продукта / клиентом, чтобы решить, должна ли ошибка перейти в следующую итерацию.

Что касается "ошибок еще не найдено". Желательно, чтобы команда находила и исправляла проблемы на каждой итерации. Если нет, обсудите это в следующей ретроспективе. Если качество продукции настолько мала , что выпуск не представляется возможным, то сразу переместить свои лучшие « искатели ошибка » для поиска ошибок (не фиксируя). Если качество достаточно высокое, чтобы предоставить бета-версию для выбора пользователей - сделайте это. Если вы не можете, то, по крайней мере, предоставьте демо-версии живых пользователей, обсуждающие слабые места, которые вы рекомендуете, нуждающиеся в улучшении.

Мы не планируем «итерации исправления ошибок», но планируем итерации системного теста перед каждым выпуском. Системный тест - это тесты интеграции, регрессии и повторного тестирования всех частей продукта. Тестеры тестируют продукт (довольно большая устаревшая система), а разработчики исправляют найденные ошибки. Если ошибок не обнаружено, мы либо начинаем исследовать графики функций для следующего проекта, либо работаем над внутренними улучшениями.

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

Вам необходимо определить набор критериев «выпуска». Они могут включать в себя:

• Среднее время между неудачами
• Количество дефектов, найденных за день
• Серьезность дефектов, найденных за день
• Количество недочетов

и т.п.

Затем в конце каждой итерации, когда некоторые люди проводят тестирование (вручную или путем написания автоматических тестов), а другие исправляют проверку, чтобы убедиться, что вы соответствуете вашим критериям. Если у вас есть, отпустите, если нет, то перейдите на другую итерацию.

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

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

Еще один способ сделать это - просто написать историю, которая гласит: «Исправьте ошибки, обнаруженные в интеграционном тестировании». Из предыдущих выпусков у вас должно быть представление о том, сколько проблем обычно обнаруживается и насколько сложно их решить, чтобы вы могли назначать сюжетные пункты на основе этих знаний. Вы можете разделить его на компоненты, если это сделает его более управляемым. В этом всегда есть неизбежная неопределенность. Добавьте несколько дополнительных очков истории, чтобы объяснить это.

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