Враг: предваряющий анализ

3.1 Прогнозируемость не значит "водопад"

Для начала еще одно предостережение, дополняющее советы, данные в предыдущей главе. В одной из наиболее современных книг создатели Scrum пишут:

Хотя прогнозируемый процесс или водопад приводят к трудностям, многие люди и организации пытаются заставить водопад работать [Schwaber 2012, стр. 29].

Позже в том же абзаце:

[Пользователь использовал] службы от фирмы PriceWaterhouseCoopers (PWC). PWC подход был предсказуемым – водопадом.

В индексном указателе книги для термина "прогнозируемый процесс" сказано: "смотри Водопад".

Игра здесь в том, чтобы с термином "прогнозируемый процесс" связать отрицательные ассоциации. Этот нечестный прием уже упоминался ранее. Под "водопадом" понимается специфическая модель жизненного цикла, главная цель введения которой была скорее педагогической, поскольку она едва ли существует в практике программной инженерии. Она использовалась как учебный пример подхода, который не следует применять при разработке программных проектов. Даже в статье 1970 года [Royce 1970], в которой впервые явным образом была описана эта модель, целью была критика такого подхода. С тех пор любимое занятие ряда авторов – пинать ногами поверженную модель "водопада".

"Прогнозируемость процесса" – это нечто совсем другое. Инженерия по определению прогнозируема. Она пытается организовать большую или меньшую часть процесса проектирования и производства заблаговременно, основываясь на методах науки и приемах управления. Существует огромное множество прогнозируемых подходов, не являющихся "водопадом". Попытка связать в сознании читателя прогнозируемость с пинаемым мячом программной инженерии и, как следствие, дискредитировать то, что не связано с собственным подходом автора, является недостойным приемом, не помогающим достижению понимания.

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

3.2 Инженерия и требования

Программная инженерия – это не просто программирование, а решение некоторой проблемы, представляющей интерес для ряда людей, так или иначе сопричастных к данной проблеме. Определение того, в чем реально состоит суть проблемы и какой вид ее решения удовлетворит сопричастников – задача, известная как анализ требований. И в этом состоит один из наиболее важных аспектов успешной разработки программного продукта. В противном случае построение совершенной системы, но не отвечающей потребностям, не приносит большой пользы. Многократно доказано, что ошибки в требованиях являются одним из худших бедствий для программной системы. Многие усилия в программной инженерии направлены на то, чтобы построить программную систему правильно. Требования направлены на то, чтобы построить правильную систему.

3.2.1 Приемы инженерии требований

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

• интервью с сопричастниками: опрос людей о том, что же им требуется;
• семинары сопричастников: собрание группы сопричастников для обсуждения требований; семинары особенно полезны, когда существуют различные классы сопричастников с различными, а иногда и конфликтующими интересами; идентификация противоречий и их открытое обсуждение способствуют пониманию и разрешению конфликтов.

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

Традиционно документ требований представляет единый последовательный текст, но этот термин покрывает и современные более гибкие форматы, такие как веб-сайт, Вики (пропагандируемые в контексте agile Ларманом [Larman 2010]) или совместно разрабатываемый документ, размещаемый в облаке, например Google Docs.

3.2.2 Agile критика предваряющего анализа требований

Школа agile отрицает идею требований, создаваемых на этапе проектирования. Это отрицание является общим для всех вариаций agile. Бек [Beck 2005], выступающий в поддержку XP, пишет:

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

Кон [Kohn 2009] в контексте Scrum и как часть отрицания предваряющего анализа пишет:

Проекты Scrum не имеют предваряющего анализа или фазы проектирования – вся работа выполняется внутри повторяющегося цикла спринтов.

С позиций agile, создание документа требований – "лишние траты" по двум причинам.

• Затратность: документ требований бесполезен при поставке продукта, поскольку он не является частью того, что передается клиентам. Поппендик [Poppendick lean 2002, 2004] пишет:

  Если ваша компания создает огромный документ с требованиями (эквивалент инвентарной описи), то вы в плену парадигм массовой продукции. Думайте "экономично" (lean) и вы найдете лучший путь.

  Не удивляйтесь, быть в плену парадигм – это не комплимент. Далее:

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

  Аналогия здесь с инвентаризацией, выполняемой на предприятиях и являющейся формой непроизводительных затрат.
