Например, на работе обсуждаю задачу, и сопровождаю речь картинками(рисую от руки), чтоб проще донести смысл, т.к. визуальная информация легче усваивается. Это не документ, просто показать и выкинуть.
Вопрос: Есть какие-нибудь стандарты/методики на такие рисунки?
UML не подойдет, т.к. слишком сложно и собеседники его не знают. М.б. есть какая-нибудь упрощенная версия…
Здравствуйте, Tihomir.I, Вы писали:
TI>Например, на работе обсуждаю задачу, и сопровождаю речь картинками(рисую от руки), чтоб проще донести смысл, т.к. визуальная информация легче усваивается. Это не документ, просто показать и выкинуть. TI>Вопрос: Есть какие-нибудь стандарты/методики на такие рисунки?
А зачем?
CS>Здравствуйте, Tihomir.I, Вы писали:
TI>>Вопрос: Есть какие-нибудь стандарты/методики на такие рисунки?
CS>В одной команде было принято использовать это вот: https://www.websequencediagrams.com
CS>Это нечто типа markdown для flow диаграм. Не знаю правда насколько это адекватно твоему вопросу.
Это интересно, но ищу не инструмент, а методику, чтоб знать, как самому рисовать эти картинки (объекты, наборы, соединения …).
Например, на доске рисую картинку, а собеседник быстро понимает суть вопроса и легче запоминает.
Как вариант — рисовать эти картинки "от балды", но м.б. есть какие-нибудь стандарты?
TI>>Например, на работе обсуждаю задачу, и сопровождаю речь картинками(рисую от руки), чтоб проще донести смысл, т.к. визуальная информация легче усваивается. Это не документ, просто показать и выкинуть. TI>>Вопрос: Есть какие-нибудь стандарты/методики на такие рисунки? 0>А зачем?
Человек так устроен, что визуальную информацию воспринимает лучше, чем звуковую. Т.е. проще один раз нарисовать, чем долго объяснить.
Отсюда вопрос — по каким стандартам рисовать?
TI>Человек так устроен, что визуальную информацию воспринимает лучше, чем звуковую. Т.е. проще один раз нарисовать, чем долго объяснить.
Это понятно.
TI>Отсюда вопрос — по каким стандартам рисовать?
Зачем стандарт?
TI>Человек так устроен, что визуальную информацию воспринимает лучше, чем звуковую. Т.е. проще один раз нарисовать, чем долго объяснить. TI>Отсюда вопрос — по каким стандартам рисовать?
Стандартный подход: не больше 3-4 разновидностей примитивов на рисунок (действие-условие-переход для логики, актор-действие-зависимость для сценариев и тд и тп). Если больше — обязательно добавляем на схему легенду.
Любая схема в процессе рисования проговаривается, при этом основная информация доносится голосом, на доске остаётся только конспект-иллюстрация.
Ну и best practices в нагрузку:
* Смысловую нагрузку (условие надо обсудить, в сценарии не уверены и тд) обозначают не новым типом блока, а пометками рядом с блоком. Знака вопроса и имени ответственного обычно хватает.
* Если рисует несколько человек — у каждого свой цвет маркера.
* В процессе обсуждения одной темы (одного пункта) с доски ничего стирать нельзя.
* Если доска документируется (фотографируется и заносится в артефакты) — обязателен модератор, иначе рано или поздно придётся объяснять шефу шефа, почему в ТЗ самолёт без крыльев
.
* По возможности не надо тратить время на рисование красивых диаграммок по результатам встречи, понятные исключения типа "надо включать в публичную документацию" обсуждать не будем.
* При обсуждении чего-либо на доске не надо использовать вспомогательные материалы. Презентации, распечатанные листы на руки, красивые схемки из розы и прочая макулатура идут лесом.
Здравствуйте, Tihomir.I, Вы писали:
TI>Это просто личный опыт или подобное существует в какой-нибудь Agile методологии? Чтоб посмотреть весь набор правил …
Опыт
Здравствуйте, Tihomir.I, Вы писали: TI>Вопрос: Есть какие-нибудь стандарты/методики на такие рисунки? TI>UML не подойдет, т.к. слишком сложно и собеседники его не знают. М.б. есть какая-нибудь упрощенная версия…
Вы работаете с дибилами? по моему для изучения диаграммы классов и диаграммы последовательностей достаточно будет наверное часа. Просто не надо использовать все детали нотации там, где это не нужно. Можно еще диаграмму пакетов.
За чем придумывать свой велосипед, когда уже все давно придумано — странный подход, не проще существующее адаптировать под себя?
Здравствуйте, Tihomir.I, Вы писали:
TI>Например, на работе обсуждаю задачу, и сопровождаю речь картинками(рисую от руки), чтоб проще донести смысл, т.к. визуальная информация легче усваивается. Это не документ, просто показать и выкинуть.
Здравствуйте, Tihomir.I, Вы писали:
TI>UML не подойдет, т.к. слишком сложно и собеседники его не знают. М.б. есть какая-нибудь упрощенная версия…
Есть. Взять UML. Использовать диаграммы только 2 типов: взаимодействия и последовательности. На диаграмме взаимодействия подписать стрелки глаголами. На диаграмме последовательностей отложить время (час, два, три... минута, вторая, третья... или даже так: минута, час, день...). Если время не откладывается, нарисовать снизу большую стрелку в том же направлении, подписав ее: «Время». По вкусу — развернуть ее с вертикали на горизонталь. Стандартную иконку, общую для всех актёров, заменять на, хотя бы, стоковую, обязательно цветную, обязательно свою для каждого типа актёра. Был UML, стало интуитивно-понятное представление.
Здравствуйте, Tihomir.I, Вы писали:
TI>Например, на работе обсуждаю задачу, и сопровождаю речь картинками(рисую от руки), чтоб проще донести смысл, т.к. визуальная информация легче усваивается. Это не документ, просто показать и выкинуть. TI>Вопрос: Есть какие-нибудь стандарты/методики на такие рисунки? TI>UML не подойдет, т.к. слишком сложно и собеседники его не знают. М.б. есть какая-нибудь упрощенная версия…
Лет 17 уже думаю над этим вопросом, а точнее над тем, как понять всё и вся. Собственно говоря всегда было заманчиво обрести способности универсального учёного. Пересмотрел много всего, промежуточная картина пока выглядит так.
Существует два вида статичных изображений.
1. Модель (предметной области)
2. Взаимосвязь (систематизация)
Для начала рассмотрим модель. На ней изображён исследуемый объект. Мы можем знать, что обозначает каждый элемент, а можем нанести сверху подписи. Так или иначе модель остаётся моделью. Однако на ней так же можно схематично изобразить протекающие процессы.
Далее идёт взаимосвязь. Именно она наиболее приближена к коду. Нет ничего более совершенного, чем элементы и связи между ними. Похоже дело в том, что так устроен человеческий мозг, хотя моё исследование в этом плане не завершено. Элементы в общем случае можно изображать прямоугольниками с текстом, связи же обычными прямыми стрелками.
Есть редакторы, в которых стрелка имеет текст, а это значит она является сущностью, что нарушает механизм группировки. Иными словами в моём понимании стрелка должна быть стрелкой обозначающей переход на новую сущность и ничем более. Но тогда мы приходим к тому, что нужно иметь промежуточный узел объясняющий нам суть перехода по стрелке. А это уже диаграммы сущность-связь (entity-relationship model или ER-модель), между прочим классика. Сущность отвечающую за переход в ней принято обозначать ромбом. Переходы могут быть пустыми, понимаемыми по умолчанию, например, всегда имеется в виду "содержит". Могут иметь подписи, "содержит", "является" (является методом), "наследует" и так далее.
Но давайте подумаем почему любая альтернатива многократно хуже. Вы могли бы рисовать не на доске, а в программе вводя десятки тысяч элементов. Предположим у вас используется UML, а теперь подумайте, сколько времени нужно затратить на рефакторинг схемы. Каждая диаграмма UML всего лишь частный случай ассоциативных связей, которые выстраиваются в мозгу. И в отличие от модели (предметной области), на которую мы и собираемся воздействовать, систематизация не нуждается в различных графических представлениях.
И подобным образом можно нарисовать аналог любой диаграммы UML или какой-то другой (блок-схемы, automata и прочее). Только вот в деле анализа в данном случае не будет ничего сдерживать. Причём в той же Dia можно очень быстро создавать стрелки, нажав клавишу L (line), и связывая элементы меняя их пространственное положение.
Видите ли в чём проблема того же UML, создавая взаимосвязи (систематизации), создали модели (предметной области). В свою очередь получилась надстройка над настоящей взаимосвязью программной системы, то есть модель пытаются систематизировать моделью, но крайне ограниченной и не связанной с универсальным человеческим мышлением. Потому всегда нужно разделять модели и взаимосвязи.
