|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Agile Modeling with Mind Map and UML — различия между версиямиМатериал из CustisWiki
Текущая версия на 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):
В майндмапах нужно использовать цвета, картинки и схемы, потому что человеческий мозг гораздо лучше приспособлен для распознавания шаблонов и образов, чем чисел и слов. Роджер Сперри (Roger Sperry), нобелевский лауреат в области физиологии, обнаружил, что кора головного мозга подразделяется на два полушария, между которыми ассиметрично распределены функции интеллекта. Его исследования показывают, что правая сторона доминирует в восприятии ритма, цветов и размеров, пространственном ориентировании, целостном восприятии (гештальте), воображении и мечтах; в то время как левая сторона сильна в логике и анализе, операциях над словами, числами и последовательностями/списками. Благодаря использованию обоих (и левого и правого) полушарий, майндмапы реализуют больший потенциал человеческой памяти, чем обычные, линейные записи. Настолько эффективны майндмапы благодаря следующим свойствам:
Чем майндмапы могут быть полезны в разработке ПО?В обзоре Chuck Frey (см. раздел «Рекомендованное чтение») показано, что три основных бизнес-приложения майндмапов это:
Например, использование майндмапов весьма уместно и эффективно в следующих ситуациях или даже фазах разработки ПО:
Майндмапы и пользовательские историиИнтерактивность — это ключевая ценность Agile. Mike Cohn в своей книге «User Story Applied» утверждает, что произошел ключевой сдвиг парадигмы от написания (документации) к общению (обсуждениям). В экстремальном программировании (XP, eXtreme programing) используются специальные карты историй (story cards) для записи результатов переговоров с пользователем. Ограничение на запись информации только на маленькую карту помогает направить обсуждение с заказчиком в конструктивном направлении. Часто даже такие карты пишут сами заказчики (или их представители), после чего их размещают на специальной стене в комнате разработчиков, как краткое резюме и просто напоминание о проведенном обсуждении. Соответственно, если возникает вопрос по пользовательской истории, нужно взять карту со стены, вспомнить, о чем там речь и обсудить ее снова. Исследование пользовательских требований с помощью майндмаповПользовательская история — это по сути фрагмент пользовательского требования. А я предлагаю использовать майндмапы пользовательских требований, чтобы целостно ухватить не только осколки, но и все пользовательские требования целиком. С одной стороны майндмап не хуже в «напоминании», чем карта истории, с другой — он явно более удобен для высокоуровнего обзора всей ситуации. Также майндмап — гибкий контейнер данных, подходящий для конспектирования слабоструктурированных интервью. Т.е. интервьювер может использовать заготовленные шаблоны для начала опроса, но когда беседа пойдет в неожиданном направлении — может легко добавить и новую ветвь, чтобы сконцентрироваться на темах, серьезно заинтересовавших опрашиваемого. Этот рисунок показывает заготовленный шаблон, для фиксации пользовательских требований. Т.е. заранее подготовлены следующие вопросы:
Ответ на этот вопрос определяет пользователей системы, и потенциальных субъектов в сценариях использования (use case actors).
Это определяет сценарий использования системы (system's story or use case candidates).
А последняя ветвь, «Homework», фиксирует уже не вопрос, а все то, в чем не удалось разобраться в проведенных переговорах. Например, я использовал этот формат для сбора требований по городской библиотечной системе — опрашивая библиотекаря я параллельно строил подобный майндмап. Более того, я присоединил мой ноутбук к дополнительному проектору и оперативно правил этот майндмап одновременно с собеседованием. А элементы в ветке «Homework», по сути, определяют план следующей встречи. Удобство фиксации таких «непредсказуемых» тем и демонстрирует гибкость майндмапов по ведению слабоструктурированных данных. Переход от майндмапов в UMLПосле исследования цельной картины пользовательских требований, можно продолжать двумя способами:
При создании майндмапа пользовательских требований, я добавляю иконки субъектов (actors), сценариев и классов, более того, все эти иконки заранее «заготовлены» в шаблонных ветках майндмап-анкеты. Использование майндмапов в сочетании с UML означает разделение требований на две модели:
ЗаключениеШаблонные майндмапы представляют прекрасный слабоструктурированный формат для расспросов, включая как структуру обязательных важных вопросов, так и удобство захвата неожиданных тем. Это также помогает исключить ошибки общения и ухватить «мягкую» высокоуровневую структуру пользовательских пожеланий и требований. Также майндмапы помогают вспомнить полный контекст требований на момент их записи. Ну, а после сбора идей на майндмапе, уже можно «сеять» ключевые слова — элементы майндмапа, чтобы «вырастить» соответствующие элементы UML-моделей. Тут уже можно использовать строгий синтаксис UML, чтобы построить семантически «богатую» модель предметной области и использовать уже ее для проектирования приложения. В Agile-разработке программного обеспечения считается, что одним из ключевых факторов успеха проекта — это коммуникация между всеми его участниками. Конечно, существует множество способов передачи и обмена информацией, но ни строгие формальные документы, ни обычные устные переговоры не являются адекватным решением. Ничто так не эффективно, как правильный набор лаконичных схем и графов, схватывающих самую суть исследуемой ситуации. И тут майндмапы и UML-диаграммы работают весьма хорошо, но каждый в своей собственной области:
СсылкиОсновы
Исследования и приложения
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». Репликация: База Знаний «Заказных Информ Систем» → «Agile Modeling with Mind Map and UML» |
![]() |
||||
![]() |
![]() |