StasFomin в 18:44, 17 августа 2009

2009-08-17T18:44:16Z

Новая страница

Перевод статьи [http://www.stickyminds.com/sitewide.asp?ObjectId=11861&Function=DETAILBROWSE&ObjectType=ART Agile Modeling with Mind Map and UML].

== Аннотация ==

Сбор требований — или, как говорят в контексте agile-разработки, сбор пользовательских историй (''user stories''), весьма важный и сложный аспект разработки ПО.
Здесь нет никаких стандартных процессов или нотаций, только понимание, что важнейшие факторы эффективности этой фазы — это коммуникация и всевозможные практики уменьшения формализма и облегчения процесса.
В этой статье ''Kenji Hiranabe'' предлагает использовать майндмапы, чтобы сфокусироваться на этих основных факторах при исследовании пользовательских требований, чтобы затем формализировать полученную модель на UML.

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

Согласно основопологающей книге «The Mind Map Book» от автора методики, Тони Бьюзана (''Tony Buzan''):
: Майндмапы (''mindmaps'', они же «интеллектуальные карты», «карты памяти», «ментальные карты») — это графическая техника ведения заметок и визуализации идей, используя лучисто-ветвистую (''радиантную'') структуру. При этом из центрального рисунка растут ветви, помеченные ключевыми словами, соответствующие ''Ключевым Упорядочивающим Идеям'', далее рекурсивно ветвятся поддеревья и т.п.

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

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

Благодаря использованию обоих (и левого и правого) полушарий, майндмапы реализуют больший потенциал человеческой памяти, чем обычные, линейные записи.
Настолько эффективны майндмапы благодаря следующим свойствам:
;Ориентированность на ключевые слова (''Keyword Orientation''): Основным структурным элементом майндмапов являются не целые предложения, а ключевые слова.
;Свободные синтаксис и семантика (''Loose Syntax and Semantics''): Наличие произвольной ассоциации — достаточная причина для связи между ключевыми словами.
;Удобство — легко использовать и быстро рисуются: Можно использовать майндмапы даже в реальном времени, для параллельного стенографирования разного рода собраний.
;Высокоуровневый обзор: Майндмап целиком легко окинуть взглядом.
;«Вспомнить все»: Майндмап пробуждает воспоминания о полном контексте ситуации, фиксируемой в момент его создания.
;Частичная структурированность (''Semistructured''): Майндмап может иметь некий заданный шаблон, но он также может расти в любых других направлениях (по требованию), например, чтобы оперативно фиксировать результаты устных переговоров в слабоструктурированном общении.

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

[[Image:An example mind map used to plan a project Christmas party.jpg|center|framed|Пример майндмапа «Планирование Рождества»]]

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

В обзоре ''Chuck Frey'' (см. раздел «Рекомендованное чтение») показано, что три основных бизнес-приложения майндмапов это:
* «Списки задач» (''To do lists'');
* «Подготовка презентаций»;
* «Ведение заметок» (''Note taking'')

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

[[Image:Meeting log mind map template.jpg|center|frame|Шаблон майндмапа «журнал собрания».]]

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

[[Image:An example of categorization (Design Patterns).jpg|center|frame|Пример классификации (шаблонов проектирования)]]

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

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

[[Image:A mind map of a retrospective meeting using Alistair Cockburn's Keep-Problem-Try technique.png|center|image|Майндмап ретроспективы в соответствии с техникой «Keep/Problem/Try» Алистэра Коуберна ('''''Alistair Cockburn''''')]].

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

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

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

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

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

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

[[Image:User-wish mind map template.png|center|frame|Шаблон майндмапа для пользовательских требований]]

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

;Кто и почему заинтересован в этой системе? (''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''), сценариев и классов, более того, все эти иконки заранее «заготовлены» в шаблонных ветках майндмап-анкеты.

[[Image:Conversion from a user-wish mind map to domain models.png|center|frame|Переход от майндмапа пользователя к модели предметной области]]

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

[[Image:Converted Domain Models in Usecases and Class diagrams.png|center|frame|Модель предметной области, преобразованная в диаграммы классов и пользовательских сценариев]]

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

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

[[Image:An illustration of how mind maps and UML work during requirements gathering and modeling.png|center|frame|Синергия майндмапов и 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»: Источник третьего рисунка-майндмапа.

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

* [http://www.mindmapping.typepad.com/ Mind mapping survey results]: Первое крупное исследование майндмаппинга в контексте разработки ПО.
* [http://www.eric-blue.com/blog/2006/12/mindmapping_and_the_software_d.html Mind mapping and the software development life cycle]: Подборка ссылок по майндмаппингу в процессе разработки ПО.
* [http://roots.dnd.no/modules.php?op=modload&name=Downloads&file=index&req=getit&lid=164 Utilizing Mind Maps for Essential Use Case Specification]: Сходства между майндмапами и сценариями.

{{replicate-from-custiswiki-to-lib}}

Agile Modeling with Mind Map and UML - История изменений

BenderBot: 1 версия

StasFomin: орфография/пунктуация

BenderBot: 1 версия

StasFomin в 18:44, 17 августа 2009

← Предыдущая	Версия 00:00, 20 августа 2009
(нет различий)

← Предыдущая	Версия 00:00, 18 августа 2009
(нет различий)