Хорошая, модная и плохая гибкая разработка

и о книге Бертрана Мейера "Agile!: The Good, the Hype and the Ugly"

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

Бертран Мейер "Agile!: The Good, the Hype and the Ugly"

Сейчас гибкие методы (agile methods) являются чуть ли не стандартом в современной разработке ПО. Все проводят статус митинги, ретроспективы, пишут user stories и тест-кейсы, делают частые релизы и привлекают бизнес-пользователей; ненавидят "водопадные" методы и доказывают вред переработок. Часть принципов и практик гибкой разработки стали частью нашей жизни, и уже появилось целое поколение разработчиков, которые даже не слышали про альтернативные методологии.

Но несмотря на все выгоды "скрУмов" далеко не каждая команда следует всем принципам той или иной гибкой методологии (хотя строгое следование гибким методом напоминает знаменитый анекдот про невинность мамы супруги). Оно и понятно, ведь даже сертифицированный скрам-мастер обладает собственным видением, заостряя внимание на одних аспектах метода, игнорируя другие, и привлекая третьи, которых в этом методе изначально не было.

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

ЦИТАТА
Когда мы выяснили недостатки догматичного следования идеям гибки методологий, мы должны постараться не попасть в аналогичную ловушку сами и постараться быть умеренными в своих суждениях. Эта книга пытается объяснить когда и как предписания гибких методологий должны быть заменены или объединены с другими техниками. Примером может служить компромисс между «гибкими» правилами о создании работающей системе на каждом шаге и пользе от создания программной инфраструктуры, которая не дает немедленных видимых результатов для пользователя.

Лично для меня каждая из приведенных выше составляющих очень важна. Если посмотреть внимательно на развитие нашей отрасли, то легко можно заметить, что она эволюционирует и строится на базе знаний и опыта, полученных ранее. И гибкие методы, тоже не являются в этом плане исключением. Так, например, итеративная разработка появилась в 70-х, труды по управлению требованиями и идея непрерывной интеграции – в 80-х, критика классического "водопада", опасности переработок, важности коммуникаций и того раньше. Таким образом, можно сказать, что гибкие методы – это очередной виток эволюции в разработке ПО, который делает акцент на определенном наборе практик, не столь популярных ранее, и уменьшает важность других практик, без которых разработка ПО считалась невозможной.

Но, как и всегда, очень важно понимать, ради чего делается акцент на одних практиках, и по какой причине важность других практик уменьшается!

О важности понимания решаемой проблемы

Для меня всегда важно не только знать, что мне нужно сделать, но и понимать, почему от меня хотят именно этого. Во-первых, понимание целей позволяет мне самому выбрать разные пути решения или же отказаться от решения вовсе, если я могу доказать, что оно себя не оправдывает. Во-вторых, понимание причин позволяет меньше надеяться на память и адаптироваться к изменениям внешнего окружения по ходу дела.

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

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

ЦИТАТА
Аргументы за и против кросс-функциональности аналогичны аргументов за и против личного владения кодом. Риски специализации заключаются в появлении рьяно обороняемых вотчин, и аналогичны проблемам зависимость от конкретного человека, который может уйти или оказаться недоступным в самый неподходящий момент для проекта. С другой стороны, любой сложный проект будет требовать узкой квалификации в определенных областях; не эффективно спрашивать неспециалиста помочь с задачей в такой области, где он обязательно напортачит или будет постоянно отвлекать соответствующего эксперта. В этом случае значительно эффективнее дождаться, когда эксперт освободится и решит проблему самостоятельно.

Простота и борьба с изменениями

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

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

Данное стремление является основополагающим в гибких методологиях и даже зафиксировано в одном из принципов в agile-манифесте:

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

