Все о SCRUM. Изучение, разработка, интеграция

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

Задачи, касающиеся модульных тестов, в плане спринта могут быть указаны отдельно или включены в блок задач, относящихся к коду. Это зависит от опыта команды: если среди участников новички, лучше будет сделать отдельную запись.

Для существующего ПО – чтобы погасить технический долг

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

Встает вопрос о способах возврата технического долга.

Прежде чем приступить непосредственно к погашению этого долга, следует определить компоненты, нуждающиеся в рефакторинге, и порядок работы над ними.

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

19.1.3 Парное программирование

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

Один разработчик сидит за клавиатурой, другой следит за экраном, предлагая идеи. Совместная работа выполняется с двух точек зрения: первая направлена на детали кода, а вторая – на общую структуру.

Рисунок 19.2 – Игра в четыре руки

• Когда следует начать?

Момент начала использования этой практики – решение команды. Работать таким образом весь день невозможно, да и не требуется: процесс довольно интенсивный и напряженный. Необходимо регулярно меняться ролями внутри пары и между парами внутри команды. Обсуждать перемещения можно во время ежедневных схваток.

Эта практика особенно рекомендуется для сложных частей ПО.

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

Работа в паре ориентирована на улучшение качества продукта: технический долг всегда меньше в отношении тех частей, что реализованы двумя участниками.

Такой подход также упрощает обмен знаниями и компетенциями в команде.

Парное программирование – квинтэссенция совместной работы.

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

• Что дальше?

Пинг-понг программирование состоит в постоянной ротации двух участников: один пишет тест и передает управление другому, второй пишет код и делает рефакторинг, затем пишет тест – и они меняются.

Моб-программирование [59] расширяет эту практику до размеров всей команды.

Она может распространяться и за пределами команды разработчиков: пары могут состоять из участника команды и Владельца продукта или даже кого-то из заинтересованных сторон.

Вот почему работа в паре – это, скорее, практика совместной работы, нежели программирования.

19.2 Практики, относящиеся к проектированию

Ранее различали этапы предварительного проектирования и рабочего проекта. Сейчас широко используется термин программная архитектура. Архитектура относится к организации компонентов и их взаимодействию. Проще говоря, архитектура глобальна и позволяет направлять выбор при проектировании компонента или разрабатывать историю.

19.2.1 Эволюционирующая архитектура

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

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

Чтобы снизить риски в отношении архитектуры, команда разрабатывает историю, значимую с точки зрения архитектуры, то есть касающуюся всех основных компонентов.

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