Об Agile по гамбургскому счету

Около десяти лет тому назад возникло ощущение, что в программной инженерии упускается нечто важное: о концепции экстремального программирования (Extreme Programming, XP) речь идет еще с 2000 года, но Scrum по большей части оставался в стороне. И когда пришло время разобраться, обнаружились две поразительные неувязки в мире методов Agile.

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

Второе расхождение — неожиданная мешанина лучших и худших идей, а также немалого числа идей неоднозначных.

В программной инженерии человек, столкнувшись с новой методикой, обычно применяет то, что в военном деле называется «система свой-чужой», то есть задается вопросом, поможет новшество или навредит, однако в случае Agile этот принцип не работает. Ситуация усугубляется тем, что тон большинства публикаций по Agile весьма восторженный (за немногими исключениями [1]), хотя восхищение еще не причина сбрасывать со счетов аналитику и трезвую оценку. В свое время специалисты, пропагандировавшие объектно-ориентированное программирование, тоже частенько демонстрировали большой энтузиазм, однако это не мешало обсуждать не только «за», но и «против».

Восторги в сторону

Применительно к Agile моей естественной реакцией было применить часто помогающее правило: если вам что-то интересно, преподайте об этом курс, а если вы чем-то озадачены, напишите об этом книгу. Так и родилась книга «Agile! The Good, the Hype and the Ugly» («Скорая разработка: полезное, хайп и вредное») [2], а также онлайн-курс «Agile Software Development» (доступен на www.edx.org). Основная цель книги — создать самоучитель по Agile-методам, который должен был стать ответом на многочисленные запросы о появлении исчерпывающего, но без излишеств сжатого описания концепций скорой разработки. Вторая цель — дать анализ и критическую оценку массовых восхвалений в адрес Agile. Последние просто поражают. Взять хотя бы книгу одного из авторов концепции Scrum, которая обещает «вдвое больше работы за половину времени» [3]. Ничего себе! Вряд ли кто-то отказался бы от возможности четырехкратного повышения производительности. В другой книге [4], также от создателей Scrum, сообщаетcя: «Индустрия программного обеспечения 40 лет вами пренебрегала — не преднамеренно, но из-за своей сути. Мы хотим восстановить партнерские отношения». Ни больше ни меньше. Интересно, а при составлении подобного заявления, случайно, не использовалась сама программная система?

В целом публикациям об Agile присущ какой-то подростковый максималистский дух («Только мы знаем истину!»). Однако идеи не рождаются в вакууме — развитие Agile стоит рассматривать как эволюцию, а не революцию. Если судить только по «агиткам» скорой разработки, это неочевидно, но сообщество программной инженерии не дожидалось появления «Манифеста Agile» для признания необходимости перемен. Например, еще в 1995 году в книге «Object Successs: A Manager's Guide to Object Orientation, Its Impact on the Corporation and Its Use for Reengineering the Software Process» для бизнес-руководителей рекомендовалось проектировать ПО с расчетом на изменение и подчеркивалась важность приоритета кода над диаграммами и документацией. Польза Agile состояла не в разработке новых идей, а в том, чтобы наконец-то убедить отрасль принять уже существующие, давно известные, а также другие — например, о ценности тестов и необходимости итеративного процесса — разработки.

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

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

Сортируем идеи Agile

Итак, распределим основные позиции Agile по категориям «полезное», «преувеличенное», «вредное» и «прекрасное».

Преувеличенное

Эту категорию еще можно назвать «заурядное» — к ней относятся идеи, которые чересчур активно рекламировались, хотя в них нет ничего выдающегося. Пример — парное программирование, практика разработки ПО парами программистов, когда один сидит за компом, а второй — рядом и между ними происходит непрерывный обмен мнениями. Экстремальное программирование в качестве стандартной практики рекомендует работать в парах. Одно из применений парного программирования — стать источником исследовательских докладов. Например, можно измерять и сравнивать результаты (скорость разработки и число ошибок) двух групп, решающих одинаковую задачу: одна с помощью парного программирования, другая традиционным способом. Подобные исследования вполне можно проводить относительно легко, используя студенческие проекты в рамках университетских курсов программной инженерии. Таких исследований немало, и они свидетельствуют о том, что парное программирование не имеет существенных преимуществ или недостатков по сравнению с другими методами, например инспектированием кода. Истина в том, что парное программирование — интересная практика, которую с успехом можно применять в определенных ситуациях (скажем, для сложной части проекта, требующей компетенции в нескольких областях), но нет причин навязывать парное программирование как единственный принцип разработки. К тому же его легко перепутать с наставничеством, смысл которого уже совершенно иной.

Среди других примеров «преувеличенного» — значение принципа самоорганизации команд (разные проекты и ситуации требуют разных стилей проектного управления), важность такого очаровательного изобретения, как «покер планирования», или роль открытых пространств. Конечно, планировка офиса для разработчиков может заслуживать внимания — ведь кое-какие из лучших программных продуктов были вообще разработаны в гаражах.

Вредное

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

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

В работе [2] приводится цитата Памелы Зейв из AT&T, которая десятки лет изучала проектирование на основе функций — методом, применяемым в телекоммуникационной индустрии. Сложность с индивидуальными функциями в том, что они взаимодействуют друг с другом, и такие взаимодействия, нередко неявные, обрекают на неудачу любой метод, предписывающий создание систем путем реализации функции за функцией. Все будет казаться классным, пока внезапно не выяснится, что очередная пользовательская история конфликтует с уже реализованными ранее, из-за чего придется вернуться к началу и все переделать. Общепринятого стандарта составления требований нет, но неплохим началом будет объектно-ориентированный анализ, при котором выявляются низкоуровневые абстракции данных, а индивидуальные сценарии не имеют значения.

