IT в России и мире в реалиях мирового кризиса

Цитата: slavae от 25.09.2018 21:20:20Двести метров джаваскрипта
Грузит текста триста байт
Я - элита программистов,
Не какой то раздолбай

Это еще что. Бывает и похлеще. В 2010 я работал в GE Energy. Там один выдающийся йеменский software architect (по жизни редкая сволочь) умудрился в одном приложении совместить голый С++, Дельфы, С# и Java. Всё это подавалось как максимальный code re-use, нельзя же в самом деле выбросить табличный редактор, написанный в середине 90-х на чистом С++, надо втулить его в дельфийские формы, а поскольку в тренде .NET, надо втулить дельфийский код в оболочку на C#, а еще добавить разработанное другой группой на Java. А на главном экране приложения еще и в окне браузера показывалась какая-то хрень на HTML, и javascript там тоже присутствовал.
И да, разработка была Agile, scrum-митинг каждый день, спринты были по две недели.

Цитата: графит от 24.09.2018 16:37:02Спасибо, посмеялся. Вы, похоже, вообще не понимаете что такое разработка софта индустриального уровня в серьезных организациях, вроде ведущих технологических лидеров, бирж и банков.

Технологический лидер индустриального уровня – это, когда например, Локхид или Цейс, Сименс или Роллс-Ройс, Алмаз-Антей или Сухой. Я представить даже не могу, чем они могут "играться" до того, как софт не будет поставлен в опытную эксплуатацию в рамках жестко прописанного процесса, подлинник которого прошит, пронумерован и скреплен печатью. Технологические лидеры, т.е. т.н. хайтек,  абсолютно не используют так называемые "современные методы" разработки софта (привет, agile) и использовать это разводилово не собираются. Хайтеку нет разницы, год ему или он сам себе будет делать софт или три – он лидер и монополист, ему важнее надежность и стабильность, нежели быстрота разработки. Для них существуют специальные стандарты ANSI, ISO/IEC, ГОСТ, описывающих все этапы жизненного цикла софта, и не только этапы, а и общие требования. Я не очень понимаю, как можно из говна и палок набросать, например, систему управления турбореактивным двигателем магистральника, загрузить ее на изделие и "дать поиграться" заказчику. Интерфейс у этой системы, кстати – кокпит того самого магистральника.
Биржи и банки – это такие же обычные продавцы, как и все остальные, просто они продают воздух. Софт. которым они пользуются, в принципе мало чем отличается от софта, который используется продавцом секондфуда "минутной доступности" в соседнем подъезде/подвале.

Цитата: adolfus от 27.09.2018 00:15:04Технологический лидер индустриального уровня – это, когда например, Локхид или Цейс, Сименс или Роллс-Ройс, Алмаз-Антей или Сухой. Я представить даже не могу, чем они могут "играться" до того, как софт не будет поставлен в опытную эксплуатацию в рамках жестко прописанного процесса, подлинник которого прошит, пронумерован и скреплен печатью. Технологические лидеры, т.е. т.н. хайтек,  абсолютно не используют так называемые "современные методы" разработки софта (привет, agile) и использовать это разводилово не собираются. Хайтеку нет разницы, год ему или он сам себе будет делать софт или три – он лидер и монополист, ему важнее надежность и стабильность, нежели быстрота разработки. Для них существуют специальные стандарты ANSI, ISO/IEC, ГОСТ, описывающих все этапы жизненного цикла софта, и не только этапы, а и общие требования. Я не очень понимаю, как можно из говна и палок набросать, например, систему управления турбореактивным двигателем магистральника, загрузить ее на изделие и "дать поиграться" заказчику. Интерфейс у этой системы, кстати – кокпит того самого магистральника.
Биржи и банки – это обычные продавцы воздуха и их софт в принципе мало чем превосходит софт, который используется продавцом секондфуда "минутной доступности" в соседнем подъезде.

Навскидку - открытая позиция в Сименсе. В описании работы

- Working in an agile development environment whilst following Scrum and SAFe principles.

Или вообще Agile Coach 80 - 100% в том же Сименс.

В общем - привет Agile.

Или выбросим быстренько Сименс из технологических лидеров?

Цитата: графит от 26.09.2018 13:02:45Вы не программист, поэтому не знаете, что 90% алгоритмов, используемых в программировании, были давным-давно описаны стариком Кнутом. Все, что делает современный образованный девелопер

