Программисты философствуют

[Justas 9]

Коллеги, вы не понимаете одну простую вещь.

Когда заказчик четко знает что именно он хочет, как именно, зачем, почему, и ТОЧНО ЗНАЕТ, ЧТО ОН НИЧЕГО НЕ БУДЕТ МЕНЯТЬ, это одно.

То есть все правильные ответы известны заранее.

Там применим т.н. вотерфолл. Вы фиксируете объем, цену, сроки.

.

Аджайл применим там, где заказчик не может определиться, или точно в полной мере на все 100% не знает что именно ему нужно.

Ему нужна, например, трейдинговая система. Чо за система, как, хочет ли он фьючерсами торговать или пока не знает. Сказать не может.

При таких установках нет правильных ответов.

Мы фиксируем цену и сроки.

Объем не фиксирован.

Это не значит что его нет.

Мансур, отличное объяснение!

[roma 59]

Мы фиксируем цену и сроки.

Объем не фиксирован.

Это не значит что его нет.

Если скажем фича 38 была в ТЗ, но в процессе разработки заказчик постоянно говорил, что фича 38 не важна и вместо ее реализации предлагал другие более важные для него вещи (фичу 177, 36, 561 и 42) - и в результате фича 38 не вошла в окончательный релиз, то заказчик это прекрасно сам понимает и

а если не понимает? идёт в суд и говорит вот ТЗ, вот фича 38, а в конечном продукте её нет - верните мне мои деньги! :-)

[abel_91 7]

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

Ты сознательно пропустил два немаловажных пункта. Предпроектное обследование объекта заказчика и проектное решение.

...

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

Это называется предпроектное обследование объекта заказчика, правда жутко кастрированное. В чем здесь преимущества аджайпа?

[mmoustaf 101]

а если не понимает? идёт в суд и говорит вот ТЗ, вот фича 38, а в конечном продукте её нет - верните мне мои деньги! :-)

То он до этого момента даже не дойдет.

Как Максим, который не готов помогать, выбирать и отвечать на вопросы.

Аджайл не работает с детским садом.

Ты сознательно пропустил два немаловажных пункта. Предпроектное обследование объекта заказчика и проектное решение.

Это называется предпроектное обследование объекта заказчика, правда жутко кастрированное. В чем здесь преимущества аджайпа?

Это вопрос только Игорю или вообще? Если вообще - посмотри мой ответ выше, если только Игорю - ну он сам ответит.

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

Кто делает предпроектное обследование?

Кто делает проект?

[abel_91 7]

То он до этого момента даже не дойдет.

Это вопрос только Игорю или вообще? Если вообще - посмотри мой ответ выше, если только Игорю - ну он сам ответит.

Ну, твой ответ выше я смотрел. Он действительно работает на мелких объектах/задачах, но при достижении определенного объема решаемых задач вся система рушится. Это я как заказчик говорю

[maksims 1]

Я тебе расскажу но задавая вопросы.

А если у тебя вопросы после появились?

Или заказчик решив тетрис, вдруг сказал - я хочу лайнз?

Это ты себе придумал.

У нас есть стадия согласования. В ней участвует вся команда и формирует бэклог.

Бэклог гибкий, он не установлен раз и навсегда. И заказчик в ходе разработки может его менять.

Блин, ну все же просто.

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

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

Кстати, в стадии согласования не может участвовать одновременно более 4х человек. Иначе - бардак. Все согласуется поэтапно.

[1] Я правильно понимаю, что ты даже примерно не знаешь, что ты хочешь для бизнеса? Что максимум, чего тебе хочется, это сделайте мне то, не знаю что?

[2] Я правильно понимаю, что весь заказ укладывается в формулу "Сделайте мне красиво". Причем ты скажешь красиво или нет только в момент финального релиза?

