Используете ли вы UML в методах разработки Agile?

Ответ 1

Бриз через Роберт Мартин Agile Принципы, шаблоны и практика

• Предложение использовать UML для передачи дизайна внутри команды. любой, кто смотрит на диаграмму, может понять решение (быстрее, чем говорить об этом) и внести более быстрый вклад.
• Если вы обнаружите, что команда делает одни и те же диаграммы снова и снова, кто-то сделает хорошую версию и сохранит ее в элементе управления wiki/source. Сверхурочная работа более полезные диаграммы начнут сопоставляться в этом месте.
• Не тратьте на него слишком много времени... вам не нужно слишком много деталей. Модели построены в архитектурных/строительных сферах, потому что строительство дома для проверки-проверки дизайна дорого или неосуществимо. Программное обеспечение не похоже на то, что вы можете проверить свой дизайн, просто закодировав его в то время, когда вы создаете модель UML вашего непроверенного дизайна (со всеми колокольчиками и свистами).

Так говорит UncleBob... Я согласен.

Ответ 2

Используйте то, что вы найдете полезным. Если диаграмма UML поможет вам визуализировать то, что вам нужно сделать, используйте ее. Если доска делает то же самое, используйте это.

Просто не делайте UML-диаграммы для создания UML-диаграмм. Наше время слишком дорого, чтобы тратить ненужные вещи.

Ответ 3

Для очень продуманного и высказанного мнения по этой теме прочитайте Martin Fowler "Is Design Dead?" , и если это вас убедит, купите/заимствовать и читать Скотта Амблера Agile Modeling.

Вкратце, UML - полезный инструмент, но не используйте его/злоупотреблять; это для мышления, а также для документирования, но код является конечным (хотя и не только) выражением дизайна - исполняемого проекта. С этой целью команда должна выполнять архитектуру и дизайн. Наконец, используйте любые инструменты для этого, которые помогают (например, доски, ручки и цифровые камеры - вам не нужен инструмент CASE)

Ответ 4

Чтобы выбросить диаграммы, да. Я обычно использовал его только как инструмент для общения идей, проблем и т.д. Схемы последовательности, примеры использования и диаграммы классов.

Если вы используете их как постоянную ссылку, вы также:

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

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

Я читал так много смешного UML в свое время в начале присоединения к проекту, который я почти всегда начинаю с кода, как того, что на самом деле происходит. Кроме того, поддерживаемый UML обычно является неправильным и, по сути, пустой тратой времени. Во всех сценариях я бы предпочел, чтобы комментарии в коде описывали странные выглядящие биты и/или очень короткие readme.txts над документами UML.

Ответ 5

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

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

Ответ 6

Для истинной гибкости вы должны выразить свой дизайн один раз и только один раз - в коде.

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

В частности, они не должны поддерживаться, поскольку это ненужное дублирование.

Ответ 7

Мы используем UML, когда вам нужно объяснить другим программистам, как работает пользовательская история. Вы можете просто набросать диаграмму взаимодействия и показать, какие объекты общаются с другими.

Очень похоже на то, что здесь описывает Мартин Фаулер: http://martinfowler.com/bliki/UmlAsSketch.html

Ответ 8

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

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

Я также считаю полезным использовать объяснения шаблонов дизайна и принципы дизайна, когда я даю презентации.

Ответ 9

"Одноразовый uml" подходит. Это быстро и грязно, поэтому не будет тратить время.

Ответ 10

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

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

Ответ 11

Я нахожу UML столь же бесценным в обмене бизнес-моделированием и потоками процессов с заинтересованными сторонами бизнеса как в проектах, связанных с проворством, так и в водопаде.

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

UML "сделано правильно" - это экономия времени. Представьте, что вы пытаетесь общаться с деловыми и техническими коллегами непоследовательным, многословным способом. Требования могут стать двусмысленными и непонятными, что приводит к неправильной работе.

UML "сделано неправильно" - это тайм-аут. UML - это средство к концу - не конец. Вам не нужно переусердствовать с деталями. Они должны быть достаточно подробными, чтобы не пропускать важную информацию, которая представляет интерес для вашей аудитории.

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

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

Это в отличие от моего опыта лечения UML в гибких проектах, где рисунки не привязаны к каскадам, но вместо этого нацелены на аудиторию во время полезности и где, как правило, после того, как история или эпос завершены.