Нда... Прямо за версту пахнуло душком... "Современного образованного девелопера"... 

---

Апломба - вагон. Понятия о предмете - крохи. Еще и поучать лезет ведь...

---

Тьфу...

Цитата: графит от 26.09.2018 15:39:181. хороший дев... фреймворки... скиллз в... фреймах... аджайл
2. Я много поработал в Европе и Штатах, и там в серьезных учреждениях, вроде банков
3. Т.е. каждая конкретная задача требует разработки абсолютно новых алгоритмов?! Зачем тогда студенты учат Кнута и прочее в институте столько лет?

1. Мил человек, ты думаешь, умнее кажешься? Наоборот! Слыхал про русские слова, обозначающие это же?

---

2. Серьезные учреждения в Штатах, милок - это АНБ, НАСА и Пентагон. Но тебя, видать, они не звали...

---

3. Во-первых, далеко не все задачи описываются стандартными алгоритмами. Доля их явно поболе десятой. Во-вторых, не учат студенты много лет Кнута в институте) Со знанием дела говорю.

Цитата: графит от 27.09.2018 00:27:46Навскидку - открытая позиция в Сименсе. В описании работы

- Working in an agile development environment whilst following Scrum and SAFe principles.

Или вообще Agile Coach 80 - 100% в том же Сименс.

В общем - привет Agile.

Или выбросим быстренько Сименс из технологических лидеров?

Сименс кроме технологического лидерства занимается разного рода бытовой техникой и кухонным оборудованием, где он даже не в десятке, а по чайникам и утюгам на уровне какого-нибудь ладомира или витька. Также присутствуют в цеху фейкоплетов, выпускающих IOT-холодильники и прочие пылесосы. Последние сами вызывают лакеев, которые меняют им фильтры и моют мусороприемники. Почему бы там не использовать модные "молодежные" методы разработки ПО. Хотя я не представляю, как можно использовать эти методы для разработки прошивок в те же утюги?
Когда я упомянул Siemens как технологического лидера, а имел ввиду его САПР'ы, софт, который прошивают в станки, турбины и прочий хайтек. Мой бывший аспирант, занимавшийся алгоритмами упреждающего управления системами, в середине 2000-х уехал в Чехию и сегодня работает в подразделении, которое занимается разработкой управляющих систем для обрабатывающего индустриального оборудования (станки по изготовлению изделий сложных форм, типа лопаток в турбины, корабельных винтов и прочих поверхностей). Все компоненты, начиная от модулей в САПР, до прошивок, контроллеров и прочих вычислителей, куда все это заливается. Под их станки заказчики строят отдельные цеха. Там свой внутренний жесткий регламент по жизненному циклу на основе ANSI ISO/IEC вплоть до постановки на производство и никаких "молодежных" технологий.

Цитата: adolfus от 27.09.2018 09:24:13Сименс кроме технологического лидерства занимается разного рода бытовой техникой и кухонным оборудованием, где он даже не в десятке, а по чайникам и утюгам на уровне какого-нибудь ладомира или витька. Также присутствуют в цеху фейкоплетов, выпускающих IOT-холодильники и прочие пылесосы. Последние сами вызывают лакеев, которые меняют им фильтры и моют мусороприемники. Почему бы там не использовать модные "молодежные" методы разработки ПО. Хотя я не представляю, как можно использовать эти методы для разработки прошивок в те же утюги?

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

Пытаетесь выкрутиться?

Вы просто не в курсе, что даже жизненный цикл "на основе ANSI ISO/IEC" никак не ограничивает предприятие в использовании аджайл в управлении проектами. И этим пользуются и в Сименс, и в АББ и в Цейсе, где работают мои бывшие коллеги - и откуда это мне известно.

Кстати, системы управления транспортом - это ведь не относится к утюгам и кухням? Это ведь очень ответственное направление, не менее серьезное, чем турбины и станки?

Вот еще руководящая позиция  в Сименсе на этом направлении, где требуется не просто знание, но и сертификация специалиста по аджайл технологии.

Вобщем спасибо, слив защитан.

Цитата: DarkRaider от 27.09.2018 11:45:47З.Ы. как результат многолетней работы agile принципов мы сейчас имеем тонны говнокода практически в каждой используемой программе и потрясающе низкую эффективность по использованию ресурсов и солидный штат полудурков в среде программистов, ЗАТО мы все это вольно или невольно оплачиваем сами и иногда с удовольствием, чем стимулируем дальнейшее развитие данной отрасли и обеспечиваем зарплатой весь этот штат.

