Agile Modeling with Mind Map and UML — различия между версиями

Текущая версия на 03:00, 20 августа 2009

Перевод статьи Agile Modeling with Mind Map and UML.

Аннотация

Сбор требований — или, как говорят в контексте agile-разработки, сбор пользовательских историй (user stories), весьма важный и сложный аспект разработки ПО.

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

Автор — Kenji Hiranabe, занимает должность CEO в компании Change Vision, Inc., работает консультантов в области разработки ПО, перевел на японский множество Agile-книг, включая «Lean Software Development», «Agile Project Management». Также он автор программы Jude, комбинированного редактора для UML и майндмапов. Ведет блог.

Что такое майндмап?

Согласно основопологающей книге «The Mind Map Book» от автора методики, Тони Бьюзана (Tony Buzan):

Майндмапы (mindmaps, они же «интеллектуальные карты», «карты памяти», «ментальные карты») — это графическая техника ведения заметок и визуализации идей, используя лучисто-ветвистую (радиантную) структуру. При этом из центрального рисунка растут ветви, помеченные ключевыми словами, соответствующие Ключевым Упорядочивающим Идеям, далее рекурсивно ветвятся поддеревья и т.п.

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

Роджер Сперри (Roger Sperry), нобелевский лауреат в области физиологии, обнаружил, что кора головного мозга подразделяется на два полушария, между которыми ассиметрично распределены функции интеллекта. Его исследования показывают, что правая сторона доминирует в восприятии ритма, цветов и размеров, пространственном ориентировании, целостном восприятии (гештальте), воображении и мечтах; в то время как левая сторона сильна в логике и анализе, операциях над словами, числами и последовательностями/списками.

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

Настолько эффективны майндмапы благодаря следующим свойствам:

Ориентированность на ключевые слова (Keyword Orientation)

Основным структурным элементом майндмапов являются не целые предложения, а ключевые слова.

Свободные синтаксис и семантика (Loose Syntax and Semantics)

Наличие произвольной ассоциации — достаточная причина для связи между ключевыми словами.

Удобство — легко использовать и быстро рисуются

Можно использовать майндмапы даже в реальном времени, для параллельного стенографирования разного рода собраний.

Высокоуровневый обзор

Майндмап целиком легко окинуть взглядом.

«Вспомнить все»

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

Частичная структурированность (Semistructured)

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

Слабоструктурированные данные (Semistructured data) — это данные с иерархической структурой, но без заранее определенной схемы. Слабоструктурированные интервью — это когда набор вопросов заранее неизвестен.

Пример майндмапа «Планирование Рождества»

Чем майндмапы могут быть полезны в разработке ПО?

В обзоре Chuck Frey (см. раздел «Рекомендованное чтение») показано, что три основных бизнес-приложения майндмапов это:

• «Списки задач» (To do lists);
• «Подготовка презентаций»;
• «Ведение заметок» (Note taking)

Например, использование майндмапов весьма уместно и эффективно в следующих ситуациях или даже фазах разработки ПО:

Планерки и прочие краткие собрания (Meeting Minutes and Agenda)

— добавляют визуальных эффектов в повестку дня или программу действий. В процессе собрания, можно подключить ноутбук к дополнительному проектору, чтобы оперативно записывать идеи и изменения. Я называют это майндмапом «журнала встречи» (meeting log, см. рисунок ниже.). Такой майндмап имеет заранее созданные ветви для «Заключения»/Conclusion и «Списка задач»/ToDo, так, что ведущий майндмап медиатор встречи не оставил эти важные пункты пустыми или неясными.

Шаблон майндмапа «журнал собрания».

Презентации

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

Классификация элементов

Практически все действия в разработке ПО требуют той или иной классификации чего-либо. Например, на следующем рисунке двадцать три паттерна проектирования поделены на три категории: «Структура/Structure», «Создание/Creation» и «Поведение/Behavior», а зависимости между шаблонами показаны пунктирными линиями-стрелками.

Пример классификации (шаблонов проектирования)

Заметки о книге или семинаре

Удобно конспектировать отзыв/аннотацию книги или содержание семинара.

Ретроспективы

Удобно использовать майндмапы для рефлексии над прошедшей итерацией (или над ходом проекта до выпуска очередной версии), чтобы провести анализ и выбрать направления для улучшения. Такие карты обычно имеют три ключевых ветви «Придерживаться/Keep», «Проблемы/Problem» и «Попробовать/Try» (см. рисунок). Члены команды каких практик из текущих нужно продолжать придерживатся, какие проблемы встретились в последней итерации, и что попробовать для их решения.

Заметки по переговорам

Использовать майндмапы для взаимодействий с пользователями (более подробно будет описано в следующих разделах).

Майндмапы и пользовательские истории

Интерактивность — это ключевая ценность Agile. Mike Cohn в своей книге «User Story Applied» утверждает, что произошел ключевой сдвиг парадигмы от написания (документации) к общению (обсуждениям). В экстремальном программировании (XP, eXtreme programing) используются специальные карты историй (story cards) для записи результатов переговоров с пользователем. Ограничение на запись информации только на маленькую карту помогает направить обсуждение с заказчиком в конструктивном направлении. Часто даже такие карты пишут сами заказчики (или их представители), после чего их размещают на специальной стене в комнате разработчиков, как краткое резюме и просто напоминание о проведенном обсуждении. Соответственно, если возникает вопрос по пользовательской истории, нужно взять карту со стены, вспомнить, о чем там речь и обсудить ее снова.

