Критерий готовности

Критерий готовности

Важно, чтобы и product owner, и команда совместными усилиями определили критерий готовности. Можно ли считать историю готовой, если весь код был добавлен в репозиторий? Или же она считается готовой, лишь после того как была развёрнута на тестовом сервере и прошла все интеграционные тесты? Где только это возможно, мы используем следующее определение критерия готовности: «история готова к развёртыванию на живом сервере», однако, иногда мы вынуждены иметь дело с определением типа «развёрнуто на тестовом сервере и готово к приёмочному тестированию».

Поначалу мы использовали детализированные контрольные листы для определения того, что история готова. А сейчас мы часто просто говорим: «история готова тогда, когда так считает тестировщик из нашей Scrum-команды». В этом случае проверка того, что пожелания product owner’а были правильно восприняты командой, остаётся на совести тестировщика. В его задачи также входит контроль того, что история достаточно «готова» для того, чтобы удовлетворить принятому критерию готовности.

В конце концов, мы осознали, что нельзя все истории ровнять под одну гребёнку. История «форма поиска пользователей» будет очень сильно отличаться от истории под названием «руководство по эксплуатации». В последнем случае «готово» может просто означать «принято отделом поддержки клиентов». Поэтому здравый смысл часто лучше, чем формальный контрольный лист.

Если вы часто путаетесь с определением критерия готовности (как это было поначалу у нас), то вам, наверное, стоит ввести поле «критерий готовности» для каждой истории.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Определение «готовности»

Из книги автора

Определение «готовности» Проблема ложной готовности решается созданием независимого определения «готовности». Для этого следует поручить бизнес-аналитикам и специалистам по тестированию создать автоматизированные приемочные тесты,[17] без прохождения которых


6.4.3.1. Критерий Limit

Из книги автора

6.4.3.1. Критерий Limit Должен подгружаться явно ключом -m limit. Прекрасно подходит для правил, производящих запись в системный журнал (logging) и т.п. Добавляя этот критерий, мы тем самым устанавливаем предельное число пакетов в единицу времени, которое способно пропустить правило.


6.4.3.2. Критерий MAC

Из книги автора

6.4.3.2. Критерий MAC MAC (Ethernet Media Access Control) критерий используется для проверки исходного MAC-адреса пакета. Расширение -m mac, на сегодняшний день, предоставляет единственный критерий, но возможно в будущем он будет расширен и станет более полезен.ПРИМЕЧАНИЕ: Модуль расширения


6.4.3.3. Критерий Mark

Из книги автора

6.4.3.3. Критерий Mark Критерий mark предоставляет возможность «пометить» пакеты специальным образом. Mark – специальное поле, которое существует только в области памяти ядра и связано с конкретным пакетом. Может использоваться в самых разнообразных целях, например, ограничение


6.4.3.4. Критерий Multiport

Из книги автора

6.4.3.4. Критерий Multiport Расширение multiport позволяет указывать в тексте правила несколько портов и диапазонов портов.ПРИМЕЧАНИЕ: Вы не сможете использовать стандартную проверку портов и расширение -m multiport (например –sport 1024:63353 -m multiport –dport 21,23,80) одновременно. Подобные правила


6.4.3.5. Критерий Owner

Из книги автора

6.4.3.5. Критерий Owner Расширение owner предназначено для проверки «владельца» пакета. Изначально данное расширение было написано как пример демонстрации возможностей iptables. Допускается использовать этот критерий только в цепочке OUTPUT. Такое ограничение наложено потому, что на


6.4.3.6. Критерий State

Из книги автора

6.4.3.6. Критерий State Критерий state используется совместно с кодом трассировки соединений и позволяет нам получать информацию о признаке состояния соединения, что позволяет судить о состоянии соединения, причем даже для таких протоколов как ICMP и UDP. Данное расширение


6.4.3.7. Критерий TOS

Из книги автора

6.4.3.7. Критерий TOS Критерий TOS предназначен для проведения проверки битов поля TOS. TOS – Type Of Service – представляет собой 8-ми битовое, поле в заголовке IP-пакета. Модуль должен загружаться явно, ключом -m tos.От переводчика: Далее приводится описание поля TOS, взятое не из оригинала,


6.4.3.8. Критерий TTL

Из книги автора

6.4.3.8. Критерий TTL TTL (Time To Live) является числовым полем в IP заголовке. При прохождении очередного маршрутизатора, это число уменьшается на 1. Если число становится равным нулю, то отправителю пакета будет передано ICMP сообщение типа 11 с кодом 0 (TTL equals 0 during transit) или с кодом 1 (TTL


6.4.4. Критерий «мусора» (Unclean match)

Из книги автора

6.4.4. Критерий «мусора» (Unclean match) Критерий unclean не имеет дополнительных ключей и для его использования достаточно явно загрузить модуль. Будьте осторожны, данный модуль находится еще на стадии разработки и поэтому в некоторых ситуациях может работать некорректно. Данная


1. Определение даты готовности инфопродукта к продаже

Из книги автора

1. Определение даты готовности инфопродукта к продаже Мы уже определили тему и название инфопродукта, поэтому сразу переходим ко второму пункту. Назначьте дату, когда вам нужно приступить к созданию следующего продукта. Один из важнейших принципов тайм-менеджмента


2.1.13. Определение готовности сокета

Из книги автора

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


Состояние готовности

Из книги автора

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


Критерий хи-квадрат

Из книги автора

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


Оценка готовности к развертыванию

Из книги автора

Оценка готовности к развертыванию Многие компании берутся за развертывание крупномасштабных систем типа PKI, не имея необходимых ресурсов. Поскольку развертывание PKI требует значительных капиталовложений, для принятия решения необходима оценка материальных ресурсов и