Wound:
Да, я хотел бы получить хороший обстоятельный ответ. Если нет времени, хорошо, я могу подождать, как тебе будет удобно - прям бери расписывай. Мне реально интересно, вдруг есть такие подходы, о которых я не знаю? Я гуглил все термины, которые ты писал в ходе нашей дискуссии, даже термин "impact mapping" загуглил. НО по coding by design - актуальной и вменяемой информации я не нашел. Я допускаю что не так и не там ищу. По этому было бы просто супер, если бы ты привел какую то вменяему инфу об этом, видео/статьи/еще что то. Ну реально из того ролика что ты постил, я не понял идеи. Если рассказами, то лучше тексом, там проще перечитывать, если картинками - то можно и видео конечно.
Я не прошу учить меня чему то, просто прошу прояснить общие принципы данных подходов. Я пока не увидел как то, что ты привел может заменить блок-схемы. Ну зрительная инфа лучше восприниматся для понимания того, что надо сделать как по мне, чем кодом. Так же как по мне(конечно это субъективно) - на пальцах(блок-схемы) - лучше отражают то, что делает та или инная система.
Т.е. в принципе все эти UML диаграммы нужны для того, что бы понимать как что с чем взаимосвязано, как оно работает, т.е. смотря на диаграмму, ты понимаешь задумку автора. Тебе код - на этом этапе, накуй не уперся, тебя интересует - как оно все вместе взаимодействует. Вот диаграммы в данном случае по моему глубокому убеждению, доносят данные знания очень быстро и очень эффективно.

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

А как другие подходы дадут больший профит? Я пока не понимаю, ты не объяснил. Курить интерфейсы того же OTPLogonProvider на майкрософте и примеры одного и того же кода? Нет уж, извините. Ты сам попробуй сыграть в угадайку по коду, которого у тебя нет. Напиши банально схему изменения пароля/просроченного пароля, владея всеми исходниками какие только найдешь в гугле(а их к слову много) на майкрософтовский Login Provider. Просто имел я опыт с этим, тонну кода перечитал, кучу времени потратил, но нет же вменяемых блоксхем, приходится код курить.

Вот у меня такое мнение. Так что как будет время, обязательно дай обстоятельно хороший ответ. Мне он правда интересен, возможно что то новое расскажешь, я что то новое для себя узнаю.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833779

korvin:
Нет, это не особо решает. В том числе и потому что топовых спецов мало, и не много компаний может себе их позволить.


Мой опыт говорит, что компании под CI/CD понимают настройки серверов сборки и деплоя, а не методологию.


Это не коммуникация, а приоритеты и условия. Не важно, смог ли ты донести мысль, что рефакторинг важен, если конкурент выкатил продукт быстрее, даже наговнокодив его без всяких скрамов и CI/CD, просто абы как — он успел занять рынок быстрее.


Если у бизнеса всё ОК, то он и так не станет особо рашить за фичами, пытаясь выиграть в конкурентной гонке за рынок, и можно на расслабоне фиксить минорные баги, оптимизировать производительность и рефакторить код для лучшего maintainability.

Добавлено 03.07.20, 21:18
А причина популярности всей этой около-agile-херни просто в том, что бизнесу так проще оценить работу программеров, их вклад и т.п., вот и всё, т.е. свести программирование к простому ремеслу, а ля работы у станка или типа того.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833778

D_KEY:
Есть более грамотные люди. И их можно пригласить. Они могут проводить тренинги, запускать команды (пилотную или сразу несколько), провести аудит.
Некоторые даже могут согласиться в штате поработать, но это редко.

Добавлено 03.07.20, 20:52

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

Добавлено 03.07.20, 20:55

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

Добавлено 03.07.20, 20:56

Тут есть нюанс. Если у бизнеса все ок, то он не станет меняться ;)

