470 ответов в теме

[Aurum_Gallente]

осторожно мат

Спойлер

[Neurox]

Нет картинки

[Jack Hareka]

вот что там:

Спойлер

[Tanhausser]

Интеллектом хлеба и наглостью вороны. Золотые слова

[Tanhausser]

[Tir]

Спойлер

Остро не хватает озвучки голосом Дроздова.

[Gwyn'bleid]

Мужики!

а кто рубит в asp.net web forms ?

есть срочное деловое предложение ) надо небольшую задачку за денежку сбацать.

[Ali On]

открою маленький секрет, длину спринта можно менять, а не брать как в учебнике написано. и не обязательно делать релиз в конце спринта. его можно делать раз в X спринтов. те кто говорят что аджайл надо делать как написано в учебнике, не понимают смысл аджайла.

 

Да это не секрет. Только мне проще забить и лидить команду как мне удобно и танковать их хотелки лицом, вместо того, чтобы бегать кругами и объяснять менеджерам/заказчикам за аджайл и его применение. Особенно, в n-ный раз.

[euroUK]

У аджайла есть одна цель. Аджайл=гибкий. То есть, это подстройка под хотелки заказчика. Если ты полгода пилишь и никак не допилишь, то это не аджайл. Цель аджайла - дать минимальную функциональность, проверить идеи, исправить, если плохо, нарастить мяса, если все работает.

 

Продут, выпущеный по аджайлу, рано или позно начинает переписываться системно. Нормальное место применения аджайла - стартапы, где через полгода твой код уже не нужен будет никому, если ты его сейчас не сделаешь. Плохое место для аджайла - банки и энтерпрайз. Если люди в десятки человек не могут описать нормально задачу, то это проблема людей. 

этап интеграции с разными системами занимает пару дней разве что для простенького сервиса на локальной машине девелопера. в реальности она занимает дольше так как мало написать свагер, нужно еще сделать чтоб бекенд работал и обслуживал запросы этого сгенерированного клиента корректно. ну и собственно внутреннюю бизнес логику клиенту тоже ты никак не сгенерируешь.

 

я тебе скажу по секрету что куча непонятной фигни не только в российских банках. и написана эта фигня была за последние 30-40 лет именно теми людьми которых ты нам тут рисуешь как профессионалов которых больше нет.

 

Когда я говорю про решения энтерпрайз уровня, у которых есть несколько архитекторов, я предполагаю, что API для интеграции предусмотрен сразу, на этапе разработки системы. Это мог быть wsdl или swagger, но бэкэнд должен быть, равно как и документация.

 

Что касается фигни, написанной теми, кого больше нет. Не было 20-30-40 лет назад тех технологий, которые есть сейчас. Люди пытались использовать COM+ для абстракций, но это был ад и отрасль была не готова. Нормальные люди уже давно переписали свои кор -системы. Только вот проблема в том, что манагеры от ИТ не видят смысла в переписывании "работающих систем", поэтому прикрепляют костыли вместо переделки сути. Именно поэтому в банковской отрасли так мало настоящих спецов, ибо там правят бал "финансисты"

[Timbldorf]

 

Продут, выпущеный по аджайлу, рано или позно начинает переписываться системно. Нормальное место применения аджайла - стартапы, где через полгода твой код уже не нужен будет никому, если ты его сейчас не сделаешь. Плохое место для аджайла - банки и энтерпрайз. Если люди в десятки человек не могут описать нормально задачу, то это проблема людей. 

...

 

 Только вот проблема в том, что манагеры от ИТ не видят смысла в переписывании "работающих систем", поэтому прикрепляют костыли вместо переделки сути. Именно поэтому в банковской отрасли так мало настоящих спецов, ибо там правят бал "финансисты"

 

Еврик, я б тебя заплюсовал до нейтрального стендинга (в т.ч. и за тему про увольнение Лилу.. лол) да не дают-с )

беда только в том что траблы не только в банковской отрасли. Весь IT теперь работает от "финансистов", в т.ч. и игрострой, который теперь клепает "коммерчески успешные" продукты.

[diniaprapor]

беда только в том что траблы не только в банковской отрасли. Весь IT теперь работает от "финансистов", в т.ч. и игрострой, который теперь клепает "коммерчески успешные" продукты.

Ты живешь в каком-то пониленде, где IT проекты хороши просто как вещь в себе, и главная цель сделать их красивыми и органичными. Обычно цель организации это все-таки заработать, a IT просто инструмент для этого. В случае IT стартапов это основной инструмент, и есть больше мотивации содержать его в чистоте и порядке. В случае банков, заводов и прочих производств это средство для поддержки основной деятельности, и на него выделяется столько ресурсов, сколько руководство считает нужным.

Следует просто осознать свое место в пищевой цепочке и перестать думать что весь мир что-то должен айтишникам просто за то что они есть и умеют в эджайл и фреймворки. 

 

