Основные подходы к разработке программных продуктов

Текстовая расшифровка десятого урока курса Введение в профессию аналитика.

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

Вот две крайности, которые давно уже у всех на слуху. Слева у нас картинка из статьи Уинстона Ройса о водопадном процессе, которая была издана в материалах НАТО ещё в 1968 году. Это, собственно, иллюстрация водопада. А справа картинка, может быть, менее известная, это крайний способ Agile разработки — экстремальное программирование.

Что такое водопад? Водопад предполагает, что при создании продукта мы последовательно проходим через определённые этапы. В данном случае в статье перечислялись такие этапы. Сначала описание системных требований (то есть общесистемных, здесь под ними понимались фактически бизнес-требования к создаваемой системе). Потом описание требований к программной составляющей этой системы, анализ этих требований, потом разработка архитектуры программы, кодирование, тестирование и использование.

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

И полная противоположность — это экстремальное программирование, где всё идёт сплошными итерациями. Где мы требования, что называется, прямо с колёс выявляем у пользователя, тут же их обсуждаем, тут же их включаем в итерацию, принимаем, разрабатываем и так далее.

Наверное, уже все аналитики в той или иной мере знакомы с концепцией Agile, проходили какие-то курсы, смотрели видео. У нас есть евангелисты Agile, которые этим уже на протяжении многих лет занимаются. И эти евангелисты всегда Agile противопоставляют водопаду. Для них водопад — это что-то крайне страшное. В нём было всё плохо, а у нас в Agile теперь всё хорошо.

Я здесь привёл скриншот, представляющий квинтэссенцию Agile-манифеста разработки программного обеспечения. Та картинка, которую я приводил на предыдущем слайде, экстремальное программирование, — это набор очень конкретных практик в разработке программного обеспечения. То есть просто правил, которым нужно жёстко следовать, и которые реализуют этот манифест в его крайней форме.

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

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

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

Как это влияет на работу с требованиями? Я свёл в табличку, чтобы сравнить, крайние методы водопада и крайние методы Agile при работе с требованиями.

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

Если в водопадном процессе требования фиксируются в виде документов, то в Agile используются лёгкие форматы их описания. Я говорил по User Stories, которые изначально предназначены не только для описания требований, но и адаптированы для того, что бы тут же пускать их в разработку. В Agile используются такие лёгкие форматы требований.

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

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

Agile появился не на пустом месте. Я тут коротко перечислил условия, благодаря которым он смог возникнуть. Во времена больших машин машинное время — это был очень дорогой ресурс. Машин было немного. Для того, что бы выполнить какие-то расчёты, нужно было записываться в очередь. Машинное время было дорогим по сравнению с трудом людей, поэтому дешевле было заранее продумать все требования, заранее разработать, как положено, программу, для того, чтобы потом на этом дорогом машинном времени получить какие-то результаты.

Естественно, переворот случился кардинальный. Сейчас машинное время не стоит практически ничего. Оборудование тоже очень доступно, и этот фактор больше не ограничивает нас в процессах разработки. И отпала необходимость в водопаде, обусловленная во многом тем, что создание системы с использованием машинного времени было само по себе достаточно дорогостоящим этапом. Сейчас нас ничего не ограничивает. Мы можем создавать продукты прямо с колёс: возникла идея, ты сел, закодировал, проверил, протестировал — выложил в интернет.

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

Многие операции роботизированы. В частности, о такой штуке, как непрерывная интеграция, конечно, в эпоху больших машин невозможно было и мечтать. А сейчас вы можете при выкладывании исходного кода в хранилище каждый раз заново делать тестовую сборку, чтобы убедиться, что у вас продукт не сломался. Т. е. программист может непрерывно кодить, сбрасывать результаты своего труда в хранилище, и при этом автоматически будет проверяться, что его код работоспособен и не сломал всё, что было до него. Во об этом до Agile нельзя было и мечтать. А в Agile — это стало одной из основных практик.

Благодаря интернету появился массовый пользователь. Раньше у нас заказывали продукты только большие организации, я ещё участвовал в проектах, которые разрабатывались по решению Совета министров СССР. Техническое задание разрабатывалось пять лет, потом оно лежало на полке пять лет, потом начиналась реализация. Cейчас это невозможно. Сейчас такие продукты никому не нужны. Массовый пользователь хочет всего быстро, с одной стороны, а с другой стороны, у нас появилась возможность его быстро удовлетворять. Мы об этом говорили, когда обсуждали возможности интернета.

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

