[Закрываются] гибкие истории и задачи
Эта функция проверит, находится ли время между часами в EST, приняв 2 параметра, массивы с часами и am / pm ...
/**
* Check if between hours array(12,'pm'), array(2,'pm')
*/
function is_between_hours($h1 = array(), $h2 = array())
{
date_default_timezone_set('US/Eastern');
$est_hour = date('H');
$h1 = ($h1[1] == 'am') ? $h1[0] : $h1[0]+12;
$h1 = ($h1 === 24) ? 12 : $h1;
$h2 = ($h2[1] == 'am') ? $h2[0] : $h2[0]+12;
$h2 = ($h2 === 24) ? 12 : $h2;
if ( $est_hour >= $h1 && $est_hour <= ($h2-1) )
return true;
return false;
}
4 ответа
Обычно я стараюсь, чтобы размер моих пользовательских историй составлял от 1 до 10 человеко-дней для завершения. Это не позволяет мне передавать разработчикам то, что Майк Кон называет «Эпиками» или «Темами», в качестве пользовательских историй, и, с другой стороны, мешает моим пользовательским историям быть настолько конкретными, чтобы подразумевать решение (они должны описывать проблему, не то, как это должно быть решено).
Что касается содержания, я удостоверяюсь, что мои истории содержат только деловую ценность - они никогда не описывают , как я (должен) удовлетворять спрос, и это не так » для понимания требуются "знания, не относящиеся к пользовательской области.
Хороший пример: Как менеджер контента, я хочу, чтобы все пользователи должны были войти в систему перед тем, как написать ответ, чтобы лишить их возможности рассылать спам .
Плохой пример: Добавить капчу на веб-сайт.
Задачи, с другой стороны, представляют собой шаги к решению решения - они описывают компоненты и функции, которые необходимо добавить / изменить. Вот здесь-то и появляется решение «Добавить капчу». Что касается размера, я стараюсь, чтобы размер каждой задачи составлял от 1/2 до 2–3 рабочих дней.
Задачи также включают набор стандартных задач, которые применяются к каждой функции / требованию / проблеме / ошибке, например:
- Документ
- Написание тестовых примеров
- Ручное тестирование
- Написание автоматизированных функциональных тестов Размер s должен составлять от 1/2 дня до 2-3 рабочих дней.
Задачи также включают набор стандартных задач, которые применяются к каждой функции / требованию / проблеме / ошибке, например:
- Документ
- Написание тестовых примеров
- Ручное тестирование
- Написание автоматизированных функциональных тестов Размер s должен составлять от 1/2 дня до 2-3 рабочих дней.
Задачи также включают набор стандартных задач, которые применяются к каждой функции / требованию / проблеме / ошибке, например:
- Документ
- Написание тестовых примеров
- Ручное тестирование
- Написание автоматизированных функциональных тестов и т.д.
Надеюсь, это поможет, Ассаф.
Пока у вас есть пользователи, пользовательские истории могут быть связаны с тем, что пользователи могут делать. Если вы предоставляете API другим разработчикам, то они ваши пользователи. На этом этапе все станет более техническим (например, пользователь может обновлять записи сотрудников)
Я основываю истории на публичном интерфейсе классов. Для детализации задачи я рассчитываю объем работы от полдня до двух дней.
Пользователь / исполнитель может быть системой, не обязательно человеком. Ваши службы будут иметь API, ожидаемые входные данные и результаты, а также соглашения об уровне обслуживания (нефункциональные требования). Все это можно указать в карточке истории.
Самое главное, что ваша карточка истории должна указывать критерии приема. Критерии соответствия помогут продвигать разработчиков Test Deiven Development Unit Tests, автоматизированных функциональных тестов и автоматизированных тестов производительности. Если критерии приемки соблюдены, карта принимается и утверждается владельцем продукта.