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

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

www.enter-agile.com


Давно стало классикой, когда выступающий перед аудиторией евангелист всего гибкого сравнивает 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 - это абсолютная гибкость ради бизнес-целей и вам решать, что в эту гибкость вкладывать, чтобы преуспеть.

No comments:

Post a Comment

 
Powered by Blogger