Оценка времени для пользовательской истории
Взято из документов
отметка времени является синонимом для типа данных rowversion и зависит от поведения синонимов типа данных. В выражениях DDL везде, где это возможно, используйте метку строки вместо метки времени. Для получения дополнительной информации см. Синонимы типов данных (Transact-SQL).
blockquote>и
Синтаксис метки времени устарел.
blockquote>и
Тип данных, который предоставляет автоматически генерируемые уникальные двоичные числа в базе данных. rowversion, как правило, используется в качестве механизма для строк таблицы штампов версий. Размер хранилища составляет 8 байт.
blockquote>Итак, соберите все вместе: представьте
TIMESTAMP(который должен бытьROWVERSION) как бессмысленный 8-байтовый двоичный файл. Если вы действительно хотите что-то с этим сделать, вы можете сохранить его как 8-байтовый двоичный файл или преобразовать его в тип длиной 8 байт. В этом случае я бы предложилBIGINT.
4 ответа
Большая техника для этого состоит в том, чтобы сломать историю к несколько меньшим задачам и оценить их друг по сравнению с другом (вместо абсолютно). Таким образом, можно сказать:
- Задача A возьмет 2 (произвольные) единицы
- Задача B приблизительно в 2 раза более сложна, чем Задача A (4 единицы)
- Задачей C является приблизительно половина, усложнил (1 единица)
Мы лучше в оценке относительной сложности, чем абсолютная сложность. Затем Вы на самом деле выполняете одну из задач и выясняете, сколько "реального времени" требуетесь Вы для реализации 1 единицы - теперь можно вычислить все задачи. Вы продолжаете обновлять свои оценки согласно тому, как Вы прогрессируете.
Эта техника от Гибкой Оценки и Планирования Mike Cohn, который является замечательной книгой по предмету.
Steve McConnel по "оценке программного обеспечения - demystifiying черная магия," сказал это лучше, чем, я буду:
"Количество, если вообще возможный. Вычислите, когда Вы не сможете рассчитать. Используйте одно только суждение только как последнее прибежище".
Глава 7 - количество, вычислите, судья (PDF).
(благодарит напомнить мне об этом :)
В школе XP гибкой разработки они защищают это, Вы не оцениваете в фактическое время, но в произвольных единицах. (Они используют "Липкие Переносы", но можно использовать что). Вы присваиваете свое лучшее предположение относительно количества единиц, которые оно возьмет для реализации той пользовательской истории.
Правда, Вы могли бы быть неправыми, но Вы поразите фазу в своей разработке, несколько повторений в, когда Ваши предположения будут главным образом правильными, и для бизнеса/клиента легко получить точный бюджет того, сколько историй они могут включать в повторение.
Хорошее эмпирическое правило вначале, когда трудно оценить, состоит в том, чтобы взять одну из Ваших самых легких задач и выделить это в значении 1. Оцените друг друга пользовательская история относительно той и выскажите свое лучшее предположение. Если что-то будет слишком сложно, или не ясно определенное достаточно, то Вы будете вынуждены дать ему действительно большое количество.
Другое ключевое понятие - то, что необходимо переоценить времена для каждой пользовательской истории каждое повторение. Поскольку Ваши истории поправляются определенные, и как Ваша оценка Вашей скорости улучшается, Вы получите более точные времена на своих историях.
Что касается неожиданностей, это действительно не опирается на оценку пользовательских историй..., так как у Вас нет пользовательских историй для представления неожиданностей.
Техника реализовала, где я работаю. Для каждого пользователя история пишут это на части карты с заголовком. Заставьте каждого человека брать карту и запись на ней число часов, они думают, что она возьмет для завершения. Заставьте их помещать карты против задачи, не показывая их друг другу. После того как Вы имеете все результаты во взгляде на числа и видите главные и минимальные значения. Вы будете обычно получать числа вполне друг близко к другу.
Для тех значений путь выше или значительно ниже спрашивает разработчика или человека с входом, почему они думают, что он занял бы много времени или настолько короткий по сравнению со средним числом. Придумывание согласия от команды в противоположность человеку означает, что все получают их взятие на задаче.
Это - идея из книги, которую я прочитал на гибких методах и забыл автора для приписывания им ее.