Введение. Обзор

Обзор

Появление идеи agile датируется 1990 годом и связано с разработкой XP – экстремального программирования, но слава пришла к agile после опубликования манифеста в 2001 году [Agile 2001].

Рис. 1.1. Agile-манифест разработки программного обеспечения

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, непосредственно занимаясь разработкой и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану;

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

Создатели Agile-манифеста опубликовали этот документ на фоне, изображающем полдюжины мужчин среднего возраста, носящих джинсы, располневших, повернувшихся к нам спиной, слушающих оратора, видимо, рассказывающего об agile-манифесте. Все это должно символизировать неотразимую силу призыва, содержащегося в манифесте. Лично я, когда хотел выразить сущность agile, то выбрал фотографию, представленную на обложке этой книги (балерина Наталья Осипова в "Лебедином озере"), что может говорить о том, насколько я не иду "в ногу со временем". Эта фотография прекрасна.

Идеи agile подняли шумиху в индустрии, стали находкой для технической прессы, явились тем видом аргументов, которые в жестком соперничестве компании использовали для привлечения лучших программистов: "Приходите к нам! Наши разработки – agile!" Не будучи единой концепцией, под agile понимается совокупность идей, содержащихся в нескольких методах, применяемых в разнообразных вариациях. К ним относятся, в частности, такие методы, как экстремальное программирование (eXtremal Programming -XP), Scrum^{3Название Scrum заимствовано из игры Регби – термин, обозначающий схватку команд перед вбрасыванием мяча.}, Crystal, Lean (Lean Software Development (LSD) – экономичная разработка). Многие разработчики используют некоторые из agile идей вне какого-либо конкретного метода. В этой главе мы попытаемся, не опускаясь до деталей, проникнуться духом agile идей, рассматривая основные концепции.

• Общие предпосылки, очерчивающие agile круг видения мира (1.1).
• Принципы: правила, лежащие в основе, организационные и технические (1.2).
• Роли: права и ответственности лиц (actors), участвующих в agile процессе (1.3).
• Практики: специфические приемы, практикуемые agile командами (1.4).
• Артефакты: инструменты, как виртуальные, так и реальные, поддерживающие применяемые практики (1.5).

Принципы следуют из предпосылок. Практики, роли, артефакты следуют из принципов. В последнем параграфе (1.6) дается первая оценка подхода.

Эта глава представляет своего рода концентрат всей книги, инспекторский обзор ключевых идей. За исключением последнего параграфа, она носит описательный характер, нейтрально представляя agile идеи. Для краткости, обобщенное описание agile методов дается здесь без ссылки на какие-либо источники. В последующих главах приводятся пространные цитаты agile авторов, где они детально обосновывают методы.

1.1 Общие предпосылки

Из текста agile манифеста с очевидностью следует, что agile – это не просто собрание ряда методов, а некоторое движение, идеология. Прежде чем рассматривать специфические принципы, практики, роли и артефакты, следует проникнуться духом agile философии. Она базируется на пяти доктринах или предпосылках.

Первая доктрина связана с фундаментальной проблемой: каковы роли разработчиков и менеджеров в разработке проекта. Методы agile переопределяют и ограничивают работу менеджеров, передавая многие из их обязанностей команде разработчиков, включая такую важную роль, как выбор предстоящих для выполнения задач и их распределение между членами команды. Можно дать социологическую интерпретацию agile движения как "революции рядовых работников"^{4В оригинале "revolt of the cubicles" – революция работников, сидящих в офисе, разделенном перегородками.}, отказ от жестких, административных методов управления, характерных для стиля Джилберт-босс^{5Джилберт-босс (Dilbert boss) – ставшее нарицательным имя персонажа популярного в 90-х годах комикса, грубого, некомпетентного босса, управляющего проектом, которому при всех неудачах всегда удается оставаться во главе проекта.}. Программисты зачастую возмущены подобными методами управления, игнорирующими специфику разработки ПО. Документы и диаграммы еще не делают систему – систему создает код. Методы agile, в частности, реабилитируют значимость кода.

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

Вторая доктрина связана с отказом от "Предваряющего анализа" и веры в то, что все следует предусмотреть. Порицая существующие методы разработки ПО, в agile мире их называют "Предваряющий анализ" (Big Upfront). Под этим понимается экстенсивное планирование в начале проекта, включающее:

• этап создания документа требований, определяющий цели проекта;
• этап проектирования, определяющий архитектуру проекта.

С точки зрения agile:

• требования не могут быть определены в начале проекта, поскольку потребители сами не знают, чего хотят; даже если удается написать документ "требований", то он является бесполезным, так как в ходе разработки эти требования будут меняться;
• этап проектирования – бесполезная трата времени, поскольку мы не знаем, что будет работать, а что нет.

Вместо документа требований agile методы рекомендуют постоянное взаимодействие с потребителями (customers) – заказчиками и пользователями. Как следствие, представители потребителей включаются в состав команды, что, с одной стороны, дает возможность им посмотреть "изнутри" на возникающие проблемы, а с другой – позволяет команде быстро реагировать на эти проблемы, имея обратную связь.

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

Если в процессе разработки решение перестает работать или становится неэффективным, выполняется рефакторинг – изменение проекта, устраняющее неэффективность.

Как следствие, agile процесс является итеративной разработкой с временными рамками. Ближайшая альтернатива документу требований – список функций с расставленными приоритетами, из которого команда выбирает функции для реализации на итерации, исходя из критерия максимизации "Возврата Инвестиций" – ROI (Return On Investment). Вследствие отсутствия "больших" задач этот выбор делается последовательными шагами, называемыми итерациями ("спринтами" в Scrum), каждый из которых занимает фиксированное время – не более нескольких недель, отсюда – "с временными рамками". В процессе разработки итеративно добавляется функциональность. Каждое добавление представляет ограниченную договорную функциональность. Литература agile изобилует причитаниями по поводу того, что при традиционном проектировании создается множество свойств, которые вряд ли кто-либо будет использовать. Стратегия agile предлагает радикально ограничивать функциональность, оставляя лишь наиболее важные свойства, оцениваемые их вкладом – их ROI. Экономное программирование – LSD ссылается на опыт, полученный в других видах деятельности, в частности, в автомобильной промышленности, где "минимизация расточительности" является одной из ключевых проблем. Система "Канбан" (Kanban), разработанная японской фирмой "Тойота", обеспечивает поставку продукции заданного качества точно в указанные сроки при минимизации затрат на всех этапах процесса работы.

На каждой итерации при выборе функциональности требуется "договоренность". С позиций agile, как невозможно в начале разработки сформулировать все требования к системе, точно так же невозможно обеспечить одновременно желаемую функциональность и выдержать сроки поставки. Для разработки с "временными рамками" достижение компромисса (вы хотите все или вы хотите получить нечто уже в следующем месяце?) достигается обычно выбором второго решения. Если не все функции, планируемые на итерации, могут быть реализованы в заданный срок, то урезается функциональность, а не передвигается срок исполнения. Пропущенная функциональность либо будет реализована на следующем шаге, либо (если последующий анализ ROI покажет ее неэффективность) будет опущена. Этот процесс планирования и согласований требует постоянных договоренностей с потребителями.

Заключительной доктриной является фокусирование на качестве, которое с точки зрения agile сводится к непрерывному тестированию (в отличие от других подходов к обеспечению качества, в частности, основанных на методах проектирования, формальной методологии, презрительно называемой "Предваряющий анализ").

Здесь мало внимания уделяется обеспечению качества в традиционном понимании, зато крайне отрицательно относятся к попыткам продолжать разработку, если уже созданный код не прошел всестороннее тестирование. Одним из вкладов гибкой разработки является повышение внимания к регрессионному тестированию^{6Регрессионное тестирование предназначено для борьбы с часто возникающей при разработке ПО ситуацией, которая описывается поговоркой: "нос вытащишь, хвост увязнет; хвост вытащишь, нос увязнет".}, предполагающее создание множества регрессионных тестов. Регрессионный тест – это тест, на котором была зафиксирована ошибка. Ошибка была исправлена, но, вероятно, она может возникнуть вновь в процессе исправления последующих ошибок. Регрессионные тесты нужно прогонять заново каждый раз, когда в систему вносятся изменения. Регрессионное тестирование было известно задолго до появления agile, но при гибкой разработке этому процессу отводится центральная роль.