Для чего я это сказал? Чтобы вы, как аналитики, испытывали гордость. Вы работаете с требованиями, а Agile-методы появились именно в связи с необходимостью новых практик работы с требованиями.

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

Понятно, что в реальной жизни, по мере того, как реализовывались те пункты, которые я на предыдущем слайде перечислил (железо становилось дешевле, средства разработки становились простыми и интерактивными, мы становились всё ближе и ближе к пользователю), естественно, появлялись методы разработки программных продуктов, которые были всё более и более итерационными. Появился так называемый спиральный метод разработки, V-образный метод разработки и т. д. Мы не будем все эти модели рассматривать. Сейчас их можно найти в любой энциклопедии.

В Rational Unified Process появилось представление о плотности процесса. Здесь на картинке нарисовано, что в процессе создания продукта у нас определённые виды активности выполняются в большей или меньшей степени. То есть ближе к началу создания продукта мы больше занимаемся бизнес-моделированием, сразу запускаем управление требованиями. Анализ требований, он итерационно идёт тоже ближе к началу. Реализация начинается не прямо с начала, но её плотность растёт со временем. Тестирование — тоже итерационный процесс и т. д.

Все процессы, которые связаны с созданием продуктов, включая те, которыми занимаются аналитики (моделирование, анализ, управление требованиями) как бы размазаны по всему жизненному циклу продукта. Естественно, это не водопад, где аналитик фактически отрабатывал на первом этапе и всё, на этом его работа заканчивалась.

И SCRUM, который уже является чистым Agile-подходом к разработке. Эта картинка символизирует SCRUM (что такое SCRUM, вы наверняка знаете). А эта большая стрелочка нам говорит о том, что и в скраме всё-таки должен быть подготовительный этап. Несмотря на то, что выпуск продукта крутится в этих коротких итерациях, тем не менее, есть подготовительный этап, на котором занимаются обработкой, в первую очередь, бизнес-требований. И аналитики задействованы и на этом этапе, и уже в конкретных итерациях.

Этим слайдом я хотел показать, что это было не бинарно: был водопад, а потом в 2000 году все переключились на Agile. Развитие процессов шло постепенно.

Но когда появился Agile, у аналитиков возник вопрос, где же мы находимся? Эта картинка из доклада Андрея Бибичева, с которым он выступал почти 10 лет назад. Аналитики задались вопросом: где же найти место в новых Agile — подходах? Если вы посмотрите эту презентацию, там много разных вариантов, куда приложить аналитика в скраме. И на сторону заказчика, и на сторону разработки, и сделать его продукт оунером или сделать его помощником продукт оунера и т. д. Всякие варианты там рассматриваются, и разбираются их преимущества и недостатки. Иллюстрирует эта картинка то, что в традиционных подходах аналитик был фактически файрволлом между заказчиком и командой разработки, т. е. он через себя пропускал всю информацию и выдавал её наружу. В Agile подходах аналитик становится вовлечён, с одной стороны, в активное общение с заказчиком, а с другой стороны — в активное взаимодействие с командой. А это означает, что аналитик вовлечён в процесс управления требованиями в широком смысле.

Что происходит в интернет-проектах? Вы, наверное, уже поняли, и по своему опыту, и по всем предыдущим модулям, которые мы рассматривали, определяя особенности интернет-проектов, что Agile сейчас в интернет-проектах одерживает безоговорочную победу по сравнению с предыдущими методами. Можно сказать, что он появился во многом как реакция на появление интернета. Agile привёл за собой эти практики, которые были предназначены для разработки интернет-проектов. Сейчас он уже пошёл дальше. Скрам вышел за пределы разработки софта. Мы уже знаем, что во многих банках уже применяются Agile-подходы, где-то лучше, где-то хуже. Эти методы становятся общепризнанными.

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

Я ещё не разобрался, как это происходило, но по моему разумению это было так. Министерство образования сформулировало требования, какие функции должен реализовывать электронный журнал для школьников, где им ставят оценки. Оформили в виде технического задания по ГОСТу. Очень хорошее техническое задание, я его видел. Это хороший пример, когда требования разрабатываются сами по себе, независимо. По водопаду этап разработки требований заканчивается выпуском определённого артефакта — это ТЗ. А потом это ТЗ используют независимые разработчики, и уже как они управляют требованиями в процессе реализации — это их дело. Они все могут работать по скраму, но в качестве основы они используют это зафиксированное техническое задание. Очень интересный кейс. Я думаю, что существуют и другие подобные кейсы.

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

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

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

Предыдущий урок: Процессы разработки и управления требованиями

Следующий урок: Основные форматы представления требований