Как я получаю достаточную деталь в планировании и оценке при использовании TDD? [закрытый]
Быстрый Google указывает на меня на то, что похоже , решение .
Открывает Ваш EDMX в редакторе файлов (или “open with†¦ ” в Visual Studio и выбирает XML-редактор). Наверху Вы найдете модель хранения, и она имеет атрибут ProviderManifestToken. Это имеет, должен иметь значение 2008. Изменение, что к 2005, перекомпилируйте, и все работает.
ПРИМЕЧАНИЕ: необходимо будет сделать этот каждый раз, когда Вы обновляете модель от базы данных.
2 ответа
В Agile и задачи, и оценки - это подвижные вещи, которые постоянно меняются.
Итак, вы можете начать с (имейте в виду, что это очень общие примеры):
- История: Переименовать файл
- Задача: исследовать проблему и разобрать (0d / 5d)
Первые разработчики берут на себя эту задачу и разбивают ее по ходу:
- История: переименовать файл
- Задача: исследовать проблему и разбить ее (4 часа / завершить)
- Задача: 1-я часть (0d / 2d)
- Задача: 2-я часть (0d / 3d)
Затем по мере продвижения эти обновления будут получать больше точный. Новые задачи добавляются и разделяются по мере появления:
- История: переименовать файл
- Задача: исследовать проблему и разбить ее (4 часа / выполнить)
- Задача: 1-я часть (4 часа / 7 часов)
- Задача: 2-я часть (1 час / 20 часов)
- Задача: новая задача, реализованная во время работы над x (0h / 5h)
Неважно, используете ли вы Scrum, Crystal, XP, TDD или любой другой гибкий вариант - все они полагаются на оценки жидкости.
Дело в том, что вы никогда не знаете, сколько времени что-то нужно сделать - просто сделайте свое предположение и пересматривайте его каждый день . Вы никогда не получите процесс, в котором не было бы неожиданностей, но с помощью Agile вы сможете управлять их воздействием.
Например, предположим, что происходит что-то неприятное:
- История: переименовать файл
- Задача: исследовать проблему и разбить (4 часа / выполнить)
- Задача: 1-я часть (10 часов / выполнить)
- Задача: 2-я часть (10 часов / 3 часа)
- Задача: новая задача реализована в процессе работы над x (3h / 1h)
- Задача: решить некорректную проблему, обнаруженную при работе над y (0h / 5d)
История теперь занимает больше времени, чем ожидалось, но все знают об этом и знают, почему, и вы можете с этим справиться.
Ваши задачи и их оценки постоянно меняются по мере выполнения работы. График выгорания - хороший индикатор того, сколько еще предстоит сделать команде. Я бы не стал заморачиваться со скоростью, но если вы сделаете это, сравните «выполненный объем» между разными итерациями, что даст вам некоторое представление о динамике проекта. Скорость работает только тогда, когда у вас очень последовательная длина итераций, размер команды и классификация (размер, сложность, сложность и т. Д.) Историй, поэтому я
Мы в TargetProcess используем более простые задачи для историй:
История: переименовать файл
- Задача: Спецификация (2 часа)
- Задача: Разработка (14 часов)
- Задача: Тестирование (6)
- Задача: обновление пользовательской документации (2 часа)
Если задача разработки занимает более 16 часов, это означает, что ее нужно разделить на несколько более мелких задач. На самом деле мы обычно не создаем задачи продолжительностью менее 2–3 часов.