Ужасный, шумный и прекрасный: оценка agile подхода

11.1 Agile ужасный

Начнем с худшего в agile подходах – идей, которые вредят процессу разработки.

11.1.1 Неприятие предваряющего анализа

Речь, бесспорно, пойдет о неприятии такой деятельности, как предваряющий анализ, прежде всего предваряющий анализ требований и предваряющее проектирование. Лозунг agile "Никакого предваряющего анализа" сопровождается заманчивыми комментариями. Это правда, что никто не может выработать полностью соответствующие требования перед началом разработки системы, – требования будут изменяться. Это правда, что архитектура должна улучшаться в процессе разработки. Эти наблюдения отражают фундаментальные сложности программной инженерии. Тщетно пытаться определить все в самом начале.

Но это не аргументы для отрицания нормальной инженерной практики, практики фактически любого разумного предпринимателя – изучить проблему до того, как попытаться ее решить, определить архитектуру решения, прежде чем конструировать отдельные детали. Альтернатива, предлагаемая agile методами, – начинать с конкретного случая: идентифицировать некоторую функциональность, построить ее, оценить и скорректировать результат, повторить этот процесс. Это не замена серьезных требований и проектирования.

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

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

11.1.2 Пользовательские истории как основа требований

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

В результате построенная система сужается, соответствует идентифицированным пользовательским историям, но не способна применяться для непредвиденных ситуаций и ее трудно адаптировать к более общим требованиям.

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

11.1.3 Разработка, базирующаяся на функциях, и игнорирование зависимостей

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

11.1.4 Отказ от средств анализа зависимостей

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

11.1.5 Отказ от традиционных менеджерских задач

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

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

11.1.6 Отказ от предваряющего обобщения

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

11.1.7 Встроенный потребитель

Идея XP встраивать в команду потребителя не очень хорошо работает на практике по причинам, объясненным в предыдущих обсуждениях. Однако введенное в Scrum понятие владельца продукта фигурирует ниже в списке блестящих идей.

11.1.8 Тренер (консультант) как отдельная роль

Идея Scrum назначения Scrum-мастера хороша для Scrum, но не подходит для большинства проектов. Хорошая разработка требует не тех, кто только говорит, но тех, кто делает.

11.1.9 Разработка, управляемая тестами

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

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

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

11.1.10 Отказ от документов

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

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

11.2 Agile шумно рекламируемый

Следующая категория включает идеи, которые могут иметь значение, но не похоже, что они делают важный вклад в то, что действительно стоит учитывать: производительность процесса разработки и качество создаваемого продукта. К этим идеям можно отнести следующие.