При этом конкретные методологии разработки, например, XP (eXtreme Programming) предлагают конкретные решения, как обеспечить выполнение данного принципа: "начинайте с самого простого рабочего решения и усложняйте его лишь тогда, когда этого будут требовать тесты" (start with the simple thing that could possible work and add complexity only when it's required by tests) (еще одно описание простоты см. в "Simplicity is the Key").

ПРИМЕЧАНИЕ
Бертран Мейер в своей книге дает достаточно формальное определение того, что такое принцип (разработки, проектирования), и чем от отличается от практики. Так вот, принцип – абстрактен, а практика – конкретна. Так, например, "будьте готовы к изменениям требованиям" – это принцип, а "используйте самое простое решение для достижения расширяемости системы" – это практика.

Несмотря на то, что совет по поводу простоты очень правильный, но он не такой простой, как кажется! (pun intended). У Рича Хики есть замечательное выступление, под названием "Simple Made Easy", о котором я писал как-то в Г+, в котором отлично показано, что "простота" (simplicity) – это не одно и тоже, что и "легкость" (easiness). Простое решение обычно отличается элегантностью и отсутствием лишнего, а легкое решение зачастую бывает примитивным и тяжелым для сопровождения, но самым легким в достижении.

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

ЦИТАТА
Каждый, кто когда-либо приходил к первому решению некоторой задачи замечал, что оно является слишком сложным, а попытка упростить его обычно означает увеличение трудозатрат, причем иногда – существенное.
Как и в других случаях, критика гибких методов некоторых общих практик является корректной: программисты заниматься ненужным и необоснованным обобщением. Но это не оправдывает отказ от проверенных практик, которые заключаются если не в попытке покрыть «самый общий случай», то как минимум случай более общий, чем текущий.
Негативный эффект от таких заявлений усиливается тем, что фундаментальная проблема изменений программного обеспечения является архитектурной. Простота изменений не возникает из воздуха: для этого архитектура решения должна быть спроектирована соответственно. Хорошие учебники учат этому, но такие Big Upfront задумки рьяно отвергаются сторонниками гибких методов.
Защита гибкими авторами изменений является правильной целью, но правильна здесь лишь цель, а не средства ее достижения.
Было бы хорошо верить в заклинание, что можно начать «с самого простого решение, которое только лишь может работать», и затем постепенно изменяя архитектуру прийти к великолепной системе. Но, к сожалению, это не так.

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

Тут очень интересно проследить сходства и различия в подходах представителя "классической" школы – Бертрана Мейера ("папы" проектирования по контракту) и яркого представителя гибкой разработки – Кента Бека ("папы" TDD и XP). Несмотря на видимые различия в подходах, Бек и Мейер предлагают лишь разные пути для достижения одной и той же цели.

Мейер формален, но он также понимает, что не все решения можно и нужно принимать на ранних этапах разработки и в этом плане сокрытие информации позволит отложить ряд решений на более поздние этапы, когда выбор решения будет очевидным. Гибкие авторы отрицательно относятся к "Big Upfront Anything", хотя никто в здравом уме не должен отрицать пользы от "сесть и подумать", прежде чем кидаться в бой с шашкой на голо.

Аналогичная картина есть и в вопросах "гибкости" решения. "Гибкие" авторы явно высказываются против "гибких" решений (и снова pun intended), поскольку чрезмерное обобщение может привести к усложнению решения, да и вообще не факт, что это обобщение возможно. Эта же проблема очевидна представителям и старой школы, поэтому тот же Мейер предложил более формальный подход ее решения: обобщать можно и нужно, но лишь тогда, когда польза от этого будет очевидна, например, в конце итерации!

ПРИМЕЧАНИЕ
Подробнее о пользе принятия решения на более поздних этапах см. заметку "Идеальная архитектура", а более полное описание подхода Мейера к повторному использованию кода см. в заметке "О повторном использовании кода".

О книге Бертрана Мейера "Agile! The Good, the Hype and the Ugly"

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

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

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

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

ЦИТАТА
Почему сторонники гибкой разработки не могут оставить в покое хорошие идеи? Хорошая идея в том, чтобы не делать слишком много в начале проекта, поскольку не вся информация доступна, откладывая некоторые архитектурные решения на более поздние итерации. Но нет никакого смысла впадать в другую крайность и запрещать любую активность по предварительному проектированию.

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

Цитаты и их обсуждения

Я уже довольно давно по мере чтения книги делюсь своими мыслями и цитатами в Г+ (и даже сделал для этого фид). В этом случае, по количеству цитат и мыслей можно судить, насколько сильное впечатление оказала та или иная книга. Несмотря на скромный размер (160 страниц) мыслей оказалось довольно много:

• 7 трюков «методологического» тролля
• И снова о крайностях
• User-visible results vs. Domain model investments
• Об универсальности членов команд
• Опасности минимализма и ориентированности на результат
• Tests vs. Specification
• О минимализме в agile
• О самоорганизующихся командах
• Что такое принцип (проектирования)?
• Разница между дизайном и архитектурой
• Тщательное планирование vs. Брать и делать

Вердикт: must read!

Дополнительные ссылки

• Accurately Analyzing Agility. Анонс Бертрана о своей новой книги (вышел всего две недели назад!, а рецензия уже готова).
• Интервью с Бертраном Мейером. Во время интервью мы коснулись ряда вопросов, поднятых в книге.
• Идеальная архитектура. О том, что можно и нужно откладывать некоторые решения на более поздние этапы разработки.
• О повторном использовании кода. Обсуждается подход, предложенный Мейером, с выделенным этапом обобщения решения.
• О книге Бертрана Мейера "Объектно-ориентированное конструирование программных систем". Рецензия лучшей книги по ООП и разработки ПО ever!

З.Ы. Понравился пост? Поделись с друзьями! Вам не сложно, а мне приятно;)