Использование UML - это все равно что смотреть себе под ноги во время ходьбы. Он делает осознанным и явным то, что обычно можно делать бессознательно. Новичкам нужно хорошо обдумать, что они делают, но профессиональный программист уже знает, что они делают. В большинстве случаев написание самого кода происходит быстрее и эффективнее, чем написание кода, потому что их интуиция программирования настроена на поставленную задачу.
Однако дело не только в том, что вы делаете. А как насчет нового сотрудника, который придет через шесть месяцев и должен быстрее освоить код? Что насчет пяти лет, когда все, кто сейчас работает над проектом, уйдут?
Невероятно полезно иметь некоторую базовую актуальную документацию, доступную для всех, кто присоединится к проекту позже. Я не сторонник полноценных UML-диаграмм с именами методов и параметрами (слишком сложными для сопровождения), но я считаю, что базовая диаграмма компонентов в системе с их взаимосвязями и основным поведением бесценна. Если конструкция системы не изменится кардинально, эта информация не должна сильно измениться, даже если реализация будет изменена.
Я обнаружил, что ключ к документации - это модерация. Никто не собирается читать 50 страниц полноценных диаграмм UML с проектной документацией, не уснув на несколько страниц. С другой стороны, большинство людей хотели бы получить 5-10 страниц простых диаграмм классов с некоторыми базовыми описаниями того, как система собрана.
Другой случай, когда я обнаружил, что UML полезен, - это когда старший разработчик отвечает за разработку компонента, но затем передает дизайн младшему разработчику для реализации.