Нефункциональные пользовательские истории
Несколько лет назад один банк попросил моего совета касательно проекта изменения системы обработки платежей. Работы было немного, и банк хотел использовать кое-какие преимущества Agile, чтобы ускорить разработку, но не хотел, чтобы Agile просочился куда-то ещё. К несчастью, это довольно частая просьба: «Увеличьте нашу скорость, только ничего не меняйте». Просмотрев техническое задание - да, у них всё ещё такое водилось - я спросил: «Сколько времени у вас отводится на данный процесс?» «Сейчас он запускается рано утром. На данный момент остаётся запас в пару часов, для нас это приемлемо.» «Хорошо, - ответил я, - давайте укажем в ТЗ текущее время работы и максимальное доступное время. По крайней мере, мы будем знать, с чем работаем.» - предложение радости не вызвало. «Но нам тогда надо провести тесты, чтобы замерить текущие показатели. Создание таких тестов займёт время, а тестовая система у нас и так перегружена, да и свободных тестировщиков у нас нет.» Я сдался. Бывают моменты, когда никакое упорство не помогает. Но угадайте, что было дальше? Когда код запустили в режиме боевой эксплуатации, он функционировал корректно, только работал так долго, что к открытию банка завершиться не успевал. Аналитики называют ограничения типа жёстких временных рамок «нефункциональными требованиями». (Лично я думаю, что правильнее отнести их к спецификациям, но давайте на этом не зацикливаться). Суть в том, что существует ограничение, не зависящее от функциональности системы. В данном примере с самой обработкой платежей всё понятно. Проблема лишь в том, занимает она час или четыре часа. Нефункциональные требования описывают аспекты системы, которые нельзя привязать к какой-то конкретной части ее функциональности. Скорость исполнения - одно из наиболее частых нефункциональных требований, но есть и другие. Ещё одно распространённое - лёгкость использования (хотя в каких единицах измерять лёгкость - это уже другой вопрос.) Ещё одно требование, появляющееся всё чаще и весьма важное, - безопасность. Нефункциональные пользовательские историиНефункциональные требования неизбежны, и неважно, видны они сразу или появляются по мере обсуждения историй и критериев приёмки. Если задуматься, обычный формат пользовательской истории отлично подходит для большинства нефункциональных требований: «Будучи бухгалтером, я хочу, чтобы балансовый отчёт формировался за две минуты.» Но не все нефункциональные требования настолько просты. Когда вы всеми силами пытаетесь втиснуть их в формат истории, и вам приходится нарушать правила грамматики или писать ужасно запутанные предложения, лучше вообще отложить в сторонку стандартный формат «Будучи тем-то…» Пишите требования так, чтобы они были понятными, а потом подкрепите их обсуждениями. А на обратной стороне карточки истории вы по-прежнему можете, если хотите, написать критерии приёмки. Временами, особенно когда система уже существует, нефункциональные требования - это как любая другая часть работы. Возьмём к примеру тот же баланс: если у бухгалтера уже есть такой отчёт, то на самом деле данная история говорит нам: «Сделайте данную функцию быстрее». Часто ключом к нефункциональным требованиям являются тесты. В первом приближении нефункциональное требование - это запрос на тестирование. Прежде, чем вы начнёте какую-либо разработку, создайте и запустите тесты. Пляшите исключительно от тестов. Возможно, это приведёт к тому, что историю выше вы разделите на две: «Будучи бухгалтером, я хочу формировать балансовый отчёт» «Будучи бухгалтером, я хочу, чтобы балансовый отчёт формировался за две минуты.» В первой истории вы создаёте функционал, для второй требуется тест, чтобы продолжить работу. Как только ваши тесты будут готовы, вы узнаете, требуется ли дальнейшая разработка. Регулярный запуск тестов помогает быстро выявить любые изменения, идущие вразрез с требованиями. В этом как раз подводный камень нефункциональных требований: поскольку они захватывают не один кусок функционала, то вы можете считать, что они давным-давно реализованы, а они вернутся, чтобы вас ужалить. Одна известная мне команда имела требование к производительности, чтобы результат приходил меньше, чем за одну секунду. Первый тест, который они сделали, был пройден успешно, следующий провалился, опоздав на 0,8 секунды. Если в будущем этот тест опять будет провален, они предпримут действия по улучшению производительности. Как задать требованияНефункциональные требования требуют количественного измерения. Быстро - насколько быстро? Безопасно - насколько безопасно? Это, в свою очередь, означает, что должны быть инструменты измерения. Но как можно измерить, например, безопасность? «Система может выстоять перед DDoS-атакой на протяжении 30 минут»? В данном случае полезно позаимствовать подход из работы системного инженера и писателя Тома Гилба. Он ввёл понятие «планового языка», основанного на хорошо определённых правилах для спецификации. Он спросил бы так:
Возможно, на эти вопросы отвечает история, а если не она, то, наверное, критерии приёмки. Если нет, задайте эти вопросы на последующих обсуждениях. Без ответов на эти вопросы тесты, особенно автоматизированные, очень сложно сделать. Хуже того, нефункциональные требования становятся субъективными: «для вас это быстро, а для меня не быстро». Ограничения и оценкаКогда вы проводите тесты по нефункциональным требованиям, становится ясно, что они представляют собой не столько требования, сколько ограничения: «Будучи бухгалтером, я хочу, чтобы балансовый отчёт формировался за две минуты.» Нефункциональные требования задают условия, в которых должна функционировать система, примерно, как и всякая другая форма технического задания. Если присмотреться к ним, то они не носят бинарный характер. Чем спрашивать, «Есть у нас функция Х или нет?», спросите «Сколько данной функции вам требуется?» Все требования становятся аналоговыми - в большей степени они удовлетворены или в меньшей?
Это даёт нам ещё один инструмент, позволяющий разбить историю на меньшие элементы. Что более важно, это возвращает нас к вопросу выгоды и ценности. Сколько ценности производят эти ограничения? В данном случае - насколько ценнее, если бухгалтер получит баланс за две минуты, а не за четыре? Знание ценности функционала открывает множество дверей. Оно помогает выполнить анализ расходов и прибыли и позволяет рассмотреть альтернативные решения. Сколько ценности будет произведено, если баланс будет формироваться две минуты? Если в первой истории баланс производится за четыре минуты, действительно ли дополнительная ценность второй истории стоит своих затрат? Освещение этих ограничений меняет наше понимание истории и требует продолжения диалога. Преждевременное его закрытие скрывает возможности разделить истории, прийти к компромиссу и максимизировать выгоды. Возможности получить выгодуНастоящая проблема с ограничениями не столько в том, чтобы создать решение, которое бы им отвечало, а в первую очередь в том, чтобы выявить, что они есть. Создание тестов и примеров ведёт к диалогу - а это большой шаг к выявлению нефункциональных требований. Это открывает возможности мельче подробить истории и рассмотреть выгоды для конечного пользователя.
Оригинал: http://www.agileconnection.com/print/art[...]g-acceptance-criteria-agile-requirements Об авторе: Аллану Келли доводилось выполнять практически всякую работу в мире ПО - от системного администратора до руководителя проекта, включая программиста и менеджера продукта. Сейчас он работает в Software Strategy, где помогает командам применять и углублять практики Agile. Его специализация - помогать софтверным компаниям подстраивать продукты и процессы под стратегию компании. Он является автором трех книг: «Xanpan - отражение Agile в разработке ПО» (https://leanpub.com/xanpan) «Бизнес-шаблоны для разработчиков ПО» и «Меняя разработку ПО: учимся Agile»; создателем «Ретроспективных Диалогов» (http://www.dialoguesheets.com) регулярным докладчиком на конференциях и частым автором для журналов. Перевод: Александра Родсет |
Еще интересные статьи на эту тему:
|