• Парное программирование, рекламируемое сверх меры. Применяемое на практике от случая к случаю, парное программирование следует включить в набор используемых программистских приемов. Но нет достоверных сведений, что оно обеспечивает существенное улучшение процесса разработки или что оно лучше таких классических приемов, как обзор кода. Нет никаких причин рекомендовать его как единственный стиль разработки.
• Открытое рабочее окружение. Нет единого способа организации рабочего окружения. Следует лишь знать, что его организация должна способствовать простым неформальным коммуникациям. Помимо этого, возможны любые решения, лишь бы они не угрожали успеху команды. (Связанная тема появится в списке хороших идей – избегать распределенных команд.)
• Самоорганизуемая команда. Некоторые команды достаточно компетентны и опытны, чтобы все вопросы управления решать самостоятельно, подобно оркестру без дирижера. Большинство команд не такие. Каждая ситуация требует собственных организационных решений, и нет никаких причин предлагать единую схему для всей индустрии.
• Сохранение устойчивого темпа. Работать размеренно – прекрасный совет. Марши смерти (аврал, бессонные ночи при сдаче системы) – не лучшая практика управления. Но совет может оказаться благим пожеланием. Когда в игру вступает экономика, хорошие намерения уходят в сторону. И это характерно не только для программистского мира. Исследователь, готовящий статью для конференции, должен успеть к контрольному сроку, как и компания, готовящая предложения для участия в конкурсе, – всем часто приходится работать в авральном режиме. Большинство методистов, конечно, могут аргументированно доказывать, что такая практика должна восприниматься как исключение.
• Производить минимальную функциональность. Всегда правильно задавать вопрос о том, будет ли востребована предлагаемая функциональность. Обычно она вводится по той причине, что некоторые важные пользователи хотят ее иметь. Всегда просто выступать против раздувания и относиться с презрением к программным монстрам (Microsoft Word и Adobe Acrobat – любимые примеры), но попробуйте удалить любую функциональность, и такой крик поднимется в мире пользователей этих систем.
• Игра в планирование, планирующий покер. Эти интересные приемы позволяют заранее оценить стоимость и время предстоящего этапа разработки, но они не могут заменить научные подходы. В частности, они таят угрозу "превосходства толпы", когда голос эксперта невозможно услышать в хоре новичков.
• Члены и наблюдатели. При встречах, на которых обсуждается проект, точка зрения людей, непосредственно его реализующих, имеет большее значение, чем взгляды остальных участников. Это тривиальное наблюдение не заслуживает того внимания, которое agile канон уделяет делению на "поросят" и "цыплят".
• Коллективное владение кодом. Политика, управляющая тем, кому разрешается вносить изменения в отдельные части кода, – деликатное дело для каждого проекта. Она зависит от природы команды и многих других обстоятельств. Бессмысленно предлагать единое решение.
• Кроссфункциональная команда. Хорошая идея поощрять разработчиков быть компетентными во многих областях, не следует делить проект на узкие королевства, управляемые одним экспертом в данной области. Кроме этих общих советов, мало что можно добавить по этому поводу. Очевидно, что существуют специальные области, требующие определенных навыков. Если один из ваших разработчиков – эксперт по базам данных, а другой – по параллельным вычислениям, то не следует поручать первому разбираться с ситуацией клинча, а второму заниматься оптимизацией запросов к данным. Это наблюдение – еще одна причина, по которой agile политика распределения задач с наибольшей бизнес-ценностью первому свободному разработчику – примитивная политика, потенциально приносящая вред успеху разработки.

11.3 Agile хороший

Продвижение рефакторинга является важным вкладом agile подхода, в частности XP. Хорошие программисты всегда знают, что недостаточно получить нечто, что работает, нужно еще раз взглянуть на проект и при необходимости улучшить его. Рефакторинг делает все достойным образом; существует каталог фундаментальных образцов рефакторинга. Заменить предваряющее проектирование рефакторингом – плохой совет, принадлежащий ужасной части agile. Но как практика, сопровождающая тщательное начальное проектирование, достойна наилучшей рекомендации для всех программных разработок.

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

Методы agile справедливо настаивают на важности коммуникаций в команде (осмотической, в терминологии Crystal) для успеха проекта. Одним из следствий является рекомендация использовать всюду, где можно, локализованные в одном месте команды, предпочитая их распределенным командам.

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

Подобным образом идентификация в Lean источников затрат и настаивание на их удалении обеспечивают отличную дисциплину для программных проектов.

11.4 Agile прекрасный

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

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

Связанные практики непрерывной интеграции и набора регрессионных тестов не являются собственно изобретением agile, но были популяризированы XP, и сегодня являются главным фактором успеха современных проектов. Индустрия, или, по крайней мере, компетентно управляемый проект ушел от старой практики "большого взрыва" и никогда к ней не вернется.

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

Итерации с жестким временным интервалом, не принимающие никаких задержек, даже если какая-то функциональность осталась нереализованной, – это отличная дисциплина, заставляющая членов команды и представителей потребителей вести планирование тщательно и реалистично, привнося стабильность в проект. (Мы видели, что это правило применимо только к итерациям, а не к проекту в целом, для которого потребитель диктует даты поставки.)

Scrum ввел четко определенное понятие владельца продукта, кто представляет цели потребителей и кто имеет право принятия решения, - что войдет в продукт, а что нет.

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

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

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

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