Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/04h1016.shtml

1.6. Гибкое программирование (Agile): гибкость достигла зрелости

       Первое издание этой книги вышло в 1995 году, и в то время среди профессиональных программистов преобладало мнение о необходимости строгого соблюдения дисциплины разработки.
       Как много изменилось с тех пор! Если первое издание книги, призывавшее пересмотреть отношение к дисциплине, напоминало глас вопиющего в пустыне, то сейчас голоса сторонников гибкости раздаются столь же громко (и даже чаще), чем голоса проповедников дисциплины. Разумеется, я говорю в первую очередь о защитниках гибких методов разработки ПО (Agile).
       Движение за гибкое программирование Agile стало, я бы сказал, естественным результатом тех ориентированных на мастерство “неуправляемых” гибких методов, о которых говорилось выше в этой книге. (Agile — это собирательный термин для таких методологий, как “экстремальное программирование” (extreme Programming, XP), Crystal Clear, адаптивное программирование (Adaptive Software Development), скрам (Scrum), метод динамической разработки систем (Dynamic Systems Development Method) и функционально-ориентированная разработка (Feature-Driven Development). Наиболее популярным среди них считается ХР.)
       Действительно ли Agile — порождение всех различных гибких методов разработки программ, о которых вы только что прочли? Чтобы ответить на этот вопрос, взглянем на ценности и принципы Agile, изложенные в “Манифесте Agile” (“Agile Manifesto”) и прилагаемых к нему “Принципах манифеста Agile” (“Principles Behind the Agile Manifesto”). Эти документы были разработаны в 2001 году на конференции в Сноуберде (Юта). Там присутствовало 17 сторонников перечисленных в предыдущем абзаце методологий, которые тогда назывались “облегченными”.
       Во-первых, есть группа ценностей Agile, утверждающих сравнительную важность ряда факторов программного проекта (сторонники движения Agile включили их в “Манифест Agile”, http://agilemanifesto.org):
       — отдельные личности и взаимодействие важнее технологических процессов и инструментов;
       — работающая программа важнее исчерпывающей документации;
       — сотрудничество с заказчиком важнее заключения контракта;
       — реакция на изменение условий важнее строгого следования плану.
       А вот список принципов Agile (http://agilemanifesto.org/principles.html):
       — отдавать высший приоритет удовлетворению заказчика, которое достигается путем ускоренной и непрерывной поставки продукта;
       — допускать изменения в требованиях, даже на поздних стадиях разработки;
       — часто выпускать работающие версии продукта;
       — поддерживать ежедневное общение коммерческих служб и разработчиков;
       — привлекать к работе мотивированных программистов, обеспечиватьих всем необходимым и доверять им;
       — общаться лично: это самый эффективный и полезный способ передачи информации;
       — принять за главный критерий прогресса работоспособное ПО;
       — поощрять разумную интенсивность работы, избегая смертельной гонки;
       — непрерывно заботиться о техническом совершенстве и хороших проектных решениях;
       — поощрять упрощение — умение выявить как можно больше работы, которую НЕ нужно делать;
       — поощрять самоуправление в командах: оно повышает качество программ;
       — регулярно исследовать возможности усовершенствований.
       Любопытно сравнить эти ценности и принципы с тем, что было сказано выше об умельцах/оппортунистах. Ряд сходных черт заметен сразу (например, приоритет людей и программ над процессами и документацией). Но вскоре выясняется, что Agile идет гораздо дальше тех первых идей. Такие аспекты, как “сотрудничество с заказчиком”, “реакция на изменение условий”, “удовлетворение заказчика” и “допущение изменений в требованиях”, оказываются значительно глубже, чем более простые размышления о гибком подходе, имевшие место в 1995 году.
       Большинство из того, что движение Agile добавило к первоначальным идеям, в значительной мере связано с социологией программных проектов. Многие цели и принципы касаются отношений с заказчиком. Прочие характеризуют отношения внутри организации, разрабатывающей ПО. Такое введение социологии в понятие о технической гибкости разработки — интересный и важный вклад сторонников Agile.
       Один из самых интересных вопросов по поводу Agile-методов — возможность их применения. В каких проектах можно их применять? Когда Agile-методы только появились, ответ на этот вопрос казался очевиден. Эли-стер Кокберн (Alistair Cockburn) указал желательные места применения Agile-методов в своей ранней книге “Agile Software Development” (Гибкая методология разработки) [Cockburn 2002]). По его мнению, их следовало применять только в проектах, удовлетворяющих таким условиям:
       — в одном помещении работают от двух до восьми человек;
       — эксперты по применению находятся неподалеку;
       — цикл разработки длится месяц;
       — есть полностью автоматизированные регрессивные тесты;
       — разработчики обладают большим опытом.
       С Кокберном согласился даже такой активный сторонник дисциплинированного подхода, как Барри Боэм (Barry Boehm). В своей книге “Balancing Agility and Discipline” (Между гибкостью и дисциплиной) [Boehm and Turner 2004], где была предпринята попытка компромисса между этими двумя подходами, Боэм писал, что Agile-методы следует применять командам, разрабатывающим небольшие системы, когда общение с заказчиками/пользователями ничем не затруднено, а технические требования изменчивы. С другой стороны, Боэм отметил, что дисциплинированные подходы (он назвал их “плановыми”) следует применять в проектах, для которых характерны следующие условия:
       — большой объем и сложность при относительно устойчивых технических требованиях;
       — высокие требования к надежности/безопасности;
       — наличие предсказуемого окружения.
       Но эти первые представления о границах применения Agile-методов несколько обветшали. Такие сторонники Agile, как Уильяме и Кокберн [Williams and Cockburn 2003] (да, тот самый упомянутый выше Кокберн!), подняли ставку размера проекта до “50 или меньше программистов, работающих в одном месте”. Другие практически сняли ограничение на размер проекта: [Sutherland 2001] утверждает, что “Agile можно масштабировать на крупные проекты”.
       Конечно, здесь решался вопрос о том, насколько широко можно использовать Agile-методы. Если они подходят только для небольших команд, то это весьма сужает область применения (и, заметим, влияет на подготовку специалистов, ибо если Agile-методы применимы только в маленьких проектах, вряд ли стоит включать их в академические программы по компьютерным наукам).
       В истории программирования уже случалось, что новые идеи, предлагаемые для определенного узкого применения, неожиданно возвеличивались сверх всякой меры. Например, язык программирования Ada первоначально разрабатывался для поддержки систем реального времени и содержал определенную порцию системных средств, позволяющих писать компиляторы Ada на самом языке Ada. Но вскоре приверженцы Ada стали рекомендовать его для применения во всех предметных областях, в частности, для бизнес-систем, где вовсе не предполагалось его использовать. (Любопытно отметить, что эти чрезмерные притязания стали в итоге предсмертным хрипом. Язык Ada в конце концов если не умер, то оказался близок к смерти, и произошло это отчасти из-за старания использовать его в областях, для которых он не предназначался.)
       Выше я упомянул строгие ограничения на область применения. Бдительный читатель может поинтересоваться, хотя бы мимоходом, каковы эти ограничения в действительности. Прекрасный ответ на этот вопрос был дан в интересном споре между сторонниками Agile и дисциплинированных методов, приведенном в [Beck and Boehm 2003]. Боэм (да, все тот же Барри Боэм) привел данные, которые, на первый взгляд, укрепляли позиции сторонников Agile, — о том, что добрых 60% программных проектов можно считать маленькими, поскольку в них участвует меньше 10 человек. Но, как отметил Боэм, оценивая такие данные, нужно учитывать фактическое время, затраченное на проект, которое зависит как от количества участников, так и от количества написанных строк кода. При таком подходе лишь 17% всех программных проектов в мире оказываются маленькими. Таким образом, по мнению Боэма, роль Agile-методов во всей системе программирования невелика.
       Другая проблема применимости Agile-методов связана с вопросом о мере методологической чистоты, которую следует соблюдать их сторонникам. Сторонники Agile-методов обычно рекомендуют принимать их безоговорочно (в отдельных гибких методологиях, вроде экстремального программирования, есть множество конкретных указаний и запретов).
       Интересный “практический” ответ на этот вопрос есть в [Lindvall et al 2004], где изучается применение Agile (обычно экстремального программирования) в ряде крупных организаций. Четыре фирмы сообщили об успешном применении Agile (выразившемся, в основном, в росте качества ПО, а также в легкости освоения, увеличении гибкости, улучшении морального состояния и сокращении издержек). Но ни в одном из этих случаев не удалось воспользоваться стандартными способами применения Agile-методов. Во всех четырех компаниях сообщили, что индивидуальная подгонка методов “абсолютно необходима” по таким причинам, как: а) потребность в известных формальностях и документации в проектах, где участвует несколько команд, использующих Agile-методы, б) естественный конфликт таких концепций Agile, как непрерывный рефакто-ринг и непрерывная интеграция, с большинством способов управления конфигурацией. В основном в этих четырех компаниях такая подгонка требовалась там, где новые методы (Agile) должны были взаимодействовать со старыми (традиционными) подходами.
       Между тем, в ходе обострения споров о применимости возникает любопытная перебранка, подчас напоминающая описанную выше стычку между программистами в баре на Прямом шоссе. Сторонники Agile говорят о “вызывающем трепет хаосе” (некоторые находят Agile-проекты хаотичными) и “отбросах структуры” (структурированные методы, под которыми они понимают соблюдение дисциплины, для них скучны и утомительны). Приверженцы дисциплины склонны называть Agile-методы “структурированной анархией”.
       Кроме того, слышны голоса другой школы. Сковронский [Skowronski 2004] утверждает, что все отмеченные выше социологические факторы несовместимы с ключевой для творческого решения проблем ситуацией, когда над задачей работает единственный исследователь. Попытавшись представить таких блестящих творцов, как Исаак Ньютон и Фома Аквинский, — известных любителей работать в одиночку, — работающими в паре, как это принято в экстремальном программировании, он делает вывод, что это совершенно невозможно. Разумеется, тут мы сталкиваемся с новой проблемой: какова роль индивидуального таланта в современных программных проектах? Этот вопрос, хотя он тесно связан с темой данной книги, мы все же оставим для последующих дискуссий за ее рамками! (Лично я убежден, что выдающийся талант может быть очень ценным на определенном этапе жизненного цикла, например в проектировании, но в целом мешает решению других задач в крупных проектах.)
       Встает и еще один вопрос, также имеющий отношение к данной книге. Способствуют ли Agile-методы усилению творческого начала? В той же книге Сковронский, конечно, отвечает на данный вопрос отрицательно. Но альтернатива Agile-методам — не блестящие индивидуальные таланты, чего так хотелось бы некоторым из нас, а дисциплинированный подход. И с учетом того, что гибкость Agile допускает гораздо больше творческой свободы, чем “отбросы структуры” дисциплинированного метода, я первым соглашусь с теми, кто считает, что Agile-программирование лучше сочетается с творчеством, чем его традиционные альтернативы.
       Чем все это закончится? Большинство программных новшеств вызывает непомерный ажиотаж, который утихает с появлением рядовых инструментов программирования, часто полезных, но далеко не соответствующих первоначальным претензиям. Вероятно, есть немало оснований считать, что то же самое произойдет с Agile-методами, как это случилось со структурным программированием (и, пожалуй, с объектно-ориентированным подходом), а ранее — со средствами CASE и языками четвертого поколения.
       Но возможен и другой вариант. Все чаще утверждают, что Agile-методы должны занять свое место наряду с традиционными дисциплинированными подходами как альтернативный способ разработки для проектов определенного рода. Например, это стремится показать Боэм в процитированной выше книге.

Ссылки
       Военм and Turner 2004 — Balancing Agility and Discipline, Addison-Wesley, 2004; Barry Boehm and Richard Turner.
       COCKBURN 2002 — Agile Software Development, Addison-Wesley, 2002; Ali-stair Cockburn.
       Evans and Boehm 2003 — “Agility Through Discipline: A Debate”, IEEE Software special issue on Agile methods, June 2003; Kent Beck vs. Barry Boehm.
       Lindvall et AL 2004 — “Agile Software Development in Large Organizations”, IEEE Computer, Dec, 2004; Mikael Lindvall, Dirk Muthig, Aldo Dagnino, Christina Wallin, Michael Stupperich, David Kiefer, John May, and Tuomo Kahkonen.
       SKOWRONSKI 2004 — “Do Agile Methods Marginalize Problem-Solvers?” IEEE Computer, Oct., 2004; Victor Skowronski.
       Sutherland 2001 — “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies”, Cutter IT Journal special issue on the Great Methodologies Debate: Part 1, Nov., 2001; Jeff Sutherland.
       Williams and Cockburn 2003 — “Agile Software Development: It's About Feedback and Change”, IEEE Software special issue on Agile methods, June, 2003; Laurie Williams and Alistair Cockburn.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/04h1016.shtml