Спустя несколько месяцев мы смогли уменьшить количество переработки до приемлемого уровня. Люди перестали работать сверхурочно (кроме редких кризисов в проекте), и — вот сюрприз! — и производительность, и качество кода заметно улучшились.

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

Это самая сложная часть. Вот только я не уверен, то ли это самая сложная часть Scrum'а, то ли разработки программного обеспечения в целом.

Организация тестирования может достаточно сильно отличаться в различных компаниях. Всё зависит от количества тестировщиков, уровня автоматизации тестирования, типа системы (просто сервер + интернет приложение или, возможно, вы выпускаете «коробочные» версии программ?), частоты релизов, критичности ПО (блог-сервер или система управления полётами) и т. д.

Мы довольно много экспериментировали, чтобы понять, как организовать процесс тестирования в Scrum'е. Сейчас я попытаюсь рассказать о том, что мы делали и чему мы успели научиться за это время.

В идеальном мире Scrum’а результатом каждого спринта должна быть система, потенциально готовая к использованию. Бери и устанавливай, да?

А вот и нет!

По нашему опыту, такой подход обычно не работает. Там будет куча противных багов. Если «качество» для вас хоть что-нибудь значит, тогда придётся позаботиться о ручном приёмочном тестировании. Это когда специально выделенные тестировщики, которые не являются частью команды, бомбят систему теми видами тестов, о которых Scrum-команда не могла даже и подумать, или на которые у неё не было времени, или соответствующего оборудования. Тестировщики работают с системой точно так же, как и пользователи, а значит, что это нужно делать вручную (если, конечно же, ваша система разработана для людей).

Команда тестировщиков найдёт баги, Scrum-команде придётся подготовить версию с исправленными багами, и рано или поздно (будем надеяться что рано) вы сможете выпустить для своих пользователей версию 1.0.1 с необходимыми исправлениями. Она будет куда более стабильной, чем глючная 1.0.0.

Когда я говорю «фаза приёмочного тестирования», я имею в виду весь период тестирования, отладки и перевыпуска, пока версия не будет достаточно хороша для выхода в свет готового продукта.

Приёмочное тестирование, мягко говоря, приносит некоторые неудобства. Оно определённо не имеет ничего общего с гибкими методологиями. И, несмотря на то, что мы не можем избавиться от этой фазы, мы можем попробовать свести её к минимуму. А если точнее, уменьшить количество времени, которое для него необходимо. Этого можно достигнуть следующими способами:

• Максимально улучшить качество исходного кода, создаваемого Scrum-командой.

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

Так как же мы можем поднять качество кода команды? Ну, вообще-то способов существует очень много. Я остановлюсь на тех, которые, как нам показалось, действуют лучше всего:

• Включите тестировщиков в Scrum-команду.

• Делайте меньше за спринт.

О, я уже слышу эти возражения:

«Но это же очевидно! Scrum-команды должны быть кросс-функциональными!»

«В Scrum-команде не должно быть выделенных ролей! У нас не может быть человека, занимающегося только тестированием!»

Я бы хотел кое-что разъяснить. В данном случае, под «тестировщиком» я подразумеваю человека, главная специализация которого тестирование, а не человека, чья роль — это исключительно тестирование.