Т.е. "Сделайте мне красиво" - это и есть твой заказ. Тебе представляют прототип системы и спрашивают: "Все ок?", а ты в ответ: "Не знаю". Тебе представляют прототип системы с наращенным функционалом и спрашивают: "Все ок?", а ты в ответ: "Не знаю". И так -цать раз, после чего ты внезапно говоришь: "Нифига! Я все хотел по другому!" Какой интересный заказчик.

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

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

[1] - нет.

[2] - нет.

Дальше комментировать бессмысленно.

[mmoustaf 101]

Ну, твой ответ выше я смотрел. Он действительно работает на мелких объектах/задачах, но при достижении определенного объема решаемых задач вся система рушится. Это я как заказчик говорю

У нас в банке это работает на крупных проектах и очень крупных.

Банк из топ 5 в мире.

[mmoustaf 101]

Блин, ну все же просто.

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

Но этого быть не может, потому что на стадии проектирования и моделирования выясняется, что именно хочет клиент.

В том-то и дело что не просто.

И не всегда. В больших и очень больших банковских проектах:

- не всегда возможно это сделать на этапе анализа и моделирования.

Потому что вообще неизвестно, что это за новый бизнес, понимаешь?

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

Он это только сейчас придумал. Даже специалистов в этой области нет. Он вообще не знает. будет эта идея работать, но жопой чувствует. что этот инвестиционный айфон полетит. Ты хоть обмоделируйся, не сможешь получить 100% ТЗ.

- требования меняются по мере разработки, понимаешь? такое бывает в жизни чаще чем ты думаешь.

Потому что банковский бизнес он гибкий что пипец, ты сегодня делаешь торговлю из расчета старых регуляторных метрик. и знаешь что будут новые (QE-5, Basel +100500) но не знаешь какие. Узнаешь черезе 3 месяца когда примут.

Вот мы работали, делаем эту НЁХ из первого пункта, и тут регулятор такой "в воздухе носится новый тренд, мы тут подумали и решили, правила планируемой торговли должны быть такими и все кто будет в новой непонятной схеме торговать должны уметь делать сделки с одновременным стрит-букингом по долговым обязательствам страхового обеспечения биржи. Вот 100500 правил."

И заказчик понимает. что если он хочет успеть в срок ему надо выкинуть какие-нибуд неважные свистопердделки, потому что нельзя не делать то, что требует регулятор. Вообще нельзя. Откажешься - с тебя штраф на 2-3 миллиарда долларов слупят. При общем объеме чистой планируемой прибыли в 10-12 ярдов за счет внедрения нового функционала терять 2 ярда не планируемых, а живых - как-то влом.

И никакой мегаколлеквиум этому не поможет. Стадия анализа, это не собрались посидели и бэклог выкатили. Нет. Это отдельная большая работа, которой в твоей схеме просто нет.

Кстати, в стадии согласования не может участвовать одновременно более 4х человек. Иначе - бардак. Все согласуется поэтапно.

Эта работа в схеме есть. Но она не заканчивается перед разработкой и не выделена одним этапом. Она длится в течение разработки.

Не бардак. А нормальная плодотворная работа.

[mmoustaf 101]

Дальше комментировать бессмысленно.

Я ж говорю - парадокс блаба.

Утрированно, зачем мне джава, если я все могу сделать на сиплюсе (или наоборот).

Большие проекты пишутся только на сиплюсах. а джава медленная и ненужная (или наоборот).

При этом у того, кто так говорит - у него есть огромный опыт сиплюса и нету опыта джавы (или наоборот).

Ну так - писал, слышал от коллег.

Поэтому при сравнении двух технологий такой человек сравнивает факты сиплюса, с мифами о джаве в своей голове (или наоборот).

А факты с мифами сравнивать невозможно.

Это неконструктивно

Я помню как все говорили - зачем HD, это дорого, ненужно, клиент все равно не берет, отстой. А разница по качеству незаметна глазом.

Прыгайте с SD, там три матрицы, сони PS150/1000, ололо.

Тоже проявление блаба.

Еще раз. В упорядоченном мире работает ватерфол.