• Изменчивость: с позиций agile клиенты сами не знают, чего хотят. Если делать то, что они думают, то придем к нереалистичной системе. В любом случае их взгляды меняются. Единственный способ удовлетворить их – начать с построения прототипа, показать его клиентам, получить обратную связь и итеративно двигаться дальше.

Эти два довода – затратность и изменчивость – часто объединяются в один. Бек [Beck 2005], например, пишет:

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

И снова здесь случай критики по ассоциации: объединение двух аргументов упрощает критику требований, предваряющих создание кода. Заметьте, Бек в предыдущей цитате отвергал понятие "фазы, производящей статический документ". Но речь идет о двух различных вещах: как мы увидим далее в деталях, требования могут быть отдельной фазой процесса разработки, но их итогом является документ, который может меняться в процессе разработки.

В действительности затратность и изменчивость – два разных аспекта, так что рассмотрим их по очереди.

3.2.3 Критика затратности

Критика затратности в принципе сводится к тому, что некоторые требования в дальнейшем не используются (не анализируются, но проектируются в терминах Поппендика). Когда вы пишете требования, то по определению они являются проектируемыми, но не прошедшими анализ. У вас нет уверенности, что все они останутся и будут выполнены. Фактически цель написания требований состоит в том, чтобы иметь твердую основу на ранних стадиях проекта, позволяющую обсуждать будущие функции системы и, в частности, решать, какие из них могут быть опущены.

Значит ли это, что усилия были пустыми "затратами"? Чтобы решить это, следует сравнить два подхода отклонения функций, исключаемых из списка необходимых функций:

1. Подход, основанный на предварительном планировании. Выполнить процесс формирования требований к системе. Оценить важность функций, вытекающих из анализа требований, решить, какие из них не являются важными, и избавиться от них.
2. Подход agile. Выбрать несколько функций. Реализовать их. Если клиентам они кажутся неудовлетворительными, то избавиться от них.

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

Иногда, но не всегда. Проблема в догматизме. Предваряющие требования полезны. Итеративная разработка полезна. Отрицание одного из этих двух дополняющих приемов во имя идеологии не способствует проекту, приносит ему вред.

Критика agile справедлива, когда их целью являются предписываемые бюрократическим окружением пухлые документы требований, иногда достигающие тысячи страниц. В то же время тщательное описание всех деталей требуется в тех случаях, когда речь идет о создании жизненно важных систем (типично для встроенных систем, например транспортных). Для большинства бизнес-систем такие документы избыточны. Они становятся настолько сложными, что трудно правильно учесть все нюансы (им свойственны противоречия и неопределенности), поэтому неудивительно, что они забываются еще до использования в процессе разработки.

Эта критика не сбрасывает со счетов понятие предваряющих записанных требований. Заметим вначале, что даже строгое определение "затрат" как чего-то, что не поставляется клиенту, не относится в полной мере к требованиям, так как требования зачастую представляют хорошую основу для написания документации по системе. Но есть и более фундаментальные причины, по которым следует сохранять некоторую дозу предваряющих требований. Программная система, несмотря на всю ее специфику (виртуальная природа, простота изменений), остается инженерным артефактом. Не следует отвергать базисные приемы инженерии, требующие спецификации того, что вы собираетесь построить, в фиксации деталей на подходящем уровне еще до того, как вы приступите к строительству.

Таким образом, есть золотая середина между экстремальной абсурдной бюрократичностью и не менее абсурдной неформальностью.

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

Однажды я был свидетелем разговора в компании менеджеров проекта. Один из них говорил: "У нас не было этапа разработки требований, мы были agile, мы были свободными. Проведя несколько недель над определением функций системы, нам не пришлось бы задержать проект на несколько месяцев, а команде не пришлось бы проводить бессонные ночи. Я никогда больше не повторю подобный эксперимент".

3.2.4 Критика изменчивости

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

