Comments 95
А вы ракету разбейте на микросервисы (модули) - и вот у вас уже не в 2 раза больше кислорода, а в 10 раз дороже кислородный компрессор. При малой связности стоимость изменений почти независима.
Проблема не в том, чтоб кислород для дыхания стал сжат вдвое сильнее, этим всё равно занимается наземный агрегат, а для перекачивания внутри ракеты, уже для дыхания, особой мощности и так не надо. Проблема в том, что теперь баки с дыхательным кислородом станут вдвое тяжелее, а ещё проектной толщины стенок может просто не хватить и придётся баки либо делать с ещё более толстыми стенками, либо ставить два бака рядом ( = существенное изменение конструкции). А ещё эти мешки с мясом туристы не только суммарно вдохнут вдвое больше, но и выдохнут вдвое больше, углекислый газ надо тоже куда-то девать.
А уж увеличение кабины в два раза - вообще смешно, это почти как в доме пытаться заменить лифт на вдвое более человекоподъёмный: мотор и трос ладно, а с кабиной-то что делать, пусть люди напихиваются вдвое плотнее? Тут надо всю шахту переделывать, а это перестройка части / всего здания... о чём и статья.
Или ещё лучше: ваша фирма производит фонарики, и вам пришёл заказ на 150 штук со следующими требованиями: питание от 3-х батареек AA, 1 лампочка накаливания, кнопку необходимо удерживать (не защёлкивается). "Отлично", думаете вы, "типичный набор компонентов".
Потом заказчик присылает письмо, в котором просит заменить лампочку на светодиод (в интернете вычитал, что они служат дольше и потребляют меньше энергии). Вы пожимаете плечами: "Ну ладно, конструкция почти та же самая, только вместо винтового патрона для лампочки - небольшая печатная плата со светодиодом."
Через 2 дня заказчик просит вас заменить батарейки на AAA, якобы для уменьшения веса. "Хм, придётся вставлять другой отсек для батареек, а отверстия от уменьшенных габаритов компенсировать дополнительными пластиковыми перегородками".
А затем заказчик просит вас поставить матрицу из 18 светодиодов, питание заменить на 3 батарейки типа D, а ещё добавить функции включения на половину и мигания красным. Как думаете, сколько компонентов у вас останется от предыдущей конструкции? Я думаю, что в лучшем случае кнопка
Вы, вероятно, сильно далеки от любых производственных процессов.
Связность как раз остается сильной из-за постоянных изменений и хотелок. А весь зоопарк потом поддерживать, версионировать общий протокол, т.е. еще хуже становится.
Наоборот, связность микросервисов меньше связности внутри монолита, поэтому изменения становятся ещё проще.
Не нужно думать о зависимостях и их конфликтах от других модулей. Не требуется обрабатывать чужие ошибки. Нет проблем с масштабированием и версионированием (потому что обратная совместимость протоколов). Пожалуй, главная проблема - оверхед.
Возвращаясь к агиле, вся фишка в том, что изменения абсолютно независимы, поэтому и команды могут не спорить, и менеджер может спокойно раскидывать задачи в любое время. Максимум, что произойдёт - это 501 Not Implemented, когда один сервис сильно опережает другой по развитию.
Как человек, который много лет работает по aqgile/scrum/<модное слово>, сильно выигрываю. Теперь мне не нужно 2 дня обсуждать, какой язык/фреймворк/формат/протокол использовать. Теперь я сам пишу протокол (например, protobuf+redis) и тупо выдаю его коллегам. Дальше пусть сами там "максимально эффективно" обрабатывают данные на своём отсталом истинно верном ansi c, но им придётся выдать мне валидный ответ.
Но самый главный выигрыш в том, что теперь мне не звонят в выходные и не просят поднять сервер, когда какой-то глупый джун что-то сломал, а ошибка отобразилась на моём модуле. Теперь все ошибки и проблемы чётко и ясно сопоставляются с виновниками, а я сплю спокойно.
Компании не понимают смысла аджайл. Он ведь про результат и людей, а не процессы и регламенты. А ты куда не придёшь везде одно и то же. 2х недельный спринт без возможности что-то сдвинуть даже если нужно. Аджайл на бумаге, а в голове бюрократия.
Самое смешное, это что как раз согласно принципам Scrum - по результатам инспекции провели адаптацию и изменили длительность спринта.
Scrum guide не декларирует спринты в 2 недели. Более того, рекомендует следующий критерий выбора оптимальной продолжительности спринта: она должна позволять выпустить продакт инкремент как результат спринта (передаю смысл, а не цитирую).
Ещё часто хотят взять от scrum то, что выгодно, например жёсткие коммиты по срокам доставки, но не соблюдать то, что неудобно - не вклинивать в спринт "срочные задачи" (мол, ну это же небольшой фикс на один час, и это горит на проде) или вообще игнорировать основные принципы agile manifesto - строить людей вокруг процессов, а не наоборот, или составлять план с диаграммой Ганта вместо "responding to change" и т.п
Agile mnifesto ничего не говорит про спринты.
Спринты фиксированной длительности - это про Scrum, почему оно именно так, объясняется в scrum guide.
Если компания выбрала Scum как подходящий для ее задач фреймворк, то приняла его правила игры.
"Давайте продлим спринт на 2 дня, потому что я не успел сделать задачу" - это не про ту гибкость, которая заложена в философию Agile.
А конкуренты, кстати, в итоге после очередного кризиса почти что закрылись, коллектив вышел на мороз, а из разработки выкупила другая контора
А ваши заказчики, были бы помельче, остались бы без шатнов, но довольные. Agile в данных примерах - растянутая по всемени нечестная продажа.
Я не знаю, насколько сложный проект у вас был с диспетчеризацией нефтепромыслов. Подозреваю, что просто нужно было визуализировать поступающие в БД в перманентном режиме сигналы с датчиков и все это выводить на экраны диспетчеров (в смысле, сотрудников-технологов, которые агрегатные состояния отслеживают). Если так - то это простой проект. За неделю разработки вывести на экраны все критические датчики - давление/ вибрация в черно-белом виде (условно). На следующей неделе раскрасить их и еще каких-нибудь приблуд добавить. Вот если бы вы разрабатывали АСУ самого нефтепромысла - т.е. управление самими агрегатами выкачки нефти, с учетом давлений, с кучей гидро/ пневмоприводов/ кучей электрики - вы бы на это смотрели совсем иначе. Предположу, что вы автоматизацией производственных процессов (доменная печь, прокатный стан etc.) никогда не занимались? Верно?
Почему-то у вас обязательно ватерфолл - это год-два разработки. А это всего лишь концепт, в нем не прописано, что он "долгий". В нем прописано, что сначала согласовываем, потом делаем.
Понятное дело, что заказчику нравится идея головой не думать - поэтому, в том числе, идея приносить хотелки до конца проекта так популярна. И владельцу конторы-разработчика нравится - заказов больше и того же тех. писа нанимать не надо - сами все сделают.
Да ну все просто же - аджайл это калька с процесса эволюции. Движемся маленькими мутациями, каждая новая итерация потихоньку делает конечный продукт ближе к идеалу, или не делает и тогда развивается другая ветка и идет к результату который пока никому непонятен, но есть вектор куда стремиться.
Ватерфол это когда уже четко заранее понятна конечная цель, критерии на 1000% определены, и каждое отклонение смертельно опасно
Как-то пришел работать компанию где решили делать теперь по эджайлу (как они это понимали) буквально за 2 месяца до моего прихода. Код отличный, фронт и бек по своим паттернам, весь код понятен и практически самодокументирован. 2 недели вкатывался в код. Начал брать задачи.
Спринты, митинги каждый день. Только задачи разбиты даже не по часам, а иногда по 10 минут. Спринт на 2 недели опаздывает на 2 недели. Каждый раз. Оценки задачи ставит руководитель разработки.
Смотрю задачу - "клиенту не нравится цвет кнопки, поменять", срок - 10 минут. Ок, поменять на какой? Нужно согласование, 4 раза пытался связаться с тем, кто принимает решение, это как понятно сам руководитель разработки. Переключаясь на другие задачи в которых был такой-же бред, где нужно было что-то спрашивать у тестировщиков, что-то у других разработчиков. Итого на код я потратил минут 30-40 за день, на согласование и переключение между контекстам и и задачами еще 8 часов. Пытался что-то втолковать руководителю разработки, что так не делают, что на проекте из пяти человек трое ушло за два месяца, что ваши оценки промахиваются в 2-3-5-10 раз - ответ один - мы так делали 10 лет, мы так привыкли работать, не нравится - уходи. Ушел.
Итого на код я потратил минут 30-40 за день
Касаемо согласования, вопрос спорный. Представьте, что вы без предварительного согласования сделали кнопку за 10 минут, отправили задачу на проверку принимающей стороне, зада некоторое время у нее лежит, после чего, она ее смотрит (тоже тратит время время) и возвращает ее вам, вы ее снова правите, и снова двигаете задачу на проверку и хорошо, если ее со второго раза примут. В итоге выиграете ли вы этим что то, оставлю вопрос открытым
Речь о том что извращенное представление Agile методик исключает анализ задач как сложный и дорогой этап разработки, заменяя его "легковесными обсуждениями" по любому поводу.
В примере zodchiy задача была бы выполнена реально за 10 минут без согласований, если бы аналитик (дизайнер) изначально написал в задаче необходимый цвет.
Вопрос оценки стоимости задачи по времени разработки - вообще интересен сам по себе. Сколько ни работаю, ещё ни разу не видел полноценно правильной оценки до начала работы, если не считать простые задачи типа поменять цвет, дополнить код выводом логов и т.п.
Даже помнится было такое "правило": "Если программист называет срок, к примеру час работы, то его надо перевести в следующий временной порядок и умножить на 3.14.. " как-то так.. ;)
А то, что двухнедельный спринт опаздывает на 2 недели .. а где иначе в больших проектах? Согласование .. до недели приходилось ждать.
сильно зависит от команды и ее погружённости в проект. на старте конечно это бессмысленно.а дальше если принять за аксиому что оценка выше 3х дней должна дополнительно ресерчиться и декомпозироваться - это дает неплохие результаты и минимальную дисперсию от ожидаемого срока.
На ресерч и декомпозицию, и как следствие, появление новых задач по итогу декомпозиции, их обсуждению и встраиванию в спринт .. потеряете много больше времени, чем на тупой кодинг в течение трех дней. Проверено много раз, особенно в ситуации, на которую я и отвечал: согласование идет долго, а часто это не только "ближайший насяльник" (тим лид), но и ещё пара-тройка от девопс, от QA, от Заказчика..
писать правильно и хорошо тоже потеря времени, гораздо быстрее тяп-ляп и в продакшен, желательно без тестов. мною проверено много раз что детальная декомпозиция иногда приводит к пересмотру проекта, сроков и способу реализации впринципе. потому что "вроде изян" это как раз и выливается в 100 часов.
работать вообще - потеря времени, ибо мгновенно и само ничегго не происходит. Писать в любом случае стоит, кмк, не тяп-ляп а как можно лучше: "старайся делать хорошо, плохо получится само". Это общие замечания, относятся как к трехдневному кодингу, так и варианту ресерч и декомпозиция. Только второй вариант вносит дополнительный издержки, часто бесполезные от слова совсем. Тоже проверено жизнью:
-"Подожди не пиши, ща мы это обсудим и согласуем. Тут надо ресерчить и спросить Заказчика" .. ага, три раза .. пока согласовывали сваял код .. как раз, те самые три дня. В итого: "Во, надо будет делать вот так..".
-"Ага, забирайте. Сделано уже".
Итого, что в итоге – простые проекты по гибкой методологии делать можно.
Сложные – только по каскадным методологиям (Waterfall) – c четким ТЗ
изначально.
Позвольте с вами не согласиться. Agile - это не только про прием изменений в проект. А даже если смотреть с точки зрения приема изменений: Если вдруг через два года разработки появились новые материалы, движки, топливо и т.д. и это можно применить в сложном проекте?
Сложные проекты тоже можно и нужно делать по Agile для повышения эффективности разработки. Но если вы не умете готовить Agile - может не надо натягивать сову на глобус?
А кто умеет? Приведите конккретный пример повышения эффективности разработки от применения этого подхода... т.с. "огласите часть списка", но конкретно: было - стало. С цифирьками..
Всё зависит от масштабов. В масштабе себя самого я умею готовить. И даже есть пример по снижению потребления экранного времени телефона с 11 часов в день до 5-6 часов. Это не про разработку, но по сути 5-6 часов потребления соцсетей стали полезными делами.
Теоретически эту историю можно отмасштабировать в разработке на команду и на компанию, но практического опыта нет.
А это вопрос не ко мне. Я вообще не хочу "готовить" аджайл. Минусы расписал в статье. Это менеджмент компаний стремится его "готовить", пытаясь натянуть сову на глобус.
Как это не к вам? А к кому же? Разве это не вы натянули сову на глобус своим утверждением (и своими примерами) в этой статье?
Еще раз приведу текст утверждения.
Итого, что в итоге – простые проекты по гибкой методологии делать можно.
Сложные – только по каскадным методологиям (Waterfall) – c четким ТЗ
изначально.
Я вижу эту ситуацию со стороны так.
Вы наблюдали много ситуаций "карго-культа". Когда компания для большого проекта пыталась применять Agile не по сути, а по внешнем признакам. И удивлялась: "почему это не взлетает? мы ж всё делаем как надо"
Вы стали экспертом в применении карго-культа. Но экспертом в Agile вы так и не стали.
Что вам сразу же подсветили в комментариях с утверждениями о том, что большие проекты по Agile успешнее, чем по водопаду.
И проблема в том, что настоящего Agile вы не видели и не понимаете. Но ваши итоги звучат как мнение именно эксперта в Agile.
Вы сами себе что-то напридумывали, и сами сделали какие-то выводы на основе своих фантазий. Ну, флаг вам в руки.
"Ваше мнение очень важно для нас" (с)
Тем не менее, запрос на гибкое управление в гигантских проектах есть.
«Один из самых больших уроков, извлечённых из проекта Уэбб, — это важность предварительного и детального понимания ракет, — сказал Ли Фейнберг, менеджер по оптике проекта Уэбб и сопредседатель группы технической оценки Habitable Worlds Observatory. — Одним из ключевых моментов здесь является то, что нам нужна гибкость. До реализации миссии пройдёт ещё лет 20».
А если верить вашему утверждению, то у астрономов нет шансов. Потому что сложные проекты можно делать только с четким ТЗ.
По моему опыту, Agile - это попытка продать историю о том что можно начать со строительства одноэтажного бунгало, а затем, при необходимости, перестроить его в многоэтажный жилой дом, а затем - в небоскреб.
Разумеется, заказчику это нравится - не надо думать о будущих потребностях, не надо далеко планировать. Ведь если потребуется - мы достроим еще пару этажей, эджайл же.
А вот разработчикам приходится либо натыкаться на ограничения архитектуры, подпирая небоскреб костылями и привязывая к крыше воздушные шары (иначе рухнет к чертям), либо заранее закладывать фундамент под небоскреб, на котором гордо стоит сарай по цене "Боинга".
В реальности, разумеется, иногда удается перестроить сарай в небоскреб, постепенно заменяя фундамент и всю внутреннюю структуру. Но есть и обратные примеры, когда проекты более чем успешно умирали под грузом технического долга, когда становилось выгоднее "выкинуть и написать заново" чем развивать проект дальше.
Это очень удобный способ доить заказчика, подсаживая его на вечные доработки.
Я эту схему уже расписывал тут: https://habr.com/ru/articles/594897/
Не сильно-то порядочный подход, IMHO
У вас мама/ папа слесарь на заводе/ домохозяйка? Каким образом вы попадали преимущественно в филиалы иностранных компаний?
Я не совсем вас понял. Я думал, что вы работали в штате каких-нибудь компаний типа, не знаю, Мицуи или Siemens. А вы, вероятно, работали во всяких Люксофтах/ Епамах, делая проекты в интеграторе.
В Люксофты/ Епамы я никогда и не стремился. Мы просто о разных вещах говорим.
И что дальше? В чем суть ваших комментов к моей статье про аджайл, в которой я описал опыт попыток его применения в местах, для аджайла плохо подходящих, коль скоро мы выяснили, что вы в компаниях не чисто ИТ-шных (о которых в статье речь и идет) попросту не работали и опыта соответствующего не имеете.
Часто уже так и есть. Как пример, дано ТЗ .. в нем банальная ошибка по вычисилению .. кто-то со стат. методами не дружил .. показываю аналитегу, тот говорит "угу" и .. через неделю (вот оно, срок согласования!) прибегает со словами: "Тут все правильно. Мы обсудили с ребятами (какими?), с заказчиком, надо делать так" .. Тимлид в то время в отпуске .. ну ок, сделал "так" .. выходит начальство и сразу же: "Тут у Вас вычисляется не правильно, надо так" -"Э-э-э, так и было, только вот, переписка с аналитегом..". -"Да мне так-то все равно, только вот Заказчик заметил и попросил исправить".. упс.
С каким заказчиком общался аналитик и "ребята" из отдела продаж?
Возьмите для примера историю VK или любой другой успешной "социальной сети" с многомиллионной аудиторией. Чем оно было на старте и чем стало сейчас в плане архитектуры?
Да, инкрементальная и итеративная разработка появились до Agile, но последний как раз лучше подходит для продуктовой разработки и развитие в динамике с высокой неопределенностью в направлениях изменений.
Есть издержки на переделку архитектуры. Но компания их несет, уже зарабатывая с сервиса.
Сколько бы заняло написание требований, проектирование и реализация VK в текущем виде? Какой бюджет на это потребовался бы? А сколько бы стоило вписать в эти требования мобилки, которых на старте не было?
Два простых примера
Два простых софизма, а не примера. Производство материальных объектов тем отличается от производство ПО, что ПО можно незаметно для санитаров переделывать/переписывать/рефакторить хоть каждую неделю. Сохраняя одно и то же внешнее поведение или наоборот постоянно его изменяя. То есть это производство, сюрприз, гибкое. И все упирается даже не в бюджет, а в наличие скиллов. А вот со скиллами как раз проблема.
По моему опыту, в скилловом коллективе любой эджайл заходит на ура. Потому что скилловые ребята и без всякого эджайла понимали, что распланировать все на 3 года вперед - нереально и что работу нужно выполнять шаг за шагом маленькими порциями, корректируясь по ходу. Практики эджайла стали для таких людей просто оформлением этих мыслей на бумаге.
Разработка ПО конечной целью имеет производство данных или оказание услуг с помощью этих данных. Поэтому аналогии на производство материальных объектов уместны.
Если вы 3 года разрабатывали новый B2C стартап, наращивали клиентскую базу, гибко шаг за шагом развивали продукт и только на финишной прямой поняли что, например, проведение платежей между клиентами невозможно в принципе по законодательству вашей страны — у вас большая проблема впустую потраченных ресурсов.
Ощущение, что скиловый коллектив может переделывать ПО хоть каждую неделю возникает если проект тривиален в своей сути или просто не запланирован на реальную эксплуатацию. Например, это характерно для многих наивных стартапов, которые делают без какой либо реально бизнес модели. Не удивительно что там Agile заходит на ура.
Если вы 3 года разрабатывали новый B2C ... гибко шаг за шагом развивали продукт и только на финишной прямой поняли
Еще один софизм. Где тут гибкость-то, извините? Если у вас не нашлось времени проконсультироваться с юристом или финансистом, то при чем тут эджайл? Эджайл про разработку ПО, а не про утрясание юридических моментов.
Ощущение, что скиловый коллектив может переделывать ПО хоть каждую
неделю возникает если проект тривиален в своей сути или просто не
запланирован на реальную эксплуатацию
На моем "тривиальном" проекте более миллиона строк кода. Клиентская база - весь крупный ритейл Западной Европы. Работаем по канбану. Спокойно переписываем что хотим и когда хотим. Спокойно обновляем версии языка и фреймворков. Что мы делаем не так?
Если у вас не нашлось времени проконсультироваться с юристом или финансистом, то при чем тут эджайл?
Вопрос ведь в том когда это время для консультаций выделить. На старте проекта, в процессе проектирования и анализа бизнес требований или спустя N итераций гибкой методологии разработки.
Получается что гибкие методологии разработки подвержены рискам растраты ресурсов и создания нежизнеспособных продуктов, точно так же как и более консервативные методологии.
Эджайл про разработку ПО, а не про утрясание юридических моментов.
Программное обеспечение потому так и называется что является обеспечением какого-то человеческого опыта. Не стоит забывать что код и его разработка не цель, а всего лишь средство:
Вам не нужно ПО "Яндекс.Лавка", вам нужна доставка продуктов домой
Вам не нужно ПО "YouTube", вам нужно посмотреть видео
Вам не нужно ПО "Хабр", вам нужно читать статьи и обсуждать темы
Поэтому разработка действительно полезного и качественного ПО не может быть отделима от условий мира, окружающего человека.
Ну и вообще я всегда думал что понимание полезности продукта в основе любой гибкой методологии, странно что вы это разделяете. Если вы написали ПО которым нельзя пользоваться из-за юридических моментов то какой же это эджайл?
На моем "тривиальном" проекте более миллиона строк кода. Клиентская база - весь крупный ритейл Западной Европы. Работаем по канбану. Спокойно переписываем что хотим и когда хотим. Спокойно обновляем версии языка и фреймворков. Что мы делаем не так?
В своих рассуждениях вы фокусируетесь на средствах разработки, как будто это и есть цель гибких методологий. Но гибкие методологии утверждают что нужно фокусироваться на работающем продукте, а не формальных средствах.
Крупный ритейл Западной Европы действительно не тривиальный как сервис и продукт? Активно развивается? Вы каждую неделю разрабатываете обеспечение для новых моделей и форматов сбыта товара? Может быть меняете правила рынка?
Проект может быть объёмным по коду, но не обязательно это свидетельствует о концептуальной сложности развития продукта.
Или речь идёт о поддержке, предоставлении ещё одной витрины или интеграции с партнёром поверх существующих CRM, CMS, SAP? Тогда никаких вопросов, канбан тут идеально подходит.
Но вообще я не настаиваю. Будет здорово, если вы сможете рассказать про реальные примеры успешного применения гибких методологий для развития крупного ритейла. Таких примеров не хватает в любом обсуждении про эджайл.
Аналогии производства ПО и материальных объектов, действительно, уместны. Но ограничено.
Разница как раз в материальности объектов. На условном заводе новую деталь можно начать испытывать только после ее изготовления, а это всегда некоторый срок. На условном сервере, новый код можно начать испытывать условно через пару минут после пуша.
Что будет если испытания прошли неудачно? С деталькой - надо будет делать новую версию, а это опять некоторый срок. С кодом - в общем случае через пару минут можешь запушить новую версию.
И это разница в подходах - фундаментально влияет на организацию труда.
Понятно, что всегда можно придумать пограничные случаи, когда новую версию кода выпускают раз в несколько дней, а детальки печатают за несколько минут. Но то исключения, а не правило.
Детали на заводе перед изготовлением могут проходить испытания в аналитических системах: продуваются на аэродинамику, рассчитываются по матмодели, перепроверяются вручную проектной группой и т.д.
А вот ПО может поставляться частью программно-аппаратного комплекса или в виде коробочного решения, которое будет работать долгими релизными циклами без обновлений.
Так что получается разницы в подходах нет, инженерный опыт организации труда на заводах применим и для разработки ПО.
То не является исключением. Наши программы работают преимущественно с представлением материальных объектов, потому что нужны нам преимущественно для улучшения материального мира.
Исключением как раз являются некоторые предметные области, где объекты изначально виртуальные: игры, информация, и т.д.
Для примера. Какой код нужно написать чтобы у всех пользователей Хабра появились верифицированные паспортные данные? Это ведь не материальные объекты, по вашей логике, верно понимаю? На ваш взгляд, насколько это реализуемо и будет ли это быстрее чем изготовление деталей на заводе?
Вы серьезно думаете, что на современных заводах каждую детальку стоит и вытачивает дядя-токарь вручную с нуля? В наше время уже даже 3D-принтеры используются на некоторых заводах, не говоря уже о другой автоматике. И разница не в том, что код запушить 2 минуты, а детальку выточить не 2 минуты. Разница в том, что на заводе никому и в голову не придет без точных предварительных расчетов согласно законам физики и сопромата наспех что-то выточить наобум и переделывать потом по 20 раз. Но в разработке ПО почему-то все по-другому: тут считается нормальным подходом не думать заранее ни о чем, не писать ТЗ, а просто сделать абы какой прототип по-быстрому, а потом переписывать множество раз. Хотя, по-моему опыту, иногда хоть какой-то предварительный анализ и рисование схем экономит десятки человеко-часов разработчиков.
Когда дядька-токарь, 3D-принтер, или станок с ЧПУ делают детальку, они знают, что эта деталька уйдёт в полностью спроектированное изделие, где все детальки подогнаны друг к другу по размерам и характеристикам. А когда дядька-программист делает функцию - он не знает, через сколько лет, месяцев, или даже дней требования к этой функции изменятся.
Требования к физическим объектам крайне редко меняются после их выпуска, и обычно с учётом наличия на рынке предыдущих версий изделий. Например, если 01.01.2024 выйдет закон, обязывающий автомобили иметь фиолетовую фару сзади, которая будет светить когда в машине есть дети - эти требования почти наверняка вступят в силу далеко не сразу, а для уже выпущенных автомобилей будут применяться "херак-херак" решения (например, прилепить фонарь к заднему стеклу, или поверх багажника).
А вот в программировании не так: сегодня вам сторонний API возвращает в JSON
массив объектов
[
{
"a": 1,
"b": "qwe"
},
{
"a": 2,
"b": "asd"
}
]а завтра этот же самый массив
положат в объект-обёртку
{
"data": [
{
"a": 1,
"b": "qwe"
},
{
"a": 2,
"b": "asd"
}
]
}- и всё, ваш код надо переписывать прямо сейчас, потому что он уже не работает. Да, та сторонняя компания выпустила уведомление о смене формата, за 3 дня, только в виде статьи в справочном центре, куда ещё надо знать как добраться. Нет, конечно же ни вы, ни коллеги / менеджеры не ходите в этот справочный центр каждый день, потому что зачем, ваш имеющийся код ведь работает (уже нет).
Не всегда такое возможно, это - раз. Бывают ситуации, когда незаметно переписать не получится, в ПО (бунгало) изначально были заложены ограничения, запрещающие доработку до небоскреба и переписывать надо всё. Совсем всё, начиная с архитектурных решений.
Распланировать разработку ПО вперед на три года не реально ни в каком коллективе, т.к. каждые пару лет в ИТ совершаются "микрореволюции" и то, что три года назад было "масое модно-молодежное" внезапно становится "антипатерном", как было с теми же АктивРекорд или Синглтон.. а как всё начиналось-то .. ;)
Вы не поняли суть статьи. В статье речь идет о том, что узкую методологию для разработки ПО пытаются использовать на производстве, в ритейле, еще где-то.
И опять - откуда эта идея, что ватерфолл - это обязательно 1-2-3-10 лет чего-то. Это концепт с идеей - определяемся четко на берегу, затем делаем.
Вы кроме разработки ПО занимались какими-то еще профессиями в жизни?
Да тот же полет в космос как классика с переделкой компоновки ступеней ракеты, потому что в исходном варианте было плохо.
Сложный проект с ватерфолом даже в физических объектах невозможен, если это сложный проект. Так как половина сборочной документации — это исследовательская работа, входящая в работы по проекту. А значит детального ТЗ на момент старта проекта у вас не будет, и это не ватерфол, а кастрат. А если вы провели все исследования и дошли до сборочной документации до подписания договора, то в рамках чего были проведены эти работы? (См знаменитую статью про разработку Приуса Тойотой)
В программных, когда создать прототип дешевле, чем написать детальное ТЗ — ватерфол еще и экономически не оправдан ни разу.
И нет, бунгало на первом этапе небоскреба это что угодно, но не эджайл. Вот МВП в виде решетки из металлоконструкций без обшивки но с антивибрационным противовесом на сотом этаже — возможно.
Ну и финалочка с ватерфолом, вот вы начали строить бунгало на острове, а потом остров вместе со стройкой выкупил арабский шейх и решил превзойти дубайский отель на тропическом острове, что вы по вотерфолу делать будете? Достраивать бунгало и пытаться стрясти оговоренную сумму? Фишка изменений требований не в том, что при ватерфоле их удается избежать, а в том, что при аджайле их можно дешевле парировать. А возникать они будут все равно.
И гибкий эджайл это не только "из ПО тянут методики в реальный мир" но и отголоски той же Тойоты, где решение о том, что сойдет с конвейера может быть изменено на середине конвейера. В разработку ПО эти идеи пришли с опозданием от реального мира, а не с опережением.
В статье речь идет о том, что узкую методологию для разработки ПО пытаются использовать на производстве
Ну пусть не пытаются. Идите на их форум и расскажите, что они не правы. Как видите, на хабре у разработчиков ПО с эджайлом проблем нет.
Вы кроме разработки ПО занимались какими-то еще профессиями в жизни?
Увы для вашей софистики - да. Я работал в АСУ ТП.
Это концепт с идеей - определяемся четко на берегу, затем делаем.
И в АСУ ТП это тоже не работает, как вам хочется. Но там нет понятия "эджайл". Вместо этого там матерятся на заказчика, у которого 7 пятниц на неделе, вытрясяют из него бабки по доп соглашениям и тоже много чего переделывают на лету.
"Идите на их форум и расскажите, что они не правы."
Я без вас прекрасно разберусь, куда мне идти, на какой форум. Вас кто-то уполномочил выступать от лица всего Хабр сообщества? Вы комментарии читали? Здесь нет единого хора голосов в поддержку аджайл. Вам показать направление, куда идти с подобными советами?
"Я работал в АСУ ТП. "
И я работал в АСУ ТП, занимался автоматизацией домен и прокатных станов. А вы что автоматизировали, позвольте спросить? Мне для понимания.
Еще про АСУ ТП мне расскажите в ключе аджайла. Оччччень интересно. В АСУ ТП тонны документации только по одной электрике.
В моем тексте нет софистики. Ваше "увы" - мимо.
Лишняя работа за бесплатно.
Вот это - ключевое. Вы не понимаете что не забесплатно, а за деньги заказчика. В описанном случае с ракетой диалог через 2 года после старта разработки был бы таким:
Заказчик: Хочу изменить ТЗ ракеты с 3х на 6 человек
Исполнитель: в принципе это будет почти что новая ракета и это займет еще 2 года и 300 лямов баксов
Заказчик: хм.... я никуда не спешу и у меня есть 300 лямов баксов!
Это вы не поняли смысл фразы "за бесплатно". "За бесплатно" - это для конечного исполнителя. Что там снимет за доработки с заказчика организатор - это до исполнителя, как правило, не доходит.
Организатор - это кто в вашем понимании? За 20 лет работы в аутсорце по обе стороны баррикад(и со стороны вендора., и со стороны аутсорсера) ни разу не видел роли "организатор".
Значит плохо понимаете структуру взаимоотношений. Попробуйте работать в штате - может быть, для вас что-то прояснится.
О, я знаю эту историю из первого примера. В итоге лавочек сделали не 20 штук, а 3 и не на 6 человек а на 2-х. Но смету в итоге раздули еще в 4 раза, а директор парков уехал на 6 лет на зону за растрату...
"c четким ТЗ изначально" можно делать что-то примитивное за короткое время
всё что сложнее утюга быстро не делается, а значит с течением времени будем иметь естественное изменение окружающего и технологического ландшафта
можно только порадоваться за тех, кто доделал УК-НЦ2 к 2023-му году благодаря "чёткому ТЗ изначально", ведь там теперь 256КБ памяти!
Тезис: agile – только для простых проектов!
Наоборот же. Предположим, вы бизнес - запускаете какой-то онлайн-сервис. У вас есть гипотезы, каким-то образом конечно же протестированные, но полностью провалидировать эти гипотезы можно только реальным продуктом, которым будут пользоваться.
И вы несёте ТЗ в контору по разработке ПО, и через 2 года вам выдают красивый онлайн-сервис.
И одновременно с вами ваш конкурент тоже решает запустить такой же сервис, только разработку ведёт по agile. Через полгода у него появляется MVP, а через 2 года половина ваших потенциальных пользователей - уже пользователи сервиса-конкурента.
Да, их сервис вышел сначала без каких-то важных фич, но это было уже лучше, чем ничего. Лучше и для пользователя, и для бизнеса.
И за эти 2 года ваш конкурент провёл кучу А-Б тестов, пообщался с пользователями, и сделал пару-тройку фич, которые были востребованы, но изначально не было известно, что они должны работать именно так.
Итого - через 2 года бизнес конкурента имеет хороший денежный поток, базу пользователей, бэклог по улучшению, и уже улучшился под потребности пользователей.
Вы через 2 года имеете сдвиг запуска ещё на 3 месяца, но это уже не так важно. Почему? Потому что вам теперь снова требуется разработка - пользоваться вашим сервисом особо не хотят, ведь в нём не хватает части удобных фич, которые есть у конкурента. Поэтому вы пишете ещё одно ТЗ и снова несёте в контору, ждёте ещё 9 месяцев... Если ещё не закроете бизнес к тому времени, потому что прибыли у вас как было 0, так и осталось.
И тем более, ваш конкурент обладает ещё более важным преимуществом - он может зафэйлиться быстрее (пресловутый fail fast). Через год он уже сможет понять, есть ли деньги в этой нише, и если проект не летит, то закрыть его. По сравнению с вами он сэкономит 50% стоимости и времени. И через 2 года уже выпустит другой сервис. А вы всё ещё будете в неведении, отобьются ли ваши вложения в разработку.
И это ещё я не беру во внимание целый ряд рисков: контора-исполнитель может вообще закрыться, или плохо написать ваш проект, или затягивать сроки. Прозрачности в waterfall гораздо меньше, потому что часто проект даже не запускается до момента 90%-готовности. Да, можно будет подать на них в суд в каких-то случаях, но нам-то нужен не суд, а сервис.
И тем более, после написания сервиса его всё равно придётся менять, развивать, дописывать. Не могу себе представить ПО, которое выпустили и не дорабатывают годами, по крайней мере в вебе. Получается, если начать менять код, то ВСЁ РАВНО ПРИДЁТСЯ МЕНЯТЬ КОД. И от истории с agile-подходом это на самом деле не будет сильно отличаться. Вот только в agile-команде к этому уже все готовы, а в waterfall-команде ещё не факт что кодовая база готова к большим доработкам.
Мне кажется, вы мало понимаете, какие у предпринимателей потребности и какие риски, и почему огромную ценность имеет быстрый фидбэк от пользователей.
Даже в вашем примере со скамейками существует так называемый тактический урбанизм - сразу обычно непонятно, как именно нужно организовать общественное пространство, чтобы людям нравилось, где именно и какие именно поставить лавочки. Поэтому за 2 недели делают самые убогие лавки за 100р/штука, ставят и смотрят, как ими пользуются, опрашивают людей. И только потом, имея фидбэк пользователей, проектируют более основательное решение.
"онлайн-сервис"
Ваш онлайн-сервис - это как раз-таки простой проект. Как это можно не понимать? Сложный проект - это цех сборки локомотивов, система прогнозирования заполненности логистических центров каких-нибудь. Все веб-сайты - магазины, заказы пиццы - это все, с точки зрения логики - примитивные вещи.
И потом - откуда у вас в голове сидит "ватерфолл - это годы"? Кто это вбил в голову?
откуда у вас в голове сидит "ватерфолл - это годы"? Кто это вбил в голову?
Никто не вбивал, не беспокойтесь. В такой срок я оцениваю разработку средних размеров проекта, включая написание ТЗ и приёмку. Это пример. Не спорю, что можно и за 2 месяца что-то небольшое сделать и запустить в эксплуатацию. Но чем больше, тем дольше.
Ваш онлайн-сервис - это как раз-таки простой проект. Как это можно не понимать?
Просто с какой точки зрения? С точки зрения наукоемкости может быть ничего замысловатого нет в том, чтобы одни люди продавали, а другие люди покупали вещи.
Если же говорить про количество и сложность процессов, количество и требования к данным, к надежности систем и т. д., то мне кажется вполне сравнимо.
Опять же, чтоб построить производственный цех, нужно стоять на плечах гигантов - иметь разработанные и апробированные технологии, кучу документации по ним, поготовленных специалистов и т. д. Построить цех с нуля невозможно. Так вот, часть современного бизнеса примерно этим и занимается - заходит в неизвестные ниши, находит новые способы решить бытовые потребности людей. Там нет методички, как построить цех. Там есть только идеи.
Даже ракеты строить учились десятилетиями методом проб и ошибок, и в науке почти всё так работает. Невозможно дать ТЗ на то, чего нет и неизвестно как это сделать.
Если вы откроете манифест аджайла, то обнаружите, что это и есть тот самый метод проб и ошибок, только применительно к разработке. Не понимаю, как можно говорить, что такой метод годится только для простых проектов, наоборот, это очень близко к RnD.
Опять же не понимаю ваше деление на простое и сложное - получается СДЭК и почта сложные, авито - простой?
я делал систему контроля качества сборки вагонов (склады, 3 лаборатории и т.д. и т.п.) на большом заводе и сервис обмена электронными документами через веб. (просто два примера)
между ними разница - как между поездкой за город и полетом на марс. веб-сервис на два порядка, если не на три, делать проще.
А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.
Это абсолютно справедливо. Для любого инструмента.
Одно из главных правил Agile-методологий – команда-исполнитель принимает от заказчика изменения/ дополнения на любой стадии проекта.
Неверное заблуждение.
Agile - не про покорность исполнителя, и прием любых изменений в любое время.
Agile - про отсутствие деления на исполнителя и заказчика. Есть команда, ответственная за результат. И лицо, принимающее ключевые решение по свойствам продукта, такой же член команды, как и все остальные.
И главный критерий использования Agile-подхода - это не простота или сложность проекта. А возможность коротких итераций для выпуска новых версий продукта. Можете выкатывать в продажу чайник новой версии каждые 1-4 недели, флаг Agile'а вам в руки. Не можете - вам Agile не нужен.
И изменение приоритетов и переобувание по фичам продукта происходит как раз между итерациями. Их так и называют "спринт" - короткий забег на заранее определенную дистанцию. Потом остановка, определение нового направления и дистанции, и новый короткий забег. Во время забега, понятно, не до изменения требований, надо просто бежать.
Как-то раз мы думали заказать стороннюю разработку, потому как считали, что нет у нас нужной компетенции. Втроем (я-разработчик, инженер и продажник) за месяц родили тз по ГОСТу. Получился хороший всеобъемлющий документ. Я его прочел и за две недели написал нужное. Если бы мы обсудили в пивной общие цели и ограничения, а потом я мог показать текущий образец любому из группы и в течение получаса получить коротки ответ "да" или "нет", написал бы недели за 3, может, чуть больше. Моё мнение о гибких методологиях такое:
- Если вы можете собрать в одной комнате людей, которые хорошо понимают результат и имеют право принимать окончательные решения, и не выпускать их, пока не будет готов документ с подписями и печатями — водопад лучший выход.
- Если нет четкого понимания, но есть возможность оперативно получать окончательную обратную связь по каждому завершенному кусочку — гибкие методологии вполне подходят.
- Самый плохой вариант — "эджайл" с согласованием каждой фичи. Тут начинается цирк по Паркинсону: кто-то переваливает ответственность, кто-то стремится доказать свою значимость через вклинивание в цепочку...
Хохма в том, что по многим вопросам у заказчика нет мнения, он ими не задавался или ему все равно. Проще просить прощения, чем разрешения: если вы сделаете как-то, и оно будет работать, заказчик скорее всего скажет "принимаем" и не будет травить согласованиями; если спросите "кнопка красная или зеленая" — получите 20 часов совещаний. Работать в общем-то можно, но очень неприятно, что проблемы менеджмента, как своего, так и заказчицкого, в итоге падают на айтишника.
Насчет ракеты хороший пример, потому что Илон Макс как раз можно сказать по эджайлу и конструирует.
Быстрая разработка, прототип и MVP уже улетает на тесты. Пофиг на стартовый стол, и прочие недоработки, давайте запустим и посмотрим что получится и получим данные для анализа. И да, в старшипе сейчас много кардинальных изменений, например механизм разделения ступеней меняют в уже летавшей ракете.
А если по классическому ватерфолу идти, пользуясь только проверенными решениями, то получится sls, который долгий и неэффективный.
Сработало в узком сегменте простых IT проектов – давайте везде его применим! В промышленности
Дальше не стал читать. Agile так-то и пришел из промышленности. Дкржу автора в курсе.
Agile для всех или привычка натягивать сову на глобус