Ответ: никак. Если бы всё было в целом хорошо, никто бы и не парился. Проблема в том, что всё нехорошо, никогда не было хорошо и никакие методологии кардинально ситуацию не улучшили за последние лет пятьдесят.
Не соглашусь. Мы с коллегами вели учёт спринтов и каждый раз на ретро пытались найти причины задержек. Но причины почти всегда были разные. Только потом, прочитав Талеба, я понял, что истинная причина задержек совсем в другом: мир принципиально непредсказуем.
Если бы мы писали систему повторно, то тогда бы знали все подводные камни. Но обычно у нас или новая технология, или не очень известная предметная область, или так называемый "творческий бизнес", который придумывает ТЗ на ходу.
Некоторым подтверждением моих слов может служить статистика. Я постоянно ссылаюсь на CHAOS REPORT 2015. Он гуглится. Там есть разнообразная статистика по проектам, с Agile, без Agile, большим, средним, маленьким.
И вот там даже у маленьких проектов, которые ведутся по Agile (считается, что это более контролируемый процесс) процент проектов, уложившихся в сроки и бюджет — всего лишь порядка 50%. Это в целом по индустрии.
Если кто-то мне не верит, могу предложить самостоятельно вести учёт спринтов, скажем, полгода, но только честно. Если что-то не успели сделать, так и пишем в табличку. Можно считать очень точно, поскольку есть перечень задач на спринт. Через полгода смотрим. Предположу, что реальная исполняемость как раз и будет 60-80%.
Интересный парадокс. Сама идея спринтов не кажется такой уж плохой. Промежуточные цели — хороший способ контролировать продвижение. Чем раньше мы узнаём о проблемах, тем больше у нас возможностей с ними справиться. Звучит хорошо.
Но, знаете, когда я читал статью, то понял, что вы действительно правы. На практике, каждая сдача спринта это стресс. Мы постоянно что-то не успеваем и постоянно думаем, как нам с этим справиться, но у нас есть "большой дедлайн", поэтому всё это мы откладываем на потом.
Кажется, что где-то что-то глобально пошло не так. Идея была в том, чтобы проверять прогресс, но сейчас речь идёт, чтобы отчитываться о прогрессе. Ситуация, когда мы не сделали 60-80% задач, не должна считаться нонсенсом — это нормальная житейская история.
Не знаю, можно ли как то излечиться от этого "синдрома отчётности". Потому что, если нельзя, то идея итераций и в самом деле гибельная.
Не знаю. Ходят слухи, что команда C# хочет что-то подобное затащить, но пока это только слухи, и не очень понятно, в каком объёме будут затаскивать.
С другой стороны — проект на F# вполне может держать в одном солюшене вместе с проектами на C#, так что уже сейчас можно писать, скажем, чистую бизнес-логику на F#, а инфраструктуру — на C#. Многие именно так и делают.
В C#, начиная с 10-й версии есть top level statements, операторы верхнего уровня. Позволяют писать простые программы без всех этих class и void Main(). Ещё можно избавиться от using, если использовать полные имена в коде. System.Int64.Parse, System.Console.ReadLin — и вот уже минус одна строка.
Да, точно, это у меня ложная память сработала. В задаче на обмен значений двух переменных без временной переменной, есть вариант с XOR, а есть вариант с вычитанием. Но на массив он не расширятся, по крайней мере, на общий случай.
Очень здорово. Даже не ожидал узнать что-нибудь настолько интересное, когда писал свой комментарий. Спасибо, погружусь в изучение.
Табулатуры вижу регулярно в интернете, но их довольно трудно парсить, именно, с программистской точки зрения.
Сам в своё время освоил всё-таки ноты и успел купить Guitar Pro, чтобы их там вводить. Но я не настоящий музыкант, любитель, так что воспринимаю всё это как некую данность. Что-то придумывать в этой области не могу, не хватает знаний.
Нет. Очевидно, вы не поняли. То, что тенденция есть, это уже из лекции Пирожкова я осознал. Но, видимо, такие темы не для вас. Можете не тратить ваше время.
Это вот прямо интересно. Никогда не думал про кодирование музыки. Мне казалось, что формат MIDI закрыл эту проблематику, но я никогда не погружался глубоко. Сам формат бинарный, но, если мне не изменяет память, есть текстовое представление?
И, да, есть классическое графическое представление — ноты.
А есть какие-то статьи или видео про ваши наработки?
Да, правда. Потому что, я напишу ещё раз — мне интересна тема визуальных языков программирования, мне интересно, как это могло бы выглядеть. И да, идея о том, что такая проблематика перед нами встанет, появилась у меня, когда я увидел, как звукорежиссёр одной группы, на концерте которой я был, ходил по залу с планшетом и настраивал звук.
Я подумал: а кто ещё может работать на планшете? А мы, программисты, сможем ли?
Мой комментарий для тех, кому интересно подумать в эту сторону. Вам не интересно. Хорошо. Давайте больше не отнимать друг у друга время.
Мне тоже кажется, что не будет одного варианта, а будет несколько.
Есть, правда, идея, что все программы могут быть представлены, как в LISP. Каждое S-выражение из LISP можно нарисовать в виде дерева. Наверное, эти рисунки будут визуально громоздки, так как сложные математические формулы будут представлены как большие куски деревьев, похожих на абстрактные синтаксические деревья.
Вы очень странные вещи пишите, серьёзно. Мне выдают ноут на работе последние лет десять, наверное. Но дело даже не в этом.
Вы тратите свои аргументы впустую. Цель моего комментария была — пофантазировать на тему, затронутую в статье, потому что она мне близка, возможно, вызвать кого-то на обсуждение и моделирование, какими могли бы быть удачные визуальные языки программирования.
Вы докопались к отдельной детали, и мы просто зря тратим время на её обсуждение. Ну, живёте вы в вашем мире с тауэрами, и живите. Это просто значит, что обсуждение перспективных идей не для вас.
У меня приблизительно такие же представления. За тем, может быть, исключением, что есть ещё чёрные лебеди, которые кардинально ломают планирование.
Вы не с тем человек спорите. Я то считаю, что 60-80% это вполне ок. Мне вот пишут, что это мало и надо 100%.
Так я, вроде, именно это и делаю. Завершим, — говорю, — от 60 до 80% запланированных задач. Чем не непредсказуемость?
Но ведь это не в наших возможностях. Об этом и был мой комментарий.
Мир непредсказуем. Как ты ни крутись, но 100% всё равно не попадёшь. И статистика это подтверждает, можете сами посмотреть, как в индустрии обстоят дела с предсказуемостью.
Ответ: никак. Если бы всё было в целом хорошо, никто бы и не парился. Проблема в том, что всё нехорошо, никогда не было хорошо и никакие методологии кардинально ситуацию не улучшили за последние лет пятьдесят.
Не соглашусь. Мы с коллегами вели учёт спринтов и каждый раз на ретро пытались найти причины задержек. Но причины почти всегда были разные. Только потом, прочитав Талеба, я понял, что истинная причина задержек совсем в другом: мир принципиально непредсказуем.
Если бы мы писали систему повторно, то тогда бы знали все подводные камни. Но обычно у нас или новая технология, или не очень известная предметная область, или так называемый "творческий бизнес", который придумывает ТЗ на ходу.
Некоторым подтверждением моих слов может служить статистика. Я постоянно ссылаюсь на CHAOS REPORT 2015. Он гуглится. Там есть разнообразная статистика по проектам, с Agile, без Agile, большим, средним, маленьким.
И вот там даже у маленьких проектов, которые ведутся по Agile (считается, что это более контролируемый процесс) процент проектов, уложившихся в сроки и бюджет — всего лишь порядка 50%. Это в целом по индустрии.
Если кто-то мне не верит, могу предложить самостоятельно вести учёт спринтов, скажем, полгода, но только честно. Если что-то не успели сделать, так и пишем в табличку. Можно считать очень точно, поскольку есть перечень задач на спринт. Через полгода смотрим. Предположу, что реальная исполняемость как раз и будет 60-80%.
Интересный парадокс. Сама идея спринтов не кажется такой уж плохой. Промежуточные цели — хороший способ контролировать продвижение. Чем раньше мы узнаём о проблемах, тем больше у нас возможностей с ними справиться. Звучит хорошо.
Но, знаете, когда я читал статью, то понял, что вы действительно правы. На практике, каждая сдача спринта это стресс. Мы постоянно что-то не успеваем и постоянно думаем, как нам с этим справиться, но у нас есть "большой дедлайн", поэтому всё это мы откладываем на потом.
Кажется, что где-то что-то глобально пошло не так. Идея была в том, чтобы проверять прогресс, но сейчас речь идёт, чтобы отчитываться о прогрессе. Ситуация, когда мы не сделали 60-80% задач, не должна считаться нонсенсом — это нормальная житейская история.
Не знаю, можно ли как то излечиться от этого "синдрома отчётности". Потому что, если нельзя, то идея итераций и в самом деле гибельная.
Не знаю. Ходят слухи, что команда C# хочет что-то подобное затащить, но пока это только слухи, и не очень понятно, в каком объёме будут затаскивать.
С другой стороны — проект на F# вполне может держать в одном солюшене вместе с проектами на C#, так что уже сейчас можно писать, скажем, чистую бизнес-логику на F#, а инфраструктуру — на C#. Многие именно так и делают.
Я не согласен с тем, что Fido убили.
Отмерло за ненадобностью.
В C#, начиная с 10-й версии есть top level statements, операторы верхнего уровня. Позволяют писать простые программы без всех этих
classиvoid Main(). Ещё можно избавиться отusing, если использовать полные имена в коде.System.Int64.Parse,System.Console.ReadLin— и вот уже минус одна строка.Да, точно, это у меня ложная память сработала. В задаче на обмен значений двух переменных без временной переменной, есть вариант с XOR, а есть вариант с вычитанием. Но на массив он не расширятся, по крайней мере, на общий случай.
Ну да, здесь подойдёт любая операция, которая при повторном применении даёт то же число. Скажем, можно вычитать из какой-нибудь константы.
Интересный поинт. Не думал об этом в таком ключе. Очень круто, думаю, это тоже возможный, и даже весьма вероятный путь развития.
Можно размышлять даже не просто о визуальном языке программирования, а о 3D-языке. Сколько интересных возможностей.
Я ещё раз повторю: вы докопались до детали, совершенно упустив основной посыл. Вам заняться нечем?
Очень здорово. Даже не ожидал узнать что-нибудь настолько интересное, когда писал свой комментарий. Спасибо, погружусь в изучение.
Табулатуры вижу регулярно в интернете, но их довольно трудно парсить, именно, с программистской точки зрения.
Сам в своё время освоил всё-таки ноты и успел купить Guitar Pro, чтобы их там вводить. Но я не настоящий музыкант, любитель, так что воспринимаю всё это как некую данность. Что-то придумывать в этой области не могу, не хватает знаний.
Нет. Очевидно, вы не поняли. То, что тенденция есть, это уже из лекции Пирожкова я осознал. Но, видимо, такие темы не для вас. Можете не тратить ваше время.
Это вот прямо интересно. Никогда не думал про кодирование музыки. Мне казалось, что формат MIDI закрыл эту проблематику, но я никогда не погружался глубоко.
Сам формат бинарный, но, если мне не изменяет память, есть текстовое представление?
И, да, есть классическое графическое представление — ноты.
А есть какие-то статьи или видео про ваши наработки?
Да, правда. Потому что, я напишу ещё раз — мне интересна тема визуальных языков программирования, мне интересно, как это могло бы выглядеть. И да, идея о том, что такая проблематика перед нами встанет, появилась у меня, когда я увидел, как звукорежиссёр одной группы, на концерте которой я был, ходил по залу с планшетом и настраивал звук.
Я подумал: а кто ещё может работать на планшете? А мы, программисты, сможем ли?
Мой комментарий для тех, кому интересно подумать в эту сторону. Вам не интересно. Хорошо. Давайте больше не отнимать друг у друга время.
Мне тоже кажется, что не будет одного варианта, а будет несколько.
Есть, правда, идея, что все программы могут быть представлены, как в LISP. Каждое S-выражение из LISP можно нарисовать в виде дерева. Наверное, эти рисунки будут визуально громоздки, так как сложные математические формулы будут представлены как большие куски деревьев, похожих на абстрактные синтаксические деревья.
Но, возможно, это будет только начало.
Вы очень странные вещи пишите, серьёзно. Мне выдают ноут на работе последние лет десять, наверное. Но дело даже не в этом.
Вы тратите свои аргументы впустую. Цель моего комментария была — пофантазировать на тему, затронутую в статье, потому что она мне близка, возможно, вызвать кого-то на обсуждение и моделирование, какими могли бы быть удачные визуальные языки программирования.
Вы докопались к отдельной детали, и мы просто зря тратим время на её обсуждение. Ну, живёте вы в вашем мире с тауэрами, и живите. Это просто значит, что обсуждение перспективных идей не для вас.
Возможно, от клавиатуры и мыши никуда не деться. Но вообще интересно пофантазировать, если языки будут визуальными, то какими?