Выступать против требований на основании того, что они меняются, – все равно что сражаться с тенью. Никто в программной инженерии не требует замораживания требований в начале проекта. Документ требований – один из артефактов ПО, такой же, как модули кода и регрессионные тесты (для многих сторонников agile – единственный артефакт, заслуживающий внимания). Документация, описание архитектуры, планы разработки, тест-планы, расписания – все это артефакты ПО. Требования являются частью ПО. Подобно другим компонентам ПО требования должны рассматриваться как актив, и подобно всему остальному они могут меняться (на практике должны находиться под постоянным управлением средств конфигурации проекта).

Нет смысла отрицать предваряющие требования на том основании, что они могут изменяться. Подходящий технический ответ на изменения требований состоит в вопросе: "А что теперь?" Когда вы пишете статью, можете менять ее структуру в ходе написания, но это не значит, что не следует начинать с плана статьи, не полагая, что он незыблем и высечен в камне. (Можно даже подозревать, что лучшие книги, написанные по agile, также начинались с плана, конечно, только из конъюнктурных соображений.) Когда компания объявляет новый продукт, у нее есть маркетинговый план, который она готова адаптировать с учетом реалий. Примеры (среди многих возможных) приходят из областей, далеких от создания ПО, но и из них следует, что запись требований не означает их замораживание.

Военные стратеги любят цитировать маршала Хельмута фон Мольтке: "Ни один план сражения не выживает при встрече с врагом". Они цитируют это, продолжая строить планы! Ситуация такая же, как и в ПО. Мы знаем, что планы – всего лишь планы, и они должны адаптироваться к реалиям. Но это не причина отказа от плана.

Обратим еще раз внимание на логическую ошибку в комментарии Бека:

"Сбор требований не является фазой, создающей статический документ".

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

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

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

3.2.5 Предметная область и создаваемая машина

Сравнивая традиционный подход к выработке требований с agile подходом, полезно обратить внимание на различия между требованиями предметной области и требованиями к создаваемой машине, сформулированные много лет назад Памелой Заве и Майклом Джексоном [Zave 1997], [Jackson 1995], [Jackson 2000]. Идея проста:

• некоторые элементы требований описывают свойства модели части мира – предметную область, в которой должна работать система;
• другие – описывают желаемые свойства самой системы или "машины", которую хотим реализовать в проекте.

В банковских приложениях правила работы со счетами, депозитами, кредитами задают свойства области. Спецификации, задающие способ оплаты, другие операции – это свойства машины. При работе в области мобильной связи законы физики, определяющие скорость распространения сигнала, видимость, как и ценовая политика компании, являются свойствами области. Функции системы, которые должны учитывать эти ограничения, являются свойствами системы – машины. Согласно Джексону и Заве, следует разделять эти требования, поскольку они имеют различную природу. Проект может менять свойства "машины", но не может менять "область". Их смешивание приводит к недоразумениям и ошибкам.

Часто используемый сторонниками agile довод, что требования являются проектируемыми, предполагает, что требования существуют как чисто клиентские потребности, преобразуемые в решения строящейся системы. Поппендик пишет:

Что касается этих вещей, называемых "требованиями"? Реально, это кандидаты на принятие решений. Отделять требования от реализации – это просто форма передачи полномочий.

(Передача полномочий – это еще одна форма непроизводительных затрат, согласно agile.) Здесь требования рассматриваются не просто как элемент проектирования, но и как элемент реализации. Автор настаивает, что проектирование и реализацию разделять не следует.

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

• В бизнес системе: "Любой платеж на сумму свыше 10 000 $ должен получить одобрение управляющего". Это правило, которое следует учитывать при построении системы, никак не пытаясь его изменить. Если оно не учтено, то система будет некорректной. Что мешает компетентному менеджеру сформулировать это и подобные правила на начальном этапе? Ничто.
• Во встроенной системе: "Все коммуникации мобильных систем телефонии должны быть согласованы с заданной частотной областью (определенной в требованиях)". Это еще один пример фундаментального ограничения, накладываемого окружением на программный проект.

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

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

Скорость света не подлежит изменениям, принимаемым в результате решения на этапе реализации.