Конец Agile: смерть от примитивизма

The End of Agile: Death by Over-Simplification
Hayim Makabee
Перевод: Мадорская Ю.М.
переведено и опубликовано с разрешения автора.

Что-то неладное происходит с применением Agile методов сегодня. Скачать pdf-версию статьи Злоупотребление термином Agile привело к крупнейшему надувательству в истории разработки программного обеспечения и генерации мультимилионной индустрии самопровозглашенных экспертов, продающих сомнительную сертификацию. Люди забыли исходные ценности и принципы Agile и вместо этого следуют негибким процессам с жесткими правилами и ритуалами.

Самый большой грех Agile-консультантов — это создание примитивного представления о процессах разработки программного обеспечения и недооценка реальной сложности создания программных систем. Разработчиков убедили, что архитектура программного обеспечения может естественным образом возникнуть из реализации простых User Stories, что «технический долг» всегда можно будет оплатить позже, что постоянный рефакторинг — это эффективный способ создания кода высокого качества и что «гибкость» может быть достигнута за счет жесткого исполнения Agile процесса.

Миф 1. Хорошие проектные решения рождаются при реализации User Stories.

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

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

Миф 2. Технический долг всегда можно оплатить в будущем

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

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

Миф 3. Постоянный рефакторинг — это эффективный способ создания кода

Рефакторинг при разработке кода стал очень популярен — ведь он направлен на улучшение кода. Такие техники как Test-Driven Development  (TDD) позволяют выполнять рефакторинг с низким риском — юнит тесты автоматически подскажут, что при изменении кода была нарушена его логига.

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

Рефа́кторинг (англ. refactoring) или реорганизация кода  — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения. Рефакторинг  не предназначен для исправления ошибок и добавления новой функциональности, он не меняет поведение программного обеспечения [15].

Миф 4. Гибкость может быть обеспечена за счет следования Agile процессу.

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

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

Agile умер, что дальше?

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

chart_agile

Несколько последних статей анонсировали конец ажиотажа по Agile. Dave Thomas написал, что «Agile мертв» и сразу после этого «Версия злого разработчика». Tim Ottinger написал «Я хочу возвращения Agile», но Bob Marshall ответил, что «Я не хочу, чтобы Agile возвращался». В конце концов неизбежное произошло «Анти-Agile манифест».

Теперь вопрос, что поможет Agile выйти на «склон просвещения»?

По моему мнению мы будем вынуждены вернуться к истокам — ко всем тем замечательным основам проектирования, которые мы обсуждали в 90-ых: SOLID-принципы объектно-ориентированного проектирования, паттерны проектирования, повторное использование, компонентно-ориентированная разработка. Только тогда, когда мы реализуем эти базовые принципы в нашем процессе разработки, мы достигнем настоящего состояния «гибкости», эффективно работая с изменениями.

Следующий вопрос: какой следующий шаг в эволюции проектирования программного обеспечения?

На мой взгляд — это «Antifragility».

Литература

  1. «Manifesto for Agile Software Development» http://agilemanifesto.org/
  2. «Principles behind the Agile Manifesto» http://agilemanifesto.org/principles.html
  3. Hayim Makabee «The Myth of Emergent Design and the Big Ball of Mud» http://effectivesoftwaredesign.com/2013/
  4. Hayim Makabee «Adaptable Design Up Front and the Open/Closed Principle» http://effectivesoftwaredesign.com/2013/
  5. Hayim Makabee  «Avoiding Technical Debt: How to Accumulate Technical Savings» http://effectivesoftwaredesign.com/2013/
  6. Hayim Makabee «Separation of Concerns» http://effectivesoftwaredesign.com/2012/
  7. Hayim Makabee «TDD and the Gamification of Testing» http://effectivesoftwaredesign.com/2011/
  8. Hayim Makabee  «Coping with Change in Agile Software Development» http://effectivesoftwaredesign.com/2014/
  9. Hayim Makabee  «Attention Agile Programmers: Project Management is not Software Engineering» http://effectivesoftwaredesign.com/2014/
  10. Hayim Makabee «Adaptable Designs for Agile Software Evolution» http://effectivesoftwaredesign.com/2013/
  11. Dave Thomas  «Agile Is Dead (Long Live Agility)» http://pragdave.me/blog/2014/
  12. Richard Bishop «Agile Is Dead: The Angry Developer Version» http://rubiquity.com/2014/
  13. Tim Ottinger «I Want Agile Back» http://agileotter.blogspot.ru/2014/
  14. «The Anti Agile Manifesto» http://antiagilemanifesto.com/
  15. https://ru.wikipedia.org/wiki/Рефакторинг
  16. https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

Хотите сослаться на эту статью? Используйте правильную ссылку:

Hayim Makabee. Конец Agile: смерть от примитивизма. //Практика проектирования систем.-2015. [электронный ресурс] — Режим доступа: http://reqcenter.pro/agile-myths/, свободный. — Загл. с экрана