Если к Николаю и ко мне придет заказчик с требованиями сделать МБР или систему управления электростанцией, то я не буду использовать там аджайл.

Такой заказ не для аджайла. Аджайл там проиграет. Я если возьмусь буду делать по ватерфолу, как и Николай.

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

[abel_91 7]

У нас в банке это работает на крупных проектах и очень крупных.

Банк из топ 5 в мире.

Банковские системы наиболее консервативны и наиболее документированы так как преступить законодательство ни кто не позволит. Следовательно желания клиента минимизируются до игольного ушка, а в рамках данного ушка аджайп рулит

[mmoustaf 101]

Банковские системы наиболее консервативны и наиболее документированы так как преступить законодательство ни кто не позволит. Следовательно желания клиента минимизируются до игольного ушка, а в рамках данного ушка аджайп рулит

Нет. Это не так.

Банковские системы наиболее подвержены изменениям (в нормальных банках, конечно, в сити, GE-Money, Дойче, Барклайсе).

Поскольку законодательство и требования бизнеса меняются на глазах.

Возьми ситуацию с базелями, QE. Или кризис Еврозоны.

И желания клиента там никак не минимизируются.

Желания клиента там - это "Я хочу такую систему, чтобы заработать много денег в любых условиях"

Вот и строй на основании этого ТЗ.

[abel_91 7]

Нет. Это не так.

Банковские системы наиболее подвержены изменениям (в нормальных банках, конечно, в сити, GE-Money, Дойче, Барклайсе).

Поскольку законодательство и требования бизнеса меняются на глазах.

Возьми ситуацию с базелями, QE. Или кризис Еврозоны.

И желания клиента там никак не минимизируются.

Желания клиента там - это "Я хочу такую систему, чтобы заработать много денег в любых условиях"

Вот и строй на основании этого ТЗ.

Во, совершенно верно Меняется законодательство, т.е. "техпроцесс" уже документирован. Или клиент способен/имеет право его обойти? Нет, дудки.

[maksims 1]

Ох. После комментария про банковские системы, я удаляюсь =))

Просто намекну, что есть такая штука ФСФР (скоро ЦБ передадут функции) у которой на каждый чих есть регламент. Он точно описывает тот тетрис, который им нужен.

Если говорить про новшества, типа новомодных сейчас программ лояльности, то у банков, по крайней у нормальных =) есть свои службы бизнесанализа. С ними работать - одно удовольствие.

Я ж говорю - парадокс блаба.

Утрированно, зачем мне джава, если я все могу сделать на сиплюсе (или наоборот).

Большие проекты пишутся только на сиплюсах. а джава медленная и ненужная (или наоборот).

При этом у того, кто так говорит - у него есть огромный опыт сиплюса и нету опыта джавы (или наоборот).

Это определяется уловиями эксплуатации системы.

Очень хочу посмортеть, как ты протолкнешь "писание на "плюсах"" при проектировании мультиплатформенных систем. Или наоборот, протолкнешь жаву для виндовс ориентированных клиентских приложений.

[mmoustaf 101]

Ох. После комментария про банковские системы, я удаляюсь =))

Просто намекну, что есть такая штука ФСФР (скоро ЦБ передадут функции) у которой на каждый чих есть регламент.

Спасибо кэп.

ФСФР база, 1.0 и 2.0 у меня с 2003 года.

И работа в РТС с 2002-го года по 2006-й

В том числе и год в тесном контакте с адресом Ленинский проспект 19 в сотрудничестве с Вячеславом Эдуардовичем.

Так что можешь не намекать.

Он точно описывает тот тетрис, который им нужен.

Тетрис который нужен мегарегулятору.

А НЕ КЛИЕНТУ.

Этот тетрис - это набор ограничений.

Но даже в рамках этих ограничений желания клиента бесконечны.

И да, при наличии этих ограничений никто не гарантируют, что не возникнут новые.

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

Во, совершенно верно Меняется законодательство, т.е. "техпроцесс" уже документирован. Или клиент способен/имеет право его обойти? Нет, дудки.

