Чистый Agile. Основы гибкости

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

Чтобы достичь этого, организации требуется разорвать связь между релизом и развертыванием. Понятие «релиз» означает, что программа технически готова к развертыванию. Решение о развертывании полностью ложится на плечи клиентов.

Возможно, вы заметили, что теми же самыми понятиями мы описывали итерации. Итерации с технической точки зрения можно развертывать. Если продолжительность итерации составляет две недели, но мы хотим выпускать релизы чаще, придется итерации сократить.

Можно ли сокращать итерации асимптотически, стремясь к нулю? Да, можно. Но это уже тема отдельного разговора.

Приемочное тестирование

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

Проблема, несомненно, в понимании слова «указывает». Многие клиенты считают, что могут, поводив руками в воздухе, расплывчато и туманно описать функционал, а потом произойдет чудо — разработчики сами догадаются обо всех мельчайших нюансах. А многие программисты хотят, чтобы клиенты точно объяснили, как должна работать программа, вплоть до координат и цвета каждого пикселя на экране.

Из этих двух крайностей нужно вывести золотую середину.

Что же такое спецификация? Спецификация по своей сути — это функция, которую можно протестировать. Например:

Когда пользователь вводит правильное имя учетной записи и пароль, а потом нажимает «войти», на экране появится страница приветствия.

Вот это и есть указание, то есть спецификация. Очевидно, что это можно протестировать.

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

Вот так работает приемочное тестирование. Опыт подсказывает, что насколько это вообще осуществимо, требования к системе должны представлять собой автоматизированные тесты.

Погодите! А кто же пишет эти тесты? Первый абзац этого раздела отвечает на наш вопрос: требования указывает клиент. Тогда получается, что клиенты должны писать автоматизированные тесты, ведь так?

Погодите! Автоматизированные тесты должны быть написаны на каком-то формальном исполняемом языке. И это работа для программистов, не иначе! Получается, что программистам придется писать эти тесты?

Погодите! Если программисты будут писать тесты, то это будет не то, чего хочет клиент. Это будут технические тесты с множеством нюансов, понятных только программистам. Они не отражают ценность тестируемого элемента для клиента. Тогда автоматизированные тесты будет писать клиент? Ведь так?

Погодите! Если автоматизированные тесты будет писать клиент, то они не будут соответствовать технологии, которую мы используем. И программистам тогда придется их переписывать, не так ли?

Вот тут-то и становится понятно, почему этот метод вводит многих людей в заблуждение.

Инструменты и методологии

А еще хуже то, что наш метод погряз в инструментах и методологиях.

Пытаясь облегчить клиентам написание автоматизированных тестов, программисты написали целое изобилие инструментов, оказывающих медвежью услугу. Имеются в виду поделки вроде FitNesse, JBehave, SpecFlow и Cucumber. Каждый из этих инструментов предоставляет формы, призванные отделять техническую сторону автоматизированного теста от пользовательской. Гипотеза состоит в том, что клиент может написать пользовательскую часть автоматизированного теста, в то время как программисты могут написать код, связывающий эти тесты с тестируемой программой.

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

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

Они предпочтут посмотреть на работающую программу или в лучшем случае доверят тестирование QA-специалистам.

Разработка через поведение