Гибкая методология разработки: стратегия для информационной эпохи

 

Первыми людьми, которые искали новую стратегию, были инженеры‑программисты, работавшие в 1980‑х – 1990‑х годах. Несколько разочарованных и вдумчивых практиков взглянули на процесс разработки программного обеспечения и задались вопросом, почему же так трудно создавать эффективные программные системы. (Оглядываясь назад, легко понять, почему было так много разочарований. Хорошо известное на тот момент исследование – «отчет 1994 года ”ХАОС”» компании Standish Group – показало, что 84 % ИТ‑проекта либо не показывали никаких результатов, либо серьезно страдали от перерасхода средств и несоблюдения установленного графика). Эти специалисты‑практики пришли к выводу, что методы, которые использовались для создания программного обеспечения, были основаны на неверной модели.

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

Наша группа разочарованных специалистов‑практиков поняла ключевое отличие в работе с программным обеспечением: после начала проекта всегда меняются требования. В течение многих лет программисты боролись с фактом изменения требований. Но эта группа применила другой подход. Они спросили себя: что если мы примем появление изменений как данность? Что если по какой‑либо причине изменение требований является неотъемлемой частью процесса разработки программного обеспечения и что произойдет, если мы оптимизируем наш процесс для возможности внесения изменений?

Если вы близки с миром цифровых технологий, вы поймете, что тот вопрос был чем‑то вроде импульса, переросшего в agile‑движение (agile – англ. Гибкий, сообразительный. Используется в контексте гибкой методики разработки – перев.). Раз уж произошло своего рода восстание контркультуры, agile теперь является мейнстримом и имеет все шансы стать самой главной моделью процесса для разработки программного обеспечения.

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

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