Техпроцесс нихрена не документирован.

Документированы ограничения.

Но если мне дали задачу написать электронную торговую площадку, то при чем тут ограничения?

Как они на желания клиента НЕ СВЯЗАННЫЕ С ОГРАНИЧЕНИЯМИ влияют?

Законодательство - это не корнструктивно-прочностные ограницения.

Или наоборот, протолкнешь жаву для виндовс ориентированных клиентских приложений.

А при чем тут писание на плюсах? Или на джаве?

Пример с плюсами и джавой был приведен в качестве иллюстрации парадокса блаба.

[mmoustaf 101]

Это определяется уловиями эксплуатации системы.

Да... ты прочел ровно не то, что я хотел сказать.

наш диалог похож на вот это

Я - Буратино. У тебя есть 3 яблока. пришел некто взял одно яблоко, сколько у тебя осталось?

Ты - А я не отдам некту яблоко. пусть он дерись.

[mmoustaf 101]

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

Или встречался, и пытался с ними расправиться в рамках известных технологий проектирования.

Я не зря говорю про парадокс блаба.

[roma 59]

Еще раз. В упорядоченном мире работает ватерфол.

Если к Николаю и ко мне придет заказчик с требованиями сделать МБР или систему управления электростанцией, то я не буду использовать там аджайл.Такой заказ не для аджайла. Аджайл там проиграет. Я если возьмусь буду делать по ватерфолу, как и Николай.

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

вот мне вот кажется в этой теме всё остальное кроме этих вот абзацев можно удалить не читать :-)

[maksims 1]

Спасибо кэп.

ФСФР база, 1.0 и 2.0 у меня с 2003 года.

И работа в РТС с 2002-го года по 2006-й

В том числе и год в тесном контакте с адресом Ленинский проспект 19 в сотрудничестве с Вячеславом Эдуардовичем.

Так что можешь не намекать.

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

А при чем тут писание на плюсах? Или на джаве?

Пример с плюсами и джавой был приведен в качестве иллюстрации парадокса блаба.

Притом, что даже выбор языка определяется требованиями к системе, а не шовинизмом разработчика.

[mmoustaf 101]

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

Я не понял что ты имеешь ввиду под "источниками данных"?

источники данных для нас - дофига.

фиды наших сделок со всех мировых бирж.

Ройтерс/Блумберг

Другие внутрибанковские системы в т.ч. и наша (но в другом регионе ).

пользовательский ввод

Пример - торговля ценными бумагами.

Москва 2005-й год - trade management/order management/position keeping (Я про трейдинг в Намибии вообще молчу - попробуй там тз составить с местными)

Вне зависимости от того, что там себе хочет ФСФР заказчик с начала не мог определиться с моделью.

Он хотел трейдинговую модель, чтобы работало как до нашей покупки но торговало везде (Москва и Лондон).

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

- использовать учетную валюту или нет? (мы по тз сделали, но в процессе промежуточных показов выяснилось, что это нафиг не надо. Передумали. Бэкофису резко стало неудобно. А до того 5 лет подряд было удобно)

- пересчитывать ли PnL (profit & loss) если в течение дня ЦБ поменял курс 3 раза (раньше курс публиковался не только в 12, но еще в 11, а в 12 он фиксировался)

(сначала в ТЗ было да пересчитываем, амендим сделки, причем так, как будто бы они были заведены так изначально)

Какую модель использовать для подсчета PnL (Trade dated vs amend dated)

Две концептуально разные модели. Заказчик в середине поменял требования.

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

Давайте-ка вот такую, больше заработаем.

- потом в середине разработки пришел и говорит - а бондами поторговать?

- а фьючерсами?

- какими методами считать позицию.

- как должен выглядеть ГУИ для такой системы.

- а почему вы вот это не делаете.

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

Она не прошла.

В ТЗ такого способа не было.

Нам что запретить ему это делать? Или инициировать процесс - иди к системному аналитику пусть он тебя послушает - пришлет нам спеку - мы в ответ изменения - а только тогда начнем?

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

