Изучайте одну новую вещь каждый день
Таблица решений — это отличный инструмент для использования как в тестировании, так и в управлении требованиями. По сути, это структурированное упражнение для формулирования требований при работе со сложными бизнес-правилами. В таблице решений бизнес-логика хорошо делится на условия, действия (решения) и правила для представления различных компонентов, формирующих бизнес-логику.
Продолжить чтение
Мы постоянно сталкиваемся с этими терминами при разработке программного обеспечения. Иногда люди называют часть программного продукта — требование/случай использования, элементы бэклога ….. Что принято использовать в программном обеспечении: «это» или «что»?
Продолжить чтение
В разработке программного обеспечения обычная «оценка» включает количественную оценку работы, необходимой для выполнения данной задачи разработки; она обычно выражается в терминах продолжительности (час / день) или расчетной единицы (сюжетная точка). Цель состоит в том, чтобы объединить ряд таких индивидуальных оценок, чтобы получить представление об общей продолжительности, работе или стоимости проекта программного обеспечения.
Продолжить чтение
Диаграмма вариантов использования UML — это основная форма требований к системе/программному обеспечению для разрабатываемой новой программы. Варианты использования определяют ожидаемое поведение (что) системы, а не точный метод его реализации (как). Полный набор вариантов использования определяет все различные способы использования системы и, следовательно, определяет все поведение, требуемое от системы, ограничивая область применения системы.
Продолжить чтение
Пример использования — это письменное описание того, как пользователь выполняет задачу в вашей системе. Он описывает поведение системы с точки зрения пользователя при ответе на запрос. Каждый вариант использования представлен в виде последовательности простых шагов, начинающихся с цели пользователя и заканчивающихся, когда цель достигнута.
Продолжить чтение
Use Case 2.0 — это масштабируемый и гибкий подход, который использует сценарии использования для фиксации требований и стимулирования постепенной разработки системы для их выполнения. Он помогает понять, как будет использоваться система, и ведет вас через разработку соответствующей системы для поддержки пользователей.
Продолжить чтение
Диаграмма вариантов использования моделирует различные типы пользователей, взаимодействующих с системой для решения проблемы. Как таковая, она описывает цели пользователей, взаимодействие между пользователями и системой, а также требуемое поведение системы при удовлетворении этих целей. Варианты использования определяют взаимодействие между внешними участниками и системой для достижения определенных целей. Диаграмма вариантов использования содержит четыре основных компонента
Продолжить чтение
Летом 2011 года Кен Швабер и Джефф Сазерленд пересмотрели свое руководство по Scrum. В нем они убрали одно давно установленное поведение, известное в Scrum, — обязательство, которое команда берет на себя перед владельцем продукта и клиентами. Обязательство было заменено прогнозом. Они говорят, что команды могут прогнозировать свою работу, но не брать на себя обязательства.
Продолжить чтение
Definition of Done (DoD) — это список требований, которым должна соответствовать история пользователя, чтобы команда могла назвать ее завершенной. В то время как критерии приемки пользовательской истории состоят из набора тестовых сценариев, которые должны быть выполнены для подтверждения того, что программное обеспечение работает так, как ожидалось.
Продолжить чтение
Каждый спринт заканчивается собранием по обзору спринта, состоящим из двух частей. Такая встреча начинается с обзора и демонстрации заказчику и заканчивается ретроспективой команды. Оба этих компонента проводятся в последний день спринта. Обзор спринта фокусируется на «проверке» и «адаптации» инкрементов (потенциально отгружаемых), в то время как ретроспектива спринта уделяет больше внимания «проверке» и «адаптации» процесса спринта.
Продолжить чтение