Что касается игростроя, то там как раньше, так и теперь есть издатели гиганты у которых основная цель деньги и инди разработчики которые вкладывают больше души в свои поделки (но тоже хотели бы есть хлеб с маслом, а в идеале и с икрой). Просто индустрия чуть больше созрела и усовершенствовала способы отьема денег у населения. 

[Timbldorf]

Ты живешь в каком-то пониленде, где IT проекты хороши просто как вещь в себе, и главная цель сделать их красивыми и органичными. Обычно цель организации это все-таки заработать, a IT просто инструмент для этого. В случае IT стартапов это основной инструмент, и есть больше мотивации содержать его в чистоте и порядке. В случае банков, заводов и прочих производств это средство для поддержки основной деятельности, и на него выделяется столько ресурсов, сколько руководство считает нужным.

Следует просто осознать свое место в пищевой цепочке и перестать думать что весь мир что-то должен айтишникам просто за то что они есть и умеют в эджайл и фреймворки. 

 

Что касается игростроя, то там как раньше, так и теперь есть издатели гиганты у которых основная цель деньги и инди разработчики которые вкладывают больше души в свои поделки (но тоже хотели бы есть хлеб с маслом, а в идеале и с икрой). Просто индустрия чуть больше созрела и усовершенствовала способы отьема денег у населения. 

 

пфф... not you =)

 

А я вот уверен что в пониленде живут люди которые думают что не имея не малейшего понятия в объекте управления они могут им управлять просто потому что они умеют в скрам и бизнес процессы.

 

Кто бы спорил что IT это инструмент для заработка денег или оптимизации процесса заработка денег на чем то другом. Проблема в том что поняши "на гироскуттерах и с макбуками" (с) даже не пытаются понять как оно работает. Но судя по всему, тебе доказывать это бессмысленно 

[euroUK]

Я и не спорю, что основная цель IT - зарабатывать деньги. Просто во главе множества крупных и некрупных фирм стоят недалекие люди, которые не понимают, что очень часто лучше переписать систему с нуля целиком, чем пристраивать костыли. Кажется, что вся система - дорого, а костыль быстро и дешево. Но когда костылей становится много - поддержка всего этого и доработка становится существенно дороже, чем если бы сразу сделали как надо.

 

Именно умение вовремя потратиться, чтобы перейти на новый качественный уровень и отличает хороших управленцев от плохих. Это как защита в ЦСКА и сборной. Лучше них не было никого на тот момент. Но если не вкладываться в молодых ты так и остаешься с двумя сорокалетними мужиками в сборной.

[Tir]

Продут, выпущеный по аджайлу, рано или позно начинает переписываться системно.

ОР ДО ГОР

Только вот проблема в том, что манагеры от ИТ не видят смысла в переписывании "работающих систем", поэтому прикрепляют костыли вместо переделки сути.

А к концу поста наш гибкий друг видимо забыл о том, что он писал в начале про то, как там что-то начинает переписываться системно.

Я и не спорю, что основная цель IT - зарабатывать деньги. Просто во главе множества крупных и некрупных фирм стоят недалекие люди, которые не понимают, что очень часто лучше переписать систему с нуля целиком, чем пристраивать костыли. Кажется, что вся система - дорого, а костыль быстро и дешево. Но когда костылей становится много - поддержка всего этого и доработка становится существенно дороже, чем если бы сразу сделали как надо.т плохих. Это как защита в ЦСКА и сборной. Лучше них не было никого на тот момент. Но если не вкладываться в молодых ты так и остаешься с двумя сорокалетними мужиками в сборной.

> эджайл
> переписываться системно
> сразу сделали как надо
И ведь как-то уживается всё вот это взаимоисключающее в одной голове и не дерётся.

[euroUK]

ОР ДО ГОР

А к концу поста наш гибкий друг видимо забыл о том, что он писал в начале про то, как там что-то начинает переписываться системно.

> эджайл
> переписываться системно
> сразу сделали как надо
И ведь как-то уживается всё вот это взаимоисключающее в одной голове и не дерётся.

 

Я для тебя возможно открою истину, но эджайл - это плохая практика разработки, которая, если ей пользоваться без оглядки, приводит к тому, что продукт большей частью состоит из костылей. Ты можешь орать или нет, но любая система сложнее заказа пиццы, которая претендует на расширяемость, модульность и поддерживаемость в дальнейшем, должна разрабатываться уже с учетом этих требований.

Поэтому в реальном мире для серьезных проектов есть 2 варианта:

1) Если продакт оунеры и аналитики сильные, то сразу ведется разработка нормально, но такая разработка редко когда может быть реализована по эджайлу, ибо на разработку ядра системы, моделей, интеграции уходит много времени и невозможно релизить MVP на неработающем ядре.