Это отдельная высокоприоритеная фича.

Притом, что даже выбор языка определяется требованиями к системе, а не шовинизмом разработчика.

Ты такой компактный.

сиплюс и джава были названы как слова для иллюстрации парадокса блаба.

Вместо них моджно было бы написать "численный метод Ньютона" и "метод Годунова" или "метод 1" и "метод 2"

[abel_91 7]

Как насчет программного комплекса для организации функционирования крупнейших (top 10) радио и ТВ станций в Западной Европе? Определенный объем уже достигнут или еще нет? Если нет, то просьба написать критерии, по которым определяется этот самый граничный объем

...

На сколько я помню, ты уже лет 10 им софт лабаешь? И еще лет на 30 работы хватит

[mmoustaf 101]

На сколько я помню, ты уже лет 10 им софт лабаешь? И еще лет на 30 работы хватит

Это все из-за аджайла.

Понятное дело любой разработчик с ТЗ, ФС, ПД и ТД закончил бы за пять лет и не выкачивал бабла из журналистов.

Но все молчат, потому что никто не любит журналистов в этом мире.

[mmoustaf 101]

Кстати, фирма была основа в 1991 году, так что по такой логике она должна была делать некий уже проект 22 года

В падении класса журналистов виноват Игорь.

До 1991 года, если все помнят - качество статей было огогогого!

А с 1991 Игорь выкачивает бабло из журналистов. следовательно журналистам меньше платят. Меньше платят - те хуже работают и пишут всякую фигню.

[abel_91 7]

Ты не поверишь, но да

...

Эт почему не поверишь? Даже и не сомневался. Устранение багов, после очередной фичи или итерации любимое занятие адептов скрама и аджайпа.

[abel_91 7]

...

Несоменно. Это только у адептов тотального планирования багов не бывает.

Ну, как это без багов, бывает. Но не еженедельно

[mmoustaf 101]

Эт почему не поверишь? Даже и не сомневался. Устранение багов, после очередной фичи или итерации любимое занятие адептов скрама и аджайпа.

Демо после итерации в аджайле - это не выкатка в продакшн. Это показ заказчику.

И да. исправление того, на что указал заказчик - это любимое дело аджайл команды.

Так на том и построен процесс.

Только это исправление "багов" не из-за плохого программирования, а багов связанных что мы не так поняли заказчика/заказчик поменял мнение.

Пример

Позишн кипинг. Заказчик захотел просчет профит-лосса.

Мы выкатываем демку. Заказчик вводит трейды, амендит трейды. Все считается как положено.

Заказчик:

- А можно я сделку поменяю которая 3 дня назад была сделана (сеттлемент через 5 дней)

- Можно

- А круто...

- А если курс валют поменю сейчас (как будто ЦБ прислал)?

- Можно

- Эээээ.. а че вы профит-лосс не обновили?

- Так по ТЗ - реалайзд профит лосс - это разница цены покупки и продажи... А сделка была сделана до того как поменяли курс

- Нненененее переделывайте, МНЕ ТАК НЕУДОБНО. МНЕ УДОБНО профит лосс считать по другому. Я тогда смогу применить новую улучшенную модель открытых позицый валютных (??? - какая. думаем мы. в тз этого не было!!!).

- Так мы ж спрашивали, аналитик спрашивал????

- А я сейчас понял только. у меня новый экономист появился неделю назад - Волкозайчик, он мне все рассказал

Поэтому в след итерации мы ему исправляем это.

А теперь представь если бы такая штука вылезла в день окончательной сдачи?

Ну, как это без багов, бывает. Но не еженедельно

У вас все баги вылезают в конце проекта при сдаче?

Размер спринта оптимальный - от недели до 4-х. Он выбирается исходя из бэклога (ТЗ по вашему)

Дело же не в том сколько ты багов отловил при разработке. а в том, сколько их осталось после релиза в продакшн.