Добавлено 03.07.20, 21:03
Wound, ты видимо хочешь хороший обстоятельный ответ. Сейчас у меня на него нет времени. Возможно, если позже оно у меня появится, я постараюсь ответить. Но на самом деле ты можешь погуглить по ключевым словам, которые я привел. Материалов много, вряд ли я тут скажу что-то отличное. При этом научить этим подходам на форуме нельзя. Но ты можешь поискать, может быть есть вебинары/курсы какие-то выложенные.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833777

korvin:
Ну тебе точно стоит прогуляться по многим компаниям и объяснить им это. =) Заодно, рассказать, какие это даёт преимущества в условиях рыночной конкуренции, когда конкурент может выкатить продукт (не идеальный, не по скраму, но уже хоть что-то делающий) и перехватить клиентскую базу, пока вы там скрамите.


Нет. Качество противоположно скорости. Всегда.


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

Добавлено 03.07.20, 20:48

Ну так я об этом и говорил.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833776

D_KEY:
Такая гонка действительно есть. Только делать это можно по-разному.

Добавлено 03.07.20, 20:46

У меня сейчас такой продукт, правда не слишком жесткий, но есть и стандарт и сертификация и испытания.

И в нем как раз выделяют mission critical часть и нет. В том числе ради того, чтобы иметь возможность обновлять продукт и поставлять новые фичи достаточно часто, когда это не касается mission critical. И, наоборот, иметь стабильность и обновлять только через долгие процедуры и сертификации то, что является mission critical.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833775

korvin:
Эм, нет. Под «mission critical» понимают определённые сферы/области применения софта (это устойчивый термин, насколько я знаю), обычно прямо связанные с человеческими жизнями/здоровьем.

Как там быстро и качественно отображается рекламный баннер на сайте — это не mission critical, как там быстро трейдинговый софт отображает котировки — это не mission critical, мобильное приложение банка (да и весь бэк банка, несмотря на то что обрабатывает реальные и большие деньги) — это не mission critical.

А ПО для мед.оборудования, для космических аппаратов, атомных станций и т.п. — это mission critical

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833774

D_KEY:
Тут я могу только еще раз повторить про разный опыт ;)
Это вполне может соблюдаться на практике. А цель agile трансформации в том, чтобы в компании именно так все и было устроено.

Добавлено 03.07.20, 20:40

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

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833773

korvin:
Видимо, разная. Я пока наблюдаю гонку за фичами. И вообще за скоростью.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833772

D_KEY:
У тебя у любой фичи практически будет mission critical часть и нет.
Если это не так, если ты руководствуешься только такими требованиями и нет никаких продуктовых гипотез, то тебе не нужен никакой agile.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833771

korvin: D_KEY, давай начнём с того, что это не «принципы», а «рекомендации», «подсказки», которые вывели для себя эти уважаемые люди, что не означает автоматически их абсолютность и уместность применения везде и всюду.

Ну вот из перечисленных тобой ни один не соблюдается на практике. Потому что бизнесу не интересен _этот_ agile, ему интересно только увеличение скорости delivery.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833770

Wound:
D_KEY, ну хватит. Ну хватит вот это отходить от темы и писать про какие то проблемы каких то пользователей.
Давай уточним, система например как 1С Предприятие - это сложная система? Система например как 3D Studio Max - это сложная истема? это же всего лишь программы. Хорошо, вот тут выше упомянули JetBrains, давай возьмем тот же IntelliJ IDEA - это сложнная система? Давай еще для сравнения возьмем например этот форум - это сложная система? Ну и для пущего эффекта возьмем например - игру "Волк ловит яйца в корзину", которую можно скачать на Google Play, это сложная система?
Ясный перец с менеджментской точки зрения речь будет идти о продуктах. Но мы же не менеджмент, правда? Мы разрабы, а значит речь идет о системах.
Я не знаю на что ты там насмотрелся, но с моей точки зрения в IT мире существует огромное множество сложных систем, под сложной системой я подразумеваю некий набор компонентов, которые взаимодействуют между собой как то там. Вот и все.


Можно нормально, без вот этих вот ваших true story, sad but true, etc. Мы все такие на российском форуме общаемся как бы.
И по подробне раскажи про "сформировать видение продукта"? Как это будет происходить?

