Специфика Agile, равно как и ограниченность сферы ее применения, заключается в том, что она работает только в коллективах, в которых преобладают умные и образованные люди, лично заинтересованные в достижении некоторых общих целей. В противном случае эта методика только создает хаос и увеличивает непроизводительные расходы.
Из своего опыта могу сформулировать довольно простой тест на готовность коллектива к работе в условиях Agile. Он заключается в оценке доли руководящих работников коллектива и ведущих специалистов, которые способны на письменное формулирование запросов к своим коллегам и подчиненным в процессе выполнения своих должностных обязанностей в общедоступном трекере задач. Если доля таких сотрудников меньше 2/3 (грубо) от общего числа, то Agile не будет работать ни при каких условиях.
Поэтому на практике обычно сосуществуют различные модели взаимодействия. Умные люди обычно выстраивают неформальные отношения для решения общих задач, которые довольно точно соответствуют принципам Agile. А для взаимодействия с тупыми людьми (что начальниками, что подчиненными) выстраиваются строго официальные регламентированные отношения, чтобы обезопасить себя от подстав со стороны таких тупых сотрудников.
Не Вас, а людей, имеющих схожие с изложенными Вами мысли. Лично про Вас ничего сказать не могу, так как изложенные Вами мысли еще не означают, что именно ими Вы руководствуетесь в своей собственной жизни. Оформление же мыслей в виде статьи вполне себе может быть попыткой разобраться в собственных проблемах. Ну или желанием потроллить народ на самоизоляции.
Похоже мы вышли на уровень, когда необходимо давать определения. Начну с себя. Мне довелось побывать в роли как заказчика, так и исполнителя. При этом в обеих ролях у меня был следующий алгоритм работы с контрагентами.
Для начала оцениваю интеллект — если тупой, то прекращаю сотрудничество. Кстати, употребление более одного раза в разговоре по существу ссылок на свой профессиональный уровень является приговором о полной профнепригодности.
Далее. Если человек умный, то смотрю на уровень его любознательности. Если человек ждет, что ему принесут все на блюдечке, то расстаемся через некоторое время (это время нужно для того, чтобы вдруг у человека появится интерес). Просто нет желания в будущем постоянно пинать умного человека.
От умных и любознательных узнаю их профессиональные предпочтения, причем вне зависимости от имеющегося образования, и пытаюсь подобрать направление работы, чтобы в нем мог реализовать себя этот умный и любознательный будущий профессионал. Кстати, в своей практике технологический стек для прикладных решений всегда выбирал исходя на основе личных предпочтений наиболее умного программиста в команде.
Ну а если встречаюсь уже с готовым профессионалом, что с ним просто договариваемся о сферах ответственности и регламентах взаимодействия для решения общей задачи. В этом случае никаких ограничений нет, кроме осознанных и согласованных желаний.
Поэтому лично я с людьми, имеющими схожие с автором статьи взгляды на жизнь, даже не пытаюсь общаться, не говоря уже о выстраивании каких-то деловых отношений. Как говорится, неудачники заразны.
Ок. Тогда может быть Вы скажите, кто должен выполнять работу, которая бы могла переложить формулировки технического задания с языка бизнеса на язык программиста? И не абстрактного программиста, а команды конкретных программистов, обладающих конкретным опытом и знаниями, а также психологическими особенностями?
Согласен. Вот только данный комментарий был предназначен не для обсуждения уровня адекватности заказчиков, а наглядной демонстрации необходимости погружения программистов в специфику бизнеса. Цитата же из договора была приведена лишь для того, чтобы не было пустых разговоров, что программисты не обязаны думать о других, а другие, наоборот, должны ходить вокруг программистов, заглядывать им в рот и утирать им сопли.
Формулировка как формулировка. Да, с одной стороны цена действительно фиксируется на стадии подписании договора. Но, с другой стороны, цена не ограничена потолком, если будет экономически обоснована.
На мой взгляд такой подход довольно разумен для крупных компаний, у которых потери от невыполнения взятых на себя обязательств по основному бизнесу гораздо выше, чем экономия на вспомогательных функциях, к которым относятся и ИТ. В таких случаях сроки исполнения обязательств гораздо значимее стоимости затрат на ИТ, которая в общих издержках порой просто не различима.
Бизнес — это синоним словосочетания «изменчивость и неопределенность». Поэтому кому хочется неизменяемости требований, то нужно забыть про бизнес и идти к государству. Но там свои тараканы в головах у заказчиков, которые уж очень сильно на любителя.
Знавал я одного программиста, который постоянно требовал от заказчика заморозки бизнес-процессов, чтобы ему было комфортнее кодировать. Но со временем выяснилось, что эти требования по заморозке просто были таким подсознательным протестом из-за потери контроля над содержательным смыслом и назначением функционала, который этот программист кодировал. В результате утраты этого понимания данный программист довольно быстро самоустранился от разработки стратегии развития программного обеспечения и его архитектуры, а в конечном итоге просто сбежал из проекта, сильно подставив своих партнеров.
Если программист не может до начала проекта с запасом оценить свою работу и сроки ее выполнения, то для таких программистов и придумывают подобные формулировки, чтобы их отпугнуть еще на стадии рассмотрения договора.
Ничего дьявольского нет. Просто есть бизнес, желающий решить свои проблемы с помощью услуг программистов. И этот бизнес готов платить любые деньги, чтобы за реальные сроки (исчисляемые в годах) программисты решили эти его проблемы.
И если программисты ранее решали подобные задачи, то бизнес рассчитывает, что они могут оценить сложность и трудоемкость задачи, чтобы с запасом установить цену и сроки, а также изначально сделать масштабируемую архитектуру, чтобы не пришлось потом на каждый чих перерабатывать тонны кода без гарантий появления новых ошибок и узких мест.
И именно с такой формулировкой в договоре программисты могут рассчитывать на интересную работу и хорошую зарплату. Если такой конкретной формулировки в договоре нет, то она неявно присутствует в ожиданиях заказчиков. Но если программисты не готовы брать на себя подобные обязательства, то никто им не запрещает кодировать для души и выкладывать свои поделки на GitHub.
С другой стороны, если команда программистов берется за такой проект, то кому в такой команде нужен ведущий программист, получающий самую высокую зарплату и имеющий право давать указания другим программистам, но при этом не желающий вникать в суть проблем заказчика, которые нужно решить с помощью написания программного кода? Ответ очевиден. Таких программистов нужно сразу гнать из команды, чтобы не отравляли атмосферу своим присутствием.
Думаю, что автору еще предстоит испытать большие разочарования от жизни, потому что в реальности происходит все следующим образом (цитата взята из реального договора на разработку программного обеспечения):
Подрядчик не вправе требовать изменения Договора (цены, сроков и т.д.) при получении уточнений, если только они прямо не противоречат Договору. Бремя доказывания такого противоречия лежит на Подрядчике.
Риск удорожания Работ вследствие реализации уточнений лежит на Подрядчике как на специалисте, который, будучи более Заказчика компетентным в области квалифицированного выполнения работ, аналогичных тем, которые являются предметом Договора, не предпринял всех возможных разумных действий к конкретизации и формализации ожиданий Заказчика до заключения Договора.
Если говорить о фототехнике, то концепция профессионального фотооборудования очень напоминает JavaScript. В нем нет встроенной фотовспышки, а есть только горячий башмак. Зачастую нет автоматических режимом установки экспозиции, зато есть куча всяких разных физических кнопок и крутилок, назначение которых любителю иногда просто непонятно. Вместо одного универсального чаще всего используются несколько объективов с фиксированным фокусным расстоянием, каждый из которых используется только для определенных ситуаций. Сама по себе техника довольно массивна, а потому требует для своей переноски объемного рюкзака или специализированного кофра.
Что интересно, весь этот обвес стоит в несколько раз дороже самой тушки фотоаппарата и практически не меняется со временем, обрастая изолентой, всякими стекляшками, пластинами и подставками. И даже сама тушка фотоаппарата меняется один раз в несколько лет, когда происходит ощутимое для фотографа улучшение всех ее характеристик. Но даже к улучшению этих характеристик приходится привыкать постепенно, так как в работе профессионала крайне важны нюансы, которые делаются руками с помощью давно привычных инструментов.
И такой ряд можно продолжить для большинства профессий.
Подобные разговоры напоминают споры о том, у какого телефона круче камера. В таких спорах самое прикольное в том, что спорят на эту тему те, кто кроме фото с самим собой и фото мест, где побывал, не умеет делать больше ничего, а мастера фотографии просто делают фото-шедевры на том, что оказалось под рукой, делая мимоходом поправку на специфику имеющейся на руках техники.
В свое время для проекта JetCalc (https://github.com/leossnet/jetcalc), в котором есть и довольно сложный интерфейс, и большие серверные вычисления, мы выбрали JavaScript, и до сих пор еще не столкнулись с принципиальными ограничениями этого языка. При этом единственный факт, что сегодня JavaScript встроен во все браузеры на всех платформах, превращает его недостатки в особенности, которые нужно просто учитывать в своей работе.
Проблеме не в конструкции самого велосипеда, а в разных мелких удобствах, которые по отдельности совершенно не принципиальны, но когда их становится очень много, то они выводят этот самый велосипед на принципиально более высокий уровень.
Когда вам говорят о велосипеде, то подразумевают не его конструкцию, а количество вложенного в него труда, потому как никто не хочет платить свои деньги за велосипед, который нужно ремонтировать либо долго настраивать сразу после покупки.
Ведь советское время, когда любой новый агрегат сразу приходилось донастраивать, давно уже закончилось. И большинство людей об этом совершенно не жалеет.
Хуавей выпускает телефоны на андроиде без сервисов из коробки, но которые каждый может установить самостоятельно при первом включении. Это типа мы не при чем, пользователи сами делают все на свой страх и риск. При этом они уже вовсю пилят собственную ОС со своими сервисами, если американцы окончательно встанут в позу.
ОС Android распространяется под лицензиями GNU и Apache. Но дело в том, что сама по себе эта ОС никому не нужна. Нужны сервисы Гугла, которые заточены на работу с этой ОС. Поэтому Гугл берет деньги с производителей железа не за ОС, а за доступ к своим сервисам.
Но гугловская ОС нужна исключительно как прокладка между железом и ява-машиной. А потому данный ограниченный функционал вполне себе можно запилить и забесплатно, рассчитывая получать деньги за сопутствующие услуги.
Делать же забесплатно полноценный функционал на ядре linux для настольного ПК дураков нет. Так как для сбора денег с такой аудитории нужно больше людей и времени, чем собственно на написание качественного кода.
Ок, подловили в неравнодушии к FreeBSD. Тем не менее, Википедия пишет:
macOS значительно отличается от предыдущих, «классических версий» Mac OS. Основа системы — POSIX-совместимая операционная система Darwin, являющаяся свободным программным обеспечением. Её ядром является XNU, в котором используется микроядро Mach и стандартные службы BSD.
Проблема Linux не в разработчиках, а в ортодоксальной лицензии GNU. Ведь что такое MacOS? Это допиленная FreeBSD, не имеющая ограничений на коммерческое использование программного кода.
Поэтому судьба Linux с лицензией GNU — оставаться платформой, на которой деньги зарабатываются не напрямую, а опосредованно через железо, услуги, обучение и т.п. А в такой модели лицензирования относительная сложность Linux для слабоподготовленного в ИТ пользователя экономически выгодна всем без исключения профессиональным разработчикам, использующим Linux не для развлечения, а для содержания себя и своей семьи.
Из своего опыта могу сформулировать довольно простой тест на готовность коллектива к работе в условиях Agile. Он заключается в оценке доли руководящих работников коллектива и ведущих специалистов, которые способны на письменное формулирование запросов к своим коллегам и подчиненным в процессе выполнения своих должностных обязанностей в общедоступном трекере задач. Если доля таких сотрудников меньше 2/3 (грубо) от общего числа, то Agile не будет работать ни при каких условиях.
Поэтому на практике обычно сосуществуют различные модели взаимодействия. Умные люди обычно выстраивают неформальные отношения для решения общих задач, которые довольно точно соответствуют принципам Agile. А для взаимодействия с тупыми людьми (что начальниками, что подчиненными) выстраиваются строго официальные регламентированные отношения, чтобы обезопасить себя от подстав со стороны таких тупых сотрудников.
В качестве дополнения привожу ссылку на методические основы применения трекера задач, которые использую в своей практике.
Для начала оцениваю интеллект — если тупой, то прекращаю сотрудничество. Кстати, употребление более одного раза в разговоре по существу ссылок на свой профессиональный уровень является приговором о полной профнепригодности.
Далее. Если человек умный, то смотрю на уровень его любознательности. Если человек ждет, что ему принесут все на блюдечке, то расстаемся через некоторое время (это время нужно для того, чтобы вдруг у человека появится интерес). Просто нет желания в будущем постоянно пинать умного человека.
От умных и любознательных узнаю их профессиональные предпочтения, причем вне зависимости от имеющегося образования, и пытаюсь подобрать направление работы, чтобы в нем мог реализовать себя этот умный и любознательный будущий профессионал. Кстати, в своей практике технологический стек для прикладных решений всегда выбирал исходя на основе личных предпочтений наиболее умного программиста в команде.
Ну а если встречаюсь уже с готовым профессионалом, что с ним просто договариваемся о сферах ответственности и регламентах взаимодействия для решения общей задачи. В этом случае никаких ограничений нет, кроме осознанных и согласованных желаний.
Поэтому лично я с людьми, имеющими схожие с автором статьи взгляды на жизнь, даже не пытаюсь общаться, не говоря уже о выстраивании каких-то деловых отношений. Как говорится, неудачники заразны.
На мой взгляд такой подход довольно разумен для крупных компаний, у которых потери от невыполнения взятых на себя обязательств по основному бизнесу гораздо выше, чем экономия на вспомогательных функциях, к которым относятся и ИТ. В таких случаях сроки исполнения обязательств гораздо значимее стоимости затрат на ИТ, которая в общих издержках порой просто не различима.
Знавал я одного программиста, который постоянно требовал от заказчика заморозки бизнес-процессов, чтобы ему было комфортнее кодировать. Но со временем выяснилось, что эти требования по заморозке просто были таким подсознательным протестом из-за потери контроля над содержательным смыслом и назначением функционала, который этот программист кодировал. В результате утраты этого понимания данный программист довольно быстро самоустранился от разработки стратегии развития программного обеспечения и его архитектуры, а в конечном итоге просто сбежал из проекта, сильно подставив своих партнеров.
Чтобы не повторяться, также см. habr.com/ru/post/501244/#comment_21595036
И если программисты ранее решали подобные задачи, то бизнес рассчитывает, что они могут оценить сложность и трудоемкость задачи, чтобы с запасом установить цену и сроки, а также изначально сделать масштабируемую архитектуру, чтобы не пришлось потом на каждый чих перерабатывать тонны кода без гарантий появления новых ошибок и узких мест.
И именно с такой формулировкой в договоре программисты могут рассчитывать на интересную работу и хорошую зарплату. Если такой конкретной формулировки в договоре нет, то она неявно присутствует в ожиданиях заказчиков. Но если программисты не готовы брать на себя подобные обязательства, то никто им не запрещает кодировать для души и выкладывать свои поделки на GitHub.
С другой стороны, если команда программистов берется за такой проект, то кому в такой команде нужен ведущий программист, получающий самую высокую зарплату и имеющий право давать указания другим программистам, но при этом не желающий вникать в суть проблем заказчика, которые нужно решить с помощью написания программного кода? Ответ очевиден. Таких программистов нужно сразу гнать из команды, чтобы не отравляли атмосферу своим присутствием.
Что интересно, весь этот обвес стоит в несколько раз дороже самой тушки фотоаппарата и практически не меняется со временем, обрастая изолентой, всякими стекляшками, пластинами и подставками. И даже сама тушка фотоаппарата меняется один раз в несколько лет, когда происходит ощутимое для фотографа улучшение всех ее характеристик. Но даже к улучшению этих характеристик приходится привыкать постепенно, так как в работе профессионала крайне важны нюансы, которые делаются руками с помощью давно привычных инструментов.
И такой ряд можно продолжить для большинства профессий.
В свое время для проекта JetCalc (https://github.com/leossnet/jetcalc), в котором есть и довольно сложный интерфейс, и большие серверные вычисления, мы выбрали JavaScript, и до сих пор еще не столкнулись с принципиальными ограничениями этого языка. При этом единственный факт, что сегодня JavaScript встроен во все браузеры на всех платформах, превращает его недостатки в особенности, которые нужно просто учитывать в своей работе.
Когда вам говорят о велосипеде, то подразумевают не его конструкцию, а количество вложенного в него труда, потому как никто не хочет платить свои деньги за велосипед, который нужно ремонтировать либо долго настраивать сразу после покупки.
Ведь советское время, когда любой новый агрегат сразу приходилось донастраивать, давно уже закончилось. И большинство людей об этом совершенно не жалеет.
Но гугловская ОС нужна исключительно как прокладка между железом и ява-машиной. А потому данный ограниченный функционал вполне себе можно запилить и забесплатно, рассчитывая получать деньги за сопутствующие услуги.
Делать же забесплатно полноценный функционал на ядре linux для настольного ПК дураков нет. Так как для сбора денег с такой аудитории нужно больше людей и времени, чем собственно на написание качественного кода.
Поэтому судьба Linux с лицензией GNU — оставаться платформой, на которой деньги зарабатываются не напрямую, а опосредованно через железо, услуги, обучение и т.п. А в такой модели лицензирования относительная сложность Linux для слабоподготовленного в ИТ пользователя экономически выгодна всем без исключения профессиональным разработчикам, использующим Linux не для развлечения, а для содержания себя и своей семьи.