Несколько советов для более эффективной доски?
Иногда меня призывают импровизировать в виде доски данных (не виртуально), диаграмм архитектуры и т. Д. Как для технической, так и для нетехнической аудитории. К сожалению, мои навыки рисования (и разборчивость печати) ужасны.
Как я могу стать более эффективным в этом? Я ищу советы по использованию стандартных символов и соединителей, некоторые стандартные способы организации и классификации информации (например, дорожки для плавания) и т. Д.
Что я могу практиковать, чтобы стать лучше в этом? Я хочу, чтобы эти визуальные презентации были эффективными для передачи моих идей, а плохо представленные диаграммы могут сделать идеи запутанными и не элегантными, даже если это не так.
12 ответов
Белая доска - отличный инструмент. Я сам делаю довольно много, и я нашел несколько вещей, которые очень эффективны:
- Используйте минимальный набор символов: прямоугольники, стрелки, круги и линии помогут вам пройти долгий путь. Предпочитаю простые вещи более продвинутым методам моделирования - все понимают прямоугольники и стрелки.
- Во время рисования мыслите вслух, чтобы помочь аудитории понять, что вы рисуете.
- Общайтесь со своей аудиторией. Белая доска - это не одностороннее общение. Если вы не уверены, что сообщение получено или чертеж понятен, просто спросите.
- Когда аудитория достаточно мала, подберите людей к доске и сделайте ручки легкодоступными, чтобы люди могли рисовать вместе с вами. Это обеспечивает лучшую визуальную связь и еще более эффективную сессию белой доски.
- Тратьте достаточно времени, чтобы писать и рисовать "аккуратно", но предпочитайте постоянную скорость общения, а не рукописный. Это сложный компромисс, который требует некоторой практики, и практика, при которой ваше письмо и рисунок понятны, увеличит как скорость письма, так и скорость рисования.
Довольно простой, но этот совет по рисованию мультяшных речевых пузырей сделал для меня огромную разницу: не рисовать коробки, а потом писать текст внутри них. Обычно вы неправильно оцениваете нужный размер, что приводит к сжатому, неразборчивому тексту. Вместо этого сначала напишите свой ярлык, а затем нарисуйте прямоугольник вокруг него.
Я был поражен тем, насколько ясность моих диаграмм улучшилась благодаря применению этого простого принципа.
Еще один хороший совет для белой доски - взять с собой цифровую камеру и сфотографировать вашу сессию. Вы можете добавить это в общий ресурс после собрания, и это здорово, если вы сможете просмотреть прошедшие сессии таким образом.
Я знаю, что немного опоздал на сцену, но я бы также порекомендовал записать то, что вы пытаетесь достичь, либо в предложении, либо с помощью нескольких пуль. Работать над разными вещами довольно легко, и это очень рано. Это также может быть использовано для контроля / отслеживания требований.
Наконец, что не менее важно, это также дает вам хорошее начало, с которого нужно начать, прежде чем переходить к диаграммам ER и другому моделированию.
Я часто пишу в Post It Notes, потому что вы можете легко перемещать их по мере обсуждения отношений между объектами. Кроме того, разные цвета Post It может передать смысл.
Ниже приведен пример:
http://www.matterco.com/wp-content/themes/matter/images/art057.jpg
- Попытка вместить слишком много в одну диаграмму может привести к путанице.
- Попробуйте визуализировать детализацию, в которой вы можете рисовать и подключать более крупные модули. Может быть, сделайте снимок этой диаграммы, чтобы сохранить идею на доске и получить обратную связь.
- Сосредоточьтесь на меньших модулях и примените детализацию, если применимо.
В вики есть некоторая базовая информация о разных диаграммах, которая может подходить для разных сценариев.
Надеюсь, это поможет.
ура
Вы знакомы с диаграммой ER? Если вы моделируете базу данных, диаграммы ER довольно универсальны для большинства людей.
Я знаю, что многие программисты склонны думать о UML как о "том дурацком дерьме, которое они хотят, чтобы я вставил в документ, который никогда не увидят", но на самом деле он был разработан для решения проблемы общения программистов.
Знайте UML, даже если это редко имеет значение, если вы используете открытую стрелку или закрытую стрелку, потому что факт заключается в том, что это может сбить с толку некоторых людей, если вы используете неправильную. Программисты очень целеустремленные существа, и это одна из тех вещей, которые им часто нравятся, когда они "застревают".
Знать несколько основных типов диаграмм UML. Каждый знает некоторый уровень объектной диаграммы, я часто комбинирую диаграммы наследования и содержания в одной картине - не будь слишком строг.
Прочитайте несколько блок-схем и фактически создайте их для сложного потока, над которым вы работаете. Они чертовски круты, когда анализируют происходящее и сообщают о чем-то, кроме простого вызова / возврата одного метода. Я не знал об этом около 1/3 моей карьеры и был просто ошарашен, когда кто-то выбросил один из них на доску (это было после того, как я все знал - но, конечно, каждый год я узнаю больше, а потом решаю Я НАКОНЕЦ все знаю).
Наконец - вы стоите там и разговариваете с человеком. Действительно, на белой доске можно просто указать, что в следующий раз, когда вы укажете на него, человек поймет, что вы имеете в виду то же самое... это визуальная помощь для улучшения вашего устного общения, вот и все.
Редактировать:
Эта страница является хорошим введением в последовательности диаграмм с множеством отличных примеров.
Убедитесь, что у вас есть большая доска.
Чем больше, тем яснее вы можете детализировать свои идеи.
Архитектурные схемы "должны" быть в UML.
Тем не мение.
Подробные UML-диаграммы - это боль в шее, поэтому не стоит вдаваться в технические подробности.
Однако существуют некоторые стереотипы классификатора, которые очень, очень помогают в том, чтобы позволить сводной диаграмме "высокого уровня" охватить ряд основ.
"Стереотипы класса Objectory" (см. http://doc.sumy.ua/prog/umld/AD970806.PDF) для классов Control, Boundary и Entity на вес золота. Добавление этих стереотипов к диаграмме классов является полезным, быстрым и формальным способом определения того, как класс (или пакет) вписывается в целое.