Вы можете доказать это ваше утверждение? Или все хайли лайкли / весь мир это знает?

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

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

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

Цитата: графит от 27.09.2018 15:56:26Вы можете доказать это ваше утверждение? Или все хайли лайкли / весь мир это знает?
Пока что никто из моих оппонентов не привел хоть один убедительный пример того, что аджайл, тдд, непрерывная интеграция, солид, кисс и прочее мешают процессу разработки или являются источником говнокода.

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

Если нужно это  доказать, укажите отдельно. Игры, банальный MS Word,  если Вы просто приведёте  примеры повседневных(возможно и профессиональных?) программ, которые стали есть меньше ресурсов и работать быстрее со временем - я с удовольствием с Вами разберу этот вопрос подробно.

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

Пока оставим в категории "весь мир знает".

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

Для этого заглянем в вики и разберём общие принципы:

Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[2]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды.

Основные идеи:

- люди и взаимодействие важнее процессов и инструментов;
  В общем то полезный общечеловеколюбивый лозунг. На заводе будет смотреться особенно уместно!

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

Очень полезные идеи при написании операционки...  впрочем что это я...  компилятора! Нет, всё равно меня зарубает...  ну ладно, интерпретатора...

Ладно, как то с примерами и правда туго, надо бы перевести принципы на понятный язык...  

Принципы, которые разъясняет Agile Manifesto[3]:

- удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
Уже через 2 недели в клиента полетит первое гавно с первым десятком кнопок, оно ещё ничего не умеет, даже дырки до СУБД ещё не проковыряли, но главное поставка!

- приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);  Любой каприз за Ваши деньги!  
Ну например, в тридевятом царстве, в тридевятом государстве, написали как то электронный дневник для школьников провели тестирование на 5 школах райцентра кукуево, всё красиво, всё работает, заказчик счастлив...  Мэра, кстати, позвали, показали...   Мэр кукуева тоже был счастлив...  и решили на всё кукукёво поставить...  сказано - сделано! Первое сентября, торжественное дёрганье рубильника...     2 сентября...  новейший электронный дневник упал и больше не поднялся...  никак...  Все забегали, засуетились... как же мол так? ведь всё ж работало...  Работало...   на 5 школах...   а когда их стало 1174, вдруг перестало...  и сделать ничего нельзя, так как архитектура не позволяет даже если на 2 ЦОДА эту хрень посадить...  Худо-бедно...  выясняют через 3 месяца секса, что оказывается, существующую платформу, нельзя переписать под новые требования по производительности, ну потому что её писало 2 студента и педагог-фанатик, в меру сил так сказать и знаний... Что поделать, надо с нуля заного писать...   больше 4х лет в нашей сказочке такая эпопея могла бы длится... зато конкурентоспособность команд программеров резко упала...  за десяток команд, в нашей сказочке, счёт перевалил...  по мере написания и обсирания...

- частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); Самое главное почаще, чтобы заказчик понимал, что работа идёт передовыми темпами!

Цитата... вот это наша новая секретарша Екатерина, печатает 600 знаков в минуту...
а вот это наша старая секретарша Антонина, печатает 1000 знаков в минуту...  такая херня получается!

- тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;


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

- рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
Главное при этом нанять хорошую службу охраны. Бывали случаи порчи мордоимущества реализатора заказчиком.

- работающее программное обеспечение — лучший измеритель прогресса;
Главное не уточнять КАК оно должно работать!

- спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
Натюрморт - "резиновый кошелёк рядом с белкой в колесе".

- постоянное внимание улучшению технического мастерства и удобному дизайну;
 Благо безумство руководства заказчика каждые 2 недели подкидывает хотелки на любой вкус.

- простота — искусство не делать лишней работы;


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

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


Ну, а теперь попробуем ответить на вопрос:
Почему же? как результат многолетней работы agile принципов мы сейчас имеем тонны говнокода, низкую эффективность, штат полудурков?

1) Вся инфраструктура разработки, обслуживает толстосумов в режиме "сделай то, не знаю что", без каких либо точных требований к заказанному.

2) К сожалению, следуя тренду, этот процесс(1) начинается с самого начала, что обычно не позволяет сделать нормально спроектированную базу проекта, которая впоследствии позволила бы обеспечивать требуемую производительность/надёжность, даже при кардинальных изменениях проекта.