2) Если аналитики и оунеры не могут точно сказать, что им нужно, то разработка ведется по эджайлу, но потом, когда продукт достигнет функциональной зрелости, его придется переписывать с учетом требований к расширяемости. 

 

Безусловно, некоторые вещи типа формочки с кнопочками можно делать и без готового бэкенда в тесной кооперации с заказчиками и оунерами, только программирование формочек я не считаю работой над системой вообще. А выдавать кредитный калькулятор по эджайлу типа "тут у нас идет завпрос кредитной истории, но мы еще не интегрировались с той подсистемой, поэтому у нас тут ничего нет" безусловно можно, но вот в нормальной ситуации - 90% вопросов это как считается и что учитывается, и без полной интеграции все это имеет ровно 0 смысла.

[Akturis]

Что то ты путаешься в понятиях.
Agile не каким боком не относится к разрабатываемой функциональности. Это методология разработки - небольшими командами, закрывающими все направления.

[Tir]

Хотел было дело простыню написать, но чот вспомнил, сколько раз я такие простыни писал (и сколько раз проговаривал словами), и какова была результативность оных проповедей, и забил. В теории ты говоришь правильный абстрактные слова. На практике это всё не работает. Ещё ни разу не видел, чтобы после таких вот переписываний чего-то реально большого, работающего в реально сложных бузинес-процессах, "с учётом требований к расширяемости" костылизация не начиналась со следующего же релиза, ибо выяснялось, что экстеншн пойнты были прикручены не там и не те, а те, которые есть, реализованы настолько криво, что расширяемости по факту не дают, и всё вот это вот. Можно конечно решить, что там архитекторы были не архитекторы и аналитики - не аналитики, и ваще решить, что все содомиты, один ты - боярин Орша, но чот мне подсказывает, что на практике ты от них даже оправданиями своих обосрамсов принципиально отличаться не будешь, окажись ты на их месте.

И это было бы даже неудивительно. Пока система маленькая с кудрявой головой, и её дизайн, хотя бы хайлевельный, со всеми юзкейсами, подсистемами, как они там будут взаимодействовать, дата моделями, интерфейс агриментами, и всем вот этим вот, умещается в голове, проектировать её по наитию и документировать, как бог на душу положит, ещё худо-бедно можно. Но по мере роста продукта это рано или поздно заканчивается, и начинают лезть внезапные импакты при запилке нового функционала, про которые кто-то не подумал, потому что ну кто же мог подумать, и ваще это не мы дизайнили/имплементили/вотэвар, бесконечные регрессии, и всё это всё равно заканчивается костылями, ибо выясняется, что иначе переписанное с учётом требований к расширяемости нужно переписывать с учётом новых требований к расширяемости прям на следующей же итерации. Тут бы в сторону формальных методов посмотреть, но пойди найди, кто про них хотя бы слышал, и ваще это сложно, скучно, без стэндапов, покера там и прочих пируэтов свободного полёта креативной мысли. А ещё долго, да. Бесконечные-то переписывания с учётом требований к расширяемости всяко быстрее, ага.

[euroUK]

Отчасти ты прав, но стоит принять внимание следующие факторы:

1) Поддержка костылей и легаси стоит дороже, начиная от разработчиков, которые понимают легаси технологии, заканчивая девопсом зоопарка

2) Добавление нового функционала в систему со множеством костылей занимает времени гораздо дольше, чем в систему без оных.

3) Переписывание системы с учетом новых технологий, тулов и IDE требует гораздо меньше времени. Если раньше писанина на C++ и Com+ была больше похожа на садомазохизм, то сейчас можно за один рабочий день написать при помощи рефлексии и экспрешенов визуальный конструктор бизнес-логики над определяемыми рантайм моделями объектов. А дальше расширяй это как хочешь и куда хочешь, вот тебе редис, вот тебе рэббит, вот тебе деплой из коробки, в котором даже миграция данных есть.

Что то ты путаешься в понятиях.
Agile не каким боком не относится к разрабатываемой функциональности. Это методология разработки - небольшими командами, закрывающими все направления.

 

Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки. - Википедия.

 

Говоря своими словами, за каждый цикл разработки ты выдаешь MVP с учетом требований на этот цикл.

[Franky]

А выдавать кредитный калькулятор по эджайлу типа "тут у нас идет завпрос кредитной истории, но мы еще не интегрировались с той подсистемой, поэтому у нас тут ничего нет" безусловно можно, но вот в нормальной ситуации - 90% вопросов это как считается и что учитывается, и без полной интеграции все это имеет ровно 0 смысла.

Ты не поверишь, но банковское ПО реально так и делается.

[euroUK]

Ты не поверишь, но банковское ПО реально так и делается.

 

Ну именно поэтому оно в банках такого уровня. И да, я знаю о чем говорю.