Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Agile — это манифест о том, как в динамично меняющемся мире делать реально полезные системы для пользователей, а не пилить сферического коня в вакууме.
В Agile нет спринтов и ритуалов. В нём нет системы контроля и планирования. В нём нет бюрократии и требований к проектированию.
Всё это есть в процессах, которые выстраиваются в командах разработки. Например, SCRUM, который зачастую превращался в SCREAM со всеми описанными пороками.
Но вопрос: это проблема SCRUM или результат работы руководителей этих команд?
В системах, где цена ошибки — это человеческая жизнь (Авиация, АЭС, пр.), нужна соответствующая система контроля качества. Agile или нет не важно.
Менеджер не должен быть «лучшим инженером», как и не должен быть «фасилитатором» — оба состояния вредны. Руководитель должен быть полноценным руководителем (а этому неплохо поучиться, чтобы не способствовать развитию Scream).
«Изменение структуры (кода) при каждом изменении требований» — это маркер, что именно инженерная команда «не понимает физики управления сложными системами». Ведь команда оказалась неспособна понять суть бизнеса компании и спроектировать систему, которая отвечает потребностям компании.
Но в целом, я согласен с идеей, что мы свернули куда-то не туда в разработке, но Agile тут явно не причём.
Зачастую в системах реального времени (Авиация, АЭС, пр.) одним контролем качества не обойдешься. Такая система должна быть изначально целиком правильно спроектированна и затем построена без отклонений от проекта. Слово Agile, лично я, тут даже на горизонте не вижу.
«Изменение структуры (кода) при каждом изменении требований» — это маркер, что именно инженерная команда «не понимает физики управления сложными системами». Ведь команда оказалась неспособна понять суть бизнеса компании и спроектировать систему, которая отвечает потребностям компании.
Таки чтобы понять суть бизнеса и спроектировать систему - это разве не этап бизнес-анализа и проектирования (или другими словами первые два этапа waterfall)?
У нас в компании уже 1,5 года скрам, и только сейчас дали 3 дня в конце спринта на анализ задач, которые идут в следующий спринт. 3 дня это на ВСЕ задачи (5-7, порой до 10 штук на программиста). Выделенного бизнес/системного аналитика у нас нет. И если задачи оказываются не готовы - их заменяют другими задачами, на которые уже не остается времени даже на такой минимальный анализ.
Понимание бизнеса не строится на анализе задачек спринта.
Сходите к вашему CEO/продакту/бизнес-лидер/etc и узнайте откуда деньги на весь банкет, кто ваши пользователи/клиенты и что им важно. Может пару custdev проведите сами или в гембу сходите, если есть возможность.
Появление аналитика только усилит все проблемы из статьи. Ведь человек за ЗП мидл разработчика будет должен, как ТОПовый эксперт уметь и в бизнес, и в архитектуру, и в разработку, и в эксплуатацию, и в продукт.
В своё время про всё это хорошо рассказал Филипп Дельгядо ещё в 2021 году — https://habr.com/ru/companies/oleg-bunin/articles/598925/. Рекомендую.
Ну а по «только сейчас дали 3 дня» повторю мысль из моего комментария выше: Возможно вам просто нужен тимлид, который имеет хороший опыт руководителя в ИТ.
Да, да все верно... Анализ то начинается задолго до задачек в спринте. Про три дня - это лайт версия, когда программист читает задачу и задает вопросы product owner и пытается предсказать за сколько нот он угадает мелодию sp / hr он сделает эту задачу. На безрыбье и рак рыба.
Я ходил в гембу с product owner и у нас была конференция для клиентов и я даже в какой-то мере проводил пресейл (хотя им не являюсь). Только по итогу - один клиент хочет предсказание закупок на склады, и показывает примеры из другого софта, которые, тем не менее, его не устраивают. А другой кучу всего и сверху еще 200 тысяч заказов в день (мы столько не вытянем в данный момент).
С ходу эти задачи не сделать. Не смотря на то, что у меня в голове сразу строится примерный план, как это можно было бы сделать - все равно нужна более детальная аналитика, плотная работа с solution architect, c sales team, да и вообще все это организовать и всех попинать. Тогда и появится шанс превратить это в детальный план, который может привести к тому, что эти два клиента к нам придут.
А должен ли это все делать рядовой, хотя и ведущий, программист?
Должен.
Каждая система — это отражение домена бизнеса и взаимодействия отдельных акторов в нём. Если мы не понимаем домен бизнеса, то не можем оптимально построить систему. Чтобы понять домен — нужно делать всё вышеперечисленное.
Но ИМХО все там будем в любом случае. AI постепенно закрывает самую долгую часть работы разработчика — написание кода. Поэтому постепенно внимание будет перераспределяться до состояния и швец, и жнец, и на дуде игрец (продакт-инженер-дизайнер в терминальной стадии).
Задайте себе вопрос, почему индустрия решила что аджайл хорош. Внезапно окажется, что 90% разработки про какие-нибудь сайты, с разной тематикой, динамикой, сложностью и нагрузкой.
Всё очень просто. Аджайл отлично подходит для разработок, которые в общем-то можно было и не делать. Для создания бессмысленной переусложнённой хрени, со сроком жизни порядка полугода. Или вообще никогда не доходящей до внедрения.
Как только начинается разработка системы для промышленности/индустрии, со сроками жизни разработки измеряемой в десятилетиях - немедленно получается тот же самый "итеративный водопад". Проектирование сверху вниз, начинающееся с концепции, ТЗ, архитектуры, плана работ, описания интерфейсов, и далее - то же самое по каждой из подсистем.
Аджайл идеально подходит, когда разработчики в сотый раз клепают ровно такую же хрень, какой занимались до этого 99 раз. Обычно это какой-нибудь стандартый проект с БД, бизнес-логикой и веб-интерфесом. Тут действительно можно работать без плана и документации, и быстро реагировать на быстроменяющиеся хотелки заказчика.
Agile придумали в тех коллективах где план как бы мешает самоорганизации сотрудников для разработки программы, но это должен быть очень сплочённый коллектив. В нынешних реалиях Agile больше работает на имидж сотрудников или же создаёт им возможность легально бить баклуши, так как если Agile в коллективе с соответствующим ТЗ нет, то значит с этим коллективом что-то не так как многие по шаблону думают, на самом деле такие коллективы сейчас просто редкость, люди другие и трава не такая зелёная.
Просто нет серебряной пули.
В стартапе очень важно уметь повернуть в тот момент, когда понял что движешься не туда. Очень часто изначально было одно виденье, сделали прототип, запустили, а оказало что половина бизнес-кейсов совсем иная нужна. Переделали, замерили метриками, поняли что вот тут вообще не перспективно, а это фичу надо развивать, потому что именно она понравилась пользователям. А заранее это нельзя узнать, потому что чтобы узнать - надо сделать и показать. На бумаге одно, а практика - критерий истины.
Оттуда и рождается подход по припиливанию фич сбоку, проверкой гипотез и прочего. Не обязательно что каждые две недели, но достаточно часто нужно менять вектор движения. И уже не раз, не два и не три было доказано что сделать сразу хорошо - это худший из возможных вариантов. А вот когда стартап стабилизировался, бизнес налажен - приходит время сделать как надо. Обычно это переписывание с нуля, иногда на другой стек. И вот тогда приходит время долгосрочного планирования.
Проблема в том что подход стартапов применяют везде, в том числе там где это совсем не нужно или даже критически вредно. Более того - тот же вотерфол, который водопад, это ведь тоже аджайл/скрам, только спринт может длиться 6 месяцев. В аджайле/скраме тоже есть планирование, обычно это созвон, доска с тикетами и прочим. Просто план на 2 недели. А 2 недели потому что так удобно, хотя кто-то делает и месяц. И потом следование четкому плану, иногда с этапами, а в конце ретроспектива. И планирование там есть и хорошее, но для горизонта в 2 недели. Если умножить это время на 20 или на 30 - это же тот же ватерфол. И два часа созвона превращается тогда уже в 60 часов, тогда то и проектирование системы влезает и всё что нужно чтобы поработать ближайшие полгода.
Проблема не в аджайле и скраме, проблема в карго-культе и не правильном выборе кванта времени под конкретный проект. Вот и весь секрет.
То, что в Agile называют гибкостью, правильнее назвать пластичностью или хрупкостью.
Сразу видно, что автор не абы кто, а целый ИНЖЕНЕР (произносить строго с придыханием).
Судя по тексту, слово "инженер" и его производные - единственное, что автор знает об инженерном деле, но слово ему это очень нравится, и он решил использовать его как символ своей борьбы за всё хорошее против всего плохого.
во-первых, не путай теплое с мягким - эджайл это принципы, а ты пишешь про скрам (по сути)
Во-вторых, эджайл имеет ограниченное применение: мелкие и квалифицированные команды, которые еще должны быть мотивированы
Спасибо автору за пояснение массам про вотерфолл вначале, красава!
На практике любой проект - гибрид, отличается только баланс предиктива/итератива
Мой опыт показывает: эджайл применим в допиливании внедренного продукта, в дендро-факельном продакшене - последнее не всегда плохо (например: у вас два дня на продукт с нуля в uat)
146% - статья точь-в-точь мои ощущения на текущем месте работы со скрамом. Лоскутное одеяло, так я это называю. С огромнейшим техническим долгом. Нам нельзя иметь задачи больше 8 sp, а еще лучше и их разбивать на более мелкие.
Я большие задачи начинаю разбивать на части, типа "часть 1", "часть 2", каждая по 8sp - меня спрашивают - а че так? Я говорю, там надо поправить 120 мест - исправить место, исправить вызывающий код, протестировать, если минимум 15-30 минут на каждое место и выходит от 30 до 60 рабочих часов на все по грубой оценке.
Мне - "Это как так 120 мест?". Я добавляю скрины в задачу, где я нажимаю find all references в IDE и оно показывает 122 ссылки + 89 (которые легаси, и мы договорились, что мы эти места не трогаем вообще). И да, я предлагал сделать эту задачу еще 3-4 года назад, когда там было 10-15-20 таких мест, но у нас тогда были другие приоритеты - фичи для клиентов. Фичи добавили, теперь таких мест стало (кэп очевидность) - 122 штуки.
Мне говорят - ну у тебя есть Codex, я говорю - окей, я попробую. Попробовал, он не осилил, навыдумывал какую-то хрень, хотя с небольшими задачами он справлялся вполне себе и экономил время раза в 1,5 - 2.
Так и живем 🙃
Менеджеры не любят давать время на рефакторинг, но это же проблема из менеджера, а не из эджайла. Они точно так же не давали бы времени на рефакторинг и в случае линейного планирования, годового планирования и т.д.
В твоем случае агильно твоё место меняется, да ещё мелкими сторями, хотя это будет дольше и дороже (как и весь эджайл). Насколько я не понял, поменялся контракт функции.
Делаешь дубль твоей функции (или что у тебя за место), настройку для переключения со старого кода на новый в местах вызова, а потом потихоньку добавляешь эту настройку и вызов по новому контракту любыми пачками, по одному вызову или по модулям/приложениям. Юнит-тесты и тесты выше уровнем дублируются до последнего этапа.
После добавления настройки её работа проверяется на проде. После изменений в нескольких некритичных частях выставляется это на прод, потом включается настройка. Выставляется больше изменений в вызывающих частях. Хоть один вызов, хоть все.
После всех изменений на прод... некоторое время НАДО ждать. А потом заводится изменение, удаляющее настройку и старый код вызовов.
Это агильный подход с feature toggle:
- Первые результаты быстро.
- Выкатывание не требует завершения всего изменения.
- Можно дробить на мелкие стори почти как заблагорассудится.
- По ходу выкатывания есть рабочий откат.
- Откат на ходу на проде может сделать даже уборщица, если ей админку дадут.
- Изменения на прод идут в порядке приоритета важности.
- После завершения перехода старый код рефакторится (удаляется).
- Работы у тебя в 2 раза больше, то есть это дороже.
После прочтения статья я чувствую себя как шаббес-гой, которому не заплатили.
Через пару лет и про т.н. ИИ такое напишут
Язык фактов.
Одни создали чучело водопада, вторые чучело в agile. И увлеченно их сжигают. Никто работать не хочет.
Автор явно путает скрам и аджайл. И судя по всему не разбирается во втором. Думаю это выжимка на рабочем опыте где очередные "эксперты" попытались добавить аджайла тоже не понимая что это такое. Рекомендую прочитать принципы и ценности в аджайл манифесте, там нет большей части того о чем пишет автор
Очень жаль что опять упирается в мартышку и очки
Ничего не мешает делать по водопаду в полном соответствии с эджаил манифестом. И много таких успешных проектов причем даже бывает разработчики об этом не в курсе просто относятся к этому как к самому собой разумеющемся. Зато где больше всего криков об эджайле обычно закостенелый каргокульт где соблюдение ритуалов преобладает над здравым смыслом.
Аджайл - для студентов, чтобы "на научной основе" трахаться сколько потребуется для хоть какого-то результата.
Ватерфолл - для профессионалов, которые умеют четко собрать требования, спроектировать результат, спланировать сроки и ресурсы. Если в ходе проекта что-то меняется, то оно доописывается, допроектируется, допланируется. Благодаря отсутствию потерь на "туда-сюда" получается вдесятеро быстрее и втрое дешевле. Минус только в том, что заказчик и спонсор должны принимать финансоао-временную ответственность за свои решения.
Эджайл появился , когда инженеры внезапно обнаружили, что система оказывается включает ещё бизнес и клиентов, кроме софта, железа и инженеров. А ещё внезапно оказалось, что бизнес и клиенты в этой системе важнее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Великая иллюзия Agile: как индустрия променяла инженерную науку на средневековый эмпиризм