3) Отсутствие нормального проектирования, управления требованиями по надёжности и эффективности приводит к тому, что на надёжность и эффективность насрать абсолютно всем "участникам похода". Заказчик - докупит лишнее железо, прогаммеры со временем исправят баги, манагеры придумают новые фичи...   всем выгодно!

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

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

(6) Пункт (5) обязывает сохранять стадность коллектива, так как директор вспомнил, что программист-сосед по стойлу использовал "вон ту херню, вон на той хреноте" - опять же есть у кого спросить! А вот на прошлой неделе, к нам привели новенького....  он супер новомодный __уэтон знает! А значит завтра, наш манагер, придумает какую нибудь фичу под _уэтон и протолкнёт её в личном общении с заказчиком. О чём нам послезавтра расскажут, на утреннем тренинге!

(7) Опять таки стадный командный дух, подкреплённый гуглом и тренингом, уже не допускает мысли о том, что при возникновении какого то сложного вопроса, можно что-то изучить, почитать и подумать. Зачем?  Всегда можно легко и просто вынести этот вопрос на обсуждение и вероятно кто то из твоих соседей уже наступал на эти грабли и разбирался, но тебе уже этого не надо делать, тебе надо его послушать, взять готовый код и понестись на крыльях ночи в новый день! Учится?  зачем?  завтра всё равно будем делать что то новое!  Неизвестное!


Впрочем, я увлёкся. Уважаемый, Графит, безусловно, доказать я Вам, ничего не смогу, так как форумы не то место, где нельзя придумать подходящий контраргумент. Но я питаю надежду на то, что, Вы, как человек (судя по Вашим предыдущим постам) здравомыслящий, сами легко поймёте разницу. Те принципы разработки и сопровождения, которые хорошо работают на 1С Торговле и прочем коммерческом прикладном ПО, могут вообще не работать в ПО боевой корабельной/авиационной системы, Мат-КАДе или в открытом проекте по управлению беспилотными летательными аппаратами. Возможно, так же, Вы, сможете представить, что ни один девелопер, даже составом всей команды включая тренера и уборщицу, не в состоянии знать тонкости процесса химической возгонки диметилацетатбромата и без предельно точного ТЗ с жёсткими требованиями по надёжности  есть все шансы получить тысяч 10-15 трупов из жителей городка окружающего завод, да, кстати, не уверен, что будет шанс поставить обновление исправляющее ошибку.

Цитата: DarkRaider от 27.09.2018 17:30:01Ну что ж, давайте попробуем доказать.
1) имеем тонны говнокода практически в каждой используемой программе и потрясающе низкую эффективность по использованию ресурсов

Если нужно это  доказать, укажите отдельно. Игры, банальный MS Word,  если Вы просто приведёте  примеры повседневных(возможно и профессиональных?) программ, которые стали есть меньше ресурсов и работать быстрее со временем - я с удовольствием с Вами разберу этот вопрос подробно.

Скрытый текст

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

Пока оставим в категории "весь мир знает".

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

Для этого заглянем в вики и разберём общие принципы:

Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[2]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды.

Основные идеи:

- люди и взаимодействие важнее процессов и инструментов;
 В общем то полезный общечеловеколюбивый лозунг. На заводе будет смотреться особенно уместно!

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

Очень полезные идеи при написании операционки...  впрочем что это я...  компилятора! Нет, всё равно меня зарубает...  ну ладно, интерпретатора...

Ладно, как то с примерами и правда туго, надо бы перевести принципы на понятный язык...  

Принципы, которые разъясняет Agile Manifesto[3]:

- удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
Уже через 2 недели в клиента полетит первое гавно с первым десятком кнопок, оно ещё ничего не умеет, даже дырки до СУБД ещё не проковыряли, но главное поставка!

- приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);  Любой каприз за Ваши деньги!  
Ну например, в тридевятом царстве, в тридевятом государстве, написали как то электронный дневник для школьников провели тестирование на 5 школах райцентра кукуево, всё красиво, всё работает, заказчик счастлив...  Мэра, кстати, позвали, показали...   Мэр кукуева тоже был счастлив...  и решили на всё кукукёво поставить...  сказано - сделано! Первое сентября, торжественное дёрганье рубильника...     2 сентября...  новейший электронный дневник упал и больше не поднялся...  никак...  Все забегали, засуетились... как же мол так? ведь всё ж работало...  Работало...   на 5 школах...   а когда их стало 1174, вдруг перестало...  и сделать ничего нельзя, так как архитектура не позволяет даже если на 2 ЦОДА эту хрень посадить...  Худо-бедно...  выясняют через 3 месяца секса, что оказывается, существующую платформу, нельзя переписать под новые требования по производительности, ну потому что её писало 2 студента и педагог-фанатик, в меру сил так сказать и знаний... Что поделать, надо с нуля заного писать...   больше 4х лет в нашей сказочке такая эпопея могла бы длится... зато конкурентоспособность команд программеров резко упала...  за десяток команд, в нашей сказочке, счёт перевалил...  по мере написания и обсирания...

- частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); Самое главное почаще, чтобы заказчик понимал, что работа идёт передовыми темпами!



- тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;


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

- рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
Главное при этом нанять хорошую службу охраны. Бывали случаи порчи мордоимущества реализатора заказчиком.

- работающее программное обеспечение — лучший измеритель прогресса;
Главное не уточнять КАК оно должно работать!

- спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
Натюрморт - "резиновый кошелёк рядом с белкой в колесе".

- постоянное внимание улучшению технического мастерства и удобному дизайну;
Благо безумство руководства заказчика каждые 2 недели подкидывает хотелки на любой вкус.

- простота — искусство не делать лишней работы;


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

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


Ну, а теперь попробуем ответить на вопрос:
Почему же? как результат многолетней работы agile принципов мы сейчас имеем тонны говнокода, низкую эффективность, штат полудурков?

1) Вся инфраструктура разработки, обслуживает толстосумов в режиме "сделай то, не знаю что", без каких либо точных требований к заказанному.

2) К сожалению, следуя тренду, этот процесс(1) начинается с самого начала, что обычно не позволяет сделать нормально спроектированную базу проекта, которая впоследствии позволила бы обеспечивать требуемую производительность/надёжность, даже при кардинальных изменениях проекта.

3) Отсутствие нормального проектирования, управления требованиями по надёжности и эффективности приводит к тому, что на надёжность и эффективность насрать абсолютно всем "участникам похода". Заказчик - докупит лишнее железо, прогаммеры со временем исправят баги, манагеры придумают новые фичи...   всем выгодно!

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

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

(6) Пункт (5) обязывает сохранять стадность коллектива, так как директор вспомнил, что программист-сосед по стойлу использовал "вон ту херню, вон на той хреноте" - опять же есть у кого спросить! А вот на прошлой неделе, к нам привели новенького....  он супер новомодный __уэтон знает! А значит завтра, наш манагер, придумает какую нибудь фичу под _уэтон и протолкнёт её в личном общении с заказчиком. О чём нам послезавтра расскажут, на утреннем тренинге!

(7) Опять таки стадный командный дух, подкреплённый гуглом и тренингом, уже не допускает мысли о том, что при возникновении какого то сложного вопроса, можно что-то изучить, почитать и подумать. Зачем?  Всегда можно легко и просто вынести этот вопрос на обсуждение и вероятно кто то из твоих соседей уже наступал на эти грабли и разбирался, но тебе уже этого не надо делать, тебе надо его послушать, взять готовый код и понестись на крыльях ночи в новый день! Учится?  зачем?  завтра всё равно будем делать что то новое!  Неизвестное!


Впрочем, я увлёкся. Уважаемый, Графит, безусловно, доказать я Вам, ничего не смогу, так как форумы не то место, где нельзя придумать подходящий контраргумент. Но я питаю надежду на то, что Вы как человек (судя по Вашим предыдущим постам) здравомыслящий и сами легко поймёте, разницу. Те принципы, которые хорошо работают на 1С Торговле и прочем коммерческом прикладном ПО, могут вообще не работать в ПО боевой корабельной/авиационной системы, Мат-КАДе или в открытом проекте по управлению беспилотными летательными аппаратами. Возможно, так же Вы сможете представить, что ни один девелопер, даже составом всей команды включая тренера и уборщицу, не в состоянии знать тонкости процесса химической возгонки диметилацетатбромата и без предельно точного ТЗ с жёсткими требованиями по надёжности - есть все шансы получить тысяч 10-15 трупов из жителей городка окружающего завод, да, кстати, не уверен, что будет шанс поставить обновление исправляющее ошибку.

Складно автор чешет. Я так не умею, так что просто яростно плюсую! Не мне одному наболело айти-проституция, когда могли бы дело делать.

