ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 365
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Глава 3. Методы взаимодействия с клиентами
130
проекта . Но после первых нескольких итераций точность графика возрастет и достигнет уровня, позволяющего четче определить ис- тинную скорость выполнения работ .
Мы ожидаем, что после нескольких первых итераций угол наклона приблизится к нулю, то есть график примет горизонтальный вид .
Мы не ждем от команды ускорения или замедления в долгосроч- ной перспективе .
Возрастание скорости
Если мы видим, что график пополз вверх, это вряд ли означает, что команда действительно стала работать быстрее . Скорее всего, это означает, что менеджер проекта выжимает из разработчиков все соки, подгоняя их . Как только руководство прибегает к давлению, то команда бессознательно начинает мухлевать с оценками, чтобы создать впечатление, будто стала работать быстрее .
Это обычное надувательство . Единицы сложности можно предста- вить как своеобразную валюту, которая обесценивается командой из-за напряжения, создаваемого извне . Вернемся к такой команде через год, и что мы увидим? Этих единиц за итерацию у них будет больше 9000! Мораль такова, что не нужно гнаться за скоростью — это всего лишь способ измерения . Зарубите себе на носу: нельзя подгонять то, что измеряешь .
Оценка итерации на встрече по планированию проводится лишь затем, чтобы дать знать заинтересованным сторонам, сколько историй возможно выполнить . Она помогает выбирать истории и планировать их выполнение . Однако такая оценка не является обязаловкой — ни о какой провальной итерации не идет речи, если скорость вдруг оказалась ниже . Помните, что только та итерация провальна, из которой не удалось получить данных .
Небольшие частые релизы
131
Снижение скорости
Если график скорости неуклонно ползет вниз, то, скорее всего, причина в качестве кода . Команда, вероятнее всего, проводит мало рефакторинга, и код начинает портиться . Одна из причин нехватки рефакторинга — команда пишет недостаточно модульных тестов и боится, что из-за рефакторинга перестанет работать то, что рабо- тало прежде . Борьба с этим страхом — важнейшая задача лидеров команды разработчиков, она полностью зависит от дисциплины при тестировании . Подробнее об этом дальше .
Когда скорость падает, усиливается давление на команду . Это ве- дет к обесцениванию единиц сложности . И за таким раздуванием единиц может скрываться падение скорости выполнения проекта .
Золотая история
Один из способов избежать обесценивания единиц сложности историй — постоянно сравнивать истории с первоначальным «зо- лотым эталоном», историей, с которой сравнивают все остальные .
Вспомните, нашей первоначальной «золотой» историей был вход, который мы оценивали в 3 единицы . Если новая история, например
исправить опечатку в меню, оценена в 10 единиц, то очевидно, что оценка этой истории раздута .
НЕБОЛЬШИЕ ЧАСТЫЕ РЕЛИЗЫ
Согласно методу «небольшие и частые релизы», команде разработ- чиков нужно выпускать релизы своего программного обеспечения как можно чаще . В конце девяностых, когда Agile только появился, мы думали, что норма — это выпуск релиза раз в месяц-два . Но сейчас этот срок стал гораздо короче . Сокращать срок можно до
Глава 3. Методы взаимодействия с клиентами
132
бесконечности . Увеличение частоты релизов происходит благодаря
непрерывной доставке (continuous delivery) . Этот метод заключа- ется в том, что релиз происходит после каждого изменения кода .
Это толкование может ввести в заблуждение, потому что выраже- ние «непрерывная доставка» создает впечатление, что мы хотим сделать короче только цикл доставки . Это не так, мы хотим со- кратить каждый цикл .
К сожалению, в силу исторических обстоятельств мы имеем пре- пятствие в виде некой значительной инерции . Эта инерция — руди- мент тех способов, к которым мы прибегали при работе с исходным кодом, когда трава была зеленее, а деревья выше .
Краткая история управления
исходным кодом
История управления исходным кодом — это повесть о циклах и их размерах . Она берет начало в 1950–1960-х годах, когда исходный код хранили в отверстиях, пробитых на кусочках бумаги (рис . 3 .3) .
Рис. 3.3. Перфокарта
Небольшие частые релизы
133
Многие из нас тогда пользовались перфокартами . Карта вмещала на себе 80 символов и представляла собой одну строку программ- ного кода . Сама программа занимала целую колоду таких карт .
Обычно их перетягивали резинкой и хранили в коробке (рис . 3 .4) .
Рис. 3.4. Колоды перфокарт в коробке
Владелец программы хранил колоду перфокарт в выдвижном ящи- ке или шкафчике . Если кому-то нужно было проработать исходный код, это приходилось делать прямо из ящика или шкафчика с по- зволения владельца .
Глава 3. Методы взаимодействия с клиентами
134
Если у вас получилось проверить исходный код, то вы были един- ственным, кто мог внести в него изменения, поскольку имели возможность физически посмотреть перфокарты . Больше никто не мог их касаться . Когда дело было сделано, нужно было отдать колоду владельцу, который клал ее в ящик или шкафчик .
Цикл для этой программы составлял столько, сколько времени у программиста был к ней физический доступ . Счет мог идти на дни, недели, месяцы .
Ленты
В 1970-х мы плавно перешли к тому, что стали хранить образы перфокарт с исходным кодом на магнитной ленте . На магнитной ленте можно держать большое количество программных модулей, а еще ее было проще копировать . Редактирование модулей вы- глядело так:
1 . Достать главную ленту с оригиналом из главной стойки .
2 . Скопировать модули, которые нужно отредактировать, с глав- ной ленты на ленту с рабочей копией .
3 . Положить главную ленту на место, чтобы другие могли полу- чить доступ к прочим модулям .
4 . Воткнуть цветную кнопку на доску выдачи рядом с названием модулей, которые нужно отредактировать . (У меня была синяя, у начальника красная, у остальных программистов из моей коман- ды были желтые . Да-да, в конце концов у нас закончились цвета .)
5 . Редактировать, компилировать и тестировать на ленте с рабочей копией .
Небольшие частые релизы
135
6 . Снова достать главную ленту .
7 . Скопировать измененные модули с ленты с рабочей копией на главную ленту .
8 . Положить обновленную главную ленту в стойку .
9 . Вынуть кнопку из доски .
И снова цикл составлял ровно столько, сколько кнопка находилась на доске выдачи . Это могло занимать часы, могло дни и даже меся- цы . Покуда кнопка находилась на доске выдачи, никто больше не мог обращаться к модулям, которые вы закрепили за собой .
Разумеется, эти модули были и на главной ленте, и в крайнем случае кто-нибудь мог в обход правил отредактировать модули непосредственно на ней . Кнопки были условным соглашением, но никак не физической преградой .
Диски и системы управления
исходным кодом
В 1980-х годах исходные коды переместились на диски . Поначалу еще использовалась доска выдачи и кнопки, но потом начали по- являться настоящие средства управления исходным кодом . Первое из того, что я помню, — это Система управления исходным кодом
(SCCS) . Она работала по тому же принципу, что и доска выдачи .
Происходила блокировка модуля на диске, из-за чего никто не мог получить доступ к его редактированию . Такое блокирование называется пессимистическим . И снова то же самое . Длительность цикла зависела от длительности блокирования . Блокировка могла длиться часами, днями, а то и месяцами .
Глава 3. Методы взаимодействия с клиентами
136
На смену Системе управления исходным кодом пришла Система управления редакциями (RCS), которая, в свою очередь, уступи- ла место Системе одновременных версий (CVS) . Во всех так или иначе применялась пессимистическая блокировка . Поэтому цикл по-прежнему длился долго . Тем не менее хранение данных на диске было куда удобнее, чем на магнитной ленте . При копировании мо- дулей с оригинала на ленту с рабочей копией очень соблазнительно было сделать модули крупными сами по себе .
С другой стороны, диски позволяли нам стремительно уменьшать размер модулей . Множество маленьких модулей просто-напросто не вело к таким издержкам, как несколько крупных . За счет умень- шения модулей продолжительность цикла стала короче, поскольку количество времени, затрачиваемое на проверку модуля, также относительно уменьшилось .
Проблема состояла в том, что изменения в программе влекли за со- бой изменения во многих модулях . В случаях, когда модули были тесно связаны, на их проверку все еще уходило много полезного времени . Некоторые из нас научились отделять связанные модули, чтобы уменьшить эти сроки . А кто-то так и не научился .
Subversion
Потом пришло время системы Subversion (SVN) . В ней появи- лось оптимистическое блокирование . Оптимистическое бло- кирование по сути никакое и не блокирование . Разработчик мог проверять модуль одновременно с другим разработчиком .
Система позволяла отслеживать действия разработчиков и ав- томатически объединять изменения в модулях . Если система обнаруживала конфликт, когда два разработчика работали над одними и теми же строками кода, то вынуждала программиста
Небольшие частые релизы
137
сперва разрешить этот конфликт, прежде чем подтвердить при- нятые изменения .
Это значительно сократило продолжительность цикла до време- ни, требуемого на редактирование, компиляцию и тестирование последовательности небольших изменений . Связанность моду- лей еще представляла собой проблему . Тесно связанные модули замедляли цикл, потому что приходилось вносить изменения во много модулей одновременно . Однако программы, где модули не были так тесно связаны, проходили цикл гораздо быстрее . Сам срок проверки больше не служил ограничивающим фактором .
Git и тесты
В наши дни мы используем Git . Сроки проверки при использо- вании Git сошли на нет . Это понятие больше не существует . На- против, любое изменение в модуль можно внести когда угодно .
Программисты разрешают конфликты между этими изменениями, как и когда этого пожелают . Маленькие несвязанные модули по- зволяют молниеносно и часто вносить изменения . Поэтому циклы составляют считаные минуты . Добавьте к этому возможность создавать всеобъемлющие и быстрые тестовые наборы, которыми можно протестировать практически все . Вот вам и все нужное для непрерывной доставки .
Историческая инерция
К сожалению, организации с трудом отказываются от унасле- дованных подходов . Циклы продолжительностью в дни, недели и месяцы глубоко укоренились в культуре многих команд, от- куда затем перешли к QA-специалистам, менеджерам и даже заинтересованным сторонам . С колокольни такой «культуры»
Глава 3. Методы взаимодействия с клиентами
138
мысль о непрерывной доставке может показаться бредом сумас- шедшего .
Небольшие и частые релизы
Agile пытается порвать шаблоны исторической инерции, предлагая как можно сильнее сократить циклы релизов . Если у вас релиз про- исходит раз в полгода, постарайтесь выпускать раз в три месяца, раз в месяц, раз в неделю, в конце концов . Продолжайте уменьшать циклы релизов, асимптотически стремясь к нулю .
Чтобы достичь этого, организации требуется разорвать связь меж- ду релизом и развертыванием . Понятие «релиз» означает, что программа технически готова к развертыванию . Решение о раз- вертывании полностью ложится на плечи клиентов .
Возможно, вы заметили, что теми же самыми понятиями мы описы- вали итерации . Итерации с технической точки зрения можно развер- тывать . Если продолжительность итерации составляет две недели, но мы хотим выпускать релизы чаще, придется итерации сократить .
Можно ли сокращать итерации асимптотически, стремясь к нулю?
Да, можно . Но это уже тема отдельного разговора .
ПРИЕМОЧНОЕ ТЕСТИРОВАНИЕ
Приемочное тестирование — один из самых непонятных и запутан- ных методов Agile, который используется реже всего . Это любо- пытно, потому что основной посыл удивительно прост: требования указывает клиент .
Проблема, несомненно, в понимании слова «указывает» . Многие клиенты считают, что могут, поводив руками в воздухе, расплыв-
Приемочное тестирование
139
чато и туманно описать функционал, а потом произойдет чудо — разработчики сами догадаются обо всех мельчайших нюансах .
А многие программисты хотят, чтобы клиенты точно объяснили, как должна работать программа, вплоть до координат и цвета каж- дого пикселя на экране .
Из этих двух крайностей нужно вывести золотую середину .
Что же такое спецификация? Спецификация по своей сути — это функция, которую можно протестировать . Например:
Когда пользователь вводит правильное имя учетной записи и па-
роль, а потом нажимает «войти», на экране появится страница
приветствия.
Вот это и есть указание, то есть спецификация . Очевидно, что это можно протестировать .
Очевидно, что тест для этой функции можно автоматизировать .
Нет причин на то, чтобы компьютер не мог удостовериться в вы- полнении указанного требования .
Вот так работает приемочное тестирование . Опыт подсказывает, что насколько это вообще осуществимо, требования к системе должны представлять собой автоматизированные тесты .
Погодите! А кто же пишет эти тесты? Первый абзац этого раздела от- вечает на наш вопрос: требования указывает клиент . Тогда получает- ся, что клиенты должны писать автоматизированные тесты, ведь так?
Погодите! Автоматизированные тесты должны быть написаны на каком-то формальном исполняемом языке . И это работа для про- граммистов, не иначе! Получается, что программистам придется писать эти тесты?
Глава 3. Методы взаимодействия с клиентами
140
Погодите! Если программисты будут писать тесты, то это будет не то, чего хочет клиент . Это будут технические тесты с множеством нюансов, понятных только программистам . Они не отражают цен- ность тестируемого элемента для клиента . Тогда автоматизирован- ные тесты будет писать клиент? Ведь так?
Погодите! Если автоматизированные тесты будет писать клиент, то они не будут соответствовать технологии, которую мы используем .
И программистам тогда придется их переписывать, не так ли?
Вот тут-то и становится понятно, почему этот метод вводит многих людей в заблуждение .
Инструменты и методологии
А еще хуже то, что наш метод погряз в инструментах и методоло- гиях .
Пытаясь облегчить клиентам написание автоматизированных тестов, программисты написали целое изобилие инструментов, оказывающих медвежью услугу . Имеются в виду поделки вроде
FitNesse, JBehave, SpecFlow и Cucumber . Каждый из этих инстру- ментов предоставляет формы, призванные отделять техническую сторону автоматизированного теста от пользовательской . Гипотеза состоит в том, что клиент может написать пользовательскую часть автоматизированного теста, в то время как программисты могут написать код, связывающий эти тесты с тестируемой программой .
Звучит круто, и инструменты вроде как неплохо способствуют разделению труда . Тем не менее клиенты неохотно берутся за подобное . Представители компаний, ответственные за указание требований в спецификациях, побаиваются формальных языков .
Они в своем большинстве предпочитают человеческие языки
130
проекта . Но после первых нескольких итераций точность графика возрастет и достигнет уровня, позволяющего четче определить ис- тинную скорость выполнения работ .
Мы ожидаем, что после нескольких первых итераций угол наклона приблизится к нулю, то есть график примет горизонтальный вид .
Мы не ждем от команды ускорения или замедления в долгосроч- ной перспективе .
Возрастание скорости
Если мы видим, что график пополз вверх, это вряд ли означает, что команда действительно стала работать быстрее . Скорее всего, это означает, что менеджер проекта выжимает из разработчиков все соки, подгоняя их . Как только руководство прибегает к давлению, то команда бессознательно начинает мухлевать с оценками, чтобы создать впечатление, будто стала работать быстрее .
Это обычное надувательство . Единицы сложности можно предста- вить как своеобразную валюту, которая обесценивается командой из-за напряжения, создаваемого извне . Вернемся к такой команде через год, и что мы увидим? Этих единиц за итерацию у них будет больше 9000! Мораль такова, что не нужно гнаться за скоростью — это всего лишь способ измерения . Зарубите себе на носу: нельзя подгонять то, что измеряешь .
Оценка итерации на встрече по планированию проводится лишь затем, чтобы дать знать заинтересованным сторонам, сколько историй возможно выполнить . Она помогает выбирать истории и планировать их выполнение . Однако такая оценка не является обязаловкой — ни о какой провальной итерации не идет речи, если скорость вдруг оказалась ниже . Помните, что только та итерация провальна, из которой не удалось получить данных .
Небольшие частые релизы
131
Снижение скорости
Если график скорости неуклонно ползет вниз, то, скорее всего, причина в качестве кода . Команда, вероятнее всего, проводит мало рефакторинга, и код начинает портиться . Одна из причин нехватки рефакторинга — команда пишет недостаточно модульных тестов и боится, что из-за рефакторинга перестанет работать то, что рабо- тало прежде . Борьба с этим страхом — важнейшая задача лидеров команды разработчиков, она полностью зависит от дисциплины при тестировании . Подробнее об этом дальше .
Когда скорость падает, усиливается давление на команду . Это ве- дет к обесцениванию единиц сложности . И за таким раздуванием единиц может скрываться падение скорости выполнения проекта .
Золотая история
Один из способов избежать обесценивания единиц сложности историй — постоянно сравнивать истории с первоначальным «зо- лотым эталоном», историей, с которой сравнивают все остальные .
Вспомните, нашей первоначальной «золотой» историей был вход, который мы оценивали в 3 единицы . Если новая история, например
исправить опечатку в меню, оценена в 10 единиц, то очевидно, что оценка этой истории раздута .
НЕБОЛЬШИЕ ЧАСТЫЕ РЕЛИЗЫ
Согласно методу «небольшие и частые релизы», команде разработ- чиков нужно выпускать релизы своего программного обеспечения как можно чаще . В конце девяностых, когда Agile только появился, мы думали, что норма — это выпуск релиза раз в месяц-два . Но сейчас этот срок стал гораздо короче . Сокращать срок можно до
Глава 3. Методы взаимодействия с клиентами
132
бесконечности . Увеличение частоты релизов происходит благодаря
непрерывной доставке (continuous delivery) . Этот метод заключа- ется в том, что релиз происходит после каждого изменения кода .
Это толкование может ввести в заблуждение, потому что выраже- ние «непрерывная доставка» создает впечатление, что мы хотим сделать короче только цикл доставки . Это не так, мы хотим со- кратить каждый цикл .
К сожалению, в силу исторических обстоятельств мы имеем пре- пятствие в виде некой значительной инерции . Эта инерция — руди- мент тех способов, к которым мы прибегали при работе с исходным кодом, когда трава была зеленее, а деревья выше .
Краткая история управления
исходным кодом
История управления исходным кодом — это повесть о циклах и их размерах . Она берет начало в 1950–1960-х годах, когда исходный код хранили в отверстиях, пробитых на кусочках бумаги (рис . 3 .3) .
Рис. 3.3. Перфокарта
Небольшие частые релизы
133
Многие из нас тогда пользовались перфокартами . Карта вмещала на себе 80 символов и представляла собой одну строку программ- ного кода . Сама программа занимала целую колоду таких карт .
Обычно их перетягивали резинкой и хранили в коробке (рис . 3 .4) .
Рис. 3.4. Колоды перфокарт в коробке
Владелец программы хранил колоду перфокарт в выдвижном ящи- ке или шкафчике . Если кому-то нужно было проработать исходный код, это приходилось делать прямо из ящика или шкафчика с по- зволения владельца .
Глава 3. Методы взаимодействия с клиентами
134
Если у вас получилось проверить исходный код, то вы были един- ственным, кто мог внести в него изменения, поскольку имели возможность физически посмотреть перфокарты . Больше никто не мог их касаться . Когда дело было сделано, нужно было отдать колоду владельцу, который клал ее в ящик или шкафчик .
Цикл для этой программы составлял столько, сколько времени у программиста был к ней физический доступ . Счет мог идти на дни, недели, месяцы .
Ленты
В 1970-х мы плавно перешли к тому, что стали хранить образы перфокарт с исходным кодом на магнитной ленте . На магнитной ленте можно держать большое количество программных модулей, а еще ее было проще копировать . Редактирование модулей вы- глядело так:
1 . Достать главную ленту с оригиналом из главной стойки .
2 . Скопировать модули, которые нужно отредактировать, с глав- ной ленты на ленту с рабочей копией .
3 . Положить главную ленту на место, чтобы другие могли полу- чить доступ к прочим модулям .
4 . Воткнуть цветную кнопку на доску выдачи рядом с названием модулей, которые нужно отредактировать . (У меня была синяя, у начальника красная, у остальных программистов из моей коман- ды были желтые . Да-да, в конце концов у нас закончились цвета .)
5 . Редактировать, компилировать и тестировать на ленте с рабочей копией .
Небольшие частые релизы
135
6 . Снова достать главную ленту .
7 . Скопировать измененные модули с ленты с рабочей копией на главную ленту .
8 . Положить обновленную главную ленту в стойку .
9 . Вынуть кнопку из доски .
И снова цикл составлял ровно столько, сколько кнопка находилась на доске выдачи . Это могло занимать часы, могло дни и даже меся- цы . Покуда кнопка находилась на доске выдачи, никто больше не мог обращаться к модулям, которые вы закрепили за собой .
Разумеется, эти модули были и на главной ленте, и в крайнем случае кто-нибудь мог в обход правил отредактировать модули непосредственно на ней . Кнопки были условным соглашением, но никак не физической преградой .
Диски и системы управления
исходным кодом
В 1980-х годах исходные коды переместились на диски . Поначалу еще использовалась доска выдачи и кнопки, но потом начали по- являться настоящие средства управления исходным кодом . Первое из того, что я помню, — это Система управления исходным кодом
(SCCS) . Она работала по тому же принципу, что и доска выдачи .
Происходила блокировка модуля на диске, из-за чего никто не мог получить доступ к его редактированию . Такое блокирование называется пессимистическим . И снова то же самое . Длительность цикла зависела от длительности блокирования . Блокировка могла длиться часами, днями, а то и месяцами .
Глава 3. Методы взаимодействия с клиентами
136
На смену Системе управления исходным кодом пришла Система управления редакциями (RCS), которая, в свою очередь, уступи- ла место Системе одновременных версий (CVS) . Во всех так или иначе применялась пессимистическая блокировка . Поэтому цикл по-прежнему длился долго . Тем не менее хранение данных на диске было куда удобнее, чем на магнитной ленте . При копировании мо- дулей с оригинала на ленту с рабочей копией очень соблазнительно было сделать модули крупными сами по себе .
С другой стороны, диски позволяли нам стремительно уменьшать размер модулей . Множество маленьких модулей просто-напросто не вело к таким издержкам, как несколько крупных . За счет умень- шения модулей продолжительность цикла стала короче, поскольку количество времени, затрачиваемое на проверку модуля, также относительно уменьшилось .
Проблема состояла в том, что изменения в программе влекли за со- бой изменения во многих модулях . В случаях, когда модули были тесно связаны, на их проверку все еще уходило много полезного времени . Некоторые из нас научились отделять связанные модули, чтобы уменьшить эти сроки . А кто-то так и не научился .
Subversion
Потом пришло время системы Subversion (SVN) . В ней появи- лось оптимистическое блокирование . Оптимистическое бло- кирование по сути никакое и не блокирование . Разработчик мог проверять модуль одновременно с другим разработчиком .
Система позволяла отслеживать действия разработчиков и ав- томатически объединять изменения в модулях . Если система обнаруживала конфликт, когда два разработчика работали над одними и теми же строками кода, то вынуждала программиста
Небольшие частые релизы
137
сперва разрешить этот конфликт, прежде чем подтвердить при- нятые изменения .
Это значительно сократило продолжительность цикла до време- ни, требуемого на редактирование, компиляцию и тестирование последовательности небольших изменений . Связанность моду- лей еще представляла собой проблему . Тесно связанные модули замедляли цикл, потому что приходилось вносить изменения во много модулей одновременно . Однако программы, где модули не были так тесно связаны, проходили цикл гораздо быстрее . Сам срок проверки больше не служил ограничивающим фактором .
Git и тесты
В наши дни мы используем Git . Сроки проверки при использо- вании Git сошли на нет . Это понятие больше не существует . На- против, любое изменение в модуль можно внести когда угодно .
Программисты разрешают конфликты между этими изменениями, как и когда этого пожелают . Маленькие несвязанные модули по- зволяют молниеносно и часто вносить изменения . Поэтому циклы составляют считаные минуты . Добавьте к этому возможность создавать всеобъемлющие и быстрые тестовые наборы, которыми можно протестировать практически все . Вот вам и все нужное для непрерывной доставки .
Историческая инерция
К сожалению, организации с трудом отказываются от унасле- дованных подходов . Циклы продолжительностью в дни, недели и месяцы глубоко укоренились в культуре многих команд, от- куда затем перешли к QA-специалистам, менеджерам и даже заинтересованным сторонам . С колокольни такой «культуры»
Глава 3. Методы взаимодействия с клиентами
138
мысль о непрерывной доставке может показаться бредом сумас- шедшего .
Небольшие и частые релизы
Agile пытается порвать шаблоны исторической инерции, предлагая как можно сильнее сократить циклы релизов . Если у вас релиз про- исходит раз в полгода, постарайтесь выпускать раз в три месяца, раз в месяц, раз в неделю, в конце концов . Продолжайте уменьшать циклы релизов, асимптотически стремясь к нулю .
Чтобы достичь этого, организации требуется разорвать связь меж- ду релизом и развертыванием . Понятие «релиз» означает, что программа технически готова к развертыванию . Решение о раз- вертывании полностью ложится на плечи клиентов .
Возможно, вы заметили, что теми же самыми понятиями мы описы- вали итерации . Итерации с технической точки зрения можно развер- тывать . Если продолжительность итерации составляет две недели, но мы хотим выпускать релизы чаще, придется итерации сократить .
Можно ли сокращать итерации асимптотически, стремясь к нулю?
Да, можно . Но это уже тема отдельного разговора .
ПРИЕМОЧНОЕ ТЕСТИРОВАНИЕ
Приемочное тестирование — один из самых непонятных и запутан- ных методов Agile, который используется реже всего . Это любо- пытно, потому что основной посыл удивительно прост: требования указывает клиент .
Проблема, несомненно, в понимании слова «указывает» . Многие клиенты считают, что могут, поводив руками в воздухе, расплыв-
Приемочное тестирование
139
чато и туманно описать функционал, а потом произойдет чудо — разработчики сами догадаются обо всех мельчайших нюансах .
А многие программисты хотят, чтобы клиенты точно объяснили, как должна работать программа, вплоть до координат и цвета каж- дого пикселя на экране .
Из этих двух крайностей нужно вывести золотую середину .
Что же такое спецификация? Спецификация по своей сути — это функция, которую можно протестировать . Например:
Когда пользователь вводит правильное имя учетной записи и па-
роль, а потом нажимает «войти», на экране появится страница
приветствия.
Вот это и есть указание, то есть спецификация . Очевидно, что это можно протестировать .
Очевидно, что тест для этой функции можно автоматизировать .
Нет причин на то, чтобы компьютер не мог удостовериться в вы- полнении указанного требования .
Вот так работает приемочное тестирование . Опыт подсказывает, что насколько это вообще осуществимо, требования к системе должны представлять собой автоматизированные тесты .
Погодите! А кто же пишет эти тесты? Первый абзац этого раздела от- вечает на наш вопрос: требования указывает клиент . Тогда получает- ся, что клиенты должны писать автоматизированные тесты, ведь так?
Погодите! Автоматизированные тесты должны быть написаны на каком-то формальном исполняемом языке . И это работа для про- граммистов, не иначе! Получается, что программистам придется писать эти тесты?
Глава 3. Методы взаимодействия с клиентами
140
Погодите! Если программисты будут писать тесты, то это будет не то, чего хочет клиент . Это будут технические тесты с множеством нюансов, понятных только программистам . Они не отражают цен- ность тестируемого элемента для клиента . Тогда автоматизирован- ные тесты будет писать клиент? Ведь так?
Погодите! Если автоматизированные тесты будет писать клиент, то они не будут соответствовать технологии, которую мы используем .
И программистам тогда придется их переписывать, не так ли?
Вот тут-то и становится понятно, почему этот метод вводит многих людей в заблуждение .
Инструменты и методологии
А еще хуже то, что наш метод погряз в инструментах и методоло- гиях .
Пытаясь облегчить клиентам написание автоматизированных тестов, программисты написали целое изобилие инструментов, оказывающих медвежью услугу . Имеются в виду поделки вроде
FitNesse, JBehave, SpecFlow и Cucumber . Каждый из этих инстру- ментов предоставляет формы, призванные отделять техническую сторону автоматизированного теста от пользовательской . Гипотеза состоит в том, что клиент может написать пользовательскую часть автоматизированного теста, в то время как программисты могут написать код, связывающий эти тесты с тестируемой программой .
Звучит круто, и инструменты вроде как неплохо способствуют разделению труда . Тем не менее клиенты неохотно берутся за подобное . Представители компаний, ответственные за указание требований в спецификациях, побаиваются формальных языков .
Они в своем большинстве предпочитают человеческие языки