В условиях достижения технологических и скажем так "научных" пределов роста - после сворачивания военных баз, печатный станок США похоже скоро останется единственным оружием, обеспечивающим доминирование на шарике. Раньше, конечно кроме станка, было и определенное превосходство в высоких технологиях (в т.ч. на базе станка - скупка не только деньгами, по все миру ученых) - превосходство бизнеса обеспечивалось ИТ, да и оно само по себе работает сейчас почти как "станок"....
Но планетарные интеллектуальные ресурсы и их месторождения все переписаны и отсортированы - механизмы "охоты за головами" отлажены... на этом поле появились конкуренты и что важнее, ну не выходят новые "пулеметы" против "луков" и компьютеры против арифмометров.
Электроколяски тупо дороже и менее удобные, чем бензиново-дизельные тарахтелки, "уголь"-"газ" дешевле и проще чужетехнологичного виэ, атома своего нет, а "космический интернет" и тому подобные свистелки, по многим параметрам хуже в разы _уже_ построенной инфраструктуры и как и в случае с ВИЭ кстати имеет свою нишу именно в недопущении развития серьезной оной в странах третьего мира, о чем боссы в оном начинают догадываться.
К тому же многие технологии не только ИТ но и в т.ч. организационные (вроде объективно удачных моментов с системами стандартизации или проектного управления) в принципе не имеют защиты от копирования.
Этот вопрос уже не потенциальной, а скоро фактической потери лидерства "США" (не гос. аппарат, а реальную тусню из истеблишмента) беспокоит и они вот недавно выпустили пространный отчет о перспективах собственной (оболочки для истеблишмента в смысле) конкурентноспособности (compete.org) - слайды из него.
Первый убойный - размер инвестиций в R&D.
в принципе на нем можно было бы закончить...
но продолжим
Уплощение "рынка" - ничего хорошего
(нано игры)
Провал стартаперской истерики... не обеспечили тупицца комманды новой НТР.
Короче очевидно - кое кому нужен какой то толчок для внутренней перезагрузки. И так как "климатическая повестка" не выстрелила, цыфровизация свое отыграла еще лет 5 назад - вполне возможно вернутся к старому доброму ВПК... в новом формате конечно.
Адекватность экспериментального подхода для роста технологий.
Комментарии
Для кого нет альтернатив?
Для ангуляра в его нише.
Ты не понял вопроса. Я спросил "для кого", а не "для чего".
Для веб программистов которые тяжелые энтерпрайзные spa приложения пишут.
Я свои предложения выложил, давай тогда выкладывай альтернативы
Он - мёртв.
чего это? недавно только новая версия вышла
Это - судороги.
Да как было процентов 20 рынка, так и осталось
ангуляряс или ангуляр?
Хотя, какая разница. Они там постоянно концы грызут.
Суть, в чем его уникальность?
Не привычка говнокодера к системе, а именно уникальность? Как среды разработки так и самого языка?
Да ни в чём.
уникальность в typescripte и в том что angular фреймворк, а остальное библиотеки. Ангуляр лучше подходит для больших проектов, а на react & vue можно что-нибудь не такое большое быстрее написать.
Я прочитал ваш комментарий ниже.
Вы храбрый человек.
американский ли?
Софт это инструмент который позволяет железу и всякой продукции выполнять всякие фентифлюшки. Софт не самоценен. Физическая продукция самоценна. И при желании может обойтись без софта. Значимость программного обеспечения мягко скажем завышена. В основном благодаря безумной пропаганде "цифровизации". Что вводит в заблуждение всяких юнцов по поводу получения профессии "программист". Научится кодить алгоритмы может да же аутист (из них не плохие кодеры получаются, к стати). А вот провести аналитику и поставить задачу, вменяемых людей днем с огнем не найдешь.
"Железо" без "софта" - кирпич. В прямом смысле слова. Причём хреновый такой кирпич.
Анализ - операции мысленного или реального расчленения целого (вещи, свойства, процесса или отношения между предметами) на составные части, выполняемая в процессе познания или предметно-практической деятельности человека.
Аналитика - часть искусства рассуждения (логики), рассматривающая учение об анализе.
дык, вспомним историю, когда понятие "инженер" девальвировалось до подмастерья. То же самое ныне и с понятием "программист". При том что подход-то за пару столетий не поменялся, 80+% качества (и соответственно успеха) проекта зависит от качества проектирования. Если присмотреться, то и иерархия в нормальных рабочих группах разработчиков подозрительно напоминает армейскую.
далеки вы от программирования, уже давно вместо водопада скрамы используют.
Там где испольщуют скрамы и обходятся без дизайна получается полный срам.
Глючное и тормозное… как бы без мата… добро, которое живёт только за счёт Закона Мура.
Как только Закон Мура кончится (а вечно он продолжаться не может) — эта культура посыпется.
При чем тут закон мура и скрам? Закон мура обходится многопоточным программированием и процессором с несколькими ядрами. Где там проблема? Смысл аджйлов - не программировать то что возможно не понадобится.
Смысл аджайлов — отказаться от планирования и дать заказчику “свободу”.
Как если бы вы строили небоскрёб, постоянно двигая лифты, переставляя унитазы и раковины с места на места каждый день, пристаивая и разрушая разные проходы и так далее.
Знаете, что получится в результате? Руины. Замок Хаула, в лучшем случае.
И вот ровно такой же ужас получается в результате аджайлов и скрамов.
Поскольку все эти аджайлы приводят к непрерывному добавлению всё новых глюков, а для их исправления вбиваются всё новые костыли (условно: когда после 100500го переносам унитаза и питьевого фонтанчика у вас объединяются в единое целое водопровод и канализация в технологиях аджайла ставится сепаратор, вместо редизайна системы… после этого вода в фонтанчике “немного” пахнет, но продажники могут объяснить заказчику, что так и надо, это потому что “зелёная” вода так и должна выглядеть и пахнуть)… всё это работает пока удаётся вашу всё более уродливую и более глючную поделку заставить работать на стоящем те же деньги железе. А для этого стомость вычислительных ресурсов должна всё время падать.
Вы, наверное, не в курсе что такое Закон Мура. Многопоточное программирование и процессор с несколькими ядрами — это следствия из Закона Мура и использование Закона Мура.
И только они позволяют как-то продавать всё более ресурсоёкие и глючные продукты, решающие те же задачи (плюс-минус), что и 10 или 20 лет назад (новые задачи, которые 10-20 лет назад решить было нельзя решаются без всего этого… если ваша задача реально требует всех ресурсов, которые есть у современного “железа”, но никакой аджайл вы не можете применить… оно просто работать, с приемлемой скоростью, не будет.
Типичный пример: когда у нас тут отвалился нормальный интернет, то на полу-3G я мог смотреть видео и даже участвовать в видеоконференциях — но поставить лайк на YouTube было невозможно, так как какие-то скрипты не успевали прогрузиться и отваливались по таймауту. Вот это вот — результат аджайла, скрума и прочих баззвордов из той же серии.
P.S. Меня, кстати, удивляет что здешние марксисты не показывают на аджайл как на “отрыжку капитализма”: это же перевод ресурсов в никуда, вот совсем в никуда — в чистом виде. И хотя я понимаю, что эта деятельность, всё же, не вполне бессмысленна, кой-какие полезные вещи оттуда таки рождаются, но для думающего человека — это довод куда как более сильный, чем все эти условные “яхты Абрамовича”. На которые, на самом деле, уходит куда как меньше ресурсов.
нет не так, смысл не делать ненужного, а в ситуации сложности прогнозирования будущего, дать возможность заказчику как можно раньше "попробовать" продукт и вносить корректировки быстрее чем это бы произошло в сравнии с водопадом.
оффтоп: Вы, наверное, еще в этом году не решили где отпуск проводить, а хотите, что бы заказчик вам точно 5летний план в виде ТЗ выложил прям сейчас.
Если вы ссылки приводите, так читайте до конца
Почему производители делают многоядерные процессоры - потому что как раз с одним ядром они уперлись в физические ограничения.
Как раз аджайл и сращивается с lean & kanban- ом. Которые в свою очередь и постулируют, что не нужны запасы, а нужно делать, только то что нужно.
So VIEL WIE NÖTIG, SO WENIG WIE MÖGLICH
Пипец у тебя каша в голове.
Человек выше всё правильно расписал, а ты просто наслушался современных и эффективных манагеров гугеля и иже с ним.
конкретнее можно, если нормально опишите, то соглашусь возможно
А зачем это нужно? Цель какая? У заказчика через неделю вырастут крылья или хвост? Что поменется-то? Откуда у вас взялась эта сложность прогнозирования в таких масштабах, что даже на полгода вперёд вы ничего спрогнозировать не можете?
Великолепный пример! И очень “в тему”, на самом деле. Разумеется где и как я буду проводить отпуск я решал в прошлом году. И апартменты у меня, разумеется тоже были забронированы в прошлом году. Визу, правда, моя сестра, с которой мы будем вместе отдыхать, пока не сделала, что меня немного напрягает… но последние два года какие-то скомканные, коронобесие и всё такое.
5летний план, наверное, в современных условиях, всё же перебор, но если речь идёт не о программировании, а о чём-то другом (скажем рекламная компания или там, банальная перепланировака помещения магазина), то сроки планирования месяц в три — считаются нормальными. Если что-то более серьёзное, какой-нибудь мостик к магазину пристраивается, то может и лет пять это занять. Спокойно обсуждается что и как будет устроено, где, после перепланировки будет лестница, а где лифт…
И только в программировании происходит, в соотвествии с новыми модными веяниями, какая-то дикая движуха ради движухи.
Совершенно верно. Но мы всё равно имеем всё растущую можность. Которую можем “сливать” в бесконечную “движуху”.
Да, мы больше не имеем возможности, когда то, что мы породили, начало тормозить, компенсировать это просто процессором со вдвое большей тактовой частотой (как было в 1995м, когда scrum только появился), да, увеличение ядер процессора уже не до конца компенсирует все проблемы, создаваемые “современными методами разработки”… но пока ещё кое-как, на Закон Мура действует. Так что новые ресурсы (тратящиеся на неэффективносто порождаемого аджайлом… добра) всё ещё появляются.
Потому он, собственно, и имеет шанс продержаться ещё какое-то время.
Постулировать можно что угодно. Но для того, чтобы увидеть чем всё это кончается — не нужно ведь быть большим специалистом.
Сравнить устройство с несколькими килобайтами оперативки и канал на 2.4Kbit/s с каналом на 10MBit/s может любой человек умеющий в арифметику.
И мощности серверов и мощности терминалов выросли на 4-5 порядков (в десятки и сотни тысяч раз), но если сравнить время реакции системы на действия пользователя с тем, что имелось полвека назад… то хорошо если разница будет на порядок.
А если использовать “устарвешую технику” (всего-то в тысячу раз быстрее, чем в те времена), то оно всё будет ворочатся гораздо медленее, чем даже первая версия “Сирены”…
А какие особо новые фичи, которые было бы невозможно реализовать в “Сирене”, получил пользователь?
P.S. Кстати я могу описать несколько фич, которые реально важны в современном мире и которые реально требуют что-нибудь типа 10-20Kbit/s и памяти где-нибудь в несколько мегабайт. Но только это где-то 1% мощности современны самых слабых систем. Остальное — чистая плата за аджайл. Где вы, типа, не делаете того, что вам не нужно… да-да, все прям поверили.
ну слету..
1. например, законы меняются, тот же dsgvo - переделка под требования заняли по времени примерно полгода работы отдела, с одной стороны транзакции должны остаться в системе 10 лет, потому что покупки, с другой стороны пользователя надо удалять по требованию, значит все надо анонимизировать, плюс автоматическая выдача всей инфы что хранится по пользователю, удаление по запросу и т.д.
2. Удобность программы для заказчика - удобность в этом случае и эргономичность и скорость работы пользователя.. Пример, первоначально заказчик думает, что ему нужен один flow для создания, например, контракта на страховку, потом понимает, что очень неудобно и придумывает другой.. быстрее увидишь ошибки, быстрее исправишь, меньше переделывать.
По поводу остального:
С ростом сложности и тормознутости программ не могу не согласиться это и так всем понятно.
Непонятно, ваше предположение, что аджейл автоматически плохой код, а значит водопад автоматически хороший.
Книжка "смертельный марш" и понятие Штурмовщина еще до всякого аджайла появились. (в том смысле, что народ гнали быстрее писать код, чтобы успеть к сроку, забив на качество)
Я бы сказал, что производительность падает, потому что растет количество уровней абстракций между железом и пользователем.
Страну, где законы меняются каждую неделю — в студию.
У нас примерно столько же заняла адапация под Arbeitszeitgesetz. Причём, что самое смешное, тул для учёта уже был в Швецарии, его нужно было только адпатировать.
Но при этом знаете что? Те же самые полгода, подобное исправление заняло бы без вских сдендапов, синкапов и TDD.
У нас в школе за два месяца практики группа школьников создала программу для создания школьного расписания. Без всяких современных технологий, под руководством учителя программирования.
На банальном Turbo Pascal.
Ага. Только вы, наверное не видели почти физическую боль, которая читалась в глазах бухгалтеров, когда их чуть не под дулом пистолета заставляли отказаться от бухгалтерии под DOS и перейти на 1C под Windows.
А, казалось бы, мелочь какая: переход между полями теперь не через Enter, а через Tab.
Только это для вас это мелочь, а для них это обозначало, что они теперь не могут одной рукой вводить данные в комьютер, а другой - работать с документами. Или с калькулятором (да, физическим, Citizen, с большими кнопками).
А ещё иногда что-то делалось только мышкой, с клавиатуры — что тоже, поняно, отдельная боль.
Где я это сказал? Жуть-кошмар можно с помощью любой технологии сотворить.
Но аджайл загоняет вас в рамки “малых итераций”. Которые некоторые вещи не позволют сделать в принципе, а некоторые — оказываются черезмерно сложными.
В резульате получается попытка создать идельный автомобиль… играясь цветом фар и формой дверей. А колёса будут квадратными, потому что менять их не позволяет фреймворк, так что смиритесь.
Ну да, только аджайл превращает Штурмовщину из того, что у вас случается в конце месяца, в то, что случается раз в неделю (а в особо запущенных случаях и ежедневно, я такое тоже видел).
Разработчики, в этом случае, обычно избегают выгорания путём избегания, всеми способами, измнений, который могут потребовать серьёзно изменить дизайн и конценрируясь на всякой фигне, которые, по большому счёту, ни на что не влияет.
Собственно весь аджайл был разрабоан, чтобы решить проблему айсберга:
Вот зачем нужен RAD и вся всё, что с ним связано. Понимате, да? Весь аджайл, изначально, был предназначен для отвлечения заказчика: пусть клиенты изливают свои дизайнерские потуги делая какие-то безвредные вещи вроде изменения своего мнения 200 раз о том, нужно ли использовать для столешницы итальянский гранит или мексиканскую плитку, или норвежскую древесину.
Но, постепенно, выросло поколение разрабочиков, которые этого не понимают, и, более того, пытаются применять аджайл для решения каких-то реальных проблем.
Аджайл для этого не предназанчен и никогда не был предназначен!
А количество уровней абстракции растёт, потому что аджайл цветёт и пахнет. И всё больше средств и сил уходит на то, что, в принципе-то, должно было быть всего лишь отвлекающим манёвром!
я не говорил про недели, тот же водопад, ну вот прикинем, на разработку надо года два работы программы, тоесть надо написать ТЗ которое следующие 2 года + еще пару лет сможет работать без изменений. Вы же не будете вносить изменения по ходу проектирования, это же уже аджайл получается. Думаю есть достаточно стран у которых в течение 4 лет могут изменятся законы или у фирм бизнес модели.
я в юности тоже писал на 1С, так что понимаю. Только заметьте, что под DOS это была самописка, которую поддерживал один программист, и реагировать на изменения законодательства ему было очень сложно.(участвовал в переводе нескольких таких на 1С) (тут я про РК, как в России не знаю)
про все остальное, работал и по waterfall и по аджайлу, все зависит от проекта, где-то клиент сразу может дать ТЗ на год вперед, где-то даже не понимает поначалу что он собственно хочет. Мне, наверное, повезло и менеджеры у меня в 90 процентов случаев были адекватные и не гонялись за цветовой гаммой.
Наверное нужно различать, коробочную разработку, продуктовую и внутреннюю. При внутренней когда пишешь, для своих же коллег из других отделов, то как-то со всеми перечисленными проблемами не сталкиваешься.
Отчасти да, количество абстракций растет, чтобы продукт быстрее писался. Гнать код и по любой модели можно. Таже ява.
Короче, работал там и там, метод разработки зависит от проекта, качество кода зависит от времени выделенного на повышение качества кода и от опыта программистов.
А затянуть гайки можно и по той модели и по этой.
Это с какого перепугу? У вас что — раз водопад, так обязательно два года? Почему? Зачем?
Водопад может и месяц потребовать и 20 лет. В зависимости от того, что мы разрабатываем.
Небоскрёб дольше строить, чем будку для собаки.
Впрочем на 20 лет лучше не закладываться, требования могут быстрее поменяться.
Хотя если мы разрабатываем софт для какой-нибудь космической или атомной программы…
Аджайл получится, если вы заложились на полгода, а через месяц прибегает менеджер и требует, чтобы вы показали клиенту как у вас небосрёбе работают лифты и удобен ли переход между чётными и нечётными этажами. И в ответ не резонное замечание, что у вас ещё пять месяцев в запасе и вы лифты ещё даже не заказывали — устраивает истерику.
Только не чтобы быстрее писался, а чтобы быстрее показывался. Это разные вещи.
В большинстве случаев аджайл — он даже не для заказчика, а для менеджера.
Который тоже нифига не понимает в разработке и тоже оценивает её по пикселям… но которому нужно отчитываться перед таким же точно начальством.
А что в итоге продукт будет делаться дольше и будет хуже… так какая нафиг разница менеджеру-то?
Ему за выполнение KPI платят, а не за качество конечного продукта.
Это с какого перепугу? У вас что — раз водопад, так обязательно два года? Почему? Зачем?
Водопад может и месяц потребовать и 20 лет. В зависимости от того, что мы разрабатываем.
Небоскрёб дольше строить, чем будку для собаки.
Впрочем на 20 лет лучше не закладываться, требования могут быстрее поменяться.
Хотя если мы разрабатываем софт для какой-нибудь космической или атомной программы…
Аджайл получится, если вы заложились на полгода, а через месяц прибегает менеджер и требует, чтобы вы показали клиенту как у вас небосрёбе работают лифты и удобен ли переход между чётными и нечётными этажами. И в ответ не резонное замечание, что у вас ещё пять месяцев в запасе и вы лифты ещё даже не заказывали — устраивает истерику.
Только не чтобы быстрее писался, а чтобы быстрее показывался. Это разные вещи.
В большинстве случаев аджайл — он даже не для заказчика, а для менеджера.
Который тоже нифига не понимает в разработке и тоже оценивает её по пикселям… но которому нужно отчитываться перед таким же точно начальством.
А что в итоге продукт будет делаться дольше и будет хуже… так какая нафиг разница менеджеру-то?
Ему за выполнение KPI платят, а не за качество конечного продукта.
ну так проекты минимум по 5 лет живут, вот я и исхожу из того, что нормальный проект это минимум два года разработки, плюс минимум еще 3 года работы без изменений.
тех проектах где я участвовал по 15 лет жили и более.
ну да давай те возьмем крайний случай, тоесть вы утверждаете на с вебприложение можно написать за то же время что и на с#
обсуждать кривых менеджеров не буду, это частные случаи
я только не понял, что вы вменяете в вину аджайлу, неоптимизированный код(что проверется профайлером и особомедленные места потом оптимизируются) или технический долг (тоесть грязный, нелогичный и непонятный код)?
Проекты могу и по полвека жить. Но новые версии вполне себе могут выходить раз или два в год. Вот создание новой версии логично организовать как водопад. Не меняя планы каждую неделю или, тем более, каждый день.
А почему не на brainfuck? Или в машинных кодах?
Когда вы сравнивает написание приложения на с и на c#, то вы, внезапно, сравниваете языки и наборы библиотек, а не стили разработки.
Ммм… как бы попроще объяснить…
О! В точку. Вот именно это.
Типичное аджайл приложение устроено примерно так: “наша гибкопочта, для того, чтобы удовлетворить все пожелания заказчиков, имеет обширный набор коробок… во Владивостоке, весов… в Нью-Йорке, операторы, знающие массу языков… сидят где-то в Индии… и разные виды почтовых марок… в Рио-Де-Жанейро… мы можем удовлетворить все ваши пожелания, а парк самолётов мы собираемся вскоре заменить на гиперлупы, так что всё станет работать очень быстро”. Вот только гиперлупь не гиперлупь, а если у вас коробка с товаром пересылается из Владивостока в Нью-Йорк, а потому, через Дели, в Рио-де-Жанейро, то всё это будет медленнее, чем если бы вы всё разместили в одном месте.
Это собственно основаная беда: чтобы “быстро итерироваться” аджайл, под лозунгом “преждевременная оптимизация — корень всех зол” порождает, как правило, настолько дико неэффективную архитектуру (с точки зрения использованных структур данных), что смысла в запуске профайлера нет, обычно, никакого. Ну ускорите вы то, что вы сотворили раз в 10. Ну будет оно работать не в десять тысяч раз медленнее, чем могло бы, а в тысячу… это такая большая разница?
Бедный Кнут! Это надо же — так извратить весь смысл его высказывания. Вы не забыли про что вообще шла речь в статье, откуда эту цитату выдрали? А чему эта статья была посвящена — помните? Нет? Так я вам напомню: там речь шла о ”раскручивании циклов” (ручном, так как компиляторы тогда этого не умели). И там же был критерий: “в развитой инжереной дисциплине улучшение в 12%, легко получаемое, никогда не рассматривается как несущественное — и я верю, что подобный же подход должен возобладать и в програмимровании” (“in established engineering disciplines a 12 % improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering”).
В этом основная проблема. Инструмент, предназначенный, в общем-то, для очень мелкой части задачи (убеждения заказчика в том, что ваше мнение очень важно для нас) — превратили в основной инструмент разработки.
Ну как если бы кондитеры свои пирожные, вместо того, чтобы печь в печи, стали пытаться формировать из шприца, которым они разные интересные узоры на тортиках рисуют.
Получилось бы и невкусно и дорого.
Прежде всего проблема аджайла в том, что он порождает много ненужного кода. Вот в принципе ненужного. Вы не можете от него избавиться, потому что клиент же может в любой момент опять попросить “перенести унитаз со 101го этажа, где у вас бассейн в подвал, где у вас ветолётная плошадка”!
Понимаете, да? Алжайл невозможен в том случае если у вас архитектура приложения близка к оптимуму! И чем больше вопросов вы решаете через алжайл — тем менее оптимально у вас приложение.
И нет, никакой профайлер вам не поможет, если проблема в слишком большом количестве слоёв.
Это добавить ещё один слой просто. А вот извести… часто проще всё заново написать. Код современные компиляторы более-мене неплохо изводят. Но аджайл приводит к совершенно диким струкурам данным! А с этим ни профайлер, ни компиляторы не могут сделать ничего.
Вот вы сделаете оптимизированную систему по водопаду на pl/sql, а потом через пару лет придет заказчик и скажет, что оракл дорого и надо переходить на mssql и все ваши оптимизации на которые вы потратили кучу денег - коту под хвост. Правда так редко бывает, но вот частый пример, переписывание с win-app на web-app и половину приложения сразу выкинуть можно, плюс вся оптимизация запросов, тоже скорее всего переписываться должна и т.д. Жизнь такая, отсутсвие аджайла не спасает от реальной жизни.
то, что сегодня оптимум по требованиям, завтра, при изменении требований, становится тормозом для дальшейшей эволюции системы.
Я, конечно, понимаю ваше желание, написать один раз хорошо и забыть, но так не бывает.
рефакторинг. все зависит как себя команда поставит. если будет продавливать рефакторинг и менеджер адекватный, то все работает нормально.
Если “так не бывает”, то откуда все эти рассказы, что такой-то и сякой-то закон очень дорого встанет банкам, потому что COBOL-программисты дорого стоят?
Так не то, что “бывает”, ещё не так давно мало кто задумывался о том, что может быть иначе.
А зачем вы переписываете win-app на web-app? Если нужна поддержка мобильников, можно сделать ещё один апп.
И в любом случае win-app никакой аджайл в web-app не превратит. Максимум чего вы можете сказать "а сейчас мы всё перепишем на angular — и через 10 лет, на всех платформах, по прежнему, всё будет работать…” — только это будет неправдой. Даже если через 10 лет и будет существовать agular, то это будет, скорее всего, другой angular, несовместимый с сегодняшним.
Отсутствие аджайла не спасает от необходимости те или иные компоненты переписывать, это правда.
Но если не заниматься “камланием на KPI”, то в очень многих случаях будет дешеле и проще взять самую дубовую, самую древнюю технологию — и всё переписать.
Только это рефакторинг, в конечном итоге, съедает столько ресурсов, что дешевле и надёжнее написать десять независимых версий того же приложения.
Бесплатных завтраков не бывает, за гибкость (и возможность в любой момент глянуть на версию в разработки и понять “как у нас идут дела”) нужно платить. Либо программистам, либо за более дорогое железо… а часто и то и другое сразу.
P.S. Самый разумный полход к аджайлу вы можете увидеть в реальных физических предметах. Где одна и та же модель автомобиля или телефона предлагается с массой разных опций ничего, по сути, не меняющих. А что-то реально сильно меняющее в железке — либо вообще никак, либо за очень, очень большие деньги. Если вы забудете про все маркетинговы слова типа “flow” и поймёте, чо весь аджайл нужен для того, чтобы повышать чувство собственной важности заказчика… то можно найту достаточно ручек, за которые он будет дёргать, видеть что картинка меняется… и будет счастлив до усрачки. Дайте же заказчику, наконец, купить для своего телефона чехол с заячьими ушками — и закройте на этом весь аджайл.
чтобы проще было разворачивать новые версии приложения.
если не запускать технический долг и нормально выстраивать границы, то все можно нормально сделать
Просто, похоже, вы не умеете в аджайл.
Гениально! А пользователи вас об этом точно просили? А сделать так, чобы приложение само обновлялось — не достачно? Chrome — может, MS Office — может, Photoshop — может, вы — не можете? Почему?
Нормально… для кого? Для менеджера? Да, наверное. И, в случае, когда вам ничего кроме KPI, не интересует — аджайл, в принципе, работает.
Но дальше-то что? Думаете лафа, когда компании могут работать себе в убыток (а это почти все западные компании) продлится вечно?
Кстати, да, простой и невинный вопрос "что же такое архитектура?" тоже может вскрыть нехилый пласт непонимания, для работ в консерватории.
ну так проекты минимум по 5 лет живут, вот я и исхожу из того, что нормальный проект это минимум два года разработки, плюс минимум еще 3 года работы без изменений.
тех проектах где я участвовал по 15 лет жили и более.
ну да давай те возьмем крайний случай, тоесть вы утверждаете на с вебприложение можно написать за то же время что и на с#
Есть же backlog, что реализовано, а что нет видно сразу, так-что менеджер просто отправляется подальше и все. вы менеджерам прям какую-то внеземную власть приписываете. просто их надо правильно дрессировать.
я только не понял, что вы вменяете в вину аджайлу, неоптимизированный код(что проверется профайлером и особомедленные места потом оптимизируются) или технический долг (тоесть грязный, нелогичный и непонятный код)?
Проблема аджайла как раз в этих “частных случаях”.
Вот только аджайл этого не допускает. Нужно, чтобы было видно не на backlog'е, а на экране! Чтобы пиксели менялись!
Если я, скажем, меняю способ генерации отчётов — то, по аджайл, я не могу генерировать впомогательные процедуры пару месяцев, а потом, наконец, собрать всё вместе — и закончить работу.
Нет, я должен как-то выкрутится так, чтобы какие-никакие отчёты появились через неделю-другую, потом заказчик на это посмотрит и 20 раз передумает… а когда, наконец, получится что-то, что его устроит — то мне дадут недельку на работу с профайлером… а потом попросят перевернуть с ног на голову ещё 3-4 раза…
Почему, блин, когда речь идёт о создании, ну, не знаю, гаджета какого-нубудь — то из папье-маше делают массо-габаритные муляжи… но никому и в голову не приходит, что этот муляж можно продавать вместо гаджета? Почему в программировании это считается нормой?
Вы же в Германии живете, разве вам ни разу не попадались нормальные менеджеры?
не знаю, не сталкивался с таким, возможно, это особенности вашей работы, возможно вы консультантом работаете, я работаю над "внутренними" проектами, возможно поэтому у нас проще
Попадались и попадаются. В Германии я, собственно, ни с какими аджайлами и скрумами не сталкивался.
Ну если у вас нет вот этих вот митапов и стендапов, то какой же это аджайл? Если вы сначала планируете, потом делаете? Чем это не водопад?
что мешает делать "внутренние" проекты по аджайлу, есть у нас и митинги и ретроспективы, код ревью, и обсуждения.
Заказчик (менеджер) накидывает в backlog, на митинге раз в месяц вытаскиваем оттуда таски и распределяем, кто что делает, Потом, в конце спринта, таск закрываем и отправляем на тестирование, потом в продакшен.
Ничего не мешает. Это вообще — вообще идеальная ситуация для аджайла.
Совершенно верно. Бабло — пилится, премии менеджеру — платятся, а что там реальные пользователи думают — вообще неважно, так как они ж никуда с подводной лодки не денутся, какой софт им поставили — с тем и будут работать.
Если раз в год что-то сделали такое, что пользователям понравилось — то и хорошо.
если реальным пользователям не нравится они уходят к другому поставщику.
А вот фиг. Реальные пользователи (радовые работники) могут ваше творение ненавидеть всеми фибрами души.
Но если человек, который платит деньги (но с приложением сам не работает) доволен (а он доволен, ваш же менеджер может столько красивых картинок показать, объяснить, что вы не зря хлеб едите) — то вам ничего не угрожает.
Собственно засилье аджайла оттуда и пошло: из странной ситуации, когда работают с продуктами — одни люди, платят за всё это — другие люди и никого, на самом деле, не волнует эффективность всего этого, так как прибыли порождаются на бирже, а не в той деятельности, которую ведёт фирма.
Ниже я уже писал, наши непосредственные клиенты, кто работает с программой, это независимые страховые маклеры. Их вроде как 20к рабочих мест. Но так как их много, то задачи ставит наш внутренний проект менеджер, который разбирается в области. Если маклеру не нравится уровень услуг, то он легко может уйти к другому поставщику.
А много их, этих поставщиков-то? А кто-нибудь из них ещё поставляет традиционные приложения?
Или у них как в давней рекламе: при всём богатстве выбора — альтернативы нет?
Вполне может быть ситуация как у Microsoft: даже после более, чем 10 лет издевательства над офисом его всё равно покупают, так как документы-то открывать как-то нужно… а совместимость фиговая даже между разными версиями MS Office, про разные другие программы — так и вообще лучше помолчать…
Но да, то, что вы, когда-то смогли убедить пользователей уйти с номальной, отзывчивой программы на… мат запрещён… — это круто.
Хотя я, когда-то, сам ушёл с Eudora Mail на GMail. Уж больно у него был хорош поиск… а сейчас уж и не осталось приличных оффлановых клиентов… хотя надо глянуть на Thunderbird…
Конечно есть, периодически уходят, иногда приходят. Про традиционные приложения не скажу, но, наверное, кто-то поставляет. Это же надо рынок мониторить.
Поищите
Versicherungsmakler Software zur Kundenverwaltung für Versicherungsvermittler
куча их
Интересно. Было бы неплохо поговорить, что их реально заставляет это делать.
Я сам пользуюсь ровно одним Web-приложением по своей воле: GMail.
И не потому что мне нужна хоть одна фишка, которую они добавили в последние 10 лет, а потому что у них поиск быстрый и надёжный, у оффлайновых клиентов так не получалось раньше.
Интересно, что заставляет пользователей вашего изделия его пользовать…
P.S. А глянуть на Thunderbird, кстати, интересная мысль. Вполне может оказаться, что в современной системе на SSD поиск не будет так тормозить, а избавиться от диких тормозов GMail было бы неплохо… хоть какая-то будет пользова от этой дискуссии.
Ответ тут простой. Maklerpool.
https://de.m.wikipedia.org/wiki/Maklerpool
Но тут вы правы, некоторые пулы предлагаю winapp. Некоторые оба варианта.
Чем завлекают - величина провизиона.
И какое к этому всему отнощение имеет аджайл? В смысле: зачем каждую неделю что-то менять?
В моём случае единственное аджайл-приложение, которое я сам выбирал привлекло меня фичей, которая никакого отношения к аджайл не имеет и за последние лет 10 не поменялась.
Всё что в GMail аджайл-наворотили — скорее было минусом (которому, правда, не удалось меня заставить отказаться от этого ужаса… хотя подумываю об этом всё чаще, в последнее время).
Есть уверенность, что в вашем случае это не так?
Ну к примеру, меняются стандарты общения со страховками. Они свои интерфейсы меняют, нам тоже надо подстраиваться. Плюс новые фишки менеджер придумывает. Проекту уже куча лет.
Может нам стоит определиться с понятием, что такое аджайл. А то ощущения, что мы разное под этим пониманием.
Страницы