Agile: почему именно эта модель?

Клиент всегда прав (с Agile он прав очень часто)

К классическим моделям разработки относится водопадная [waterfall] модель. Её отличает строгая последовательность: составление плана - написание документации (под ключ) - проектирование - разработка - тестирование - ввод в эксплуатацию. В этой цепочке требования клиента должны быть жёстко описаны, и только после этого начинается работа над дизайном (архитектурой) проекта. Но кто может дать гарантию того, что требования не изменятся? Только сам клиент, но такая ситуация редка, да и невозможна, ибо заказчику не безразличны его вложения. В обратном случае вышло бы так: деньги я вложил, делайте как сочтёте нужным, а в конце меня всё устроит. Нонсенс! Требования меняются: как со стороны клиента (уточнения, пересмотры, пожелания), так и со стороны среды, в которой будет крутится продукт.

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

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

Возврат инвестиций

Другая немаловажная ситуация связана с материальными вкладами клиента. Если что-то пойдёт не так, и заказчик пожелает разорвать отношения с разработчиком, то в случае водопадной модели он останется без денег и без ПО. Это почти наверняка так, поскольку цикл разработки не завершён, то есть, например, не проводилось тестирование, а следовательно, продукт сырой и никому не нужный. Что в случае с Agile? Здесь иначе, даже вот как: клиент с первых итераций получает работающее ПО (пусть и не обладающее всеми нужными функциями, но стабильное).

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

Мыслить перспективой

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

Ещё одна характерная черта - написание тестов - также происходит при участии заказчика. Тестовые модули определяют код, способствуют тому, чтобы последний принимал более простую форму: разработчики начинают задумываться, что же от них требуется, и искать лучший (читай лёгкий) путь для достижения этого. Таким образом, код пишется под тесты, а затем проверяется этими же самыми тестами. Разумеется, что звезду таким подходом не схватить, но оно и не требуется.

Вместо вывода.

Agile - ваш выбор (как клиента), если:

• результат нужен как можно раньше
• вы не знаете что вам нужно, но хотите узнать
• вы желаете контролировать риски