В этом и есть проблема всех этих блок-схема-редакторов. С их помощью можно кое-что нарисовать, но не больше. В 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 и ничего - живут ведь люди.
Не соглашусь с этим выражением. Боль - это не мотивация. Боль - это основа страха. За сохранение жизни, за сохранение статуса итд. И как отдельный индивидум справляется со своим страхом - начальнику часто не понять, тк. это целая наука. может быть кто-то в страхе найдёт источник для мотивации, но это не гарантировано. Поэтому, я-бы не ставил знак равенства.
Про перестановку - соглашусь. Но Ваше первое и последнее заявления не разделяю. В название сказано - самый быстрый алгоритм. Там ничего не сказано про "должен он быть общего назначения". И не знаю как у других, но я сортирую больше всего числа. Поэтому и беру для этого Countingsort, т.к. разница по скорости сортировки даже с Timsort раз в 10. И для многих, кто впервые сталкивается с таким заголовком - начинают верить, что оно так и есть.
И не понимаю, в чём Вы не согласны с моим выражением " заголовок и правда не соответствует содержанию". Если заголовок уточнить условиями, которые описали Вы, то да, мой пример не подходил-бы. Не люблю, когда неточно выражаются, а потом это приводит к непониманию - "иди, мол сделай вон то и не делай вид, что не понимаешь..."
а в этих методиках куда ни глянь - всё надуманно, всё возведено в статус "не поддаётся оспариванию", за основу берётся выдуманное или нереальное поведение людей. Люди в своём начале ленивые, хитрые, алчные, преследующие свои цели, а не цели каких-то дядей. Конечно никто не будет хотеть брать на себя ответственность. Зачем она нужна, если это не восполняется и не оплачивается дополнительно. По мне agile - это совок. Никто ни за что не отвечает, всё общее, а значит - зачем выпендриваться - будь как все, ведь на фоне всех никто и не увидит твою ненужность. Качество? Да кому оно нужно, ведь работает как-нибудь, сроки просчитывать и исполнять - себя не уважать. А всё почему? Да потому что нет никакой ответственности за весь этот бардак. Ни product owner, ни scrum master, ни отдельные участники всяких там squad(ов) - никто ни за что не отвечает. Ни за костыльную архитектуру, ни за плохое качество, ни за отсутвие документации, ни за говно-код, ни за срыв сроков итд. - никто и ни за что не отвечает. Но в теории - методика классная. Всё может, всё обещает..
Это- надо-ж так - целую науку Project Management с формулами, с огромным багажем работающих механизмов снесли за раз и взамен предлагают только в теории работающие представления.
Нет, сопротивление бесполезно. Это как религия. Если это в головах, то никакое логическое обоснование не помогает. И потери как финансовые, так и по времени и качеству игнорируют как непоказательные. И весь менеджмент должен свой сук сами себе пилить и видоизменять всю иерархию на agile. И доказательство, что это плохо или хорошо лежит не на тех, кто с этими agile методами пришли, а те должны доказывать, кто в этом не уверен. Т.е. не тот должен доказыват, кто утверждает, что бог существует, а тот, кто в его существование не верит...А как это сделать, если это невозможно в принципе.
чел, ты крут. Можно я переведу всё твоё высказывание на нац. язык (живу в Европе) и отправлю своему шефу или многим шефам. т.к. при агиле их у нас тьма. Все какие-то owner(ы), но ничего не происходит, кроме того, что ты в краткой и ёмкой форме описал.
Не соглашусь с оценкой, что по быстроте один из самых быстрых. да, может быть Нотация Big O для Timsort O(n log n), но эта нотация говорит только о поверхностном анализе. Детали кроятся в другом.
Если речь идёт о числах, то алгоритму Countingsort нет равных. Если речь идёт об строковых значениях, то в алгоритме Timsort элементы перставляются очень большое (из перспектив других алгоритмов - ненужное) количество раз, если изначальная ситуация значений из average case/worst case. А перестановка строк - очень интенсивная операция. Сравнение тоже, но если не обращать внимание на усилия по перестановки, то можно быстро получить сюрпризы по скорости выполнения, когда задача будет отсортировать не десять значений, а например 1 миллион.
И хоть сортировка неплохая, но всё равно - заголовк не соответствует содержанию.
IBCS вообще классная вещь. Это настолько здорово, что до сих пор не понимаю, почему это до сих пор не стандарт. В музыки есть стандарт — ноты, в эелктронике есть стандарт — схемы и эл. компоненты Везде есть стандарты — только в описании данных их нет. И каждый рисуит их так, как хочет. И потом — никто не понимает, делают исходя из этого непонимания неправильные выводы итд…
Счтаю, что черезчур завышено значение/неправильность использования иконок. Простое слово «нормально» после вопроса «как дела?» несёт тоже не всегда то, для чего это используется. Но нам это не мешает. Мы продолжаем использовать в разговоре упрощенные формы общения. Так-же и с иконками. В руках багатых на слова людей — они обагащают речь. В руках людей, не владеющих и человеческим языком — и язык иконок будет тоже непонятным, поверхсностным итд.
Согласен. Тоже так думаю. И везде так и говорю. Хотя убедился — редко, кто в это верит.
Пойду дальше в высказывании. В большем количестве фирм, где используется Excel, то со всеми в встроенными возможностями (vba, автоматизация) можно делать много чего, что будет получше, чем тонна всякого черезчур платного софта. Почти все бизнес процессы можно с Excel и Office оцифровать. А с пакетом Office 365 (Excel, Word, PowerPoint, Teams, OneNote, PowerBI etc.) так и вообще — все.
Кстати на примере с Excel я вижу как думают люди. Там сразу видно, если созданные ими конструкции нелогичны, сложные, часто не поддающие пониманию или последующему сопровождению или видоизменению итп. Это как своего рода визитная карточка. Мне сразу понятно, кто передо мной.
Эти вами описываемые шаги были нужны и при постройки пирамид. И при постройке атомной бомбы или ракеты на марс. В этом нет ничего нового. В этом то и суть, что не изучать, опыт других, можно открывать для себя истины и думать, что это что-то новое и неизвестное. Почитайте Дейла Корнеги по управлению людьми. Его книгам больше сотни лет, а в них вы найдёте много из того с чем вы сталкиваетесь впервые. Или из того, что вы здесь упоминайте.
Спасибо за ответ. Не желаю обидеть лично вас. Но сейчас куда не "ткни палкой" — везде скрам мастера. Без технического образования, без образования в области проект менеджмента, без навыков в психологии или поведения человека. Но прошедшие н-дневные курсы. И уверенные в себе, что в состоянии воссоеденить, контролировать и довести до результата технические, специализированные и организационные задачи. При этом думающие, что все люди стремятся к одной цели. Всё это не работает от слова совсем. Только единичные случаи или тривиальные задачи. Но и то и другое часто зависит не от навыков скрам мастера а от ситуации или уже установившейся культураы, подходящего психоттипа команды, как выше уже упомянул- от тривиальности задачи, ну и пару других исходный параметров. Проект менеджмент- это наука, которую нельзя за два дня прослушки взять и владеть. Потому что всё, что не было выучино, будет с командой на личном опыте пережито… И по большей части это будут ошибки. Как-бы этого не хотелось.
В этом и есть проблема всех этих блок-схема-редакторов. С их помощью можно кое-что нарисовать, но не больше. В 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 и ничего - живут ведь люди.
Не соглашусь с этим выражением. Боль - это не мотивация. Боль - это основа страха. За сохранение жизни, за сохранение статуса итд. И как отдельный индивидум справляется со своим страхом - начальнику часто не понять, тк. это целая наука. может быть кто-то в страхе найдёт источник для мотивации, но это не гарантировано. Поэтому, я-бы не ставил знак равенства.
Про перестановку - соглашусь. Но Ваше первое и последнее заявления не разделяю.
В название сказано - самый быстрый алгоритм. Там ничего не сказано про "должен он быть общего назначения". И не знаю как у других, но я сортирую больше всего числа. Поэтому и беру для этого Countingsort, т.к. разница по скорости сортировки даже с Timsort раз в 10. И для многих, кто впервые сталкивается с таким заголовком - начинают верить, что оно так и есть.
И не понимаю, в чём Вы не согласны с моим выражением " заголовок и правда не соответствует содержанию". Если заголовок уточнить условиями, которые описали Вы, то да, мой пример не подходил-бы. Не люблю, когда неточно выражаются, а потом это приводит к непониманию - "иди, мол сделай вон то и не делай вид, что не понимаешь..."
а в этих методиках куда ни глянь - всё надуманно, всё возведено в статус "не поддаётся оспариванию", за основу берётся выдуманное или нереальное поведение людей. Люди в своём начале ленивые, хитрые, алчные, преследующие свои цели, а не цели каких-то дядей. Конечно никто не будет хотеть брать на себя ответственность. Зачем она нужна, если это не восполняется и не оплачивается дополнительно. По мне agile - это совок. Никто ни за что не отвечает, всё общее, а значит - зачем выпендриваться - будь как все, ведь на фоне всех никто и не увидит твою ненужность. Качество? Да кому оно нужно, ведь работает как-нибудь, сроки просчитывать и исполнять - себя не уважать. А всё почему? Да потому что нет никакой ответственности за весь этот бардак. Ни product owner, ни scrum master, ни отдельные участники всяких там squad(ов) - никто ни за что не отвечает. Ни за костыльную архитектуру, ни за плохое качество, ни за отсутвие документации, ни за говно-код, ни за срыв сроков итд. - никто и ни за что не отвечает. Но в теории - методика классная. Всё может, всё обещает..
Это- надо-ж так - целую науку Project Management с формулами, с огромным багажем работающих механизмов снесли за раз и взамен предлагают только в теории работающие представления.
Нет, сопротивление бесполезно. Это как религия. Если это в головах, то никакое логическое обоснование не помогает. И потери как финансовые, так и по времени и качеству игнорируют как непоказательные. И весь менеджмент должен свой сук сами себе пилить и видоизменять всю иерархию на agile. И доказательство, что это плохо или хорошо лежит не на тех, кто с этими agile методами пришли, а те должны доказывать, кто в этом не уверен. Т.е. не тот должен доказыват, кто утверждает, что бог существует, а тот, кто в его существование не верит...А как это сделать, если это невозможно в принципе.
чел, ты крут. Можно я переведу всё твоё высказывание на нац. язык (живу в Европе) и отправлю своему шефу или многим шефам. т.к. при агиле их у нас тьма. Все какие-то owner(ы), но ничего не происходит, кроме того, что ты в краткой и ёмкой форме описал.
Не соглашусь с оценкой, что по быстроте один из самых быстрых. да, может быть Нотация Big O для Timsort O(n log n), но эта нотация говорит только о поверхностном анализе. Детали кроятся в другом.
Если речь идёт о числах, то алгоритму Countingsort нет равных. Если речь идёт об строковых значениях, то в алгоритме Timsort элементы перставляются очень большое (из перспектив других алгоритмов - ненужное) количество раз, если изначальная ситуация значений из average case/worst case. А перестановка строк - очень интенсивная операция. Сравнение тоже, но если не обращать внимание на усилия по перестановки, то можно быстро получить сюрпризы по скорости выполнения, когда задача будет отсортировать не десять значений, а например 1 миллион.
И хоть сортировка неплохая, но всё равно - заголовк не соответствует содержанию.
Пойду дальше в высказывании. В большем количестве фирм, где используется Excel, то со всеми в встроенными возможностями (vba, автоматизация) можно делать много чего, что будет получше, чем тонна всякого черезчур платного софта. Почти все бизнес процессы можно с Excel и Office оцифровать. А с пакетом Office 365 (Excel, Word, PowerPoint, Teams, OneNote, PowerBI etc.) так и вообще — все.
Кстати на примере с Excel я вижу как думают люди. Там сразу видно, если созданные ими конструкции нелогичны, сложные, часто не поддающие пониманию или последующему сопровождению или видоизменению итп. Это как своего рода визитная карточка. Мне сразу понятно, кто передо мной.
Может быть стоит обратить внимание на социальные проблемы в космосе? Например отсутствие женского начала. И его компенсировать.
Эти вами описываемые шаги были нужны и при постройки пирамид. И при постройке атомной бомбы или ракеты на марс. В этом нет ничего нового. В этом то и суть, что не изучать, опыт других, можно открывать для себя истины и думать, что это что-то новое и неизвестное. Почитайте Дейла Корнеги по управлению людьми. Его книгам больше сотни лет, а в них вы найдёте много из того с чем вы сталкиваетесь впервые. Или из того, что вы здесь упоминайте.
Спасибо за ответ. Не желаю обидеть лично вас. Но сейчас куда не "ткни палкой" — везде скрам мастера. Без технического образования, без образования в области проект менеджмента, без навыков в психологии или поведения человека. Но прошедшие н-дневные курсы. И уверенные в себе, что в состоянии воссоеденить, контролировать и довести до результата технические, специализированные и организационные задачи. При этом думающие, что все люди стремятся к одной цели. Всё это не работает от слова совсем. Только единичные случаи или тривиальные задачи. Но и то и другое часто зависит не от навыков скрам мастера а от ситуации или уже установившейся культураы, подходящего психоттипа команды, как выше уже упомянул- от тривиальности задачи, ну и пару других исходный параметров. Проект менеджмент- это наука, которую нельзя за два дня прослушки взять и владеть. Потому что всё, что не было выучино, будет с командой на личном опыте пережито… И по большей части это будут ошибки. Как-бы этого не хотелось.