Антипаттерн: Agile против всего на свете

Раздел: Programming / Теория разработки @ 16.02.2010 | Ключевые слова: waterfall agiile rup

Автор: Александр Якима

Давно стало классикой, когда выступающий перед аудиторией евангелист всего гибкого сравнивает Agile с другими более ранними методологиями разработки (чаще всего достается Waterfall’у и RUP) в негативном контексте — и то и это неправильно во всем, кроме Agile. И поскольку я искренне поддерживаю идею того, что Agile пришел на смену другим методам, должен согласиться, что гибкие методы лучше… однако, не ценой беспощадной критики классических методов. Объясню почему…

Основная причина — критика эта носит идеологический (весьма эмоционально глубокий) и в то же время недалекий с точки зрения рациональности характер. Основное последствие — новоиспеченные сторонники гибких методологий часто проявляют полный нигилизм по отношению не только к самой концепции Водопада или RUP, но и к частным методам, среди которых есть много полезного для гибкой разработки. Парадокс? Вовсе нет. Примеры…

Анализ требований

Если не пытаться понять, что в действительности стоит за общей формулировкой фичи, которую записали на бумажке, то очень вероятно, что вам придется просто переделывать «имплементацию не того, что ожидалось». И тут стоит вспомнить, что в Водопаде и RUP управление требованиями — это отдельная дисциплина, в которую инвестируется много усилий. Итак, напомним себе, зачем нам нужен Agile с точки зрения требований: для того, чтобы доставить максимальную ценность пользователю максимально быстро. Переменной величиной, которой как раз нужно уметь правильно управлять, является объем работы (scope), так как он как раз и не равен конечной пользе. Иными словами, задача управления требованиями в Agile — минимизировать scope как можно ближе до уровня только полезной функциональности. Но это искусство и тяжелый труд, в котором дисциплина работы с требованиями стоит на первых позициях! Если этой дисциплины нет, а вся культура управления требованиями сведена к написанию карточек и последующей их произвольной интерпретацией, то тогда Agile ничем не лучше Водопада, где недостаток работы с требованиями состоит только в том, что они разрабатываются заранее и поэтому далеко не всегда соответствуют знаниям, приобретенным под конец разработки системы. Тогда Водопад даже лучше, потому что в данном отношении более предсказуем — нам хотя бы известно, в чем мы ошибаемся. Итак, вывод №1:

Управление требованиями в Agile требует огромной дисциплины, примеры которой следует позаимствовать в RUP или Waterfall.

Документация

Документация — это не часть управления требованиями (хотя пересечения существенны), поэтому я вынес ее в отдельный пункт. Отказ от документации, как от первородного зла, ведет к тому, что приобретенный ценный опыт и знания будут недоступны тогда, когда они нужны. Это документация к коду, требованиям, схеме дэплоймента… да вообще к чему угодно. Итак, в отношении документации мы должны помнить, почему мы предпочитаем Agile другим методам разработки — потому что Agile позволяет приобретать знания о системе значительно быстрее других методов разработки. Но если у команды нет культуры работы со знаниями, то это преимущество теряется. Итак, вывод №2:

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

Архитектура системы

Часто архитектура как сущность вообще отвергается, а привычные из RUP артефакты (представление 4+1, к примеру или его составляющие: use-case сценарии, диаграммы дэплоймента и т. п.) возводятся в ранг ругательств. Почему они не нужны? Да потому, что у нас среди гибких методов есть все на замену традиционным. Не верите - вот вам трюк на этот случай: система безопасно эволюционирует под действием двух факторов — постоянного рефакторинга и полного покрытия юнит-тестами… На самом деле обычно нет ни одного, ни другого. Эти два фактора действенны, но мало кто из команд, называющих себя гибкими, действительно умеют этим пользоваться. Наоборот, «технический долг» системе неумолимо накапливается и в конце концов приводит к горьким последствиям. Почему мы выбираем Agile с точки зрения архитектуры? Потому, что Agile дает возможность быстро строить новые системы и поддерживать в них изменения. Но если мы невнимательно относимся к архитектуре системы — ни то ни другое невозможно. Итак, вывод №3:

Разработка и поддержка архитектуры так же важна в Agile, как и в RUP или Waterfall. Несмотря на отличия в жизненном цикле архитектуры, дисциплину и отдельные методы следует заимствовать у традиционных методов.

Подведем итог

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

Распечатать статью