Цитата: DarkRaider от 27.09.2018 11:45:47З.Ы. как результат многолетней работы agile принципов мы сейчас имеем тонны говнокода практически в каждой используемой программе и потрясающе низкую эффективность по использованию ресурсов и солидный штат полудурков в среде программистов, ЗАТО мы все это вольно или невольно оплачиваем сами и иногда с удовольствием, чем стимулируем дальнейшее развитие данной отрасли и обеспечиваем зарплатой весь этот штат.

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

Цитата: Yuri__1964 от 28.09.2018 02:55:19Ну наверно всё таки не в agile как таковом дело, а кто, как и где это применяет, у современных менеджеров горизонт планирования это проект, а зачем им больше бонус то надо получать в этом году, с их точки зрения особой необходимости в квалифицированных программистов  особой необходимости нет, а зачем мы же применяем agile, TDD, как может приложение не работать если 100% покрыто тестами оно просто обязано хорошо работать, надо просто выпустить указание обеспечить 100% ну и контролировать это, время для написания тестов можно считать равным нулю, это же всего лишь тесты там думать то не надо. Но глупо винить в этом agile

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

Цитата: Быдлокодер от 28.09.2018 10:24:14Как раз наоборот - команда нужна квалифицированная и, желательно, однородная. И есть проблемы с использованием на agile студентов-полставочников с рваным режимом работы.

Не нужна в agile квалифицированная команда, послушная нужна и управляемая. Квалифицированным в ней должен быть 1 человек, которым сложные места и дыры затыкаются, потому как в остальное время он только тимлиду мозг парит и тренеру все карты путает своим votum separatum.

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

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

Цитата: rat1111 от 07.10.2018 01:08:56Ну... Если манагер диплом МБА получал не в жмеринском всегалактическом университете - не навешает ни разу.
Основная проблема с МБА в России в том, что управление - вещь сильно культурозависимая, а курс МБА делался под вполне определенную культуру - штаты/британия и в русской культуре многие вещи оттуда - не пришей кобыле хвост в лучшем случае. Тем не менее, многие базовые вещи в этом курсе даже без адаптации вполне себе на уровне. А с учетом того, что программисты - в массе своей сильно "обамериканены" - у волосатика навешать лапшу грамотному манагеру с МБА - шансов близко к нулю.

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

Цитата: rat1111 от 07.10.2018 01:08:56Ну... Если манагер диплом МБА получал не в жмеринском всегалактическом университете - не навешает ни разу.
Основная проблема с МБА в России в том, что управление - вещь сильно культурозависимая, а курс МБА делался под вполне определенную культуру - штаты/британия и в русской культуре многие вещи оттуда - не пришей кобыле хвост в лучшем случае. Тем не менее, многие базовые вещи в этом курсе даже без адаптации вполне себе на уровне. А с учетом того, что программисты - в массе своей сильно "обамериканены" - у волосатика навешать лапшу грамотному манагеру с МБА - шансов близко к нулю.

Вы зря переоцениваете европейские дипломы.

Я, наверное еще этого не упоминал этого, но последние лет десять-пятнадцать работаю исключительно с европейскими, американскими и британскими манагерами - МБАшниками. Все там успешно "вешается" при желании. И исходя из того, что институт консалтинговых услуг, который используется как минимум на 30% для исправления косяков, из которых большинство как раз и вызвано "лапшой", процветает - никакие британо/американские МБА не являются гарантией и защитой для менеджеров.

И по поводу волосатиков - топовые ИТшники в европах выглядят как белые воротнички - дорогой костюм, часы Брейтлинг и новый Мерседес/БМВ на парковке. Никаких джинс, футболок и свитеров.

Отсюда

Создатели ботнета Mirai теперь сражаются с преступностью на стороне ФБР




Три подзащитных студента, стоявшие за ботнетом Mirai – онлайн-инструментом, учинившим разрушения по всему интернету осенью 2016 при помощи мощнейших распределённых атак на отказ от обслуживания – в четверг предстанут перед судом на Аляске и попросят судью вынести новый приговор: они надеются на то, что их заставят работать на ФБР.