К тебе приходит заказчик, говорит мне нужна вот такая вот система, с такими вот параметрами, и уметь она должна это вот это и это, заказчик шарит в теме, он ни какой то холуй, которого можно загрузить вот этими "impact mapping" и "true story", он знает что хочет получить дает тебе ТЗ написанное в общих чертах что и как, ясный перец без описания интерфейсов и всяких программных сущностей, он как бы не по этим делам. Ну и? Твои действия?



Вот как раз в этом и вопрос - как спроектировать гибкий каркас системы, не взглянув на задачу прищурившись из далека? Расскажи секрет плиз ))


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

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833769

D_KEY: Пруфы противоречий.
3 из 12 принципов agile (можно обнаружить на сайте манифеста):


Добавлено 03.07.20, 20:32

У нас разная практика :-?
У меня другой опыт, я видел то, о чем пишу.
Пункты из принципов я привел. Могу из scrum гайда еще привести.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833768

korvin:
Ага, но проектирование тут всё равно идёт сильно вперёд, и оно более скурпулёзное, нельзя просто взять и agile'овски сказать: а давайте сделаем вот так, потом посмотрим, что будет, проанализируем реакцию пользователей, т.к. какой-нибдь томограф может выжечь пациенту мозг (или типа того, я утрирую, но думаю, ты понял)


Вот у нас подумывают взять скрам-мастера в команду, пойдёшь? (P.S. есть код на плюсах, если что)


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

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833767

Oleg2004: Надо понимать что это фотка esperanto? :)

https://forum.sources.ru/index.php?showtopic=418813&view=findpost&p=3833766

D_KEY:
Смотри выше. Я видел, когда такая проблема была и как она ушла после фикса проблем в коммуникации.

Добавлено 03.07.20, 20:21

То, что ты тут описал противоречит agile подходу :)
У тебя в agile независимые и самостоятельные команды, принимающие решения об объеме работ, которые они берут в итерацию.
Если это не так, то у тебя не agile и тогда говорить нужно о другом.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833765

Wound:
Ну ок, тут ты прав, софтварные конторы(заказчики) для которых пишут другие софтварных конторы - я как то не учел.

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833764

D_KEY:
Частные подробности могу при встрече рассказать. А в общих чертах, PO обязательно должен понимать, что мы вставляем костыли и что за это нужно заплатить потом. Т.е. приходит он с какой-то бизнес задачей(user story или еще чего), команда дает оценки и прогноз, когда сделает. Если уже тут команда снижает оценку и костылит, то проблема в команде и ее ответственности за качество. Если же прогноз дан с учетом нормально сделанного решения и PO согласен, то все должно быть ок. Если же PO говорит, что пипец как срочно, сделайте плиз раньше, то начинается торг. Мы можем убрать часть требований, если это позволит быстрее сделать без потери качества, а можем решить, что сейчас сделаем прототип или костыль вставис, но тут же в бэклог заносим пункт на создание нормального решения и обсуждаем, когда нужно.
Нормальный PO понимает(а если нет, можно объяснить), что костыли рано или поздно приведут к тому, что мы или замедлимся или вообще не сможем делать нужные фичи впоследствии.

Добавлено 03.07.20, 20:17

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

https://forum.sources.ru/index.php?showtopic=419109&view=findpost&p=3833763

MIF: А почему не используешь штатные средства .Net: System.Data.OracleClient? Я чего-то не понимаю в вопросе?

https://forum.sources.ru/index.php?showtopic=419106&view=findpost&p=3833666

JoeUser:
Видать в поддержку американских братьев. А во время штурма колледжа они случайно рэпчик не читали?

https://forum.sources.ru/index.php?showtopic=416603&view=findpost&p=3833665

Oleg2004: Ну и я свою фотку опубликую...На ней мне 66 лет Oleg_Lusin.jpg (, : 10)
Может кто меня и захочет увидеть... :D

https://forum.sources.ru/index.php?showtopic=418813&view=findpost&p=3833664