У меня есть два связанных вопроса относительно Scrum.

Наша компания пытается это реализовать и, конечно, мы прыгаем через обручи.

Оба вопроса касаются вопроса «сделано значит сделано!»

1) Действительно легко определить «Готово» для задач, которые / имеют - четкие критерии приемлемости теста - полностью автономные - тестируются в конце тестерами

Что нужно делать с такими задачами, как: - проектирование архитектуры - рефакторинг - разработка некоторых служебных классов

Основная проблема в том, что это почти полностью внутренняя сущность, и нет способа проверить / протестировать ее извне.

В качестве примера реализация функции является своего рода бинарной - она выполнена (и проходит все тестовые случаи) или не выполнена (не проходите некоторые тестовые случаи).

Лучшее, что приходит мне в голову, - попросить другого разработчика пересмотреть эту задачу. Однако это никоим образом не дает четкого способа определить, полностью ли это сделано или нет.

Итак, вопрос в том, как вы определяете «Готово» для таких внутренних задач?

2) Задача отладки / исправления ошибок

Я знаю, что гибкая методология не рекомендует иметь большие задачи. По крайней мере, если задача большая, ее следует разделить на более мелкие задачи.

Допустим, у нас есть довольно большая проблема - какая-то большая модернизация модуля (чтобы заменить новую устаревшую архитектуру новой). Конечно, эта задача делится на десятки небольших задач. Однако я знаю, что в конце у нас будет довольно длительный сеанс отладки / исправления.

Я знаю, что это обычно проблема модели водопада. Тем не менее, я думаю, что трудно избавиться от этого (особенно для довольно больших изменений).

Должен ли я выделить специальную задачу для отладки / исправления / интеграции системы и т. Д.?

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

Мне не нравится этот путь из-за этой огромной монолитной задачи.

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

Мне не нравится этот путь, потому что в этом случае вся оценка станет поддельной. Мы оцениваем задачу, помечаем ее как выполненную в любое время. И мы откроем новые задачи для ошибок с новыми оценками. Итак, мы получим реальное время = приблизительное время, что определенно не хорошо.

Как вы решаете эту проблему?

С уважением, Виктор