Не, ну как может быть изначальный срок обязательными, если по дороге все/многое может меняться? Ведь воочию вижу каждый день именно неподтвеождение этого тезиса.
Или есть сроки, тогда всякие изменения по ходу не имеют место быть, или постоянные изменения, но тогда срок только действует на них, но никак на изначальный срок.
Во втором случае вы берёте ТЗ, делаете что-то месяц, потом показываете результат заказчику и в случае необходимости изменяете ТЗ. И так двенадцать раз.
Вашего вопроса не понял. Это же ваши слова выше, и они имеют смысл. Потому что в этом то и суть agile, что не через год встречаются заказчик и исполнитель. Но если это так и изменения будут по ходу дела проявляться, то тогда как можно говорить, что что-то будет длится год если не известно, что будет сделано.
Короче противоречие , но мало кого это волнует. И если это не будет работать, то проблему будут не в методике искать, а в неправильном использовании agile. А сама противоречивая методика не имеет права поддаваться сомнению.
С вами согласен. Сам обожаю ассемблер. За возможности, за красоту и за самоудовлетворение. Хотя в большинстве своём люди всё же покупают компьютер, а не собирают его на уровне активных и пасивных эллементов сами. Хотя такие тоже имеются. Но увы, количество таких стойких и любящих своё дело всё меньше и меньше.
Вместе с этим процессы разработки продукта становятся прозрачнее и уменьшаются риски, что проект не будет принят.
Мне вот интересно, как вообще себе предствляют ситуацию те, кто такое пишет?
Принят - это значит, что сделано то, о чём договорились. Договорились - это значит описали ожидаемую систему/продукт с её параметрами и функциями. Если договора на конкретные детали нет, а детали обсуждаются каждые 1-10 недель, где вообще находится граница, когда будет что-то принято или нет? Ведь в каждом спринте всё меняется, иногда переворачивается вверх ногами.Как люди себе представляют себе само выражение "принят" в таком случае?
Waterfall — условно существующая каскадная модель разработки. Здесь процесс воспринимается как поток, а переход от одного этапа к другому происходит только после успешного завершения предыдущего.
А не чё, что водопад уже с 60-70-х годох в чистом виде нигде не используется, а для популиризации agile его везде для сравнения за уши тянут - никого не трогает.
Потому что на предполагаемые проблемы с чистой моделью водопада было введено множество модифицированных моделей водопада. Эти модели могут отражать некоторые или все критические замечания по поводу «чистой» модели водопада.
К ним относятся модели
быстрого развития (modified waterfalls), которые Стив МакКоннелл называет «модифицированными водопадами»
«модель сашими» (sashimi model) Питера ДеГрейса (водопад с перекрывающимися фазами)
водопад с подпроектами и водопад с уменьшением риска. Существуют и другие комбинации моделей разработки программного обеспечения, такие как «инкрементная водопадная модель» итд.
И все эти модели уже есть гибкие. Т.е. если бы сравнение шло с ними, то в некоторых местах не видно было-бы никакой разницы. Но нет, надо сравнивать с динозаврами, как в СССР всегда сравнивали с 1913-м годом, чтобы воочию показать, какой "огромный" прогресс имеет место быть.
Автор путает безопасность реализации с безопасностью программирования. Visual Studio тоже безопасный инструмент, если только понимать, что программисту разрешено делать с инструментом то, что инструментом предусмотрено. Но. Это не мешает ему в коде извращаться так, как ему захочется.
талмуты ненужной информации держал в руках, но и они - и их полное отсутствие - не есть решение. Это два радикальных полюса, которых надо остерегаться.
А вы видили-ли в agile, что кто-то несёт вообще какую-нибудь ответственность? Такого понятия там нет. Прям социализм какой-то - каждый решает сам, что делать. Ну или коллектив. А коллектив - это то ещё состояние общества. Оно отображает и преумножает все сильные, но и все слабые стороны людей. И коллектив сообща тоже всегда сходит с пути. Итд.
Потому что самодисциплина каждого в отвельности и группы в целом будет всё меньше и меньше работать, если со стороны не будет какой-нибудь "плётки".
Ну тогда всё сводится к статистике как в анекдоте по поводу вероятности увидеть динозавра на Красной площади и ответу - 50 на 50, мол или увижу или нет.
Очень сильная мотивация у людей, которые вот-вот накаплиют опыт, которые молоды, видят перспективы роста. Когда-же происходит созревания человека, то он смотрит на мир совсем иными глазами, и пытается из инвестиций в прошлом сделать капитал в будущем. И вот тут аджайл не даёт ответов. В надежде, что на замену всегда много других придёт. А проблема накопления потому что сегодня получить базовый опыт не так легко с теми темпами, которые сегодня, в мире. Agile в этом случае не только ответ на вызовы сегодня, но и триггер ухудшения для вызовов в будущем. Потому что координально ломает устои не предоставляя взамен основ, а только скрывает проблемы с поля зрения. Один только пункт из манифест что работающая система стоит ваше, чем документация - это просто пиизыв для тех, кто никогда этого не собирался делать, за это и не браться. Итд.
Не соглашусь в принципе. Почитайте книги по Project Management. Это целая наука. С формулами для расчёта рисков, возможной реализации, планирования, работа со stakeholder(ами) итд. А здесь (и не только здесь) общие фразы - ..понимайте, не волнуйтесь, не контролируйте, поддерживайте, используйте мотивацию итд. Поэтому все сложные проекты, которые я когда-либо пережил и которые пытались с agile(м) провести - это были провалы. По времени, по качеству и всё возвращалось на круги своя. Но терялись специалисты, терялось время, терялись деньги. Потому что как-то так так и работает - как-то так.Извините - их более детально описать не имею права. Но поверьте моему мнению на слово.
Потому что все люди разные. У каждого свои цели. Один ленивый, другой трудяга, один хитрый, другой простодушный, один - серая мышка, другой хочет быть звездой на проект-сцене, один - живёт один и ему немного надо. И в деньгах и по времени он готов днём и ночью работать. А у другого - семья, дети с их проблемами или болезнями итд. Уравниловка никогда не работает. Тем более на долгое время. Это противоречит нашему природой заложеной принципу. Я несколько раз бывал в фирме, которая работает по принципу - плоская хирархия. Так вот. Там средний возраст - 30 лет. А почему. Ну ответ кроется в сути agile. Когда-то люди мечтают иметь больше, чем просто безконтрольность со стороны "несправедливых" начальников и свободные руки в выборе задач. Когда люди взрослеют и понимают, что это конструкция им этого не позволит добиться. Поэтому уходят. Сказать, что это работает - это значит сказать не правду. Хотя именно в этой фирме - это работает. Но это больше похоже на принцип, когда выставляется на показ то, что на самом деле вырвано из общего правила.
И мотиваций должно быть тонна с горкой. Одному леденца хватит, другому грамоты, как лучшему работнику месяца, а третьего надо и масажировать и машину предоставить итд. Потому что он того может стоить. Почему? Ну не знаю - а я всю свою жизнь сталкиваюсь с людьми, которые очень разный уровень мастерства к различным темам или ремеслам имеют. Програмы писать может каждый. Хорошие намного меньше. Ценные или стреляющие идеи имеют и могут единицы.
Один продавец может продать кучу машин ,а другой намного меньше. Оба имеют одинаковые условия, но знают и работают по разному. И почему я не должен поощерять хорошего продавца/программиста/дизайнера итд. Об этом ни слова - хотя пост о мотивации.
По иронии судьбы, чем больше руководство пытается управлять и контролировать, тем меньше вероятность того, что случится прирост в производительности.
Мне это кажется выдумкой. Слева и справа - от булочной за углом до Теслы только и наблюдаю как - структура, контроль, дисциплина, правильный подбор людей, талант и в исполнении и в управлении - приводят к целям, которые устанавливаются. Не важно прирост, создавание чего-либо или завоевание новых рынков сбыта.
Есть какие-нибудь доказательства Вашим словам? Не ссылки на такие-же высказывания в других книжках по agile, а именно статистика.
Вдохновляйте: объясняйте почему нужно делать работу, а не что нужно делать. Давайте командам решать проблемы самим, но не давайте им планы, которым нужно следовать.
Всё опять свелось к советам менеджерам, как сделать что-то agile. Но вы так и не обьяснили, как мотивируются люди, работая в агиле. Да, есть такое - как совместное решение задач. И гармоничным коллектив - тоже хорошая вещь. Но каждый идёт/едет вечером домой. Где его ждёт жена и дети. Он с ними хочет поехать в отпуск, он хочет себе купить новую и дорогую машину и планирует профинансировать покупку дома. Итак. В чём заключается мотивация человека, который хочет не сегодня, но завтра себе больше позволить, чем сегодня?
Откажитесь от контроля: чем больше вы пытаетесь контролировать сотрудников, тем менее автономными становятся команды и тем меньше мотивации остаётся у их членов.
Хорошо, он работает в agile-команде. С кем он будет разговаривать насчёт повышения зарплаты? Со своим начальником по линии. Но тот с ним не оговаривал ни цели, ни способ их достижения. Он его не контролирует и не может как-либо повлиять на него. Значит начальник по линии не может адекватно с ним вести разговоры развитию в росте, по повышению зарплаты. В какой-то момент эти самые линии вообще должны исчезнуть по идее agile.
Мотивалки, типа "ты работаешь над самым прекрассным проектом и с самым хорошим agile-коллективом" когда-то перестают быть чем-то особенным. На Вдохновляйте - далеко не уедешь. Какие есть возможности роста в agile? Роста в виде значимости? Финасового роста?
В этом и есть проблема всех этих блок-схема-редакторов. С их помощью можно кое-что нарисовать, но не больше. В 90'х были такие case редакторы, оно они не стрельнули. Потому что ими генерированный код надо было допиливать или видоизменять. И как только один раз такое делалось, то терялась вся суть использования этого case редактора.
Графические редакторы только там нужны, где все то, что с ними создаётся и есть то что исполняется. Те. они должны представлять из себя нааамного большую абстракцию, чем простой язык программирования. Вот тут уже кем-то указаный MatLab или например редакторы обьектов, цветов и стилей в том же Photoshop. Или редакторы 3D или какой-нибудь CAD программы, или редакторы Workflow процессов. Вон например описание инфраструктуры будущей архитектуры приложений AWS использует похожий принцип, когда используемые элементы как квадратики, кружочки и линии представляют из себя целые горы строчек в настоящем языке программирования. Но они от пользователя "спрятаны". Вот тогда есть толк от такого редактора. Когда он упрощает сложность каких-либо процессов. Когда-же он просто видоизменяет, то что уже есть, но требует всё равно столько же суппорта и при этом уже является 150-м вариантом на рынке, то и успеха у такого начинания мало. Как раз сам работаю над таким framework для своей специализированной идеи. Именно для узкого коридора возможностей, где настоящее програмирование и правда есть муторное дело.
Язык ДРАКОН содержит большое число правил. К счастью, их не надо учить и запоминать. Почему? Потому что правила знает назубок, хранит в своей памяти и скрупулезно выполняет программа ДРАКОН-конструктор
заменяю слово Дракон на букву C (можно и C++, Java, C#, Assembler, Phyton, SQL...) - получаем:
Язык C содержит большое число правил. К счастью, их не надо учить и запоминать. Почему? Потому что правила знает назубок, хранит в своей памяти и скрупулезно выполняет программа C-конструктор.
И ведь тоже правда?!
Хотя и выражение автора и переделанное высказывание не имеют смысла от слова совсем. Ведь, если компилятор знает все правила использования языка, это вообще не говорит о том, что человек не должен знать эти правила. Это как с музыкой. Даже умея читать музыкальные ноты, не говоря уже о том, что просто зная, чо они есть - не создать музыкальное произведение. Для этого надо их и ноты знать, и их размерность, и знать как использовать, и где, и стили, и разновидности инструментов, иметь слух, талант итд. Инструмент болгарка тоже знает как вертеть диск вокруг оси, но этого мало, чтобы распились плитку и не отколоть края.
Соглашусь с Вами. Хотя наверное для "продажи" своей идеи просто перебрали в формуле супер-пупер представления. Ни о какой незопасности тут не может быть и речи. Просто сегодня многие люди склонны не к текстовому программированию, а именно к визуальному. Ведь с визуальным можно и детей подключать, что и делают и LEGO, и например такая форма программирования как scetch, которую и для питона, Java и для Arduino подходит. Но раз сказавши "безопаснее", не могут согласиться с тем, что это было через-чур, поэтому и продолжают как мантру повторять это.
Безопасность приходит не от визуальности, а от функтиональных возможностях редактора, который разрешает/запрещает те или иные действия. Например между одним и другим блоком может встать только специальный блок, а не какой-нибудь. Или открыв визуально цикл, сразу в схему вставляется и конец цикла. И не может быть отдельно удалённым. Т.е. безопасность не от блоков или реализации тех или иных синтаксических конструкций азыла, а именно от того, как это всё в редакторе организовано. Но это уже другая песня.
Изобретать велосипед иногда полезно, если при этом появляется совсем другой результат. Т.е. методом даже того-же ТРИЗ можно всегда в что-то новое добавить что-то и получить совсем другое. Или лучшее или специализированое для опревделённых задач итд.
С языком Дракон происходит совсем другое. Изобрели тоже самое, что уже до этого существовало. Но то - вдруг описывается как что-то плохое и Дракон здесь вроде-бы как лучше. Хотя на самом деле блок-схемы уже используются всё реже и реже (так у неспециалистов в MS Office набростать плоские и несложные схемы), а многое новое описывается языком BPMN. Потому что это удовлетворяет современным требованиям намного лучше, чем какие-нибудь блок-схемы типа EPK или как в этой статье - языка дракона.
И использование кричащих названий (как в желтой прессе) только усугубляет всё с этим языком связаным. Он не создавался как медицинский, здесь-же он показан как медицинский. В других статьях он может стать языком архитекторов, композиторов или специально для мясо-комбината. Плюс - указание на "Русский Алгоритмический язык". Русским может быть человеческий язык, культура, но ни как не язык программирования.
Даже немного смешно, когда заходишь на их сайт drakon.su, а там стоит "Дружелюбный Русский Алгоритмический язык", а гиф(ка) показывает развития алгоритма и все тексты там на ангклиском. Короче - какой-то оксюморон.
И авторам не понять, почему нет того восприятия, как они его ожидают. Им невдомёк, что создали то, что уже давно существовало до них. И маленькие рюшечки в виде тонкой или толстой линии, или кружочки в циклах - просто мелочи, которые ничего конкретного не улучшают. И для более обширных задач есть современные подходы.
Это больше на плагиат похоже, чем на создание чего-то нового.
1-й. Почему ?: потому что в старой системе она была.
2-й. Почему? Понятия не имею, но мне было удобно.
3-й. Почему? Ты чё, дебил что-ли? Что докопался?
Есть целая наука под названием Requirement Management. В ней описаны и методы, как у специалистов 'выудить' нужную информацию, так и способы как создать каталог как функциональных, так и нефукциональных требований. На основе которых создаётся стабильная архитектура, процесы и их жизненные циклы, дизайн GUI и структура интерфейсов. Не имя первой - всё просто тяп-ляп. Нагромождение изменений из одного sprint(a) в другой. И вроде хочется сказать, что раньше с этим было лучше, но понимаешь, что от этого ничего не изменится - тренд такой сегодня,
плюс. если используют базы данных. то и таблицы названы, атрибуты в них итд. - без логики и адекватное кол-во времени не позволит во всём разобраться. И как в вашем примере, и в похожих ситуациях - проще всё переписать заново, чем разбираться в дебрях. К сожалению.
Я понимаю, что у такого подхода есть минусы. Но ведь есть и плюсы. Поэтому такой радикальности ведь не надо. В разных странах есть например и этажи с номером 0 и ничего - живут ведь люди.
Не, ну как может быть изначальный срок обязательными, если по дороге все/многое может меняться? Ведь воочию вижу каждый день именно неподтвеождение этого тезиса.
Или есть сроки, тогда всякие изменения по ходу не имеют место быть, или постоянные изменения, но тогда срок только действует на них, но никак на изначальный срок.
Вашего вопроса не понял. Это же ваши слова выше, и они имеют смысл. Потому что в этом то и суть agile, что не через год встречаются заказчик и исполнитель. Но если это так и изменения будут по ходу дела проявляться, то тогда как можно говорить, что что-то будет длится год если не известно, что будет сделано.
Короче противоречие , но мало кого это волнует. И если это не будет работать, то проблему будут не в методике искать, а в неправильном использовании agile. А сама противоречивая методика не имеет права поддаваться сомнению.
С вами согласен. Сам обожаю ассемблер. За возможности, за красоту и за самоудовлетворение. Хотя в большинстве своём люди всё же покупают компьютер, а не собирают его на уровне активных и пасивных эллементов сами. Хотя такие тоже имеются. Но увы, количество таких стойких и любящих своё дело всё меньше и меньше.
Мне думается, что когда 12 раз, то вероятность того, что 12 раз или год - непланируемы. потому что ...
расчитывается, когда знаешь, что делать.Когда знаешь, что делать, но по ходу дела это меняется, размерность год - теряет смысл.
Мне вот интересно, как вообще себе предствляют ситуацию те, кто такое пишет?
Принят - это значит, что сделано то, о чём договорились. Договорились - это значит описали ожидаемую систему/продукт с её параметрами и функциями. Если договора на конкретные детали нет, а детали обсуждаются каждые 1-10 недель, где вообще находится граница, когда будет что-то принято или нет? Ведь в каждом спринте всё меняется, иногда переворачивается вверх ногами.Как люди себе представляют себе само выражение "принят" в таком случае?
А не чё, что водопад уже с 60-70-х годох в чистом виде нигде не используется, а для популиризации agile его везде для сравнения за уши тянут - никого не трогает.
Потому что на предполагаемые проблемы с чистой моделью водопада было введено множество модифицированных моделей водопада. Эти модели могут отражать некоторые или все критические замечания по поводу «чистой» модели водопада.
К ним относятся модели
быстрого развития (modified waterfalls), которые Стив МакКоннелл называет «модифицированными водопадами»
«модель сашими» (sashimi model) Питера ДеГрейса (водопад с перекрывающимися фазами)
водопад с подпроектами и водопад с уменьшением риска. Существуют и другие комбинации моделей разработки программного обеспечения, такие как «инкрементная водопадная модель» итд.
И все эти модели уже есть гибкие. Т.е. если бы сравнение шло с ними, то в некоторых местах не видно было-бы никакой разницы. Но нет, надо сравнивать с динозаврами, как в СССР всегда сравнивали с 1913-м годом, чтобы воочию показать, какой "огромный" прогресс имеет место быть.
Автор путает безопасность реализации с безопасностью программирования. Visual Studio тоже безопасный инструмент, если только понимать, что программисту разрешено делать с инструментом то, что инструментом предусмотрено. Но. Это не мешает ему в коде извращаться так, как ему захочется.
талмуты ненужной информации держал в руках, но и они - и их полное отсутствие - не есть решение. Это два радикальных полюса, которых надо остерегаться.
А вы видили-ли в agile, что кто-то несёт вообще какую-нибудь ответственность? Такого понятия там нет. Прям социализм какой-то - каждый решает сам, что делать. Ну или коллектив. А коллектив - это то ещё состояние общества. Оно отображает и преумножает все сильные, но и все слабые стороны людей. И коллектив сообща тоже всегда сходит с пути. Итд.
Потому что самодисциплина каждого в отвельности и группы в целом будет всё меньше и меньше работать, если со стороны не будет какой-нибудь "плётки".
Ну тогда всё сводится к статистике как в анекдоте по поводу вероятности увидеть динозавра на Красной площади и ответу - 50 на 50, мол или увижу или нет.
Очень сильная мотивация у людей, которые вот-вот накаплиют опыт, которые молоды, видят перспективы роста. Когда-же происходит созревания человека, то он смотрит на мир совсем иными глазами, и пытается из инвестиций в прошлом сделать капитал в будущем. И вот тут аджайл не даёт ответов. В надежде, что на замену всегда много других придёт. А проблема накопления потому что сегодня получить базовый опыт не так легко с теми темпами, которые сегодня, в мире. Agile в этом случае не только ответ на вызовы сегодня, но и триггер ухудшения для вызовов в будущем. Потому что координально ломает устои не предоставляя взамен основ, а только скрывает проблемы с поля зрения. Один только пункт из манифест что работающая система стоит ваше, чем документация - это просто пиизыв для тех, кто никогда этого не собирался делать, за это и не браться. Итд.
А что лучше - велосипед или подводная лодка? Передвигаться оба могут. Но. Смотря для каких задач.
Не соглашусь в принципе. Почитайте книги по Project Management. Это целая наука. С формулами для расчёта рисков, возможной реализации, планирования, работа со stakeholder(ами) итд. А здесь (и не только здесь) общие фразы - ..понимайте, не волнуйтесь, не контролируйте, поддерживайте, используйте мотивацию итд. Поэтому все сложные проекты, которые я когда-либо пережил и которые пытались с agile(м) провести - это были провалы. По времени, по качеству и всё возвращалось на круги своя. Но терялись специалисты, терялось время, терялись деньги. Потому что как-то так так и работает - как-то так.Извините - их более детально описать не имею права. Но поверьте моему мнению на слово.
Потому что все люди разные. У каждого свои цели. Один ленивый, другой трудяга, один хитрый, другой простодушный, один - серая мышка, другой хочет быть звездой на проект-сцене, один - живёт один и ему немного надо. И в деньгах и по времени он готов днём и ночью работать. А у другого - семья, дети с их проблемами или болезнями итд. Уравниловка никогда не работает. Тем более на долгое время. Это противоречит нашему природой заложеной принципу. Я несколько раз бывал в фирме, которая работает по принципу - плоская хирархия. Так вот. Там средний возраст - 30 лет. А почему. Ну ответ кроется в сути agile. Когда-то люди мечтают иметь больше, чем просто безконтрольность со стороны "несправедливых" начальников и свободные руки в выборе задач. Когда люди взрослеют и понимают, что это конструкция им этого не позволит добиться. Поэтому уходят. Сказать, что это работает - это значит сказать не правду. Хотя именно в этой фирме - это работает. Но это больше похоже на принцип, когда выставляется на показ то, что на самом деле вырвано из общего правила.
И мотиваций должно быть тонна с горкой. Одному леденца хватит, другому грамоты, как лучшему работнику месяца, а третьего надо и масажировать и машину предоставить итд. Потому что он того может стоить. Почему? Ну не знаю - а я всю свою жизнь сталкиваюсь с людьми, которые очень разный уровень мастерства к различным темам или ремеслам имеют. Програмы писать может каждый. Хорошие намного меньше. Ценные или стреляющие идеи имеют и могут единицы.
Один продавец может продать кучу машин ,а другой намного меньше. Оба имеют одинаковые условия, но знают и работают по разному. И почему я не должен поощерять хорошего продавца/программиста/дизайнера итд. Об этом ни слова - хотя пост о мотивации.
Мне это кажется выдумкой. Слева и справа - от булочной за углом до Теслы только и наблюдаю как - структура, контроль, дисциплина, правильный подбор людей, талант и в исполнении и в управлении - приводят к целям, которые устанавливаются. Не важно прирост, создавание чего-либо или завоевание новых рынков сбыта.
Есть какие-нибудь доказательства Вашим словам? Не ссылки на такие-же высказывания в других книжках по agile, а именно статистика.
Всё опять свелось к советам менеджерам, как сделать что-то agile. Но вы так и не обьяснили, как мотивируются люди, работая в агиле. Да, есть такое - как совместное решение задач. И гармоничным коллектив - тоже хорошая вещь. Но каждый идёт/едет вечером домой. Где его ждёт жена и дети. Он с ними хочет поехать в отпуск, он хочет себе купить новую и дорогую машину и планирует профинансировать покупку дома. Итак. В чём заключается мотивация человека, который хочет не сегодня, но завтра себе больше позволить, чем сегодня?
Хорошо, он работает в agile-команде. С кем он будет разговаривать насчёт повышения зарплаты? Со своим начальником по линии. Но тот с ним не оговаривал ни цели, ни способ их достижения. Он его не контролирует и не может как-либо повлиять на него. Значит начальник по линии не может адекватно с ним вести разговоры развитию в росте, по повышению зарплаты. В какой-то момент эти самые линии вообще должны исчезнуть по идее agile.
Мотивалки, типа "ты работаешь над самым прекрассным проектом и с самым хорошим agile-коллективом" когда-то перестают быть чем-то особенным. На Вдохновляйте - далеко не уедешь. Какие есть возможности роста в agile? Роста в виде значимости? Финасового роста?
В этом и есть проблема всех этих блок-схема-редакторов. С их помощью можно кое-что нарисовать, но не больше. В 90'х были такие case редакторы, оно они не стрельнули. Потому что ими генерированный код надо было допиливать или видоизменять. И как только один раз такое делалось, то терялась вся суть использования этого case редактора.
Графические редакторы только там нужны, где все то, что с ними создаётся и есть то что исполняется. Те. они должны представлять из себя нааамного большую абстракцию, чем простой язык программирования. Вот тут уже кем-то указаный MatLab или например редакторы обьектов, цветов и стилей в том же Photoshop. Или редакторы 3D или какой-нибудь CAD программы, или редакторы Workflow процессов. Вон например описание инфраструктуры будущей архитектуры приложений AWS использует похожий принцип, когда используемые элементы как квадратики, кружочки и линии представляют из себя целые горы строчек в настоящем языке программирования. Но они от пользователя "спрятаны". Вот тогда есть толк от такого редактора. Когда он упрощает сложность каких-либо процессов. Когда-же он просто видоизменяет, то что уже есть, но требует всё равно столько же суппорта и при этом уже является 150-м вариантом на рынке, то и успеха у такого начинания мало. Как раз сам работаю над таким framework для своей специализированной идеи. Именно для узкого коридора возможностей, где настоящее програмирование и правда есть муторное дело.
заменяю слово Дракон на букву C (можно и C++, Java, C#, Assembler, Phyton, SQL...) - получаем:
Язык C содержит большое число правил. К счастью, их не надо учить и запоминать. Почему? Потому что правила знает назубок, хранит в своей памяти и скрупулезно выполняет программа C-конструктор.
И ведь тоже правда?!
Хотя и выражение автора и переделанное высказывание не имеют смысла от слова совсем. Ведь, если компилятор знает все правила использования языка, это вообще не говорит о том, что человек не должен знать эти правила. Это как с музыкой. Даже умея читать музыкальные ноты, не говоря уже о том, что просто зная, чо они есть - не создать музыкальное произведение. Для этого надо их и ноты знать, и их размерность, и знать как использовать, и где, и стили, и разновидности инструментов, иметь слух, талант итд. Инструмент болгарка тоже знает как вертеть диск вокруг оси, но этого мало, чтобы распились плитку и не отколоть края.
Соглашусь с Вами. Хотя наверное для "продажи" своей идеи просто перебрали в формуле супер-пупер представления. Ни о какой незопасности тут не может быть и речи. Просто сегодня многие люди склонны не к текстовому программированию, а именно к визуальному. Ведь с визуальным можно и детей подключать, что и делают и LEGO, и например такая форма программирования как scetch, которую и для питона, Java и для Arduino подходит. Но раз сказавши "безопаснее", не могут согласиться с тем, что это было через-чур, поэтому и продолжают как мантру повторять это.
Безопасность приходит не от визуальности, а от функтиональных возможностях редактора, который разрешает/запрещает те или иные действия. Например между одним и другим блоком может встать только специальный блок, а не какой-нибудь. Или открыв визуально цикл, сразу в схему вставляется и конец цикла. И не может быть отдельно удалённым. Т.е. безопасность не от блоков или реализации тех или иных синтаксических конструкций азыла, а именно от того, как это всё в редакторе организовано. Но это уже другая песня.
Изобретать велосипед иногда полезно, если при этом появляется совсем другой результат. Т.е. методом даже того-же ТРИЗ можно всегда в что-то новое добавить что-то и получить совсем другое. Или лучшее или специализированое для опревделённых задач итд.
С языком Дракон происходит совсем другое. Изобрели тоже самое, что уже до этого существовало. Но то - вдруг описывается как что-то плохое и Дракон здесь вроде-бы как лучше. Хотя на самом деле блок-схемы уже используются всё реже и реже (так у неспециалистов в MS Office набростать плоские и несложные схемы), а многое новое описывается языком BPMN. Потому что это удовлетворяет современным требованиям намного лучше, чем какие-нибудь блок-схемы типа EPK или как в этой статье - языка дракона.
И использование кричащих названий (как в желтой прессе) только усугубляет всё с этим языком связаным. Он не создавался как медицинский, здесь-же он показан как медицинский. В других статьях он может стать языком архитекторов, композиторов или специально для мясо-комбината. Плюс - указание на "Русский Алгоритмический язык". Русским может быть человеческий язык, культура, но ни как не язык программирования.
Даже немного смешно, когда заходишь на их сайт drakon.su, а там стоит "Дружелюбный Русский Алгоритмический язык", а гиф(ка) показывает развития алгоритма и все тексты там на ангклиском. Короче - какой-то оксюморон.
И авторам не понять, почему нет того восприятия, как они его ожидают. Им невдомёк, что создали то, что уже давно существовало до них. И маленькие рюшечки в виде тонкой или толстой линии, или кружочки в циклах - просто мелочи, которые ничего конкретного не улучшают. И для более обширных задач есть современные подходы.
Это больше на плагиат похоже, чем на создание чего-то нового.
Проблема: "Не хватает кнопки загрузки".
1-й. Почему ?: потому что в старой системе она была.
2-й. Почему? Понятия не имею, но мне было удобно.
3-й. Почему? Ты чё, дебил что-ли? Что докопался?
Есть целая наука под названием Requirement Management. В ней описаны и методы, как у специалистов 'выудить' нужную информацию, так и способы как создать каталог как функциональных, так и нефукциональных требований. На основе которых создаётся стабильная архитектура, процесы и их жизненные циклы, дизайн GUI и структура интерфейсов. Не имя первой - всё просто тяп-ляп. Нагромождение изменений из одного sprint(a) в другой. И вроде хочется сказать, что раньше с этим было лучше, но понимаешь, что от этого ничего не изменится - тренд такой сегодня,
плюс. если используют базы данных. то и таблицы названы, атрибуты в них итд. - без логики и адекватное кол-во времени не позволит во всём разобраться. И как в вашем примере, и в похожих ситуациях - проще всё переписать заново, чем разбираться в дебрях. К сожалению.
Я понимаю, что у такого подхода есть минусы. Но ведь есть и плюсы. Поэтому такой радикальности ведь не надо. В разных странах есть например и этажи с номером 0 и ничего - живут ведь люди.