Джосайа Уайт, Парас Джа и Далтон Норман, каждому из которых было от 18 до 20 лет на момент создания и запуска Mirai, в декабре признали себя виновными в создании вредоносной программы. Ботнет, завладевший доступом к сотням тысяч устройств из «интернета вещей» и объединивший их в цифровую армию, начал своё существование в качестве инструмента для атаки вражеских хостеров игры Minecraft, но впоследствии вырос до онлайн-цунами из вредоносного трафика, вырубавшего целых провайдеров хостинга. На момент его появления в разгар обвинений «русских хакеров» во вмешательстве в американские выборы многие испугались, что появился неизвестный новый враг, собирающийся обрушить интернет.

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

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

Однако нюанс заключается в том, как именно правительство хочет, чтобы они отработали свой срок: «Далее, США просят Суд, по согласованию с комитетом о Пробации, определить общественные работы в виде постоянной работы с ФБР по борьбе с киберпреступлениями и обеспечению кибербезопасности», — говорится в меморандуме приговора.

Цитата: Поверонов от 07.10.2018 12:31:53"топовые ИТшники"  это как раз и есть манагеры или UX. У нас в бэкенде обычный дрес-код джинсы (летом шорты) и длинные рубашки ( футболки только если очень фирменные ) Так ходят и администраторы, и дэвы и менеджеры команд. В самом центре Западной Европы. А на парковках нынче у многих Теслы.

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

Тесла - не самый дешевый авто, по цене вполне сравним и с Мерс и с БМВ. Обычно подразумевает наличие второй, ДВС машины. Я не встречал ни одного владельца Теслы, у кого это единственная машина. Но это, конечно, не правило, а мой личный опыт.

Цитата: графит от 07.10.2018 14:41:17У вас - возможно и так, но мне чаще встречаются организации, в которых не манагеры, а еще сеньоры и архитекты уже вынуждены забыть о джинсках и футболках, т.к. митинги с менеджментом среднего и верхнего уровня или заказчиком могут случиться спонтанно. Поэтому "волосатики" и хиппи просто не имеют шансов выбраться в сеньоры. Следование корпоративной этике и дресс-коду в карьерном росте никто не отменял.

Тесла - не самый дешевый авто, по цене вполне сравним и с Мерс и с БМВ. Обычно подразумевает наличие второй, ДВС машины. Я не встречал ни одного владельца Теслы, у кого это единственная машина. Но это, конечно, не правило, а мой личный опыт.

Как раз манагеры которые *здуна гоняют и бумажки перекладывают или впаривают товары в магазинах в основном и ходят в костюмчиках. Дресс-код - в значительной мере уже пережиДок прошлого. Зачем носить неудобныю одежду, если общаешься только с коллегами? У нас всё для людей - одевайся как хочешь в рамках приличия, даже спортзал есть. Вообще в IT компаниях дресс-код - не пришей козе рукав. Всем пофиг на одежду. Главное - навыки. На прошлой работе(связь) поначалу тоже хотели(жена гендира, рождённая в селе:)) дебильный дресс-код ввести(типа самая важная деталь в рабочем процессе), даже для монтажников, когда в офис являются, ещё до моего прихода, но не прижился.
Нормальному человеку костюм нужен только в двух ситуациях - на свадьбе и на похоронах:)

Цитата: графит от 07.10.2018 14:41:17У вас - возможно и так, но мне чаще встречаются организации, в которых не манагеры, а еще сеньоры и архитекты уже вынуждены забыть о джинсках и футболках, т.к. митинги с менеджментом среднего и верхнего уровня или заказчиком могут случиться спонтанно. Поэтому "волосатики" и хиппи просто не имеют шансов выбраться в сеньоры. Следование корпоративной этике и дресс-коду в карьерном росте никто не отменял.

Тесла - не самый дешевый авто, по цене вполне сравним и с Мерс и с БМВ. Обычно подразумевает наличие второй, ДВС машины. Я не встречал ни одного владельца Теслы, у кого это единственная машина. Но это, конечно, не правило, а мой личный опыт.

Так у вас что на митинг с топ менеджерами надо в костюме приходить странная у вас компания

Цитата: Поверонов от 07.10.2018 10:37:01Да не нужно навешивать -достаточно не соскребать ее оттуда. В сущности аджиль это манагерский жест отчаяния - закорачивание заказчика на разработчиков, с убиранием всех промежуточных манагерских прокладок в форме испорченных телефонов (вспомним скетч о раскраске перпендикулярных линий:

Да никто и не навешивает на самом деле, это всё как раз от самих менеджеров то и идёт, им нужно ускориться, отчитаться, IT-шникам то самим это и не очень то и надо.