Тут однако тонкость есть, "запитаем насосы от выбегающей турбины" делали на выключенном реакторе. И только половину насосов (4 из 8). При том, что четверть насосов (2 из 8) вообще не должна была работать (она всегда в резерве, как диск в RAID-6) даже при полной загрузке реактора. Так что на выключенном реакторе при эксперименте должны были работать 2/3 от охлаждения максимально разогнанного реактора.
Собственно, это уже был третий эксперимент, после 1983 и 1984. И по "самым гуманным советским законам" без успешного прохода этого эксперимента реактор вообще нельзя было запускать. Но все остальные АЭС РБМК были "под военными" (МинСредМаш), для которых официальные советские законы значили чуть меньше хорошей туалетной бумаги. А ЧАЭС была под гражданским правительством, пришлось хотя бы пытаться законы выполнять...
Простой вопрос, откуда они вообще узнали, что критически важные данные когда-то там были в удалённой папке "Хлам"?
А если правду в комментах написали, что обвиняемый уволился два года назад (следовательно, и папка была удалена как минимум два года назад, или больше) - то уже два вопроса: как узнали и почему два года всем наплевать было.
Тут картинка "Здравствуйте. Мы уже почти закончили выполнять ваш прошлогодний заказ. Но не могли бы вы прислать пароль от архива с заказом?"
на пингвинах и подобных можно тогда просто какую-нибудь log-based FS поставить, из которых удаление информации технически невозможно, только добавление (хотя пользователю и КАЖЕТСЯ, что он там чего-то переписал или удалил, как на CD-R было).
Не очень понимаю кого и как может дискриминировать всемирном теневое правительство программистов. Отказать в доступе на порнхаб? Научить хомячка уклоняться от кликов? Заставить чатГПТ придумывать анекдоты тупее чем у соседа?
Ничего не имею против такой схемы, особенно если Васе дадут часы на это "делиться компетенцией", но однако причём тут всякие митболы и прочие кнедлики по скраму? Обсуждение инженерных задач инженерами происходит постоянно, без привязки к красным дням календаря и без церемоний. Кнедлики только отнимают время, которое инженеры могли бы потратить на обмен опытом.
P.S. да и РП в данном контексте едва ли относится к бизнесу, скорее это прораб, самый тёртый жизнью из программистов.
Valve also threatens game publishers with punitive action, including removal of their Steam-enabled games, if they sell non-Steam-enabled versions of those games at lower prices
...provisions within Steamworks Documentation to impose conditions on how non-Steam-enabled games are sold and priced
Ну то есть "да, вы имеете право продавать игры дешевле, если вы вообще не будете продавать стим-ключи никогда и нигде". Надо просто продавать на Стиме игры без стим-ключей. Что может быть проще?
В общем как с любым запретом, вводят его под предлогом одних случаев, а наказания применяют в других случаях, "расширительная трактовка" (с).
А вот статья 2021 года, со стороны Valve. Евангелист Valve утверждает, что...
In almost every case, those games will be offered at the same base price. Instead of passing on the savings, the publishers just pocket the 18 percentage-point difference between the EGS cut and the Steam cut
...производители сами поднимают цену в альтернативных магазинах, потому что хотят и жадные, а не потому, что принудили. Несмотря на то, что уже в следующем абзаце приводят игру, которую Valve запретил производителю продавать даже со своего личного сайта (разумеется, в той сборке вообще не было ни строчки кода от стима, но всё равно запрещено).
Допускаю, что с тех пор Valve стали аккуратнеe и тщательнее прописали алгоритмы lawfare. Во всяком случае в 2023 году уже появляются разговоры про действительно появившуюся разницу цен в магазинах.
За восемь минут до ответа на этот комментарий неизвестный герой, чисто случайно похожий на Grey83, плюнул мне в карму за - внимание - "распространение рекламы".
Надеюсь добровольный евангелист Valve расскажет мне кого именно я рекламировал и передаст оплату этой рекламы. Он же честный человек, да?
так чтобы понять "удобно или не удобно" - опять же требуется долгосрочная работа по реальному, каждодневному сценарию.
то, что покажется удобным, в течении 5 минут, может оказаться нифига не удобным за 5 часов. То, что кажется удобным при тестировании одной функции, может оказаться неудобно, когда надо выполнять разные функции (в том числе никак не относящиеся к изменённому функционалу).
условно, в качестве фичи для фастфуда выкатили кофе-машину, в которой оператор работает на площадке, на которую надо по лесенке подниматься. Пока оператор тестирует ТОЛЬКО изменения - всё зашибись. А вот как только из тестового контура передеплоим в боевой, где надо продавать не только кофе, - сразу становится плохо. Но в чистой теории, конечно, если покупатель выделит несколько сотрудников которые в full time будут повторять работу других сотрудников и ничего кроме этого - тогда можно и на тестовом. Либо частичный деплой, берём 5% сотрудников покупателя и переключаем их на работу с тестовой сборкой в реальном контуре.
будь оно иначе - не требовалось бы две недели на спринты давать, хватило бы полдня.
— Капитан, как скоро вы сможете приземлиться? — Не могу вам сказать. — Мне можно, я доктор. — Я просто этого не знаю. — А предположить вы не можете? — Займёт не меньше двух часов. — Вы так долго будете предполагать?
с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.
Первое требует второго. Хотя, конечно, второе не гарантирует первого.
"В лабораторных условиях" я и сам могу протестить, мне для этого даже и QA не нужен. А реальные задачи вне боевого не тестируются. У покупателя тоже нет лишних сотрудников, которые будут буквально повторять все реальные задачи обычных сотрудников на отдельном контуре.
...и это я ещё про "плавающие ошибки" не говорю ;-)
> что 2 недели - наиболее оптимальный срок для заказчика
...а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?
Потому что это очень сильный критерий применимости скрама.
абсолютно игнорируют вопросы "в каких случаях?"
Следовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом
У скрама много недостатков, но то, что автор раз за разом пинает именно разбиение задач
Вы сказали, что единственная причина по которой пинают скрам, это когда пинающие не умеют в декомпозицию, и поэтому не могут заранее просчитать сложность задачи.
Других причин, кроме неумения в декомпозицию, для недовольства скрамом нет, согласно вашему тезису.
...а этот понимающий бизнес нанимает техрайтеров, которые сразу по закрытию инженерной задачи подлетают к разрабу, выспрашивают у него всё-всё-всё, от верхнего уровня идей до неочевидных ловушек на низких уровнях, и записывают это в структурированной и регулярно обновляемой документации?
когда уходит сотрудник
...и чо?
вариант 1: Главный Начальник сдувает пыль с машины времени и заставляет "пустого" новичка, только что из HR, просмотреть в реальном времени все "митинги" с участием ушедшего. Сколько это времени займёт и какой процент этого потока слов новичок реально осознает?
вариант 2: новичку дают доступ к "гиту" и "жире" и говорят - быстро изучи всё, что сделал Вася Пупкин. Переменная количество_митингов_на_которых_послушно_ораторствовал_ушедший, при этом вообще не используется.
Все эти митинги никак не коррелируют с накоплением корпоративного знания. В лучшем случае это самообман.
насчет "бежишь как белка" - это твоё отношение. Можно ведь и по другому посмотреть.
если тебе накидали 100 задач с равным приоритетом - то это твоя свобода и гибкость. прочитать эти задачи, сгруппировать их для себя (по технологиям, которые нужно вспомнить, по модулям которые надо переписать, по соседним отделам с которыми совместно надо будет решать - как тебе удобнее). Потом берёшь одну группу, по своему выбору, погружаешься в неё один раз и начинаешь пилить "отсюда и до обеда".
конечно, 90% задач пролетают по срокам, но они ВСЁ РАВНО пролетели бы. И твоя реальная ответственность только в ВЫБОРЕ, какие из 10% НЕ будут сорваны.
Собственно, "100 задач с лопаты" это твой личный горизонт планирования себя. Когда ты просматриваешь это список, прислушиваешься к своему самочувствию, и решаешь. Сегодня я "голодный", я хочу закопаться в глубину и нахрен отрефакторить один говномодуль. А завтра я "с похмелья" и трёх переменных в голове не удержу, сделаю я лучше три мелких фикса, которые можно на рефлексах исправлять. И т.д.
Неужели было бы лучше, если бы ты с утра видел ровно две таски, о которых ты ничего заранее не знал, но которые до заката надо отресёрчить, имплементнуть, оттестить и передать в QA ?
...а потом (я из легаси) окажется, что после увеличения размеров буфера плеера у тебя печать документов на бумагу стала работать с задержкой в несколько часов. Пока не накопится документов страниц на 100 - принтер даже не начинает печатать. Ну вот так оно когда-то получилось, когда скрам и аджайл свели к "сделай просто, чтобы уже завтра продать".
нужно сначала провести ресерч, который будет содержать до половины реализации задачи
А вторая половина - это груминг. Когда задача уже решена, но надо её обмазать проверками ошибок, логированием, метриками, конфигурацией, документацией и прочей фигнёй, нужной для долгосрочного использования, но именно решением проблемы (в узком смысле) уже не являющимся.
Окончание ресёрча и решение задачи (пусть на уровне MVP) - это зачастую синонимы.
P.S. Кстати, вынесение задачи документирования в отдельный спринт/таск *не работает*.
По факту либо ты пишешь полную документацию "сразу в жиру", а весь таск сводится к "переписать из Жиры в Ворд" (но откуда тогда брать человекомесяцы на это?), либо таск на документацию отъезжает на пару лет, а через пару лет какой-то новый техрайтер - с нулевым знанием проекта - приходит разрабам (чьи мозги уже начисто промыты ещё 100500 тасками с тех пор решёнными) и говорит "ну, рассказывайте, что вы там за фигню наворотили два года назад, а я это в Word перепишу, один час вам на всё так и быть разрешу списать".
Вообще, вне всяких методологий. Даже вне разработки ПО. Обучение джунов я всегда начинаю именно с обучения декомпозиции.
То есть вы написали, что не только в геймдеве, а вообще в любой промышленности - даже где компьютеров нет вообще - скрам работает. А если скрам не работает, то причина - как вы пишете - в том, что все работнгики - низкоквалифицированные джуны, которых никто не учил ГЛАВНОМУ.
В общем-то вы проиллюстрировали тезис про "элегантный коммунизм". Который в рекламе работает везде, а после продажи - почти нигде.
Вы, видимо, не успели прочитать статью, но успели прочитать заголовок.
В статье написано
Это гарантирует, что в Steam всегда будут более низкие цены, чем у платформ-конкурентов.
Проблема известная. Конкретных цифр не помню, но выглядит он примерно так.
Условная компания Х-production делает новую игру и хочет её продавать за $75.
Она её размещает сразу в нескольких магазинах - Microsoft, Google, Apple, Steam, GoG, EPIC и какие там ещё.
Каждый магазин добавляет свой процент, за само право там продаваться, и у Valve он один из самых больших.
После того как Valve добавило свои $25 - суммарная цена стала $100. А в других магазинах наценка меньше, там окончательная цена оказалась $80 или $90. Иногда, наверное, и даже больше, чем у Valve, но такие случаи их не огорчают.
После этого магазин Valve обращается к изготовителю Х-production и говорит, что они обязаны либо задрать отпускную цену во всех остальных магазинах, чтобы там было как минимум $100, либо понизить цену для Valve, чтобы общая стоимость в Valve (с их самой большой наценкой) стала не хуже, чем в другом магазине (с разумной маржой).
Тут однако тонкость есть, "запитаем насосы от выбегающей турбины" делали на выключенном реакторе. И только половину насосов (4 из 8). При том, что четверть насосов (2 из 8) вообще не должна была работать (она всегда в резерве, как диск в RAID-6) даже при полной загрузке реактора. Так что на выключенном реакторе при эксперименте должны были работать 2/3 от охлаждения максимально разогнанного реактора.
Собственно, это уже был третий эксперимент, после 1983 и 1984. И по "самым гуманным советским законам" без успешного прохода этого эксперимента реактор вообще нельзя было запускать. Но все остальные АЭС РБМК были "под военными" (МинСредМаш), для которых официальные советские законы значили чуть меньше хорошей туалетной бумаги. А ЧАЭС была под гражданским правительством, пришлось хотя бы пытаться законы выполнять...
неолурк://мне.вас.жаль
Данных реально в статье нет.
Простой вопрос, откуда они вообще узнали, что критически важные данные когда-то там были в удалённой папке "Хлам"?
А если правду в комментах написали, что обвиняемый уволился два года назад (следовательно, и папка была удалена как минимум два года назад, или больше) - то уже два вопроса: как узнали и почему два года всем наплевать было.
Тут картинка "Здравствуйте. Мы уже почти закончили выполнять ваш прошлогодний заказ. Но не могли бы вы прислать пароль от архива с заказом?"
на пингвинах и подобных можно тогда просто какую-нибудь log-based FS поставить, из которых удаление информации технически невозможно, только добавление (хотя пользователю и КАЖЕТСЯ, что он там чего-то переписал или удалил, как на CD-R было).
Не очень понимаю кого и как может дискриминировать всемирном теневое правительство программистов. Отказать в доступе на порнхаб? Научить хомячка уклоняться от кликов? Заставить чатГПТ придумывать анекдоты тупее чем у соседа?
Ничего не имею против такой схемы, особенно если Васе дадут часы на это "делиться компетенцией", но однако причём тут всякие митболы и прочие кнедлики по скраму? Обсуждение инженерных задач инженерами происходит постоянно, без привязки к красным дням календаря и без церемоний. Кнедлики только отнимают время, которое инженеры могли бы потратить на обмен опытом.
P.S. да и РП в данном контексте едва ли относится к бизнесу, скорее это прораб, самый тёртый жизнью из программистов.
в других своих комментариях я вообще не говорил о каких-то компаниях. Кроме того, они были либо вчера, либо через хотя бы 10 минут после кармования.
Да и ваш ответ, ровно через 8 минут после случившегося кармования, красит этот сюжет в те цвета, в которые красит.
Но конечно же, это никакое не доказательство, я же сразу написал, что неизвестный паладин Valve на вас похож чисто случайно.
https://www.techpowerup.com/294750/valve-antitrust-class-action-lawsuit-allowed-to-proceed
Ну то есть "да, вы имеете право продавать игры дешевле, если вы вообще не будете продавать стим-ключи никогда и нигде". Надо просто продавать на Стиме игры без стим-ключей. Что может быть проще?
В общем как с любым запретом, вводят его под предлогом одних случаев, а наказания применяют в других случаях, "расширительная трактовка" (с).
----
https://arstechnica.com/gaming/2021/05/why-lower-platform-fees-dont-lead-to-lower-prices-on-the-epic-games-store/
А вот статья 2021 года, со стороны Valve. Евангелист Valve утверждает, что...
...производители сами поднимают цену в альтернативных магазинах, потому что хотят и жадные, а не потому, что принудили. Несмотря на то, что уже в следующем абзаце приводят игру, которую Valve запретил производителю продавать даже со своего личного сайта (разумеется, в той сборке вообще не было ни строчки кода от стима, но всё равно запрещено).
http://blog.wolfire.com/2021/05/Regarding-the-Valve-class-action
Допускаю, что с тех пор Valve стали аккуратнеe и тщательнее прописали алгоритмы lawfare. Во всяком случае в 2023 году уже появляются разговоры про действительно появившуюся разницу цен в магазинах.
https://steamcommunity.com/app/362960/discussions/0/3814033305513254085
Хабр забавное место.
За восемь минут до ответа на этот комментарий неизвестный герой, чисто случайно похожий на Grey83, плюнул мне в карму за - внимание - "распространение рекламы".
Надеюсь добровольный евангелист Valve расскажет мне кого именно я рекламировал и передаст оплату этой рекламы. Он же честный человек, да?
так чтобы понять "удобно или не удобно" - опять же требуется долгосрочная работа по реальному, каждодневному сценарию.
то, что покажется удобным, в течении 5 минут, может оказаться нифига не удобным за 5 часов. То, что кажется удобным при тестировании одной функции, может оказаться неудобно, когда надо выполнять разные функции (в том числе никак не относящиеся к изменённому функционалу).
условно, в качестве фичи для фастфуда выкатили кофе-машину, в которой оператор работает на площадке, на которую надо по лесенке подниматься. Пока оператор тестирует ТОЛЬКО изменения - всё зашибись. А вот как только из тестового контура передеплоим в боевой, где надо продавать не только кофе, - сразу становится плохо. Но в чистой теории, конечно, если покупатель выделит несколько сотрудников которые в full time будут повторять работу других сотрудников и ничего кроме этого - тогда можно и на тестовом. Либо частичный деплой, берём 5% сотрудников покупателя и переключаем их на работу с тестовой сборкой в реальном контуре.
будь оно иначе - не требовалось бы две недели на спринты давать, хватило бы полдня.
— Капитан, как скоро вы сможете приземлиться?
— Не могу вам сказать.
— Мне можно, я доктор.
— Я просто этого не знаю.
— А предположить вы не можете?
— Займёт не меньше двух часов.
— Вы так долго будете предполагать?
Первое требует второго. Хотя, конечно, второе не гарантирует первого.
"В лабораторных условиях" я и сам могу протестить, мне для этого даже и QA не нужен. А реальные задачи вне боевого не тестируются. У покупателя тоже нет лишних сотрудников, которые будут буквально повторять все реальные задачи обычных сотрудников на отдельном контуре.
...и это я ещё про "плавающие ошибки" не говорю ;-)
> что 2 недели - наиболее оптимальный срок для заказчика
...а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?
Потому что это очень сильный критерий применимости скрама.
Следовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом
немедленно
на реальных или идентичных реальным задачах
то вот и получился критерий "не тот случай"
Вы сказали, что единственная причина по которой пинают скрам, это когда пинающие не умеют в декомпозицию, и поэтому не могут заранее просчитать сложность задачи.
Других причин, кроме неумения в декомпозицию, для недовольства скрамом нет, согласно вашему тезису.
...а этот понимающий бизнес нанимает техрайтеров, которые сразу по закрытию инженерной задачи подлетают к разрабу, выспрашивают у него всё-всё-всё, от верхнего уровня идей до неочевидных ловушек на низких уровнях, и записывают это в структурированной и регулярно обновляемой документации?
...и чо?
вариант 1: Главный Начальник сдувает пыль с машины времени и заставляет "пустого" новичка, только что из HR, просмотреть в реальном времени все "митинги" с участием ушедшего. Сколько это времени займёт и какой процент этого потока слов новичок реально осознает?
вариант 2: новичку дают доступ к "гиту" и "жире" и говорят - быстро изучи всё, что сделал Вася Пупкин. Переменная количество_митингов_на_которых_послушно_ораторствовал_ушедший, при этом вообще не используется.
Все эти митинги никак не коррелируют с накоплением корпоративного знания. В лучшем случае это самообман.
англицизм это обычный профессиональный жаргон, удобный тем что отсекает лишние контексты.
англицизм - это явно прописанный namespace/scope/module.
переработка может означать что угодно, например печать газеты на бумаге из макулатуры.
а вот refactoring - это конкретно, и crunch - тоже конкретно.
насчет "бежишь как белка" - это твоё отношение. Можно ведь и по другому посмотреть.
если тебе накидали 100 задач с равным приоритетом - то это твоя свобода и гибкость.
прочитать эти задачи, сгруппировать их для себя (по технологиям, которые нужно вспомнить, по модулям которые надо переписать, по соседним отделам с которыми совместно надо будет решать - как тебе удобнее). Потом берёшь одну группу, по своему выбору, погружаешься в неё один раз и начинаешь пилить "отсюда и до обеда".
конечно, 90% задач пролетают по срокам, но они ВСЁ РАВНО пролетели бы. И твоя реальная ответственность только в ВЫБОРЕ, какие из 10% НЕ будут сорваны.
Собственно, "100 задач с лопаты" это твой личный горизонт планирования себя. Когда ты просматриваешь это список, прислушиваешься к своему самочувствию, и решаешь. Сегодня я "голодный", я хочу закопаться в глубину и нахрен отрефакторить один говномодуль. А завтра я "с похмелья" и трёх переменных в голове не удержу, сделаю я лучше три мелких фикса, которые можно на рефлексах исправлять. И т.д.
Неужели было бы лучше, если бы ты с утра видел ровно две таски, о которых ты ничего заранее не знал, но которые до заката надо отресёрчить, имплементнуть, оттестить и передать в QA ?
...а потом (я из легаси) окажется, что после увеличения размеров буфера плеера у тебя печать документов на бумагу стала работать с задержкой в несколько часов. Пока не накопится документов страниц на 100 - принтер даже не начинает печатать. Ну вот так оно когда-то получилось, когда скрам и аджайл свели к "сделай просто, чтобы уже завтра продать".
А вторая половина - это груминг. Когда задача уже решена, но надо её обмазать проверками ошибок, логированием, метриками, конфигурацией, документацией и прочей фигнёй, нужной для долгосрочного использования, но именно решением проблемы (в узком смысле) уже не являющимся.
Окончание ресёрча и решение задачи (пусть на уровне MVP) - это зачастую синонимы.
P.S. Кстати, вынесение задачи документирования в отдельный спринт/таск *не работает*.
По факту либо ты пишешь полную документацию "сразу в жиру", а весь таск сводится к "переписать из Жиры в Ворд" (но откуда тогда брать человекомесяцы на это?), либо таск на документацию отъезжает на пару лет, а через пару лет какой-то новый техрайтер - с нулевым знанием проекта - приходит разрабам (чьи мозги уже начисто промыты ещё 100500 тасками с тех пор решёнными) и говорит "ну, рассказывайте, что вы там за фигню наворотили два года назад, а я это в Word перепишу, один час вам на всё так и быть разрешу списать".
при чем же здесь пустыни? вы написали:
То есть вы написали, что не только в геймдеве, а вообще в любой промышленности - даже где компьютеров нет вообще - скрам работает. А если скрам не работает, то причина - как вы пишете - в том, что все работнгики - низкоквалифицированные джуны, которых никто не учил ГЛАВНОМУ.
В общем-то вы проиллюстрировали тезис про "элегантный коммунизм". Который в рекламе работает везде, а после продажи - почти нигде.
Вы, видимо, не успели прочитать статью, но успели прочитать заголовок.
В статье написано
Проблема известная. Конкретных цифр не помню, но выглядит он примерно так.
Условная компания Х-production делает новую игру и хочет её продавать за $75.
Она её размещает сразу в нескольких магазинах - Microsoft, Google, Apple, Steam, GoG, EPIC и какие там ещё.
Каждый магазин добавляет свой процент, за само право там продаваться, и у Valve он один из самых больших.
После того как Valve добавило свои $25 - суммарная цена стала $100. А в других магазинах наценка меньше, там окончательная цена оказалась $80 или $90. Иногда, наверное, и даже больше, чем у Valve, но такие случаи их не огорчают.
После этого магазин Valve обращается к изготовителю Х-production и говорит, что они обязаны либо задрать отпускную цену во всех остальных магазинах, чтобы там было как минимум $100, либо понизить цену для Valve, чтобы общая стоимость в Valve (с их самой большой наценкой) стала не хуже, чем в другом магазине (с разумной маржой).
Ваш капитан.