вторник, 27 октября 2020 г.

[work] Наткнулся тут на невероятное...

В поисках информации о "спиральной динамике" нашел такого автора на vc.ru: Максим Цепков. А среди его статей ознакомился вот с этой: "Реальность цифрового мира: проекты делает некомпетентная команда". И вот в этой статье практически сходу споткнулся о пару-тройку моментов, которые заставили всерьез задуматься о том, а не сказочный ли пишет все эти буквы? Уж простите мне мой французский, но запись в блог сразу после прочтения, еще под свежими впечатлениями.

Итак, цитата:

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

Оказывается, для этого уже давно есть методы. Первые из них появились, естественно, в IT как раз тогда, когда было осознанно, что регламенты и правила не работают, а ключевым фактором успеха является человеческий фактор. Об этом есть классическая книга Тома ДеМарко «Peopleware» (1987), которая в русском переводе так и называется «Человеческий фактор».

И как ответ на эту ситуацию появился Agile. Он взлетел именно поэтому, что появился во время прихода персоналок. Персоналки ведь пришли не домой, они сделали компьютеры доступными для мелких и средних компаний. И потребовалось массово автоматизировать бизнес, возник дефицит разработчиков. Их не было, выпуск институтов не увеличился. И именно Scrum и Agile обеспечили решение этой проблемы, позволив успешно делать проекты некомпетентной командой. Это был один из ключевых факторов их успеха и широкого распространения. В России, кстати, мы это не очень ощутили, потому что именно тогда, в период появления персоналок, развалилась оборонка и много квалифицированных инженеров ушли в айтишники, они демпфировали этот кризис.

Что меня здесь смущает?

Первое. Agile и персоналки. Если я правильно помню, то первопроходцы Agile делали приснопамятную систему расчета компенсаций для Крайслера в 1993-1999 годах как раз таки не для персоналок вообще, а для мейнфреймов. Могу ошибаться, поэтому если кто-то владеет информацией лучше меня, то поправте плиз.

Далее, период развития интереса к Agile, начиная с появления Agile Manifesto -- это уже нулевые годы. Когда у персоналок был не то, чтобы приход. Они уже давно пришли. А приход тогда как раз был у Web-а. И именно в конце 1990-х и начале нулевых стартовал и нарастал массовый переход от десктопа к Web-у. В условиях когда не было ни толком развитых Web-технологий, ни опытных Web-разработчиков, зато спрос на Web-разработку был сумасшедший. Так если уж благодаря чему-то Agile и взлетел, так это благодаря Web-разработке.

Второе. Что-то мне трудно припомнить, чтобы в 1990-е в России после распада оборонки квалифицированные инженеры массово уходили в айтишники. При том, что как раз в оборонке до 1990-х огромное количество разработчиков и трудилось. А потом осталось без куска хлеба. В прямом смысле. И поэтому уже существующие профессиональные кадры разбегались и выживали кто как может: кто-то уехал, кто-то переквалифицировался на бух- и складской учет (dBase/FoxBase/Clarion, а затем и 1C с Галактикой и Ко), кто-то ушел в преподавание, кто-то смог уйти в сисадмины (в банках в то время был большой спрос), кто-то тупо торговал широпотребом на рынке.

Так что как-то с моими воспоминаниями ну никак не бьется. Но я и не из России. Поэтому опять же, вопрос к более знающим людям: действительно ли в 1990-х квалифицированные инженеры из оборонки в РФ уходили в айтишники?

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

3 комментария:

Alexander Stavonin комментирует...

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

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

eao197 комментирует...

@Alexander Stavonin

У меня сейчас цель в том, чтобы посмотреть на Agile с нескольких точек зрения:

1. Причины возникновения и первоначальные цели/способы применения. Как мне представляется, Agile методы возникли как реакция не на некомпетентность, а на кризис производства (причем не только, да и не столько ПО). Т.е. в 1980-х и 1990-х резко вырос спрос, а существующий технологический уклад (в частности, методы производства) не могли этот спрос удовлетворить. И нужен был какой-то резкий технологический скачек, который бы помог преодолеть текущий кризис.

В результате появились Agile подходы к производству, авторы которых исходили из более чем прагматичных соображений: мол, если мы не можем a) предсказать скачи запросов от потребителей и b) не можем использовать старые методы для преодоления резких внезапных скачков, то давайте откажемся и от планирования "в долгую" и от размеренного технологического процесса. А займемся тупо разруливанием внезапных проблем здесь и сейчас, затрачивая на каждую проблему минимум средств.

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

Это уже затем Agile стали пробовать применять и в софтостроении.

2. Во что со временем превратилось Agile в мире разработки ПО. И это вообще отдельная тема для осознания. Т.к., на мой взгляд, из квинтэссенции здравого смысла, коей Agile был изначально (т.е. делаем тот минимум, который можем, пробуем, если получилось, то делаем следующий маленький шажок, если не получилось, то быстро анализируем причины и переделываем, но опять по минимуму), гибкие методы сейчас превратились в какие-то религиозные верования секстанского толка.

Т.е. из "пофиг на формальности, главное выжить" Agile скатилось в религиозные войны о том, что "если у вас scrum без вот этой вот штуки, то у вас и не scrum вовсе". И в крестовые походы под знаменами "кто не в Agile, тех на костер!".

Применительно же к статье (даже к статьям Максима Цепкова) у меня вопрос такой: если человек в своих построениях исходит из неверных фактов (как то: приход Agile был обусловлен переходом на персоналки и в 1990-х в РФ был переход не-айтишников в айтишники), то насколько достоверны выводы, который Цепков строит.

И вот как раз по поводу достоверности фактов у меня есть сомнения.

Skynin комментирует...

Все как-то напутано

Впервые контр предложение именно для разработки ПО озвучено Ройсом. где для контраста он создал соломенное чучело "водопадная модель" Ее в таком виде тоже не было, он там и писал об этом. Но аджайлисты продолжают воевать с этим чучелом.

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

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

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