38. Scrum процесс: доска задач и ее использование

Инструмент мониторинга и управления внутри спринта, доска задач, по функционалу похожа на аналогичный инструмент из канбана. Но поскольку в Scrum имеются фиксированные итерации, доска по завершении спринта «обнуляется» - с нее убираются все стикеры.

На стикерах указывается наименование истории пользователя, и они двигаются по соответствующим состояниям во время спринта.

В начале спринта все истории пользователей находятся в первом столбце, отсортированные вертикально по важности (рисунок 1).

По мере того, как истории пользователей реализуются, члены команды меняют статусы у задач, и доска к середине спринта выглядит примерно так (рисунок 2).

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

Еще один способ использования доски:

- Истории пользователей берутся достаточно большие (3-7 на спринт) и располагаются в отдельном столбце;

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

39.Разработка, управляемая тестированием (Test Driven Development)

Разработка через тестирование (англ. test-drivendevelopment, TDD) – техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки:

1. пишется тест, покрывающий желаемое изменение;

2. пишется код, который позволит пройти тест;

3. проводится рефакторинг нового кода к соответствующим стандартам.

Тест – это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода.

Рисунок 1 – Цикл разработки через тестирование

Преимущества

Согласно проведенным исследованиям использование TTD приводит к следующим улучшениям:

• повышение продуктивности программистов;

• снижение необходимости использовать отладчик;

• улучшение проектных решений;

• снижение временных затрат на разработку;

• упрощение процесса рефакторинга;

• обеспечение полного покрытия тестами;

• замена стандартной документации.

Слабые места в TTD

• к TDD сложно привыкнуть;

• существуют задачи, которые невозможно решить только при помощи тестов;

• сложно применять в тех случаях, когда для тестирования необходимо прохождение функциональных тестов;

• требуется больше времени на разработку и поддержку тестов, а одобрение со стороны руководства очень важно;

• проблемы с истолкованием требований к приложению;

• создание ложного ощущение надежности, приводящее к меньшему количеству действий по контролю качества;

• тесты сами по себе являются источником накладных расходов;

• уровень покрытия тестами, получаемый в результате разработки через тестирование, не может быть легко получен впоследствии

40.Разработка, управляемая поведением (Behavior Driven Development)

В программной инженерии, разработка управляемая поведением (англ, behavior-drivendevelopment, BDD) – это процесс разработки программного обеспечения, основанный на разработке управляемой тестированием (TDD).

BDD комбинирует основные техники и принципы TDD с идеями взятыми из проблемно-ориентированного проектирования (англ, domain-drivendesign) и объектно-ориентированного анализа и проектирования для предоставления разработчикам и бизнес-аналитикам разделяемых инструментов и процессов для взаимодействия в процессе разработки программных продуктов.

Принципы BDD

BDD – это специализированная версия TDD, которая сфокусирована спецификации поведения программных модулей.

TDD это методология разработки ПО, которая основывается на том, что для каждого модуля программы, разработчик должен:

• сначала определить набор тестов;

• затем реализовать модуль;

• в конце проверить, что реализация модуля успешно проходит все тесты.

BDD требует, что тесты любого программного модуля должны быть указаны в терминах желаемого поведения данного модуля.

Желаемое поведение, есть то, что имеет бизнес-значимость (ценность) для любого, кто эксплуатирует разрабатываемый программный модуль.

Спецификация поведения BDD

Заголовок

История должна иметь четкий и ясный заголовок.

Повествование

Короткая, вводная секция, которая описывает:

Приемочный критерий или сценарий

• Описание каждого отдельного случая повествования. Такой сценарий имеет следующую структуру:

• Он начинается с указания начальных условий, которые должны выполняться перед началом сценария. Это может состоять из одного или нескольких пунктов.

• Далее указывается, какое событие является началом выполнения сценария.

• В конце указывается ожидаемый результат в виде одного или нескольких пунктов.

Принципы инструментария

Специальный инструментарий BDD, как и TDD, это фреймворк для тестирования разрабатываемого ПО.

Принципом BDD инструментария является то, чтобы сделать документы требований напрямую исполняемыми наборами тестов. Точная реализация этого принципа зависит от конкретного инструмента, но в Agile-практике приняты следующие действия:

1. Инструмент читает спецификацию документа.

2. Инструмент точно понимает полностью формализированные части языка (например, термин Given) и, основываясь на этом, разбивает каждый сценарий на значимые части.

3. Каждая часть в сценарии трансформируется в некий параметр для теста в истории пользователя. Эта часть работы требует знания специфики проекта разработчиками.

4. Фреймворк затем выполняет тест для каждого сценария, используя его параметры