Site icon AppTractor

Трудности проектирования

← Предыдущая статья

Приветствую вас, коллеги!

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

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

В соответствии с уже рассказанными теоретическими выкладками, такие ситуации происходят из-за комбинации трех факторов:

Борьба с архитектурой

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

Agile спешит на помощь

Шестая по счету колонка — оптимальное, на мой взгляд, место чтобы более серьезно рассказать о методологии Agile. Я уже рассказал про специфику разработки как постоянное создание нового, про проблему сложности с кошельком Миллера, и, наконец, про трудности проектирования, вызванные этими занимательными фактами. Такое положение дел не могло устраивать крупный бизнес, автоматизация которого является одной из крупнейших областей разработки программного обеспечения (на самом деле, статистики по «областям разработки программного обеспечения» у меня нет, и как ее собрать я не представляю, если кто из читателей обладает этой информацией — буду благодарен за наводку). С точки зрения бизнеса, постоянные неудачи, срывы сроков и превышения бюджетов в области разработки не могло быть оправдано молодостью этой отрасли. Бизнес требовал, и разработчики искали способы более точно предсказывать цену, сроки и риски разработки.

В начале 2001 года инициативная группа известных специалистов по разработке выдвинула концепцию «гибкой модели разработки», представленную в Agile Manifesto. Основная идея Agile состоит в том, что нужно балансировать проектирование и непосредственно разработку, для чего вводится понятие «итерации», являющейся в Agile методологи ключевой.

Сила итераций

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

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

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

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

И их слабость

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

Exit mobile version