Comments 27
Выгоните уже аджайлистов и тупых менеджеров! Ну сколько можно нужные вещи выпиливать?
Выход сырых обновлений, выход сырых продуктов, неисправляемые ошибки - это всё аджайл и гонка за призрачной ценностью "непрерывной разработки продукта"
Нужен работающий продукт, а не постоянно допиливаемый в раскоряченном состоянии. Это и про ОС и про Офисные приложения. "Новый Teams" вроде как уже GA, но сих пор косячный. То календарь не интегрируется с Outlook, то в адресной вместо e-mail показывает UPN, то задалбывает пользователей своей рекламой "новых" фич, которые кроме манагеров в разработке для повышения их KPI, никому больше даром не сдались .
А аджайлисты-то тут причем?
К постоянному зуду пилить нахрен ненужные фичи к "продукту", имитируя бурную "полезную" деятельность. Боясь остаться без работы?
Это, безусловно, проблема, но конкретно к Agile она не имеет никакого отношения
Это именно прямое следствие внерения гибких методологий разработки. Цикличность, непрерывность, спринты дэйлики/виклики и всё с ними связанное. Круговая порука менеджмента и разрабов. Одним нужно постоянно что-то придумывать, другим это что-то внедрить в срок. Результат: тонна ненужных фич и якобы улучшений наклёпанные в авральном порядке, тестирование задвигается на второй план во имя сроков, а как следствие огромный технический долг и постоянные недоделки.
Вместо нормально поставленных и спланированных наперёд целей суетливое и бездумное добавление "хоть чего-нибудь" ради добавлений и демонстрации высокой загруженности. Прикольно, что высокую загруженность через некоторое время имитировать уже не приходится. Бездумно наваленные "улучшения" приводят к непредсказуемым побочным эффектам. И зачастую такой, сцуко "продукт" проще переписать с нуля, чем разгрести то, что скрумщики/аджайлисы нагородили с своей непрерывной деятельности.
В классических методологиях при неграмотном подходе ...
Ваши контраргументы сводятся к набившему оскомину "у вас неправильный аджайл/скрам". Однако весь негатив, который Вы отрицаете, вызван именно массовым культом аджайла, который удобен разработчикам и менеджерам, но не даёт удобства и преимуществ конечному пользователю, давая на выходе тотально недоделанные кривые "продукты". Им очень удобно прикрываться. Вот единственный плюс. И чаще всего он перевешивает всё остальное при выборе методологии разработки.
Есть хоть где-то примеры реально положительного результата от использования аджайла? Ну кроме "мы пахали" и "мы современная команда" и прочих понтов на ивентах.
Может пора наконец закопать эту удобную "продуктовую" идеологию и придумать что-то нормальное, без обмана потребителя и бизнеса, если он конечный заказчик?
Нет, вы не внимательно читаете. Речь о том, что если менеджеры и маркетологи идиоты и хотят творить херню и/или имитировать бурную деятельность, то они будут успешно творить херню и имитировать бурную деятельность вне зависимости от наличия или отсутствия аджайла, а вообще при любой методологии разработки.
Вот здесь как раз Вы не видите суть. Менеджеры всегда, ну хорошо, почти всегда, ищут самый лёгкий путь делать меньше, дороже и желательно чтобы была возможноть бесконечно доить заказчика. А что им лучше всего для этго подходит? Аджайл и продуктовый подход.
Суть аджайла в продуктовом подходе - бесконечно и бестолково пилить лютую дичь. Ваш пример это не продуктовый подход. Сделали рассчитались, ушли к следующему заказчику. Т.е. был конечный срок и конечная цель. Это проект, и как вы там внутри итерации выполняли и называли - мало кому интересно.
Аджайл и продуктовый подход просто подталкивают к тому, чтобы творить дичь бесконечно. И в этом качестве они больше зло, чем что-то полезное.
.. где-то возможно используя слова из аджайла/скрама менеджеры творят херню ..
Увы, не где-то, а повсеместно, за редкими исключениями. Аджайл манифест это вообще настолько размытая лажа, что толковать её можно как угодно.
Скрум - ещё большая дичь, адаптированная под максимальный доход от общения с заказчиком. Пляски и ритуалы (процессы) имеют единственную ценность на начальном этапе работ, когда происходит инветаризация ресурсов и хотелок, дальше всё превращается в красиво поданный обряд объяснения заказчику, почему он должен платить много и вечно. И не жаловаться на нынешнее раскоряченное состояние результата.
То, что вы процитировали про boundaries и goal перечеркивается дальнейшими уточнениями из того же SCRUM guide, что цели (и границы) могут (и должны!) меняться по ходу работы, а конечная дата вообще ничто, если работа идёт над его величеством продуктом.
Поэтому необходимо выкинуть и осудить текущие наркоманские определения и создать честные новые, исключающие такую лютую трактову, крайне желательно с ребрендингом.
Порядочным командам, например таким, как из вашего примера, это никак не помешает, задо выбъет из под ног почву у 99% мошенников, паразитирующих на бесконечной гибкой разработке "по Аджайлу" и со скрумом.
Linux ОС это не грозит. :)
В линукс своих косяков хватает. На волне роста популярности они поняли, что очень далеко отстали от винды и макоси в вопросах sandboxing приложений. Так что Линуксам ещё грозит волна новоиспечённых вирусов.
Да и с ядрами у них какие-то интересные отношения. Всё было хорошо и прекрасно, пока не началось 5.19. После этого все мои AMDшные лаптопы начали падать при любом вызове хоть чего-то что походило на 3д рендеринг. И валялись они до тех пор, пока не появилось 6.6.
Хотя, мне, на линуксе проще, чем на винде, я тут уже привык. Но очень не рекомендую разглагольствовать на уровне 2000х годов фразами "винда - кал, линукс - рулит".
Linux движется абсолютно тем же курсом, просто с некоторой задержкой. Там точно так же правят бал корпораты, которые просто кладут болт на хотелки пользователей и делают как им удобнее.
Последний пример - навязывание этого убогого snap в качестве стандарта. Ну какому юзеру может понравиться, что Блокнот с Калькулятором теперь по 5 секунд запускаются? Или что в браузере за пределами хомки ничего не откроешь? Или что в том же блокноте теперь не открыть ни единого файла, имя которого начинается с точки? Но разработчикам плевать, у них свои соображения, бесконечно далёкие от желаний тех, кто этим потом будет пользоваться.
они поняли, что очень далеко отстали от винды и макоси в вопросах sandboxing приложений
Для меня это прозвучало как "Самолёт, в отличие от других видов транспорта, плохо летает" Что умеют мак и винда в вопросах sandboxing?
В винде она особо не нужна, потому что там есть инфраструктура антивирусов. Более того, их псевдо-контейнеры через Hyper-V или виртуализация на основе RDP отработаны достаточно хорошо. Так же, новые приложения appx это контейнеры. Да, согласен, там в широком распростанении не густо. Но они на рынке уже не один десяток лет. Они знают что делать.
Для макоси - там всё по другому с правами доступа и установкой ПО.
Но обе ОСи достаточно древние. Естественно, всё намного "лучше" на уровне iOS и Андроида. Там песочница была почти что с начала.
У Линуха есть снап, который все ненавидят. Есть флатпак, которым никто не пользуется. Есть аппимедж, от которого толку - ноль. Но самое главное - есть иксы, которые сколько не контенеризируй на запрос хендла экрана выдают доступ ко всему экрану. Надо переходить на Wayland. Но тут тоже не всем хорошо. Там не хватает хорошего напильника.
На самом деле на десктопных осях неудобно всем. Надо сесть и разработать с нуля. Более менее такое провернуть может только макось. Все остальные должны тянуть на себе 25 лет легаси кода.
А ещё есть firejail и bubblewrap, которые вопросы безопасности отдельного пользователя в общем закрывают. Иксы это действительно дырища, но решается она не только переходом на wayland. Можно запускать отдельный Х сервер и либо показывать его на отдельный виртуальный стол (переключаться по Ctrl-Alt-F#) либо транслировать в окно.
Хотя бы в ядре возможностей огораживания всего, чего угодно, хватает. Осталось воплотить. А Android уже медленно падает жертвой своего легаси, потому что для дальнейшего (нормального) развития разрешений, начала 2010 гг., их надо бы конкретизировать (т.е. добавлять более точечные), но они этого почти не делают. Вместо этого неудобным API обрезают доступ. Например ни Termux (Android 12+ насколько знаю), ни OSMonitor (давно, не видит приложений) нормально не работают, и работать больше не будут. Потому что в случае с OSMonitor эта возможность использовалась трекинговыми приложениями для сбора данных о пользователях. Мне кажется у WebExtensions похожая назревает проблема, когда захочется других/точечных разрешений.
В целом это тема о категоризации элементов, и чем их становится больше, тем развитее должна быть система категоризации.
инструмент останется доступным в качестве дополнительной функции по требованию
То есть они хотят что бы по умолчанию *.cmd файлы перестали работать? Очень обдуманное, взвешенное и своевременное решение. Интересно сколько софта перестанет работать. Кроме самой Микрософт такую подставу никто не мог придумать. Интересно будет посмотреть развитие это триллера.
Все на месте будет.
The major known difference between legacy and current is the implementation of UTF-8. The legacy host has extremely rudimentary and often incorrect support of UTF-8 with code page 65001. The current console host contains incremental improvements release-over-release of Windows 10 to improve this support. Applications that are attempting to rely on predicting "known incorrect" interpretations of UTF-8 from the legacy console will find themselves receiving different answers as support is improved.
Как можно отказаться от поддержки VBScript? Миллионы скриптов в софте, в инструментарии админов должны пойти прахом?
Кому оно мешает?
Microsoft прекратит поддержку режима консоли Legacy в Windows 11