Не знаю, как в других странах, а у нас любят увлекаться идеей использовать какой-то, довольно узкий, инструмент, как панацею.
Получилось забить гвоздь молотком – получилось. Давайте попробуем с помощью молотка почистить фарфоровую посуду от налета. Ну очевидно же!
Не избежал этой участи и пресловутый Agile. Так называемые гибкие методологии разработки. Сработало в узком сегменте простых IT проектов – давайте везде его применим! В промышленности, в обучении – всюду, куда фантазии хватит его вставить.
А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.
Тезис: agile – только для простых проектов!
Одно из главных правил Agile-методологий – команда-исполнитель принимает от заказчика изменения/ дополнения на любой стадии проекта.
Простыми словами – заказчику не нужно напрягать голову в момент согласования заказа – приходи хоть через месяц, хоть через год, и говори: «Ой, я забыл совсем – вот тут нужно еще добавить вот это, а вот это должно быть не зеленым, а коричневым». И команда-исполнитель это должна принимать.
Выгодно это заказчику? Конечно, заказчику это выгодно. Выгодно это исполнителю? Очевидно, что нет. Лишняя работа за бесплатно.
Но проблема, на самом деле, еще глубже, чем дополнительные нагрузки на исполнителей. Дело в том, что гибкие методологии можно использовать только на простых проектах. И категорически противопоказано их использовать на сложных.
Два простых примера
Первый пример
Приходит заказчик (мэрия города) в артель, занимающуюся изготовлением уличного инвентаря, и говорит: «Мы открываем новый парк в N-ском районе, нам нужно для парка 20 лавок, каждая лавка должна быть рассчитана на 3-х человек».
Артельщики говорят: «Не вопрос – у лавки будет одна секция и две опорные металлические стойки. Вот дизайн, вот стоимость, срок – 3 недели».
Мэрия говорит: «По рукам».
Второй пример
Приходит какой-нибудь умник с мешком денег в аэрокосмическое агентство условной страны Y и говорит: «Хочу организовать туристический маршрут на орбиту – нужна ракета, способная брать на борт 3-х человек».
В агентстве умнику говорят: «Хорошо, вот вам смета, вот сроки – 5 лет».
А теперь применим правило гибких методологий – прием изменений в проект на любых стадиях проекта.
В первом примере.
Приходит заказчик (мэрия города) в артель через две недели после начала работы и говорит: «Вы знаете, мы просчитались, в N-ском районе живет в два раза больше людей, поэтому нам нужно для парка 20 лавок не по 3 человека на лавку, а по 6».
Артельщики говорят: «Не вопрос – нам нужно будет для лавки 2 секции, вместо одной, и 3 стойки вместо двух. Мы уже купили короткие доски, а нам теперь нужны длинные. Оплачивайте дополнительные стойки, уже купленные короткие доски и новые длинные и все сделаем».
Т.е. стоимость проекта вырастет более чем на 50% от первоначальной сметы, но, во всяком случае, проект может быть выполнен и будет выполнен в заявленные сроки – никаких существенных препятствий для этого нет.
А теперь посмотрим, что произойдет во втором примере.
Приходит умник в аэрокосмическое агентство через 2 года после начала проекта и говорит: «Вы знаете, я пересчитал бизнес-план, мне мало 3-х человек, мне нужно выводить на орбиту минимум шесть, чтобы проект был рентабельным».
Ракетчики смотрят на умника как на идиота и говорят: «Вы понимаете, что это совсем другая задача? Если будет не 3 человека, а 6 – это не только увеличение выводимой на орбиту массы в два раза, это еще и дополнительный запас кислорода, это увеличение жилого пространства в ракете в 2 раза, это увеличение топливных баков, это другая обшивка – это совершенно новый проект! Более того, сейчас не только таких двигателей может не быть, может еще просто не существовать технологий, чтобы их строить.
Итого, что в итоге – простые проекты по гибкой методологии делать можно. Сложные – только по каскадным методологиям (Waterfall) – c четким ТЗ изначально.
У всех методов есть рамки применения. Они не универсальны. Нужно об этом всегда помнить.
Комментарии (73)
MiraclePtr
19.09.2023 20:29+7agile – только для простых проектов
А на самом деле ровно наоборот. Вотерфол отлично подходит для небольших проектов - где и список требований/спецификаций не настолько огромный, и где за время разработки сама ситуация, влияющая на эти требования/спецификации, не успеет сильно поменяться.
А Agile хорошо заходит именно для больших проектов. Во-первых, сейчас мир очень ускорился и очень переменчивый. Как уже сказано, за те год-два-три, что вы что-то пилите "от и до", ситуация может измениться значительно - конкуренты выкатят какую-то этакую киллер-фичу или революционную идею, изменятся требования законодательства, да и куча всего другого может изменится - и конечный продукт по тем требования/спецификациям, то вы утверждали в начале разработки, будет уже просто никому не нужен.
Во-вторых да, тут известная проблема с заказчиками: клиент приходит к вам со списком хотелок, которые условно говоря сформулированы на 5 страницах. Потом бизнес-аналитики или технологи это все дело внимательно читают, задают вопросы, смотрят как что сделано у конкурентов разговаривают с инженерами, сверяются с отраслевыми стандартами, и т.д., в итоге превращают эти 5 страниц требований в 50 (а то и в 150), и отдают это ТЗ обратно заказчику на согласование. Проблема в том, что закзачик практически всегда это итоговое ТЗ или особо не читает, или читает, но при этом все равно представляя какую-то картину, которая у него была с самого начала в голове, натягивая на нее все написанное. И когда после долгого времени разработки по утвержденному ТЗ все готово, то... оказывается, что нужно было вообще совсем другое. И заказчик в печали. Разработчики, кстати, тоже будут демотивированы - так долго делали, столько старались, а в итоге результат всей этой работы придется выкидывать и переделывать. Можно, конечно, сказать заказчику, мол, сам дурак, какое ТЗ такой и результат, сами утвердили и подписали, вот только заказчики от этого не изменятся, а просто пойдут со своими мешками денег к тем, кто более гибкий (неспроста Agile - это именно "гибкие" методологии), а вы останетесь без заказов. А "гибкие" товарищи гораздо быстрее адаптируются - склепали быстренько прототип, показали клиенту, приняли отзывы и правки, доработали, пошли пилить дальше. И все довольны. Мы к чему-то такому пришли ещё лет так 15 (!) назад, когда в нашей провинции, где я тогда жил и работал, даже ещё слов таких как "аджайл" не знали - просто пришли к этому опытным путем, и это оказалось реально эффективнее. Нашими заказчиками были большие нефтяные компании (мы делали системы диспетчеризации нефтепромыслов). Наши конкуренты работали именно по вотерфолу - согласовали, утвердили, через полгода-год приехали на развертывание и наладку. Мы же за месяц-два пилили черновик очередной фичи, приезжали на промысел, показывали начальству, технологам, диспетчерам, выслушивали, обсуждали, принимили предложения, дорабатывали как просят, и ехали домой делать следующую фичу - и нашей системой заказчики (разные) в итоге были гораздо более довольны, отзывались гораздо теплее, и "проталкивали" дальше гораздо активнее. А конкуренты, кстати, в итоге после очередного кризиса почти что закрылись, коллектив вышел на мороз, а из разработки выкупила другая контора. Такие дела.
Ravager
19.09.2023 20:29+6Компании не понимают смысла аджайл. Он ведь про результат и людей, а не процессы и регламенты. А ты куда не придёшь везде одно и то же. 2х недельный спринт без возможности что-то сдвинуть даже если нужно. Аджайл на бумаге, а в голове бюрократия.
MiraclePtr
19.09.2023 20:29-1А ты куда не придёшь везде одно и то же
Эм... Ну у меня обратный опыт. Везде, где я работал, там где использовали Agile, никто не принимал Scrum и подобное как неписанную библию. Из недавнего - команда решила, что во-первых спринтовые церемонии (планнинги, ретро, и т.д.) занимают слишком много времени, а стори, наоборот, в две недели иногда не укладываются - в итоге менеджеры согласились и теперь спринты по 3 недели, а некоторые специальные (например, отдельно выделенные под рефакторинг) даже по 4.
alexrozen
19.09.2023 20:29+1Ещё часто хотят взять от scrum то, что выгодно, например жёсткие коммиты по срокам доставки, но не соблюдать то, что неудобно - не вклинивать в спринт "срочные задачи" (мол, ну это же небольшой фикс на один час, и это горит на проде) или вообще игнорировать основные принципы agile manifesto - строить людей вокруг процессов, а не наоборот, или составлять план с диаграммой Ганта вместо "responding to change" и т.п
grumbler70
19.09.2023 20:29А конкуренты, кстати, в итоге после очередного кризиса почти что закрылись, коллектив вышел на мороз, а из разработки выкупила другая контора
А ваши заказчики, были бы помельче, остались бы без шатнов, но довольные. Agile в данных примерах - растянутая по всемени нечестная продажа.
buharof Автор
19.09.2023 20:29Я не знаю, насколько сложный проект у вас был с диспетчеризацией нефтепромыслов. Подозреваю, что просто нужно было визуализировать поступающие в БД в перманентном режиме сигналы с датчиков и все это выводить на экраны диспетчеров (в смысле, сотрудников-технологов, которые агрегатные состояния отслеживают). Если так - то это простой проект. За неделю разработки вывести на экраны все критические датчики - давление/ вибрация в черно-белом виде (условно). На следующей неделе раскрасить их и еще каких-нибудь приблуд добавить. Вот если бы вы разрабатывали АСУ самого нефтепромысла - т.е. управление самими агрегатами выкачки нефти, с учетом давлений, с кучей гидро/ пневмоприводов/ кучей электрики - вы бы на это смотрели совсем иначе. Предположу, что вы автоматизацией производственных процессов (доменная печь, прокатный стан etc.) никогда не занимались? Верно?
Почему-то у вас обязательно ватерфолл - это год-два разработки. А это всего лишь концепт, в нем не прописано, что он "долгий". В нем прописано, что сначала согласовываем, потом делаем.
Понятное дело, что заказчику нравится идея головой не думать - поэтому, в том числе, идея приносить хотелки до конца проекта так популярна. И владельцу конторы-разработчика нравится - заказов больше и того же тех. писа нанимать не надо - сами все сделают.
MiraclePtr
19.09.2023 20:29Верно
Нет, не просто. Первая часть да, сбор данных с разных железок (в том числе с диковинными никому неизвестными протоколами, передача данных по радиоканалу с огромными потерями, когда в каждый пакет нужно запихнуть данных по-максимуму, автоматический выбор алгоритмов маршрутизации через ретрансляторы, если часть ретрансляторов ушла из эфира, и т.д.). Но и довольно много было непосредственно "на месте" - управление гидроприводами АГЗУ, причем там шла именно связка с верхним уровнем - не просто каруселькой по кругу, а если скважина режимная, наступило ее время по режиму, с КТПНа пришел сигнал о том что насос запустился, то гидропривод переводится на нее вне очереди, но остальная очередь (включая то что нащелкал диспетчер) сохраняется. Плюс интерактивные вопросы диспетчеру типа "произошло то-то и то-то, что делать будем?", и куча разных комбинаций. Математика (расчет обводненности) на месте по данным с массомеров. Управление насосами накачки реагента в скважины. Динамометрирование для штанговых насосов. Аналитика сырых данных с ЭЦН для технологов. Детектирование утечек на трубе по волнам давления. Там действительно каждый код на каждом новом промысле заказчики (не один, их было много) подкидывали что-то новое, сильно веселее чем просто взять данные со вторички и вывести на скаду.
Почему-то у вас обязательно ватерфолл - это год-два разработки.
Как хорошо сказали ниже, "В такой срок я оцениваю разработку средних размеров проекта, включая написание ТЗ и приёмку."
buharof Автор
19.09.2023 20:29+1Мне не очень верится, что до опасного производства (скважины, тем более нефть) могли допустить людей без предварительных барьеров безопасности (аджайл без подробнейшей документации и подобное). Тем более случайных, с улицы.
MiraclePtr
19.09.2023 20:29Там не только нефть, но и газ. В тех местах, что мы автоматизировали, почти не было ничего опасного, в худшем случае гидропривод сгорит или ЭЦН остановится, а где и было (например, при наполнении ёмкостей до уровня) - софтовые защиты дублировались существующей резервной автоматикой (например релейной), но такие места можно было по пальцам пересчитать.
Можете верить, можете нет, мне плевать, главное что я все это видел своими глазами и делал своими руками.
zodchiy
19.09.2023 20:29+6Как-то пришел работать компанию где решили делать теперь по эджайлу (как они это понимали) буквально за 2 месяца до моего прихода. Код отличный, фронт и бек по своим паттернам, весь код понятен и практически самодокументирован. 2 недели вкатывался в код. Начал брать задачи.
Спринты, митинги каждый день. Только задачи разбиты даже не по часам, а иногда по 10 минут. Спринт на 2 недели опаздывает на 2 недели. Каждый раз. Оценки задачи ставит руководитель разработки.
Смотрю задачу - "клиенту не нравится цвет кнопки, поменять", срок - 10 минут. Ок, поменять на какой? Нужно согласование, 4 раза пытался связаться с тем, кто принимает решение, это как понятно сам руководитель разработки. Переключаясь на другие задачи в которых был такой-же бред, где нужно было что-то спрашивать у тестировщиков, что-то у других разработчиков. Итого на код я потратил минут 30-40 за день, на согласование и переключение между контекстам и и задачами еще 8 часов. Пытался что-то втолковать руководителю разработки, что так не делают, что на проекте из пяти человек трое ушло за два месяца, что ваши оценки промахиваются в 2-3-5-10 раз - ответ один - мы так делали 10 лет, мы так привыкли работать, не нравится - уходи. Ушел.
Lendcore
19.09.2023 20:29+1Итого на код я потратил минут 30-40 за день
Касаемо согласования, вопрос спорный. Представьте, что вы без предварительного согласования сделали кнопку за 10 минут, отправили задачу на проверку принимающей стороне, зада некоторое время у нее лежит, после чего, она ее смотрит (тоже тратит время время) и возвращает ее вам, вы ее снова правите, и снова двигаете задачу на проверку и хорошо, если ее со второго раза примут. В итоге выиграете ли вы этим что то, оставлю вопрос открытым
lebedec
19.09.2023 20:29+3Речь о том что извращенное представление Agile методик исключает анализ задач как сложный и дорогой этап разработки, заменяя его "легковесными обсуждениями" по любому поводу.
В примере zodchiy задача была бы выполнена реально за 10 минут без согласований, если бы аналитик (дизайнер) изначально написал в задаче необходимый цвет.
VladimirFarshatov
19.09.2023 20:29-1Вопрос оценки стоимости задачи по времени разработки - вообще интересен сам по себе. Сколько ни работаю, ещё ни разу не видел полноценно правильной оценки до начала работы, если не считать простые задачи типа поменять цвет, дополнить код выводом логов и т.п.
Даже помнится было такое "правило": "Если программист называет срок, к примеру час работы, то его надо перевести в следующий временной порядок и умножить на 3.14.. " как-то так.. ;)
А то, что двухнедельный спринт опаздывает на 2 недели .. а где иначе в больших проектах? Согласование .. до недели приходилось ждать.
Ravager
19.09.2023 20:29сильно зависит от команды и ее погружённости в проект. на старте конечно это бессмысленно.а дальше если принять за аксиому что оценка выше 3х дней должна дополнительно ресерчиться и декомпозироваться - это дает неплохие результаты и минимальную дисперсию от ожидаемого срока.
VladimirFarshatov
19.09.2023 20:29На ресерч и декомпозицию, и как следствие, появление новых задач по итогу декомпозиции, их обсуждению и встраиванию в спринт .. потеряете много больше времени, чем на тупой кодинг в течение трех дней. Проверено много раз, особенно в ситуации, на которую я и отвечал: согласование идет долго, а часто это не только "ближайший насяльник" (тим лид), но и ещё пара-тройка от девопс, от QA, от Заказчика..
Ravager
19.09.2023 20:29писать правильно и хорошо тоже потеря времени, гораздо быстрее тяп-ляп и в продакшен, желательно без тестов. мною проверено много раз что детальная декомпозиция иногда приводит к пересмотру проекта, сроков и способу реализации впринципе. потому что "вроде изян" это как раз и выливается в 100 часов.
VladimirFarshatov
19.09.2023 20:29работать вообще - потеря времени, ибо мгновенно и само ничегго не происходит. Писать в любом случае стоит, кмк, не тяп-ляп а как можно лучше: "старайся делать хорошо, плохо получится само". Это общие замечания, относятся как к трехдневному кодингу, так и варианту ресерч и декомпозиция. Только второй вариант вносит дополнительный издержки, часто бесполезные от слова совсем. Тоже проверено жизнью:
-"Подожди не пиши, ща мы это обсудим и согласуем. Тут надо ресерчить и спросить Заказчика" .. ага, три раза .. пока согласовывали сваял код .. как раз, те самые три дня. В итого: "Во, надо будет делать вот так..".
-"Ага, забирайте. Сделано уже".
MiraclePtr
19.09.2023 20:29извращенное представление Agile методик исключает анализ задач
ну это именно извращенное представление. по-хорошему Agile совсем не исключает анализ задач и написание-согласование спецификаций
fizteh147
19.09.2023 20:29+1Итого, что в итоге – простые проекты по гибкой методологии делать можно.
Сложные – только по каскадным методологиям (Waterfall) – c четким ТЗ
изначально.Позвольте с вами не согласиться. Agile - это не только про прием изменений в проект. А даже если смотреть с точки зрения приема изменений: Если вдруг через два года разработки появились новые материалы, движки, топливо и т.д. и это можно применить в сложном проекте?
Сложные проекты тоже можно и нужно делать по Agile для повышения эффективности разработки. Но если вы не умете готовить Agile - может не надо натягивать сову на глобус?
VladimirFarshatov
19.09.2023 20:29+3А кто умеет? Приведите конккретный пример повышения эффективности разработки от применения этого подхода... т.с. "огласите часть списка", но конкретно: было - стало. С цифирьками..
fizteh147
19.09.2023 20:29-1Всё зависит от масштабов. В масштабе себя самого я умею готовить. И даже есть пример по снижению потребления экранного времени телефона с 11 часов в день до 5-6 часов. Это не про разработку, но по сути 5-6 часов потребления соцсетей стали полезными делами.
Теоретически эту историю можно отмасштабировать в разработке на команду и на компанию, но практического опыта нет.
buharof Автор
19.09.2023 20:29+1А это вопрос не ко мне. Я вообще не хочу "готовить" аджайл. Минусы расписал в статье. Это менеджмент компаний стремится его "готовить", пытаясь натянуть сову на глобус.
Akela_wolf
19.09.2023 20:29+9По моему опыту, Agile - это попытка продать историю о том что можно начать со строительства одноэтажного бунгало, а затем, при необходимости, перестроить его в многоэтажный жилой дом, а затем - в небоскреб.
Разумеется, заказчику это нравится - не надо думать о будущих потребностях, не надо далеко планировать. Ведь если потребуется - мы достроим еще пару этажей, эджайл же.
А вот разработчикам приходится либо натыкаться на ограничения архитектуры, подпирая небоскреб костылями и привязывая к крыше воздушные шары (иначе рухнет к чертям), либо заранее закладывать фундамент под небоскреб, на котором гордо стоит сарай по цене "Боинга".
В реальности, разумеется, иногда удается перестроить сарай в небоскреб, постепенно заменяя фундамент и всю внутреннюю структуру. Но есть и обратные примеры, когда проекты более чем успешно умирали под грузом технического долга, когда становилось выгоднее "выкинуть и написать заново" чем развивать проект дальше.
Leetc0deMonkey
19.09.2023 20:29+10По моему опыту, Agile - это попытка продать историю
Это попытка заказчика переложить ответственность "я сам не знаю чего хочу" на исполнителя.
grumbler70
19.09.2023 20:29+1Это очень удобный способ доить заказчика, подсаживая его на вечные доработки.
Я эту схему уже расписывал тут: https://habr.com/ru/articles/594897/Не сильно-то порядочный подход, IMHO
MiraclePtr
19.09.2023 20:29Эти заказчики платят деньги, а других заказчиков и нет, и вы их не переделаете (они просто уйду к более сговорчивым конкурентам), придется научиться жить с такими.
Leetc0deMonkey
19.09.2023 20:29а других заказчиков и нет,
О как. Неужели закат айти уже на горизонте?
и вы их не переделаете (они просто уйду к более сговорчивым конкурентам), придется научиться жить с такими.
Т.е. менеджмент не делает свою работу по обработке заказчика, а разгребают пусть лоховатые ойтишнеги бегом вприсядку.
MiraclePtr
19.09.2023 20:29Неужели закат айти уже на горизонте?
И не надейтесь. "Других нет", это не значит что "таких" мало.
а разгребают пусть лоховатые ойтишнеги бегом вприсядку.
Менеджмент не всесильный чтобы менять человеческую природу, а ойтишнегам вообще пофиг, что заказали, то и получили, главное платите за жопочасы.
Leetc0deMonkey
19.09.2023 20:29главное платите за жопочасы.
Да, конечно. Типа оставайтесь после работы и выходите в выхи. За что ж вам такие деньжища-то платят. Которые вот после такой переоценки не такие уж деньжища получаются.
MiraclePtr
19.09.2023 20:29Типа оставайтесь после работы и выходите в выхи.
Ан нет. Work-life balance же. У нас в европах после 4-5 часов вечера в офисе и в онлайне уже вообще никого, а уж о том чтобы выйти выхи менеджеры вообще заикнуться боятся.
Leetc0deMonkey
19.09.2023 20:29У нас в европах
Ну вот с этого и надо было начинать.
MiraclePtr
19.09.2023 20:29Да я бы не сказал, что когда я работал в РФ (правда тоже преимущественно в филиалах иностранных компаний) ситуация чем-то сильно отличалась.
buharof Автор
19.09.2023 20:29У вас мама/ папа слесарь на заводе/ домохозяйка? Каким образом вы попадали преимущественно в филиалы иностранных компаний?
MiraclePtr
19.09.2023 20:29+1Эм... А что в этом сложного? 1. Откликаетесь на вакансию 2. Проходите интервью. 3. Получаете оффер.
Короче говоря, ровно точно так же, как и в российские компании. Сейчас, понятно дело, большинство этих иностранных компаний из РФ ушло, но раньше попасть на работу в них было ничуть не сложнее, чем в чисто-отечественные. Единственное различие - на интервью могли уровень разговорного английского проверить, B1 всегда было более чем достаточно (чтобы хотя бы немного мог коммуницировать).
VladimirFarshatov
19.09.2023 20:29Часто уже так и есть. Как пример, дано ТЗ .. в нем банальная ошибка по вычисилению .. кто-то со стат. методами не дружил .. показываю аналитегу, тот говорит "угу" и .. через неделю (вот оно, срок согласования!) прибегает со словами: "Тут все правильно. Мы обсудили с ребятами (какими?), с заказчиком, надо делать так" .. Тимлид в то время в отпуске .. ну ок, сделал "так" .. выходит начальство и сразу же: "Тут у Вас вычисляется не правильно, надо так" -"Э-э-э, так и было, только вот, переписка с аналитегом..". -"Да мне так-то все равно, только вот Заказчик заметил и попросил исправить".. упс.
С каким заказчиком общался аналитик и "ребята" из отдела продаж?
panzerfaust
19.09.2023 20:29+2Два простых примера
Два простых софизма, а не примера. Производство материальных объектов тем отличается от производство ПО, что ПО можно
незаметно для санитаровпеределывать/переписывать/рефакторить хоть каждую неделю. Сохраняя одно и то же внешнее поведение или наоборот постоянно его изменяя. То есть это производство, сюрприз, гибкое. И все упирается даже не в бюджет, а в наличие скиллов. А вот со скиллами как раз проблема.По моему опыту, в скилловом коллективе любой эджайл заходит на ура. Потому что скилловые ребята и без всякого эджайла понимали, что распланировать все на 3 года вперед - нереально и что работу нужно выполнять шаг за шагом маленькими порциями, корректируясь по ходу. Практики эджайла стали для таких людей просто оформлением этих мыслей на бумаге.
lebedec
19.09.2023 20:29+2Разработка ПО конечной целью имеет производство данных или оказание услуг с помощью этих данных. Поэтому аналогии на производство материальных объектов уместны.
Если вы 3 года разрабатывали новый B2C стартап, наращивали клиентскую базу, гибко шаг за шагом развивали продукт и только на финишной прямой поняли что, например, проведение платежей между клиентами невозможно в принципе по законодательству вашей страны — у вас большая проблема впустую потраченных ресурсов.
Ощущение, что скиловый коллектив может переделывать ПО хоть каждую неделю возникает если проект тривиален в своей сути или просто не запланирован на реальную эксплуатацию. Например, это характерно для многих наивных стартапов, которые делают без какой либо реально бизнес модели. Не удивительно что там Agile заходит на ура.
panzerfaust
19.09.2023 20:29Если вы 3 года разрабатывали новый B2C ... гибко шаг за шагом развивали продукт и только на финишной прямой поняли
Еще один софизм. Где тут гибкость-то, извините? Если у вас не нашлось времени проконсультироваться с юристом или финансистом, то при чем тут эджайл? Эджайл про разработку ПО, а не про утрясание юридических моментов.
Ощущение, что скиловый коллектив может переделывать ПО хоть каждую
неделю возникает если проект тривиален в своей сути или просто не
запланирован на реальную эксплуатациюНа моем "тривиальном" проекте более миллиона строк кода. Клиентская база - весь крупный ритейл Западной Европы. Работаем по канбану. Спокойно переписываем что хотим и когда хотим. Спокойно обновляем версии языка и фреймворков. Что мы делаем не так?
lebedec
19.09.2023 20:29Если у вас не нашлось времени проконсультироваться с юристом или финансистом, то при чем тут эджайл?
Вопрос ведь в том когда это время для консультаций выделить. На старте проекта, в процессе проектирования и анализа бизнес требований или спустя N итераций гибкой методологии разработки.
Получается что гибкие методологии разработки подвержены рискам растраты ресурсов и создания нежизнеспособных продуктов, точно так же как и более консервативные методологии.
Эджайл про разработку ПО, а не про утрясание юридических моментов.
Программное обеспечение потому так и называется что является обеспечением какого-то человеческого опыта. Не стоит забывать что код и его разработка не цель, а всего лишь средство:
Вам не нужно ПО "Яндекс.Лавка", вам нужна доставка продуктов домой
Вам не нужно ПО "YouTube", вам нужно посмотреть видео
Вам не нужно ПО "Хабр", вам нужно читать статьи и обсуждать темы
Поэтому разработка действительно полезного и качественного ПО не может быть отделима от условий мира, окружающего человека.
Ну и вообще я всегда думал что понимание полезности продукта в основе любой гибкой методологии, странно что вы это разделяете. Если вы написали ПО которым нельзя пользоваться из-за юридических моментов то какой же это эджайл?
На моем "тривиальном" проекте более миллиона строк кода. Клиентская база - весь крупный ритейл Западной Европы. Работаем по канбану. Спокойно переписываем что хотим и когда хотим. Спокойно обновляем версии языка и фреймворков. Что мы делаем не так?
В своих рассуждениях вы фокусируетесь на средствах разработки, как будто это и есть цель гибких методологий. Но гибкие методологии утверждают что нужно фокусироваться на работающем продукте, а не формальных средствах.
Крупный ритейл Западной Европы действительно не тривиальный как сервис и продукт? Активно развивается? Вы каждую неделю разрабатываете обеспечение для новых моделей и форматов сбыта товара? Может быть меняете правила рынка?
Проект может быть объёмным по коду, но не обязательно это свидетельствует о концептуальной сложности развития продукта.
Или речь идёт о поддержке, предоставлении ещё одной витрины или интеграции с партнёром поверх существующих CRM, CMS, SAP? Тогда никаких вопросов, канбан тут идеально подходит.
Но вообще я не настаиваю. Будет здорово, если вы сможете рассказать про реальные примеры успешного применения гибких методологий для развития крупного ритейла. Таких примеров не хватает в любом обсуждении про эджайл.
ggo
19.09.2023 20:29+1Аналогии производства ПО и материальных объектов, действительно, уместны. Но ограничено.
Разница как раз в материальности объектов. На условном заводе новую деталь можно начать испытывать только после ее изготовления, а это всегда некоторый срок. На условном сервере, новый код можно начать испытывать условно через пару минут после пуша.
Что будет если испытания прошли неудачно? С деталькой - надо будет делать новую версию, а это опять некоторый срок. С кодом - в общем случае через пару минут можешь запушить новую версию.
И это разница в подходах - фундаментально влияет на организацию труда.
Понятно, что всегда можно придумать пограничные случаи, когда новую версию кода выпускают раз в несколько дней, а детальки печатают за несколько минут. Но то исключения, а не правило.
lebedec
19.09.2023 20:29+1Детали на заводе перед изготовлением могут проходить испытания в аналитических системах: продуваются на аэродинамику, рассчитываются по матмодели, перепроверяются вручную проектной группой и т.д.
А вот ПО может поставляться частью программно-аппаратного комплекса или в виде коробочного решения, которое будет работать долгими релизными циклами без обновлений.
Так что получается разницы в подходах нет, инженерный опыт организации труда на заводах применим и для разработки ПО.
То не является исключением. Наши программы работают преимущественно с представлением материальных объектов, потому что нужны нам преимущественно для улучшения материального мира.
Исключением как раз являются некоторые предметные области, где объекты изначально виртуальные: игры, информация, и т.д.
Для примера. Какой код нужно написать чтобы у всех пользователей Хабра появились верифицированные паспортные данные? Это ведь не материальные объекты, по вашей логике, верно понимаю? На ваш взгляд, насколько это реализуемо и будет ли это быстрее чем изготовление деталей на заводе?
summerwind
19.09.2023 20:29+3Вы серьезно думаете, что на современных заводах каждую детальку стоит и вытачивает дядя-токарь вручную с нуля? В наше время уже даже 3D-принтеры используются на некоторых заводах, не говоря уже о другой автоматике. И разница не в том, что код запушить 2 минуты, а детальку выточить не 2 минуты. Разница в том, что на заводе никому и в голову не придет без точных предварительных расчетов согласно законам физики и сопромата наспех что-то выточить наобум и переделывать потом по 20 раз. Но в разработке ПО почему-то все по-другому: тут считается нормальным подходом не думать заранее ни о чем, не писать ТЗ, а просто сделать абы какой прототип по-быстрому, а потом переписывать множество раз. Хотя, по-моему опыту, иногда хоть какой-то предварительный анализ и рисование схем экономит десятки человеко-часов разработчиков.
DirectoriX
19.09.2023 20:29Когда дядька-токарь, 3D-принтер, или станок с ЧПУ делают детальку, они знают, что эта деталька уйдёт в полностью спроектированное изделие, где все детальки подогнаны друг к другу по размерам и характеристикам. А когда дядька-программист делает функцию - он не знает, через сколько лет, месяцев, или даже дней требования к этой функции изменятся.
Требования к физическим объектам крайне редко меняются после их выпуска, и обычно с учётом наличия на рынке предыдущих версий изделий. Например, если 01.01.2024 выйдет закон, обязывающий автомобили иметь фиолетовую фару сзади, которая будет светить когда в машине есть дети - эти требования почти наверняка вступят в силу далеко не сразу, а для уже выпущенных автомобилей будут применяться "херак-херак" решения (например, прилепить фонарь к заднему стеклу, или поверх багажника).
А вот в программировании не так: сегодня вам сторонний API возвращает в JSON
массив объектов
[ { "a": 1, "b": "qwe" }, { "a": 2, "b": "asd" } ]а завтра этот же самый массив
положат в объект-обёртку
{ "data": [ { "a": 1, "b": "qwe" }, { "a": 2, "b": "asd" } ] }- и всё, ваш код надо переписывать прямо сейчас, потому что он уже не работает. Да, та сторонняя компания выпустила уведомление о смене формата, за 3 дня, только в виде статьи в справочном центре, куда ещё надо знать как добраться. Нет, конечно же ни вы, ни коллеги / менеджеры не ходите в этот справочный центр каждый день, потому что зачем, ваш имеющийся код ведь работает (уже нет).
VladimirFarshatov
19.09.2023 20:29+1Не всегда такое возможно, это - раз. Бывают ситуации, когда незаметно переписать не получится, в ПО (бунгало) изначально были заложены ограничения, запрещающие доработку до небоскреба и переписывать надо всё. Совсем всё, начиная с архитектурных решений.
Распланировать разработку ПО вперед на три года не реально ни в каком коллективе, т.к. каждые пару лет в ИТ совершаются "микрореволюции" и то, что три года назад было "масое модно-молодежное" внезапно становится "антипатерном", как было с теми же АктивРекорд или Синглтон.. а как всё начиналось-то .. ;)
buharof Автор
19.09.2023 20:29-1Вы не поняли суть статьи. В статье речь идет о том, что узкую методологию для разработки ПО пытаются использовать на производстве, в ритейле, еще где-то.
И опять - откуда эта идея, что ватерфолл - это обязательно 1-2-3-10 лет чего-то. Это концепт с идеей - определяемся четко на берегу, затем делаем.
Вы кроме разработки ПО занимались какими-то еще профессиями в жизни?
Ndochp
19.09.2023 20:29Да тот же полет в космос как классика с переделкой компоновки ступеней ракеты, потому что в исходном варианте было плохо.
Сложный проект с ватерфолом даже в физических объектах невозможен, если это сложный проект. Так как половина сборочной документации — это исследовательская работа, входящая в работы по проекту. А значит детального ТЗ на момент старта проекта у вас не будет, и это не ватерфол, а кастрат. А если вы провели все исследования и дошли до сборочной документации до подписания договора, то в рамках чего были проведены эти работы? (См знаменитую статью про разработку Приуса Тойотой)
В программных, когда создать прототип дешевле, чем написать детальное ТЗ — ватерфол еще и экономически не оправдан ни разу.
И нет, бунгало на первом этапе небоскреба это что угодно, но не эджайл. Вот МВП в виде решетки из металлоконструкций без обшивки но с антивибрационным противовесом на сотом этаже — возможно.Ну и финалочка с ватерфолом, вот вы начали строить бунгало на острове, а потом остров вместе со стройкой выкупил арабский шейх и решил превзойти дубайский отель на тропическом острове, что вы по вотерфолу делать будете? Достраивать бунгало и пытаться стрясти оговоренную сумму? Фишка изменений требований не в том, что при ватерфоле их удается избежать, а в том, что при аджайле их можно дешевле парировать. А возникать они будут все равно.
И гибкий эджайл это не только "из ПО тянут методики в реальный мир" но и отголоски той же Тойоты, где решение о том, что сойдет с конвейера может быть изменено на середине конвейера. В разработку ПО эти идеи пришли с опозданием от реального мира, а не с опережением.
panzerfaust
19.09.2023 20:29В статье речь идет о том, что узкую методологию для разработки ПО пытаются использовать на производстве
Ну пусть не пытаются. Идите на их форум и расскажите, что они не правы. Как видите, на хабре у разработчиков ПО с эджайлом проблем нет.
Вы кроме разработки ПО занимались какими-то еще профессиями в жизни?
Увы для вашей софистики - да. Я работал в АСУ ТП.
Это концепт с идеей - определяемся четко на берегу, затем делаем.
И в АСУ ТП это тоже не работает, как вам хочется. Но там нет понятия "эджайл". Вместо этого там матерятся на заказчика, у которого 7 пятниц на неделе, вытрясяют из него бабки по доп соглашениям и тоже много чего переделывают на лету.
buharof Автор
19.09.2023 20:29-1"Идите на их форум и расскажите, что они не правы."
Я без вас прекрасно разберусь, куда мне идти, на какой форум. Вас кто-то уполномочил выступать от лица всего Хабр сообщества? Вы комментарии читали? Здесь нет единого хора голосов в поддержку аджайл. Вам показать направление, куда идти с подобными советами?
"Я работал в АСУ ТП. "
И я работал в АСУ ТП, занимался автоматизацией домен и прокатных станов. А вы что автоматизировали, позвольте спросить? Мне для понимания.
Еще про АСУ ТП мне расскажите в ключе аджайла. Оччччень интересно. В АСУ ТП тонны документации только по одной электрике.
В моем тексте нет софистики. Ваше "увы" - мимо.
Ndochp
19.09.2023 20:29+2Ага, а потом увидев краны не в ту сторону на атомной станции при итоговой приемке ребята поправили документацию, а не подняли панику.
(с какого-то форума-сборника факапов на атомных станциях.)
sergey_prokofiev
19.09.2023 20:29+2Лишняя работа за бесплатно.
Вот это - ключевое. Вы не понимаете что не забесплатно, а за деньги заказчика. В описанном случае с ракетой диалог через 2 года после старта разработки был бы таким:
Заказчик: Хочу изменить ТЗ ракеты с 3х на 6 человек
Исполнитель: в принципе это будет почти что новая ракета и это займет еще 2 года и 300 лямов баксов
Заказчик: хм.... я никуда не спешу и у меня есть 300 лямов баксов!
buharof Автор
19.09.2023 20:29-2Это вы не поняли смысл фразы "за бесплатно". "За бесплатно" - это для конечного исполнителя. Что там снимет за доработки с заказчика организатор - это до исполнителя, как правило, не доходит.
sergey_prokofiev
19.09.2023 20:29Организатор - это кто в вашем понимании? За 20 лет работы в аутсорце по обе стороны баррикад(и со стороны вендора., и со стороны аутсорсера) ни разу не видел роли "организатор".
buharof Автор
19.09.2023 20:29Значит плохо понимаете структуру взаимоотношений. Попробуйте работать в штате - может быть, для вас что-то прояснится.
sergey_prokofiev
19.09.2023 20:29+1Я то как раз прекрасно понимаю "структуру взаимоотношений". А если вы и есть "конечный исполнитель в штате", то ваше дело получить задачу, взять под козырек и выполнить ее в срок. За что, собственно говоря, вам и платят зарплату регулярно. А почему вам поставили именно такую задачу - не ваше дело.
MiraclePtr
19.09.2023 20:29За бесплатно" - это для конечного исполнителя
Конечному исполнителю обычно платят зарплату за каждый рабочий день.
Yuri_nedre
19.09.2023 20:29+3О, я знаю эту историю из первого примера. В итоге лавочек сделали не 20 штук, а 3 и не на 6 человек а на 2-х. Но смету в итоге раздули еще в 4 раза, а директор парков уехал на 6 лет на зону за растрату...
Evgueni_Gavrilov
19.09.2023 20:29"c четким ТЗ изначально" можно делать что-то примитивное за короткое время
всё что сложнее утюга быстро не делается, а значит с течением времени будем иметь естественное изменение окружающего и технологического ландшафта
можно только порадоваться за тех, кто доделал УК-НЦ2 к 2023-му году благодаря "чёткому ТЗ изначально", ведь там теперь 256КБ памяти!
Captain_Jack
19.09.2023 20:29+2Тезис: agile – только для простых проектов!
Наоборот же. Предположим, вы бизнес - запускаете какой-то онлайн-сервис. У вас есть гипотезы, каким-то образом конечно же протестированные, но полностью провалидировать эти гипотезы можно только реальным продуктом, которым будут пользоваться.
И вы несёте ТЗ в контору по разработке ПО, и через 2 года вам выдают красивый онлайн-сервис.
И одновременно с вами ваш конкурент тоже решает запустить такой же сервис, только разработку ведёт по agile. Через полгода у него появляется MVP, а через 2 года половина ваших потенциальных пользователей - уже пользователи сервиса-конкурента.
Да, их сервис вышел сначала без каких-то важных фич, но это было уже лучше, чем ничего. Лучше и для пользователя, и для бизнеса.
И за эти 2 года ваш конкурент провёл кучу А-Б тестов, пообщался с пользователями, и сделал пару-тройку фич, которые были востребованы, но изначально не было известно, что они должны работать именно так.
Итого - через 2 года бизнес конкурента имеет хороший денежный поток, базу пользователей, бэклог по улучшению, и уже улучшился под потребности пользователей.
Вы через 2 года имеете сдвиг запуска ещё на 3 месяца, но это уже не так важно. Почему? Потому что вам теперь снова требуется разработка - пользоваться вашим сервисом особо не хотят, ведь в нём не хватает части удобных фич, которые есть у конкурента. Поэтому вы пишете ещё одно ТЗ и снова несёте в контору, ждёте ещё 9 месяцев... Если ещё не закроете бизнес к тому времени, потому что прибыли у вас как было 0, так и осталось.
И тем более, ваш конкурент обладает ещё более важным преимуществом - он может зафэйлиться быстрее (пресловутый fail fast). Через год он уже сможет понять, есть ли деньги в этой нише, и если проект не летит, то закрыть его. По сравнению с вами он сэкономит 50% стоимости и времени. И через 2 года уже выпустит другой сервис. А вы всё ещё будете в неведении, отобьются ли ваши вложения в разработку.
И это ещё я не беру во внимание целый ряд рисков: контора-исполнитель может вообще закрыться, или плохо написать ваш проект, или затягивать сроки. Прозрачности в waterfall гораздо меньше, потому что часто проект даже не запускается до момента 90%-готовности. Да, можно будет подать на них в суд в каких-то случаях, но нам-то нужен не суд, а сервис.
И тем более, после написания сервиса его всё равно придётся менять, развивать, дописывать. Не могу себе представить ПО, которое выпустили и не дорабатывают годами, по крайней мере в вебе. Получается, если начать менять код, то ВСЁ РАВНО ПРИДЁТСЯ МЕНЯТЬ КОД. И от истории с agile-подходом это на самом деле не будет сильно отличаться. Вот только в agile-команде к этому уже все готовы, а в waterfall-команде ещё не факт что кодовая база готова к большим доработкам.
Мне кажется, вы мало понимаете, какие у предпринимателей потребности и какие риски, и почему огромную ценность имеет быстрый фидбэк от пользователей.
Даже в вашем примере со скамейками существует так называемый тактический урбанизм - сразу обычно непонятно, как именно нужно организовать общественное пространство, чтобы людям нравилось, где именно и какие именно поставить лавочки. Поэтому за 2 недели делают самые убогие лавки за 100р/штука, ставят и смотрят, как ими пользуются, опрашивают людей. И только потом, имея фидбэк пользователей, проектируют более основательное решение.
buharof Автор
19.09.2023 20:29-1"онлайн-сервис"
Ваш онлайн-сервис - это как раз-таки простой проект. Как это можно не понимать? Сложный проект - это цех сборки локомотивов, система прогнозирования заполненности логистических центров каких-нибудь. Все веб-сайты - магазины, заказы пиццы - это все, с точки зрения логики - примитивные вещи.
И потом - откуда у вас в голове сидит "ватерфолл - это годы"? Кто это вбил в голову?
Captain_Jack
19.09.2023 20:29+1откуда у вас в голове сидит "ватерфолл - это годы"? Кто это вбил в голову?
Никто не вбивал, не беспокойтесь. В такой срок я оцениваю разработку средних размеров проекта, включая написание ТЗ и приёмку. Это пример. Не спорю, что можно и за 2 месяца что-то небольшое сделать и запустить в эксплуатацию. Но чем больше, тем дольше.
Ваш онлайн-сервис - это как раз-таки простой проект. Как это можно не понимать?
Просто с какой точки зрения? С точки зрения наукоемкости может быть ничего замысловатого нет в том, чтобы одни люди продавали, а другие люди покупали вещи.
Если же говорить про количество и сложность процессов, количество и требования к данным, к надежности систем и т. д., то мне кажется вполне сравнимо.
Опять же, чтоб построить производственный цех, нужно стоять на плечах гигантов - иметь разработанные и апробированные технологии, кучу документации по ним, поготовленных специалистов и т. д. Построить цех с нуля невозможно. Так вот, часть современного бизнеса примерно этим и занимается - заходит в неизвестные ниши, находит новые способы решить бытовые потребности людей. Там нет методички, как построить цех. Там есть только идеи.
Даже ракеты строить учились десятилетиями методом проб и ошибок, и в науке почти всё так работает. Невозможно дать ТЗ на то, чего нет и неизвестно как это сделать.
Если вы откроете манифест аджайла, то обнаружите, что это и есть тот самый метод проб и ошибок, только применительно к разработке. Не понимаю, как можно говорить, что такой метод годится только для простых проектов, наоборот, это очень близко к RnD.
Captain_Jack
19.09.2023 20:29+1Опять же не понимаю ваше деление на простое и сложное - получается СДЭК и почта сложные, авито - простой?
buharof Автор
19.09.2023 20:29+1я делал систему контроля качества сборки вагонов (склады, 3 лаборатории и т.д. и т.п.) на большом заводе и сервис обмена электронными документами через веб. (просто два примера)
между ними разница - как между поездкой за город и полетом на марс. веб-сервис на два порядка, если не на три, делать проще.
ggo
19.09.2023 20:29+1А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.
Это абсолютно справедливо. Для любого инструмента.
Одно из главных правил Agile-методологий – команда-исполнитель принимает от заказчика изменения/ дополнения на любой стадии проекта.
Неверное заблуждение.
Agile - не про покорность исполнителя, и прием любых изменений в любое время.
Agile - про отсутствие деления на исполнителя и заказчика. Есть команда, ответственная за результат. И лицо, принимающее ключевые решение по свойствам продукта, такой же член команды, как и все остальные.
И главный критерий использования Agile-подхода - это не простота или сложность проекта. А возможность коротких итераций для выпуска новых версий продукта. Можете выкатывать в продажу чайник новой версии каждые 1-4 недели, флаг Agile'а вам в руки. Не можете - вам Agile не нужен.
И изменение приоритетов и переобувание по фичам продукта происходит как раз между итерациями. Их так и называют "спринт" - короткий забег на заранее определенную дистанцию. Потом остановка, определение нового направления и дистанции, и новый короткий забег. Во время забега, понятно, не до изменения требований, надо просто бежать.
Eugene64
19.09.2023 20:29+1Существует положительный опыт адаптации Agile в аэрокосмической области. Scaled Composites построила в качестае эксперимента в Agile серию самолётов Model 401 Sierra https://www.scaled.com/portfolio/sierra/ . Там в описании есть об этом. Разумеется, когда работают с железом, есть разумные пределы прав заказчика по изменению требований.
buharof Автор
19.09.2023 20:29-2Прочитал инфо на сайте - инфо крайне мало. Больше похоже на рекламный трюк. Как сейчас все суют в свою рекламу якобы ИИ.
Gryphon88
19.09.2023 20:29+2Как-то раз мы думали заказать стороннюю разработку, потому как считали, что нет у нас нужной компетенции. Втроем (я-разработчик, инженер и продажник) за месяц родили тз по ГОСТу. Получился хороший всеобъемлющий документ. Я его прочел и за две недели написал нужное. Если бы мы обсудили в пивной общие цели и ограничения, а потом я мог показать текущий образец любому из группы и в течение получаса получить коротки ответ "да" или "нет", написал бы недели за 3, может, чуть больше. Моё мнение о гибких методологиях такое:
- Если вы можете собрать в одной комнате людей, которые хорошо понимают результат и имеют право принимать окончательные решения, и не выпускать их, пока не будет готов документ с подписями и печатями — водопад лучший выход.
- Если нет четкого понимания, но есть возможность оперативно получать окончательную обратную связь по каждому завершенному кусочку — гибкие методологии вполне подходят.
- Самый плохой вариант — "эджайл" с согласованием каждой фичи. Тут начинается цирк по Паркинсону: кто-то переваливает ответственность, кто-то стремится доказать свою значимость через вклинивание в цепочку...
Хохма в том, что по многим вопросам у заказчика нет мнения, он ими не задавался или ему все равно. Проще просить прощения, чем разрешения: если вы сделаете как-то, и оно будет работать, заказчик скорее всего скажет "принимаем" и не будет травить согласованиями; если спросите "кнопка красная или зеленая" — получите 20 часов совещаний. Работать в общем-то можно, но очень неприятно, что проблемы менеджмента, как своего, так и заказчицкого, в итоге падают на айтишника.
piton-vas
19.09.2023 20:29+1Насчет ракеты хороший пример, потому что Илон Макс как раз можно сказать по эджайлу и конструирует.
Быстрая разработка, прототип и MVP уже улетает на тесты. Пофиг на стартовый стол, и прочие недоработки, давайте запустим и посмотрим что получится и получим данные для анализа. И да, в старшипе сейчас много кардинальных изменений, например механизм разделения ступеней меняют в уже летавшей ракете.
А если по классическому ватерфолу идти, пользуясь только проверенными решениями, то получится sls, который долгий и неэффективный.
Abobcum
А вы ракету разбейте на микросервисы (модули) - и вот у вас уже не в 2 раза больше кислорода, а в 10 раз дороже кислородный компрессор. При малой связности стоимость изменений почти независима.
DirectoriX
Проблема не в том, чтоб кислород для дыхания стал сжат вдвое сильнее, этим всё равно занимается наземный агрегат, а для перекачивания внутри ракеты, уже для дыхания, особой мощности и так не надо. Проблема в том, что теперь баки с дыхательным кислородом станут вдвое тяжелее, а ещё проектной толщины стенок может просто не хватить и придётся баки либо делать с ещё более толстыми стенками, либо ставить два бака рядом ( = существенное изменение конструкции). А ещё э
ти мешки с мясомтуристы не только суммарно вдохнут вдвое больше, но и выдохнут вдвое больше, углекислый газ надо тоже куда-то девать.А уж увеличение кабины в два раза - вообще смешно, это почти как в доме пытаться заменить лифт на вдвое более человекоподъёмный: мотор и трос ладно, а с кабиной-то что делать, пусть люди напихиваются вдвое плотнее? Тут надо всю шахту переделывать, а это перестройка части / всего здания... о чём и статья.
Или ещё лучше: ваша фирма производит фонарики, и вам пришёл заказ на 150 штук со следующими требованиями: питание от 3-х батареек AA, 1 лампочка накаливания, кнопку необходимо удерживать (не защёлкивается). "Отлично", думаете вы, "типичный набор компонентов".
Потом заказчик присылает письмо, в котором просит заменить лампочку на светодиод (в интернете вычитал, что они служат дольше и потребляют меньше энергии). Вы пожимаете плечами: "Ну ладно, конструкция почти та же самая, только вместо винтового патрона для лампочки - небольшая печатная плата со светодиодом."
Через 2 дня заказчик просит вас заменить батарейки на AAA, якобы для уменьшения веса. "Хм, придётся вставлять другой отсек для батареек, а отверстия от уменьшенных габаритов компенсировать дополнительными пластиковыми перегородками".
А затем заказчик просит вас поставить матрицу из 18 светодиодов, питание заменить на 3 батарейки типа D, а ещё добавить функции включения на половину и мигания красным. Как думаете, сколько компонентов у вас останется от предыдущей конструкции? Я думаю, что в лучшем случае кнопка
arheops
Есть лифты для таких случаев, кстати. Они открываются сраза на двух этажах или полу-этажах.
А с фонариком типичный ИТ проект. Оно так и бывает, ничего в конечной версии от первой.
buharof Автор
Вы, вероятно, сильно далеки от любых производственных процессов.
ac130kz
Связность как раз остается сильной из-за постоянных изменений и хотелок. А весь зоопарк потом поддерживать, версионировать общий протокол, т.е. еще хуже становится.
Abobcum
Наоборот, связность микросервисов меньше связности внутри монолита, поэтому изменения становятся ещё проще.
Не нужно думать о зависимостях и их конфликтах от других модулей. Не требуется обрабатывать чужие ошибки. Нет проблем с масштабированием и версионированием (потому что обратная совместимость протоколов). Пожалуй, главная проблема - оверхед.
Возвращаясь к агиле, вся фишка в том, что изменения абсолютно независимы, поэтому и команды могут не спорить, и менеджер может спокойно раскидывать задачи в любое время. Максимум, что произойдёт - это 501 Not Implemented, когда один сервис сильно опережает другой по развитию.
Как человек, который много лет работает по aqgile/scrum/<модное слово>, сильно выигрываю. Теперь мне не нужно 2 дня обсуждать, какой язык/фреймворк/формат/протокол использовать. Теперь я сам пишу протокол (например, protobuf+redis) и тупо выдаю его коллегам. Дальше пусть сами там "максимально эффективно" обрабатывают данные на своём отсталом истинно верном ansi c, но им придётся выдать мне валидный ответ.
Но самый главный выигрыш в том, что теперь мне не звонят в выходные и не просят поднять сервер, когда какой-то глупый джун что-то сломал, а ошибка отобразилась на моём модуле. Теперь все ошибки и проблемы чётко и ясно сопоставляются с виновниками, а я сплю спокойно.