Полезное

Отказ от подготовительной работы и составление требований на основе пользовательских историй — все это примеры вредных советов, которые иногда могут сосуществовать вместе с вполне обоснованными рекомендациями, перечисленными в книгах по Agile. Перед тем как перейти к категориям «полезного» и «прекрасного», уместно привести пример метода, который можно отнести как к худшим, так и к лучшим в зависимости от его использования.

Как уже упоминалось, в начале прошлого десятилетия в программной инженерии стали применяться методы Agile, но в образовательной среде они еще не были отражены, и студенты осваивали их уже на практике в компаниях, а не на занятиях. В 2002 году, на заре моей преподавательской карьеры, во время перерыва на одной из лекций о проектировании ПО ко мне подошел третьекурсник и спросил, почему я до сих пор преподаю подобную чушь — ведь все уже давно поняли, что проектирование не нужно, а требуется лишь максимально простым способом добиться работоспособности системы, а потом выполнить рефакторизацию. Я был поражен, так как тогда еще не осознавал, насколько глубоко распространились идеи экстремального программирования. Студент ошибался: невозможно «волшебным образом» с помощью рефакторизации превратить дефектную, убогую архитектуру в качественную — рефакторизация мусора снова приведет к мусору. В этом смысле рефакторизацию стоит отнести к «вредному», но она же относится и к категории полезного, так как приучает к тому, что нельзя довольствоваться первоначальной версией ПО только потому, что она работоспособна. Систематически подвергать сомнению реализованные архитектурные решения и искать возможности для усовершенствования необходимо сделать привычкой. Другими словами, верный подход — это обстоятельная предварительная работа по созданию качественной архитектуры и последующее дополнительное ее улучшение путем рефакторизации.

У Agile-методов есть преимущества, очевидные сегодня многим с учетом того, насколько сильное влияние на разработку ПО они оказали. Самое заметное то, что проекты уже не осуществляются по схеме разделения задачи на крупные фрагменты, самостоятельные подпроекты, которые спустя месяцы пытаются соединить друг с другом. Такой подход сейчас звучит дико, хотя недавно был нормой. Разделить задачу легко, а вот процедура соединения может стать настоящим кошмаром: разноголосица допущений, нередко неявных, определяет архитектуру различных компонентов, делая их несовместимыми. Единственное средство против этого — пресекать расхождения с самого начала.

Итеративная разработка появилась еще до Agile, однако именно в рамках этой концепции она стала стандартом, причем итерации укоротились. Еще несколько лет назад призыв к шестинедельным спринтам воспринимался бы очень смелым, а сегодня не редкость неделя или даже один день. И это еще без упоминания набирающих популярность методов DevOps с их стремительным чередованием разработки, тестирования и развертывания. Непрерывные интеграция и тестирование стали естественными дополнениями идеи итераций. Эта и еще кое-какие заповеди Agile полезны по-настоящему.

Прекрасное

Кое-что из полезного вполне заслуживает «апгрейда» до прекрасного. Приведем пару примеров из числа идей, которые фигурируют в публикациях об Agile, но реже других, менее значительных.

Первая идея заслуживает основательного обсуждения, но здесь ограничимся лишь ее упоминанием: никакого ветвления проекта (branching). Ветвление — зло.

Вторая идея встречается в публикациях по Scrum, но без конкретного названия. Я называю ее правилом закрытого окна, согласно которому список задач для итерации, особенно современной короткой, не должен увеличиваться. Неважно, руководитель какого уровня требует дополнения, ответ должен быть отрицательным: предложенная функциональность должна будет подождать до следующего спринта. Для этого правила существует механизм «аварийного выхода» (исключение) — если добавление действительно важное, вы можете отменить спринт и начать заново. Это поможет в экстренных случаях, однако мера настолько крайняя, что прибегать к ней можно лишь очень редко. Преимущество правила закрытого окна в том, что оно обеспечивает стабильность программным проектам, предотвращая непрестанный приток якобы удачных идей, которые будут подрывать процесс разработки. По прошествии какого-то времени некоторые из этих идей уже не будут казаться такими блестящими — данное правило способствует отсеву лишнего и отбору только самых лучших предложений. Долго ждать своей очереди им не придется. Правило закрытого окна не работало бы в рамках проектов старого образца, состоящих из длинных стадий, но с типичным спринтом длиной в месяц средняя задержка будет лишь две недели, и этого времени вполне хватит на доработку идей. Никакие предложения новых функций не могут быть настолько критичными, чтобы не подождать пару недель.

***

Чтобы использовать преимущества Agile, нужно замечать и отвергать вредное, игнорировать преувеличенное и брать на вооружение полезное и прекрасное. Участники рынка научились этому достаточно быстро. Несмотря на угрожающие заявления некоторых апологетов Agile («следуйте только моим заповедям, а не то…»), в рамках всех проектов, с которыми я имел дело, на вооружение берется лишь часть идей выбранной методологии, а те, что не вписываются в культуру или не соответствуют потребностям компании, отвергаются.

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

Литература

1. B. Boehm, R. Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley, 2003.
2. B. Meyer. Agile! The Good, the Hype and the Ugly. Springer, 2014.
3. J. Sutherland. Scrum: The Art of Doing Twice the Work in Half the Time. Random House, 2015.
4. K. Schwaber, J. Sutherland. Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust. John Wiley & Sons, 2012.

Бертран Мейер (bertrand.meyer@inf.ethz.ch) — профессор программной инженерии Миланского университета и Университета Иннополис.