Согласно первому сценарию Грефа, искусственный интеллект возьмёт на себя большое количество функций, что позволит всем людям на планете работать меньше, а зарабатывать больше.
Тут ошибка, будет примерно так:
искусственный интеллект возьмёт на себя большое количество функций, что позволит таким людям как Гфер работать меньше, а зарабатывать больше
Наличие информации, обосновывающей достоинства использования способов, методов обеспечения доступа к заблокированным ресурсам или сетям, а также дающей положительную оценку или одобрение действиям по использованию таких способов, методов.
То есть написать правду, что использование VPN в публичных WiFi сетях может повысить безопасность ваших коммуникаций, это теперь нарушение? Уху там ели что ли?
Дети галлюцинируют от недостатка знаний, взрослые перестают галлюцинировать (иногда и в определенных областях) потому что они знают больше, можно сказать достаточно (спросите меня о механизме появления черных дыр и не оставьте мне выбора отвечать или нет, то я вам тоже такого нагаллюцинирую, что не зная с кем вы говорите, подумаете что это ChatGPT). А GPT содержат столько знаний, сколько ни в одного человека за всю жизнь не влезет и тут проблема уже в другом - в избытке этих знаний. Галлюцинации могут возникать как раз из-за такого избытка, когда невозможно достоверно вычислить то самое среднее, потому что вариантов намного больше, чем у обычного взрослого человека.
Возможно, решение лежит в поиске новых механизмов работы с этими массивами, механизме, которого у человека нет и вряд ли появится, а потому его придется изобретать, а не просто реализовывать по кальке. Может это некая многоступенчатая обработка, когда есть несколько точных небольших моделей на входе, которые коллективно и достоверно определяют/сужают тему и смысл запроса и инструктируют низлежащую модель, обладающую всеми существующими знаниями или что угодно ещё.
Не понимаю причем тут доброта, я объективно указал на ваши ошибки, это во-первых. Во-вторых, я прекрасно понимаю о чем говорю, иначе не писал бы, и как раз прекрасно понял что вы написали в статье. А теперь если у вас есть что написать про сути моего комментария - добро пожаловать, а просто в чем-то обвинять меня - это вас не красит.
Вначале мы старались полностью соответствовать этому фреймворку — выполнять все необходимые ритуалы.
Если вы старались, то должны были узнать, что там нет "ритуалов", есть только "события".
Однако постепенно пришло осознание, что соблюдать их все затратно, это отъедает время, которое можно было бы уделить разработке продукта.
Нет, вы изначально не понимали зачем эти события, поэтому к вам пришло такое "осознание". Когда не понимаешь предназначения чего-либо, оно всегда кажется бессмысленным.
Есть такая штука как ёмкость.
Она показывает вес работ, который команда (или её член), в среднем, закрывает за спринт в сторипойнтах (далее — sp).
Нет такой "штуки", как "ёмкость", есть velocity. Этот термин обычно переводят как скорость и он используется для измерения объема работы, которую команда может выполнить за один спринт. Это показатель производительности команды.
Каждый член команды дает по ним свою оценку. Внимание, вопрос! Сколько весит пользовательская история?
Опять двадцать пять — в сторипоинтах оцениваются истории, а не задачи, которые нужно выполнить, чтобы реализовать эти истории. Ваш вопрос не имеет никакого смысла.
Но, на мой взгляд, этот подход имеет существенное ограничение. Всё потому, что каждый член команды будет выполнять свою часть работы в соответствии со своей специализацией. Как я, как системный аналитик, могу адекватно оценить работу фронтенд-разработчика? Я могу адекватно оценить задачи анализа, да и то не всегда, потому что в наших задачах есть высокая доля неопределённости.
Ну, теперь точно понятно — вы не старались полностью соответствовать этому фреймворку, иначе знали бы о таком понятии, как кроссфункциональная команда, почему она важна и как ее создавать.
скрам-планирование
Что это вообще такое?)
Большая часть данных, если не все, уже лежат у вас в таск-трекере: оценки, приоритеты и т.д. Остаётся только ёмкость. Но и её, с определенными допущениями, можно вычислить ретроспективно, либо задать директивно.
Насмешили — "вычислить" или "задать")
Вывод: Не надо линейного программирования в Scrum, надо его хотя бы раз изучить правильно)
Наиболее здоровые проекты на мой взгляд, это проекты с диктатурой сильного и влиятельного Fullstack программиста архитектора. Которому хватает влияния и полномочий продвигать правильные решения и блокировать всякий бред.
И причем тут вообще Scrum или его отсутствие?) А когда диктует один человек, то и решения получаются однобокие, один никогда не будет знать все и принимать идеальные решения, другое дело когда в Scrum Team три сеньора собрались и решили как сделать лучше и нафиг диктатуру.
Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.
Это в каком веке автор написал оригинальную статью? Смотреть нужно на https://scrumguides.org/index.html. А теперь настоящая цитата с отсылкой к источнику:
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.
Определение Scrum из Руководство по Scrum. Могу только лишний раз заметить, что не стоит слепо верить всему, что на Хабре пишут/переводят некоторые — все нужно перепроверять в источниках.
Церемонии
Scrum-команда должна следовать некоторым церемониям.
Примечание: мне никогда не нравился этот религиозный термин, используемый для описания подобных совещаний, но что уж есть.
А действительно, когда он это писал? 18 октября? Видимо, писал по памяти, а она, порой, как известно, подруга ненадежная) Нет там никаких церемоний, есть события (events). Ищем там же раздел События Scrum.
Ежедневные совещания — ежедневные КОРОТКИЕ совещания (примерно 15 минут), на которых маленькая команда разработчиков (примерно 3-7 человек) обсуждает свой прогресс и выделяет мешающие двигаться дальше проблемы, не вдаваясь в подробности. Это время, в которое можно попросить Алису устроить отдельное совещание о проблеме кэширования на стороне сервера и спросить Боба о том, почему параметр даты является строкой, а не временем Unix.
Ну и чушь (как автор просил называть 😁) Вот такие товарищи сначала ничего не поняли, а потом вещают что это плохой способ работы) Знаете зачем Daily Scrum? Да, формально каждый должен ответить на три вопроса, однако спрашивать Боба о типах данных не нужно. Вы можете и обычно так и происходит, после Daily Scrum устроить любые беседы по обсуждению типов данных, но после. Daily Scrum — это не только апдейт для коллег и источник информации о проблемах для Scrum Master, это (о чем многие не догадываются) один из способов культивирования самоорганизующейся команды. Самоорганизующаяся команда — это одна из основ и часто вы должны задать себе вопрос: если команда не может сама организоваться и провести Daily Scrum так, как это ожидается, то как она вообще станет самоорганизующейся? У кого-то это сечас вызвало жуткий зуд)
Это отдельные личности или группы, определённые в Scrum:
Стейкхолдеры — это заинтересованные лица, они хотят быть информированными, участвующими, они получают прибыль от продукта, чем бы ни был «продукт» в вашей компании. Да, при желании определение «продукта» можно растянуть на что угодно. Это могут быть конечные пользователи, другие команды и даже другие бизнесы.
Теперь я точно уверен — да, автор изучал Scrum в прошлом веке) Нет там никаких стейкхолдеров, есть только три роли)
Планирование, вне зависимости от инструментария, занимает кучу времени, и в результате вы получаете заранее установленные задачи, измеряемые в сторипоинтах. Эти поинты, которые должны помочь в понимании сложности конкретной задачи, вместо этого используются для измерения времени.
Опять чушь) В сторипоинтах User Stories, а задачи, которые реализуют конкретную User Story — их скоуп определяется так, чтобы занимать не больше одного рабочего дня, то они, фактически, измеряются в длительности по времени, нет никаких сторипоинтов у задач)
Представим возможную ситуацию: ни владельца продукта, ни Scrum-мастера нет в офисе. Один на больничном, второй в отпуске. Будет ли ваша команда продолжать участвовать в ежедневных совещаниях? Сомневаюсь.
А теперь перечитайте выше — если команда не может сама организовать такое простое событие, как она будет вообще самоорганизовываться? Если никак, то потом и будут появляться такие авторы, которые несут эту чушь, скрывая свою ненависть за шуточными высказываниями.
Это заметно по кривому FB.
Стоит трижды подумать что именно вы отправляете в ChatGPT или DALL-E, ведь OpenAI может использовать предоставленные пользователями данные для улучшения своих моделей со всеми вытекающими последствиями.
А кто одобрил покупку конкурентов? Уже тогда было все ясно, а сейчас они внезапно прозрели? 🤦♂️
Утекли... Да Маск их лично передал и сказал разместить в X.
О Грефе я и не говорил - это гипотетические рассуждения о гипотетическом человеке, который стоит во главе корпорации, владеющей развитым ИИ.
Тут ошибка, будет примерно так:
Скажите что я ошибаюсь.
То есть написать правду, что использование VPN в публичных WiFi сетях может повысить безопасность ваших коммуникаций, это теперь нарушение? Уху там ели что ли?
Всегда остается ненулевая вероятность глупой фатально-летальной ошибки, которую ИИ не допустил бы. Иначе откуда все ДТП?
Дети галлюцинируют от недостатка знаний, взрослые перестают галлюцинировать (иногда и в определенных областях) потому что они знают больше, можно сказать достаточно (спросите меня о механизме появления черных дыр и не оставьте мне выбора отвечать или нет, то я вам тоже такого нагаллюцинирую, что не зная с кем вы говорите, подумаете что это ChatGPT). А GPT содержат столько знаний, сколько ни в одного человека за всю жизнь не влезет и тут проблема уже в другом - в избытке этих знаний. Галлюцинации могут возникать как раз из-за такого избытка, когда невозможно достоверно вычислить то самое среднее, потому что вариантов намного больше, чем у обычного взрослого человека.
Возможно, решение лежит в поиске новых механизмов работы с этими массивами, механизме, которого у человека нет и вряд ли появится, а потому его придется изобретать, а не просто реализовывать по кальке. Может это некая многоступенчатая обработка, когда есть несколько точных небольших моделей на входе, которые коллективно и достоверно определяют/сужают тему и смысл запроса и инструктируют низлежащую модель, обладающую всеми существующими знаниями или что угодно ещё.
Не понимаю причем тут доброта, я объективно указал на ваши ошибки, это во-первых. Во-вторых, я прекрасно понимаю о чем говорю, иначе не писал бы, и как раз прекрасно понял что вы написали в статье. А теперь если у вас есть что написать про сути моего комментария - добро пожаловать, а просто в чем-то обвинять меня - это вас не красит.
Del
Ну, блин, куда ни глянь — везде одно и то же 🤦♂️
Если вы старались, то должны были узнать, что там нет "ритуалов", есть только "события".
Нет, вы изначально не понимали зачем эти события, поэтому к вам пришло такое "осознание". Когда не понимаешь предназначения чего-либо, оно всегда кажется бессмысленным.
Нет такой "штуки", как "ёмкость", есть velocity. Этот термин обычно переводят как скорость и он используется для измерения объема работы, которую команда может выполнить за один спринт. Это показатель производительности команды.
Опять двадцать пять — в сторипоинтах оцениваются истории, а не задачи, которые нужно выполнить, чтобы реализовать эти истории. Ваш вопрос не имеет никакого смысла.
Ну, теперь точно понятно — вы не старались полностью соответствовать этому фреймворку, иначе знали бы о таком понятии, как кроссфункциональная команда, почему она важна и как ее создавать.
Что это вообще такое?)
Насмешили — "вычислить" или "задать")
Вывод: Не надо линейного программирования в Scrum, надо его хотя бы раз изучить правильно)
Быстро прочёл, показалось зампред соседа 😦
Взрослые и адекватные люди умеют договариваться, для остальных Scrum не подходит)
Вы же, наверное, недавно статью писали? И точно что‑то упустили, как минимум, мультимодальность.
Поздравляю! Вы, наконец, открыли для себя prompt engineering, который уже почти стал профессией) Догоняйте)
Вот, точно, а я все думаю в чем прикол — автор оригинала русский! 😁
И причем тут вообще Scrum или его отсутствие?) А когда диктует один человек, то и решения получаются однобокие, один никогда не будет знать все и принимать идеальные решения, другое дело когда в Scrum Team три сеньора собрались и решили как сделать лучше и нафиг диктатуру.
Это в каком веке автор написал оригинальную статью? Смотреть нужно на https://scrumguides.org/index.html. А теперь настоящая цитата с отсылкой к источнику:
Определение Scrum из Руководство по Scrum. Могу только лишний раз заметить, что не стоит слепо верить всему, что на Хабре пишут/переводят некоторые — все нужно перепроверять в источниках.
А действительно, когда он это писал? 18 октября? Видимо, писал по памяти, а она, порой, как известно, подруга ненадежная) Нет там никаких церемоний, есть события (events). Ищем там же раздел События Scrum.
Ну и чушь (как автор просил называть 😁) Вот такие товарищи сначала ничего не поняли, а потом вещают что это плохой способ работы) Знаете зачем Daily Scrum? Да, формально каждый должен ответить на три вопроса, однако спрашивать Боба о типах данных не нужно. Вы можете и обычно так и происходит, после Daily Scrum устроить любые беседы по обсуждению типов данных, но после. Daily Scrum — это не только апдейт для коллег и источник информации о проблемах для Scrum Master, это (о чем многие не догадываются) один из способов культивирования самоорганизующейся команды. Самоорганизующаяся команда — это одна из основ и часто вы должны задать себе вопрос: если команда не может сама организоваться и провести Daily Scrum так, как это ожидается, то как она вообще станет самоорганизующейся? У кого-то это сечас вызвало жуткий зуд)
Теперь я точно уверен — да, автор изучал Scrum в прошлом веке) Нет там никаких стейкхолдеров, есть только три роли)
Опять чушь) В сторипоинтах User Stories, а задачи, которые реализуют конкретную User Story — их скоуп определяется так, чтобы занимать не больше одного рабочего дня, то они, фактически, измеряются в длительности по времени, нет никаких сторипоинтов у задач)
А теперь перечитайте выше — если команда не может сама организовать такое простое событие, как она будет вообще самоорганизовываться? Если никак, то потом и будут появляться такие авторы, которые несут эту чушь, скрывая свою ненависть за шуточными высказываниями.
Вы слишком добры 😆
Я думаю что для этого придется
разработатьадаптировать код action Release Please на Rust, это следующий шаг)