Agile Modeling with Mind Map and UML
Перевод статьи 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», а зависимости между шаблонами показаны пунктирными линиями-стрелками.
.jpg)
- Заметки о книге или семинаре
- Удобно конспектировать отзыв/аннотацию книги или содержание семинара.
- Ретроспективы
- Удобно использовать майндмапы для рефлексии над прошедшей итерацией (или над ходом проекта до выпуска очередной версии), чтобы провести анализ и выбрать направления для улучшения. Такие карты обычно имеют три ключевых ветви «Придерживаться/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 диаграммы удобно порождать из «стабилизировавшихся» майндмапов, для детальной проработки и дальнейшего стандартного использования в цикле разработке ПО.
Ссылки
Основы
- 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: Сходства между майндмапами и сценариями.
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
Репликация: База Знаний «Заказных Информ Систем» → «Agile Modeling with Mind Map and UML»