Scrum и XP: заметки с передовой (Книберг) - страница 49

• Для устранения тесного связывания между классами применяйте внедрение зависимостей на основе сеттеров (Setter Based Injection) (разумеется, за исключением случаев, когда такое связывание просто необходимо).

• Избегайте аббревиатур. Общеизвестные аббревиатуры, такие как DAO, допустимы.

• Методы, которые возвращают коллекции или массивы, не должны возвращать null. Возвращайте пустые коллекции и массивы вместо null.

Устойчивый темп / энергичная работа

Множество книг по Agile-разработке программного обеспечения утверждают, что затянувшаяся переработка ведёт к падению продуктивности.

После некоторых не вполне добровольных экспериментов на эту тему, я могу только согласиться с этим всем сердцем!

Около года назад одна из наших команд (самая большая) очень-очень много работала сверхурочно. Качество кода было ужасное, и большую часть времени команда «тушила пожары». У тестировщиков (которые тоже работали сверхурочно) не было ни малейшей возможности нормально протестировать систему. Наши пользователи были в ярости, а газетчики готовы были нас растерзать.

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

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

Как мы тестируем

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

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

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

Скорее всего, вам не избежать фазы приёмочного тестирования

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

А вот и нет!

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