Исследование пользовательских требований с помощью майндмапов

Пользовательская история — это по сути фрагмент пользовательского требования.

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

С одной стороны майндмап не хуже в «напоминании», чем карта истории,

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

Шаблон майндмапа для пользовательских требований

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

Т.е. заранее подготовлены следующие вопросы:

Кто и почему заинтересован в этой системе? (Who will be happy because of this system and why?)

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

Кто будет использовать систему? (Who will use the system?)

Ответ на этот вопрос определяет пользователей системы, и потенциальных субъектов в сценариях использования (use case actors).

Когда они должны использовать систему? (When will they use the system?)

Это определяет сценарий использования системы (system's story or use case candidates).

Какая информация должна вестись в системе? (What information do you want to manage with the system?)

Здесь определяются основные сущности или объекты в модели предметной области, включая понятийный аппарат и собственно, решаемые проблемы.

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

Например, я использовал этот формат для сбора требований по городской библиотечной системе — опрашивая библиотекаря я параллельно строил подобный майндмап. Более того, я присоединил мой ноутбук к дополнительному проектору и оперативно правил этот майндмап одновременно с собеседованием. А элементы в ветке «Homework», по сути, определяют план следующей встречи.

Удобство фиксации таких «непредсказуемых» тем и демонстрирует гибкость майндмапов по ведению слабоструктурированных данных.

Переход от майндмапов в UML

После исследования цельной картины пользовательских требований, можно продолжать двумя способами:

• Собрать пользовательские истории, в духе практик планирования из XP (экстремального программирования).
• Создать гибкую модель из моделей сценариев использования и модель сущностей предметной области. Для того и другого майндмап пользовательских требований будет прекрасной исходной точкой.

При создании майндмапа пользовательских требований, я добавляю иконки субъектов (actors), сценариев и классов, более того, все эти иконки заранее «заготовлены» в шаблонных ветках майндмап-анкеты.

Переход от майндмапа пользователя к модели предметной области

Использование майндмапов в сочетании с UML означает разделение требований на две модели:

• Cбор требований, когда происходит быстрое выявление обмен туманными идеями и ключевыми высокоуровневыми концепциями. Этот этап можно характеризовать как экстенсивный (divergent), что требует и соответствующего мышления («не упустить ничего») и подходящих инструментов лаконичного конспектирования (т.е. майндмапов).
• Моделирование на UML, в котором моделируется предметная область и сценарии собранные на первом этапе. И мышление на этом этапе будет другим — интенсивным/конвергентным (convergent).

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

Заключение

Шаблонные майндмапы представляют прекрасный слабоструктурированный формат для расспросов, включая как структуру обязательных важных вопросов, так и удобство захвата неожиданных тем. Это также помогает исключить ошибки общения и ухватить «мягкую» высокоуровневую структуру пользовательских пожеланий и требований. Также майндмапы помогают вспомнить полный контекст требований на момент их записи. Ну, а после сбора идей на майндмапе, уже можно «сеять» ключевые слова — элементы майндмапа, чтобы «вырастить» соответствующие элементы UML-моделей.

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

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

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

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

И тут майндмапы и UML-диаграммы работают весьма хорошо, но каждый в своей собственной области:

• Майндмапы весьма хороши для сбора туманных и неструктурированных пользовательских требований и затем частичного их структурирования.
• UML диаграммы удобно порождать из «стабилизировавшихся» майндмапов, для детальной проработки и дальнейшего стандартного использования в цикле разработке ПО.

Синергия майндмапов и UML при сборе требований

Ссылки

Основы

Tony Buzan «The Mind Map Book»

Собственно «библия» майндмаппинга. Существует русский перевод — «Супермышление», по этой книге есть русскоязычный видеосеминар.

Craig Larman «Agile and Iterative Development»

Краткое введение в майндмаппинг как agile-практику для быстрой работы с требованиями.

Alistair Cockburn «Agile Software Development»

В частности, там рассказывается об упомянутом в статье подходе «Keep/Problem/Try» к проведению.

Scott Ambler «Agile Modeling»

Собственно родоначальник понятия «Agile Modeling».

Mike Cohn «User Stories Applied»

Обоснование, что Agile-сбор требований требует сдвига парадигмы от написания к общению.

James and Suzanne Robertson «Mastering the Requirements Process»

Кратко обсуждает идею использования майндмапов в процессе сбора требований.

Esther Derby and Diana Larsen «Agile Retrospectives»

Источник третьего рисунка-майндмапа.

Исследования и приложения

• Mind mapping survey results: Первое крупное исследование майндмаппинга в контексте разработки ПО.
• Mind mapping and the software development life cycle: Подборка ссылок по майндмаппингу в процессе разработки ПО.
• Utilizing Mind Maps for Essential Use Case Specification: Сходства между майндмапами и сценариями.