UML vs Нафиг

[D_KEY]

Цитата korvin @ 03.07.20, 20:35

Ну вот из перечисленных тобой ни один не соблюдается на практике.

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

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

Цитата korvin @ 03.07.20, 20:35

Потому что бизнесу не интересен _этот_ agile, ему интересно только увеличение скорости delivery.

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

Сообщение отредактировано: D_KEY - 03.07.20, 20:41

[korvin]

Цитата D_KEY @ 03.07.20, 20:35

У тебя у любой фичи практически будет mission critical часть и нет.

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

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

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

[D_KEY]

Цитата korvin @ 03.07.20, 20:36

Цитата D_KEY @ 03.07.20, 20:30

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

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

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

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

Цитата korvin @ 03.07.20, 20:41

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

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

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

Сообщение отредактировано: D_KEY - 03.07.20, 20:47

[korvin]

Цитата D_KEY @ 03.07.20, 20:37

Это вполне может соблюдаться на практике. А цель agile трансформации в том, чтобы в компании именно так все и было устроено.

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

Цитата D_KEY @ 03.07.20, 20:37

Так следование этим принципам как раз и позволяет надежно и стабильно быстро поставку осуществлять.

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

Цитата D_KEY @ 03.07.20, 20:37

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

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

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

Цитата D_KEY @ 03.07.20, 20:42

когда это не касается (mission critical)

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

[D_KEY]

Цитата korvin @ 03.07.20, 20:46

Ну тебе точно стоит прогуляться по многим компаниям и объяснить им это. =)

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

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

Цитата korvin @ 03.07.20, 20:46

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

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

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

Цитата korvin @ 03.07.20, 20:46

Ага, надо доносить, обычно до них это всё равно не доходит

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

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

Цитата korvin @ 03.07.20, 20:46

Заодно, рассказать, какие это даёт преимущества в условиях рыночной конкуренции

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

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

[korvin]

Цитата D_KEY @ 03.07.20, 20:49

Если за это мы готовы платить больше денег

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

Цитата D_KEY @ 03.07.20, 20:49

Например, мой опыт говориь, что CI/CD улучшает и качество и скорость.

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

Цитата D_KEY @ 03.07.20, 20:49

Ну вот я и говорю, что проблема в коммуникации.

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

Цитата D_KEY @ 03.07.20, 20:49

Если у бизнеса все ок, то он не станет меняться

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

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

[Wound]

Цитата D_KEY @ 03.07.20, 20:49

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

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

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

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

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

Сообщение отредактировано: Wound - 03.07.20, 21:26

[D_KEY]

Цитата korvin @ 03.07.20, 21:06

т.е. свести программирование к простому ремеслу, а ля работы у станка или типа того.

Да, странный у тебя agile.

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

Цитата Wound @ 03.07.20, 21:21

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

Возможно, я как-то криво высказывал свои мысли. Я полностью согласен с тем, что ты тут пишешь

Цитата

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

Спор-то был не об этом, а о том, чтоб проектировать UMLем всю систему, а потом кодить.
Вот я считаю такой подход неэффективным.

[korvin]

Цитата D_KEY @ 03.07.20, 21:22

Да, странный у тебя agile.

Это не у меня =)

[Wound]

Цитата D_KEY @ 03.07.20, 21:22

Спор-то был не об этом, а о том, чтоб проектировать UMLем всю систему, а потом кодить.
Вот я считаю такой подход неэффективным.

Нет, ты прикалываешься? При такой постановке вопроса - я как бы с тобой согласен. Конечно - это маразм проектрировать UMLem всю систему а потом кодить. Это и правда 90-80 года, как ты раньше писал. Я лично вел речь об использовании блок-схем в принципе.
Но с тобой я спорить начал после того, как ты сказал что чем больше схем, тем хуже спроектирована программа. Я в данном случае в корне не согласен! Да это конечно вполне может быть . Но это не основной критерий того, что программа плохо спроектирована. Еще бывает так, что программа сразу охватывает много разных концепций и устройств, т.е. так сложилось что очень много зависимостей в самой системе заложено технологически от нее не зависяще.
Допустим тебе нужно работать с каким то девайсом, а еще иметь веб интерфейс для работы с ним. Уже несколько зависимостей появляется, даже без кода. Вот об этом я. И блок-схемы в данном случае - очень сильно выручают, особенно когда еще и система спроектирована криво.

Сообщение отредактировано: Wound - 03.07.20, 21:37

[D_KEY]

Цитата Wound @ 03.07.20, 21:36

Конечно - это маразм проектрировать UMLem всю систему а потом кодить. Это и правда 90-80 года, как ты раньше писал.

Ну хоть тут мы согласны

Цитата

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

Я сказал вот так:

Цитата D_KEY @ 03.07.20, 12:12

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

Это несколько отличается от того, что ты сейчас написал