понедельник, 16 июня 2014 г.

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

и о книге Бертрана Мейера "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"

clip_image002

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

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

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

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

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

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

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

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

Вердикт: must read!

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

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

8 комментариев:

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

    ОтветитьУдалить
    Ответы
    1. Я бы посоветовал первые 150-200 страниц книги Гради Буча "Объектно-ориентированный анализ и проектирование" (желательно 2-е издание, а не 3-е). Там очень хорошо описаны подходы борьбы со сложностью, иерархия, инкапсуляция и т.п. Все эти вещи очень помогают бороться со сложностью и удерживать сложные задачи в голове.

      Удалить
  2. Опечатка? "Так вот, принцип – абстрактен, он практика – конкретна." не "но" случаем?

    ОтветитьУдалить
  3. Никогда бы не подумал, что Бертран Мейер мог написать такую книгу!
    И пожалуй, об этом нигде не узнать, кроме этого блога:)

    Сергей, хочу прокомментировать второй абзац поста.
    Когда у нас провалился SCRUM, волей-неволей пришлось задумываться о причинах провала. Мысли были ровно как во втором абзаце - какие "принципы" проигнорировали, какие "аспекты" упустили, какие "мелочи" оставили без внимания и т.п. и т.д., вплоть до "На какие вопросы забывали отвечать во время Daily Scrum?"

    Установить причину провала было трудно.

    Сложность #1.
    Чтобы понять, где и что мы упустили, требуется хорошо представлять, а что вообще есть SCRUM? Говорят, когда Толстого спросили в чем смысл романа "Анна Каренина", он ответил, что ему придется пересказать роман слово в слово.

    Книжка в 500 страниц - это и есть SCRUM? Но это слишком, чтобы быть простым. Сложные вещи вызывают недоверие.

    Пришлось искать первоисточники, и оказалось, что SCRUM это всего 16(!) страниц очень простого английского!
    https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf

    Сложность #2.
    Найти первопричину.
    К счастью, в коротком, но чрезвычайно емком оригинале это сделать проще.
    Красноречивое определение:
    The Development Team consists of professionals who do the work of delivering a potentially
    releasable Increment of “Done” product at the end of each Sprint.

    Ключевое слово тут, думаю, "профессионалы".

    Что бы мы не делали, какие митинги не устраивали, они не сделали бы нас техническими профессионалами.

    Возможно этим и объясняется вся магия SCRUM-a - команда профи и именно она сделает проект, ну а сам SCRUM просто сделает их работу более приятной, прозрачной и предсказуемой.

    Поэтому нам для успеха SCRUM-а на проекте следовало изучать в первую очередь не Agile техники, а сети, безопасность, алгоритмы, языки, базы данных.


    ОтветитьУдалить
    Ответы
    1. Спасибо за развернутый комментарий.

      Мне понравился акцент на профессионалах. Кстати, где-то в своей книге Мейер обсуждал этот аспект гибких методов в контексте управления командами.

      Да и выводы вы сделали очень правильные, ИМХО. Я с ними согласен.

      Удалить
  4. Все-таки отвратительно перевели в свое время "Хороший, плохой, злой". Перевели бы как "Хороший, плохой и уродливый", у тебя заголовок был бы удачнее.

    ОтветитьУдалить
    Ответы
    1. Да мне кажется, что заметку можно и так переименовать, чтобы лучше отразить ее суть.

      Удалить