Штурм-моделирование: лучшая практика

Перевод статьи Model Storming: An Agile Best Practice, автор - Scott W. Ambler

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

Это обычное явление в гибких проектах. Extreme Programmers (XP) называют его стендап сессией дизайна, или сеансом вопросов и ответов клиента, и это характерно для традиционных проектов. Я думаю, что пришло время поговорить об этом, чтобы мы могли найти способы улучшить его.

Мой опыт состоит в том, что подавляющее большинство сеансов моделирования связаны с несколькими людьми, обычно двумя или тремя, которые обсуждают проблему во время рисования на бумаге или на доске. Эти «модельные штурмовые сессии», как правило, импровизированные, один участник проектной группы просит другого моделировать с ними, как правило, длятся сессии от пяти до десяти минут (редко можно делать это более 30 минут). Люди собираются вместе, собираются вокруг общего инструмента моделирования (например, интерактивной доски), исследуют проблему до тех пор, пока не убедятся, что они ее понимают, затем они продолжают.

Модель анализа

Вы будете моделировать штурм для анализа требований. Например, заинтересованная сторона может сказать вам, что создаваемая вами система должна иметь возможность редактировать информацию о студентах. Вместе вы создаете эскиз того, как будет выглядеть экран, см. Рисунок 1, рисуя несколько примеров, пока вы не придете к общему пониманию того, что нужно построить. Эскизы являются инклюзивными моделями, потому что вы используете простые инструменты и методы моделирования, что позволяет использовать Agile Modeling (AM). Обратите внимание, что вы также можете создать модель в рамках вашего моделирования итераций.

Рис. 1

Проектная модель штурма

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

Java-программисты часто будут работать через сложный код, зарисовывая быструю диаграмму последовательности UML (см. Рис. 2), XP создадут карты Class Responsability Collaborator (CRC) на стандартных карточках индексов (см. Рис. 3), чтобы изучить подробные проблемы структурного проектирования. Программисты на Visual Basic могут рисовать блок-схемы для моделирования сложного бизнес-правила (см. Рис. 4). Независимо от модели (-ей), которую вам нужно создать, вы все еще моделируете штурм.

Рис 2

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

Рис 3

Рис 4

Почему это работает?

Почему модель штурма на основе JIT работает намного лучше, чем другие методы моделирования? По нескольким причинам:

  1. Так или иначе, требования будут меняться в течение всего проекта.

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

  3. Если вы регулярно доставляли рабочее ПО, ваши заинтересованные стороны теперь имеют опыт работы с созданной системой за три месяца. Другими словами, они могут дать вам лучшие ответы.

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

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

Принятие модели шторма

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

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