Почему Scrum или Agile зло? ваше мнение

Архитекторы не любят scrum/agile потому что там нет такой роли как архитектор. Мол, гибкая разработка приводит к отношению «мы как-то начнем с MVP и как-то налепим эту вавилонскую башню по имени проект»

На практике, в аутсорсинге или аутстафе, в старте проекта все-таки участвует архитектор, просто позже уже проект менеджится по Скраму (спринты, ретроспективы, стендапы, etc)

Кто не читал 12 принципов Agile Manifesto — c ними можно ознакомиться здесь
agilemanifesto.org/principles.html

Что вам кажется неправильным во всех этих Scrum/Agile подходах и почему они зло? Что кажется странным? Что вам нравится и считаете годным?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Вкратце — потому что Scrum (как самая распространенная имплементация Agile) базируется на представалении об идеальном мире. Ну, типа как визуализировали СССР на витражах — мускулистые сталевары, инженеры под изображением атома и аппетитные колхозницы с колосками или ягнятами на руках. Все румяные, улыбаются и с радостью предвкушают следующий трудовой день.

Только вот эта идеальная картина в 90% с треском рушится при столкновении с реальностью аутсорса. Квинтэссенция подхода — сознательная, взаимоменяемая команда, переживающая за продукт.

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

И парадокс в том, что если вдруг каким-то чудом получилось собрать вышеупомянутую команду — то выбор конкретного процесса управления разработкой перестает иметь значение, так как настолько сильная команда заделиверит хороший результат при использовании любого из :))

Второй фактор — это непосредственно кастомер, его процессы и персонал. Опять же, возращаясь к Скраму — могу сказать что по моему опыту действительно сильный продакт овнер — это в лучшем случае в 30% случаев. А это второй ключевой компонент.

То есть имеет место регулярные попытки построить процесс при нарушении базовых принципов с предсказуемым результатом. И если на выходе каким-то чудом получается успешный результат — это в большинстве случаем вопреки, а не благодаря. Что стоит заметных дополнительных усилий, нервов, и уж никак не добавляет популярности процессу.

P.S. Скрам-фанатики мне очень напоминают адептов социализма/коммунизма. Ну, то есть идея непогрешима, а в случае фэйла — то у вас люди всегда неправильные ( «недостаточно вовлечены», my favorite -> «недостаточно эджайл», «недостаточно you name it» )

Agile это прежде всего про итеративную разработку и фокус на fail fast.

В моей текущей команде первое что я сделал это убил Скрам. Скрам создавал стресс — людей просили оценивать тикеты, в конце спринта половина тикетов не сделано, в середине спринта всегда кому-то надо что-то срочно сделать или починить, куча непонятных митингов «церемоний» и так далее.

Теперь у нас Канбан и все довольны. Мы больше не оцениваем тикеты, мы просто делаем что надо сделать. Каждую неделю мы планируем, каждые две недели мы показываем демо, каждый день проводим стендапы. У нас больше нет проблемы починить баг или сделать что-то срочное «сегодня».

Когда мы начинаем новую большую фичу — мы делаем user story mapping и определяем абсолютный минимум, так называемый MVP. После того как MVP в продакшене, мы итерируем и развиваем фичу. Или мы видим что это фейл и делаем что-то другое.

Только я хочу отметить что это не про аутсорсинг. Я работаю в продуктовой компании где фокус на результат, а не на продажу жопочасов. А вообще в нормальных компаниях команды работают так как им удобно. Я думаю FAANGи хороший пример — там все по разному в разных командах.

Я еще не видел двух компаний в которых Scrum, Agile и т.п. означали одни и те же вещи. Каждый натягивает эту сову на глобус как он хочет.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

О, уже и этот атрибут религии появился.

сто шагов© в эжаил!

Почему Scrum или Agile зло?

Вообще-то для программистов добро. Можно срамиться и хорошо кушать.
А вот для заказчиков таки зло. Бабки просрали и посрамились.

Посему нам, програмерам выгодно массово внедрять срам с аджайлом.

они не зло.
но чтобы они стали добром — нужны соответствующие условия.

Необходимых, но не достаточных всего то 2.

В действительности ж обычно их нет
Аджайл — не работает если:
1. Заказчики не могут по нем работать («Назовите точную дату сдачи и дайте гарантии выполения»)
2. Программисты не могут по нем работать («Дайте мне четкое ТЗ!!!»)

еще из моей коллекции
Why Isn’t Agile Working?

в итоге чаще всего имеем презренный забюрокартизированный «водопад» украшенный рюшечками аджайла.

Особенно сильно это в аутсорсе, где дистанция между исполнителем и заказчиком делает невозможным получать плюшки от аджайла (или итеративной разработки, RUP, FDD, ..., ).

Фрилансеры и продуктовые компании — могут их получить.

в итоге чаще всего имеем презренный забюрокартизированный «водопад» украшенный рюшечками аджайла.

Если только говнопад, как на свинарнике. Водопад — это четкое и однозначное ТЗ, четкие и последовательные этапы проекта и его сдача заказчику в итоге.

Четкого ТЗ для сегодняшних проектов существовать не может. Сильно много факторов входят в игру.

Ты просто посмотри на мир ширше и увидишь, что может.

примените к себе, и откройте глаза наконец, чтобы увидеть что мир:
изменчив, асбтракции текут, и «если хотите расмешить Бога — то расскажите ему о своих планах»
VUCA — volatility, uncertainty, complexity, ambiguity — нестабильность, неопределённость, сложность и неоднозначность

Косность харакатрена — для детей, которые этого не знают в силу возраста и малости опыта, и для стариков потерявших нейропластичность мозга.

— совет слепого зрячему.

Слепой точно знает, что он много не видит и пытается найти пути увидеть. Зрячий всегда уверен, что он видит всё, а в реальности видит всего лишь чуть больше, чем слепой.

Слепой точно знает

потому что он не ходит по местности.

и не в курсе что «Карта — не местность»

а в программировании в тьме монографий можно прочесть, если свести к лакончиности. Если уж опыта нет, или ничему то жизнь не научила ;)

Требования ВСЕГДА изменятся.

но слепой сидит на месте и рассуждает на основе своих иллюзий.
как упоротый математик :)

это даже странно что это надо пояснять.

давно ж известно
Ходить по воде и разрабатывать программы, следуя спецификации, очень просто... если они заморожены. — Edward V Berard

Вот этот Эдвард может смотреть ширше.

только он как и многие другие говорят что верования в хождение по замороженной воде — наивны.

собственно причинами самого появления аджайл манифеста было как раз это осознание.
Как и других методик к управлению разработкой.
Как и самого ООП, и т.д. и т.п.

Потому что у другого классика мне нравится
Неважно что умеет делать ваша программа сегодня. Важно что она будет уметь завтра (моя приписка — потому что этого не знает никто, но она должна будет уметь это делать)

Зимой замороженной воды море. А в Арктике и Антарктике еще больше, причем и летом и зимой.

Важно что она будет уметь завтра

Вот когда из гати через болото сделаешь капитальный мост по сраму, тогда и расскажешь про срамы.

о том что для планировании невозможно получить всю информацию говорится не одно тысячилетие. От Ганибала до промышленно-финансовых воротил.

А программирование — это и близко не строительство мостов и не математика.
Хотя и «строительство мостов» это немало решений по месту. Потому что чертеж — еще не мост. Нужно наладить само строительство, со всеми нюансами управления людьми, логистикой а то и политикой успокаивания «протестующих экологов и местного населения» против этого строительства.

А программирование — это и близко не строительство мостов и не математика.

Вот поэтому я не против срама, если платят хорошо. В нем есть один большой плюс — никто не спросит за результат, нужно только быть деятельным (ИБД) на спринтах.

З.Ы. Но нужно знать важное — сколько денех у того, кто платит, чтобы вовремя слинять на +500.

А в Арктике и Антарктике еще больше, причем и летом и зимой.

...или как потратить пару часов на намеки имея ввиду «недоступный для других уровень программных продуктов со строгой спецификацией и валидацией»

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

сейчас доступен во многих аналогичных направлениях по всему миру

Ты это говоришь из опыта или из научпопа?

да, удивительный вечный джун. Старожил доу, как и я.
Разбанил вот, а он еще более «заджунился».

...из недавних историй
Vadim Lukashevich
Дата первого полета марсианского вертолета Ingenuity снова ушла «вправо». Напомню, что расчековка и проворот лопастей вертолета прошел нормально, как и тест вращения на начальной скорости. Но с выходом на взлетный режим (более 2000 оборотов/мин) возникли проблемы. Если бы на этом этапе все прошло нормально, что следующей стала бы попытка взлета — раскручивание соосного винта на взлетные обороты с последующим изменением шага, т.е. поворотом втулок лопастей на положительный угол атаки для создания подъемной силы. Но не удалось раскрутить винты до нужной скорости...
Анализ проблемы показал, что она оказалась серьезнее, чем предполагалось. Однако сам вертолет (т.е. матчасть) в норме — дело в последовательности операций. Все выходные искалось решение, и в итоге команда разработчиков пришла к выводу, что нужно модифицировать программное обеспечение вертолета.
(конец цитаты)

таким бы идеалистам в NASA работать, там сплошь криворукие что программисты, что инженеры, что математики. Вечно какие-то проблемы выплывают у них в проде.

А у Маска так вообще ракеты постоянно только и взрываются. Ему бы Инженеров нанять, а не сброд какой-то

Я никого джуном не называл. Идеализм присущ в той или иной степени разным людям — это нормально, и я сам идеалист в определенных вопросах.

Насчёт наса — думаю мы всех деталей их внутренной кухни не знаем, за исключением если вы там не работали.

конечно присущ. без него невозможно само мышление.

но мы говорим о конретной теме. и за годы в ней — уже есть маркеры джуна.
они подмечены многими авторитетами :)

их также можно обнаружить в всяких статьях на медиуме, реддите, dev.to от коллег.
статьях типа
«Вот что я понял за 20 лет в программировании»

Джуну это все пояснить «невозможно», он категорически отрицает.
Знаю по собственному опыту руления и обучения джунов.

И если чел не слеп и не дурак, а всего лишь просто малоопытный, то, как недавно мне один джун написал, после первых месяцев на новой работе «+500»:

Эта работа дана мне осознать почему джунов не берут на работу 🙃. Работаю с джуном верстальщиком, так это тихий ужас. Вещи, которые сами по себе подразумеваются она не делает сразу. До этого с другим верстальщиком работал там получше было. Но эта работа своеобразный урок, полезный опыт всё равно
...
Хотя я сам ещё джун, но возможно уже лучше понимаю как быть близким к миддлу или похожим хотя бы
(конец цитаты)

парень молодец, учится, смекает.
а в начале то нашего знакомства что он говорил, как рассуждал

Насчёт наса — думаю мы всех деталей их внутренной кухни не знаем,

кухня ни при чем.
есть — неполнота информации.

из которой неверно делать выводы что никакого планирования, спек, ... — не нужно.

это как в автомобильной теме:
1. Перед поездкой по незнакому маршруту — очень полезно ознакомиться с картой и прикинуть маршрут.
2. Но вы никогда не сможете спланировать дорожную обстановку — какой лось вас подрежет, или вообще въедет вам в бок с второстепенной, когда вы на главной, потому что его солнце ослепило, и он не видел знака Уступи дорогу"

Вот наивность, джуновость и есть полное непонимание о чем второй пункт

А идеализм да, неотъемлимый атрибут упорядоченного мышления.

2. Но вы никогда не сможете спланировать дорожную обстановку

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

теоретически с ватерфолом, такого быть не может, но вот практически, оно именно так сплошь и рядом — и это нормально, мы люди и всего знать/узнать/помнить не можем. ватерфол эту часть человеческой натуры игнорирует, и поэтому на него не стоит надеятся.
да можно придумать костыли — срубит деревья рядом с бывшим мостом и попытаться соорудить мост самому и может даже удасться перевезти машину, а можно попытаться съехать в овраг и найти мель в речке и каким-то чудом перетянуть машину на другую сторону. только костыли могут помочь, а может быть как c Cyberpunk 2077

я о другом. может карта которой вы располагаете не актуальн

а я, и Коржибски, о том что карта — ВСЕГДА неактуальна
«Гладко было на бумаге, да забыли про овраги»
«В теориии между теорией и практикой нет разницы, а на практике — она есть»

если бы сделали более лучший ресерч

при бесконечном времени.
а на практике, один миллиардер сказал нечто вроде
«Стоимость и время получения первых 80% информации меньше получения остальных 20%. А решения вам надо принимать — сегодня»

или как в одной статье «что я понял за 20 лет»

Люди массово считают что программы пишутся сразу те и правильно, после каких-то глубоких расчетов.
А в действительности хорошо если мы, программисты угадаем 15%.
Остальное дописывается, исправляется потом.
Написание программ больше похоже на стрельбу трассирующими пулями, чем на точный расчет траектории каждой пули

Другой
Разработка ПО более похожа на создание анимационного кино, чем создание инженерного продукта. со всеми изменяющиимся видениями продюсера, кризисами сценариста, очереди на сервера рендеринга, рекламными планами и т.п.

Ну и сама тема — чтобы понять о чем аджайл, что он может и почему не работает — нужно копнуть в биографии-опыт его авторов, в проблемы, решение которых они попробовали озвучить в манифесте.

А так да, если бы да кабы более точный ресерч, если бы да как бы мир был детерминированным и статичным, если бы, если бы

а о том что мы можем знать, но не узнали т.к. не предприняли достаточное количество стараний.

у этих стараний тоже название уже есть:
Одна из распространенных проблем — это так называемый «аналитический ступор»

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

Даже лёд бывает трескается под ногами и уходишь под воду. Спецификации пишутся людьми, а компетентность пишущего ее может быть далека от хорошей (и скорее всего так и будет), но пусть это самый лучший специалист в мире — это будет человек. Человекам свойственно ошибаться, и уставать в итоге некоторые части ТЗ могут быть проработанными не на должном уровне, а порой 1 ошибка в спецификации может стоит крайне дорого, настолько что прийдется переписывать все. А возвращаясь к размерам сегодняшних проектов то ошибок будет скорее всего много.

Это только на бумаге это идея выглядет хорошо, в реальности все всегда иначе.

И вот тут ты подобрался к одному важному моменту: 1 ошибка в спецификации (водопад) или хрен знает сколько их при разработке «как бог на душу положит» (срам).

Я последний год работал по спецификациям. В среднем 1/4 спецификации противоречила сама себе и ее приходилось менять, что влекло за собой ещё больше изменений. Аджайл — это просто принятие реальности. Про скрам ничего говорит не буду, так как он чересчур специфический.

А я не так давно поработал в стартапе по попилу бабла инвестора. Два года мы успешно пилили и даже какую-то херню слепили. По итогу инвестор остался без штанов.
Продать слепленное не смогли по простой причине — дорогое очень вышло. Причина простая: был выкинут первый этап водопада — оценка требований рынка и его потребностей, оценка возможности вообще сделать подобное и разработка ТЗ под оное. Кстати, если бы был первый этот этап, то таки сделали бы то, что вполне продавалось бы. А да, если бы у инвестора были деньги еще на 3 года, то можно было выкинуть нафиг налепленное, заюзать его как базу для ТЗ и сделать то, что продавалось бы и принесло бы прибыль инвестору.

Кстати для меня стартап этот был очень выгоден — мне платили и неплохо за то, что я учился там многому (учиться всегда полезно, позже можно продать полученные знания).

Для стартапов придумали специально lean и я так понимаю вы по нему реально не работали. Вообще работа в стартапе должна быть абсолютно другой чем в продукте.

Так решили директор с инвестором. Мне в общем пофиг почему. Я два года по сраму поработал без напряга, учился и за этом мне еще и неплохо платили. В общем для меня было всё очень хорошо.
Сейчас вот ищу подобное что-то.

З.Ы. И стартап был продуктовый — это продукт, только маленький еще.
Или ты продуктовой разработкой считаешь только саппорт древних отложений мамонта в продукте, которому уже лет 20?

ну они то же люди, выбрали что знают/слышали да и все. то что они хорошо не подумали что они делают бывает и с ватерфолом, ибо ту же оценку требований рынка можно делать крайне по разному, и результаты будут крайне разными.

продуктом я считаю состоявшийся стартап — то есть он стал окупаться.

ну они то же люди, выбрали что знают/слышали

Во, поэтому програмерам выгодно рекламировать срам.

З.Ы. дело в том, что иногда хочется честно на форуме высказаться, что думаешь о чем-то, а не только в финансово выгодном плане.

все так.

добавлю что
спецификация не может быть полной по методу ее создания — абстрагирование. то есть процесса преднамеренного опускания деталей.

а у самого программиста, самого компетентного — всегда есть сроки. и приходится ...

вобщем мало мальски опытные знают сами, цену идеализму :)

а у самого программиста, самого компетентного — всегда есть сроки. и приходится ...

Озвучивать выгодные тебе, как программисту.

Расскажу тебе байку. Помню начальство (было лет 15 назад) захотело по одному проекту четкую диаграмму Ганта с планом. Мне не проблема удовлетворить начальство — все разрисовал и они получили завышенные в 5-7 раз, но абсолютно обоснованные сроки. Больше подобного не просили.

Аджайл — не работает если:
1. Заказчики не могут по нем работать («Назовите точную дату сдачи и дайте гарантии выполения»)
2. Программисты не могут по нем работать («Дайте мне четкое ТЗ!!!»)

Верхи не могут, низы не хотят.
С такими вариантами, редко что работает.

С такими вариантами, редко что работает.

это да.

просто интересней — почему так.
причем — почему появился аджайл как решение проблем (и каких), вокруг него восторг, а вот применять его — не хотят/не могут

по другому
что в нем такого что он вызывает восторг, является желанной бирочкой, признаком качества — но при этом

не любят scrum/agile
почему они зло?
очему появился аджайл как решение проблем (и каких),

проблема была одна — удешевление разработки, ватерфал для многих был слишком дорог

а вот применять его — не хотят/не могут

easy to learn hard to master — (явную) «стоимость» разработки «порешали» ценой (скрытой) сложности.

ватерфал для многих был слишком дорог

а начать лучше с того, что
В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.
(вики)

Мое прочтение его статьи: он ввел этот термин как «соломенное чучело», показав что он, ватерфол — невозможен в принципе, хотя идеалистично очень бы хотелось. особенно менеджменту.

(явную) «стоимость» разработки «порешали» ценой (скрытой) сложности

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

Байки про расчет времени реализации в программировании опущу. На доу ж все таки.

Я к тому что:
Термин «кризис программного обеспечения» был введён Фридрихом Л. Бауэром на Конференции НАТО «Инженерия программного обеспечения» в 1968 в Гармиш-Партенкирхене (Германия).
Термин использовался Эдсгером В. Дейкстрой в 1972 в его лекции при получении премии Тьюринга:
Причины кризиса программного обеспечения были связаны с общей сложностью аппаратного обеспечения и сложностью разработки программного обеспечения. Кризис проявляет себя самым различным образом:
Стоимость проектов превышает бюджет.
В проектах превышаются сроки выполнения.
Программное обеспечение было слишком неэффективным.
Программное обеспечение имело слишком низкое качество.
Программное обеспечение зачастую не отвечало необходимым требованиям.
Проекты были неуправляемыми, и возникали трудности с поддержкой кода.
Программное обеспечение было непригодным для распространения.

и дело осталось за малым, зная эту проблему, найти метод ее решения
на дворе 2021 год
и как успехи?

проблема была одна — удешевление разработки, ватерфал для многих был слишком дорог

Там скорее проблема нечетких требований и желание сбить с заказчика побольше — если требования не выписаны, но в результате должны быть реализованы, то это ЧР и за доп. плату. В идеале — посадить заказчика с фиксед прайса на т/м или вообще на дедик тиму.

А посему — это в интересах кастомера делать ватерфол, а в интересах кодера — итеративную разработку.

А посему — это в интересах кастомера делать ватерфол, а в интересах кодера — итеративную разработку.

потому что кодер не может обеспечить поставку в срок. потому что оценивает объем работ, по разным не очень глубоких исследований — меньше в 6-9 раз.
а кастомер хочет сроки и фиксированный бюджет.

а когда все фикси и сроки тоже, то нередко получается продукт, который не нужен кастомеру.

об этом ж тьма сколько написано :)

Там скорее проблема нечетких требований и желание сбить с заказчика побольше

это так выглядит для заказчика.
а в действительности, особенно когда заказчик выбирает — сейлсы ему занижают цену, даже зная реальную, в расчете на то что потом доберут.
и сроки, тоже обещают заманчивее других

и заказчик потом удивляется, почему-то это сроки сорваны и денех надо минимум еще столько же!

про это ж вся тема, с конца 60ых :)

причем, точно так же происходит «у строителей мостов»
— мне бы дачку, вот такую, сколько стоит, и за сколько сделаете?
— сейчас, смету набросаем. Вот: ...
(аха, понятно, пойду у других поспрошаю)
— сейчас, смету набросаем, Вот ...
(ух ты, в 3 раза дешевле, и в 7 раз быстрее, пусть строят)

а потом, как в одном видео было, «как друг у меня дачу строил». кажется от Дорофеева.
вместо обещанных полугода — два года. И когда бюджет превысил изначальную стоимость в 5 раз — начал продавать недострой

Вообще, как понимаю про строительство мостов массово такое же идеализированное представление.
Как и со многим другим, от чего далек обычный программист, и ему мерещится что уж там то, у них, все круто, а вот у нас «бардак»

из недавнего — уже несколько крупных автопроизводителей останавливали производства в этом году.
потому что — песка на Земле мало. тьху, нехватка микросхем.

А TSMC говорит что дефицит возможно сохранится до конца 2023го.
где планирование, а?
где эти экономисты, социологи и спецы в статистике?

а когда все фикси и сроки тоже, то нередко получается продукт, который не нужен кастомеру.

На фиксед прайсе кастомер может потом пойти в суд и выбить неустойку.

и заказчик потом удивляется, почему-то это сроки сорваны и денех надо минимум еще столько же!

Заказчик идет в суд и требует закрыть за цену по контракту.

а в действительности, особенно когда заказчик выбирает — сейлсы ему занижают цену, даже зная реальную, в расчете на то что потом доберут.

Проблемы галеры

где планирование, а?

Ковидный форс-мажор

Заказчик идет в суд и требует закрыть за цену по контракту.

да, я в курсе что у некоторых в их мире — просранное время можно купить за деньги

На фиксед прайсе кастомер может потом пойти в суд и выбить неустойку.

или не выбить.
или исполнитель все риски — вложил в цену. и потому она выше в разы чем вон там, какие-то бравые джуны предлагают «все переписать с нуля, за выходные».
ну потому что они ж знают как правильно разрабатывать ПО. а остальные — не знают.

это ж тоже классика опознания джуна
когда новичек после пары дней на проекте — где дока? что это за архитектура? почему говнокод?

а те кто в теме, даже читать не будут, статью с названием типа
«Оценка срока проекта. Почему она почти всегда сильно занижена и что с этим делать»

это джну надо объяснять, почему так.
но он да, расскажет об идеальном мире, точном инженерном расчете движения каждой молекулы, и — делов то, в суд, и все возвернут и доделают наконец, в качестве штрафных санкций, за так.

«Оценка срока проекта. Почему она почти всегда сильно занижена и что с этим делать»

То

или исполнитель все риски — вложил в цену.

В том числе и риск прилета метеорита в главного разработчика.

И в итоге всё получится — долго, дорого и качественно.

И в итоге всё получится — долго, дорого и качественно.

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

писал уже, идите поучите программистов NASA и инженеров у Маска — как софт писать, чтобы марсоходы с спутниками не висли(а то регулярно) и чтобы ракеты не взрывались.

за сим откланиваюсь. вы ж не джун, рассказывать вам за жизть.

когда новичек после пары дней на проекте — где дока? что это за архитектура? почему говнокод?

Бывалый на этом месте либо просит рейт в два раза больше, либо времени на таски в два раза больше, либо валит с проекта.

но он да, расскажет об идеальном мире, точном инженерном расчете движения каждой молекулы, и — делов то, в суд, и все возвернут и доделают наконец, в качестве штрафных санкций, за так.

Если недоделают, то заказчик вообще ничего не заплатит

Главное не текущее состояние проекта а тенденция его изменений и направление

Там скорее проблема нечетких требований

при желании, эта проблема легко решается.

А посему — это в интересах кастомера делать ватерфол

Если у него хватит денег.
Например, если «требования нечеткие», и кастомер не знает, что он хочет — web app/mobile app/chat bot/whatever, но готов заплатить за все — то почему и нет.

Если у него хватит денег.
готов заплатить за все

Так есть деньги или нет денег? Если кастомер не знает (не говорит) чего хочет и не контроллирует процесс, то такого кастомера имеет смысл уволить.

Методології апріорі не можуть бути злом.
Злом є люди, зокрема, шизонуті адепти вищезгаданих методологій, які, замість того щоб працювати, носяться із пмбуком як німфоманка з огірком, та все вишукують, на який би ще ото глобус натягнуть сову, бажано — декілька.

Методології апріорі не можуть бути злом.

Уявіть собі методологію, в який за зрив строків здачі розстрілюють кожного десятого.

І шо?! Методологія все ще не буде злом. Банально тому що «бумага всё стерпит» © Доведено, наприклад, Біблією :)
Злом, знову ж таки, буде умовний адепт методології.

Але про всяк випадок, для любителів reductio ad absurdum, трохи скоригую:

Гнучкі методології апріорі не можуть...

Ну а що стосується «розстріляного кожного десятого», то:
— моїм моральним нормам це не суперечить, за умови, що всі учасники процесу знали, на що йшли;
— припускаю, що в окремих випадках підхід в цілому може бути доцільним та співрозмірним важелем мотивації.

І шо?! Методологія все ще не буде злом

Серйозно?

для любителів reductio ad absurdum

Самі з собою ведете цікаву беседу... ну ok.

припускаю, що в окремих випадках підхід в цілому може бути доцільним та співрозмірним важелем мотивації.

:)))

І шо?! Методологія все ще не буде злом. Банально тому що «бумага всё стерпит» © Доведено, наприклад, Біблією :)
Злом, знову ж таки, буде умовний адепт методології.

Вы как маленький — он скажет, что «исполнял свою роль», «в гайде так написано», и «решение принимал не он».

Основные причины, по которым я ненавижу срам:
1) Сраммастеры хотят срамные эстимейты
Ну серьезно, приходишь ты такой на новый проект или галеру, пытаешься найти где тут туалет, кухня и банкомат, а к тебе на серьезных щщах подваливает какой-то додик и говорит: «У нас тут планирование, вот список задач, вот тут все говорят сколько времени займет и ты говори». И не имеет значения, что ты новый на проекте, или задача из какой-то вообще незнакомой области, или ты понятия не имеешь, что тот кусок говнокода делает — нет, надо эстимейт и ниипёт. При этом они еще и обижаются, если говоришь, что за 3 месяца сделаешь, а точнее оценить не можешь. Жутко бесит. Самые адекватные из сраммастеров соглашаются на investigation таски — типа этот спринт смотришь, что и в какой последовательности нужно будет сделать, а в следующем уже делаешь. Ещё жутко бесит, когда в команде находится трудолюбивый задрот, который заявляет на твой эстимейт «ну это слишком долго, я сделаю в три раза быстрее». К счастью, такие встречаются всё реже, или хотя бы у них хватает ума не отсвечивать, но всё равно как-то даже стыдно рядом с такими сидеть. Ну сделаешь ты быстрее, так сиди и молчи, всем же выгоднее, если эстимейт больше будет — можно будет своими делами позаниматься, нет, я у мамы пионер, надо вякнуть. И даже как-то неприлично ему за такое пояснять — вроде как взрослый человек, а такую дичь творит.
2) Бесполезность сраммастеров
Ну действительно — все технические люди (девелоперы, тестеры, даже аналитики) в принципе что-то делают. Не будем говорить о том, что глобально это всё нафиг никому не надо, и все занимаются бессмысленной ерундой, но все эти персонажи что-то потихоньку куда-то пихают и прикладывают какие-то усилия. А что делает сраммастер? Особенно если это выделенный, сертифицированный сраммастер из палаты мер и весов? Ничего! Он не делает тупо ничего полезного. Наш вот смотрел на бурндовн чарт в джире и еженедельно нам что-то про него рассказывал, говорил, что задачи должны быть маленькие и статусы надо обновлять регулярно. При этом не удивлюсь, если и получал он в районе ~4-5к, т.е. как нормальный человек. Но толку от него ноль! Нафиг он нужен, если он ничего полезного не делает? Ни требования нормально выяснить не может, ни даже контакта на стороне заказчика найти. Ещё и просил, чтобы его в копию во всю переписку ставили, при этом я зуб даю, что он там ни слова не понимал. Короче, суть претензии — если есть на галере гребцы, то сраммастера — это исключительно пассажиры. Прув ми вронг.
3) Дейли митинги, они же стендапы
Может в тех «тру аджайл» командах это и имеет какой-то смысл, но всё что мне встречалось — это тупо попытка контроля за гребцами, чтобы они хоть что-то делали. При этом контрится это на раз-два, учитывая полную техническую безграмотность сраммастеров. При должном умении можно месяцами водить его за нос, при этом на каждом митинге всем будет казаться, что ты тут горы сдвигаешь и пашешь как проклятый. Не надо меня спрашивать, что я вчера делал — тебя это не касается. К концу спринта должны быть сделаны задачи, на которые я лично дал эстимейт и сказал, что они будут сделаны. Всё! Если это не выполнено — тогда и спрашивай.
Еще одна неприятная особенность — это тупо трата времени. Мне откровенно всё равно, что делает Вася рядом со мной — делает ли он вообще хоть что-то, какие там у него проблемы и будет ли завтра Вася или Петя. Меня волнует исключительно соотношение «мой объём работы/моя зарплата». Если у Васи ко мне вопрос — пусть подойдёт и спросит напрямую, зачем напрягать 5+ людей упоминаниями в виде «Это нужно будет обсудить с ...., я после митинга к нему обращусь».

Как-то так. Реально бесит этот ваш срам, и к сожалению, он практически везде сейчас. Может кто знает какие-то домены, где этой дряни поменьше?

Первый пункт везде такой, приходишь такой на проект и попадаешь на sprint planning. Можно сказать Скрам мастеру, чтоб он игнорил твои оценки. Но лучше тим лида втихую спрашивать то, как он оценивает, чтоб вопросов не было и не выделяться. Смешно. Но такой вот срам реально.

1) Сраммастеры хотят срамные эстимейты

Все хотят эстимейты, но в скраме случается «чудо», и скраммастер преврашает «естимейт» в «комитмент».

Короче, суть претензии — если есть на галере гребцы, то сраммастера — это исключительно пассажиры.

В гайде когда-то была аналогия с свиньями-курами, но ее потом убрали.

Вкратце — потому что Scrum (как самая распространенная имплементация Agile) базируется на представалении об идеальном мире. Ну, типа как визуализировали СССР на витражах — мускулистые сталевары, инженеры под изображением атома и аппетитные колхозницы с колосками или ягнятами на руках. Все румяные, улыбаются и с радостью предвкушают следующий трудовой день.

Только вот эта идеальная картина в 90% с треском рушится при столкновении с реальностью аутсорса. Квинтэссенция подхода — сознательная, взаимоменяемая команда, переживающая за продукт.

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

И парадокс в том, что если вдруг каким-то чудом получилось собрать вышеупомянутую команду — то выбор конкретного процесса управления разработкой перестает иметь значение, так как настолько сильная команда заделиверит хороший результат при использовании любого из :))

Второй фактор — это непосредственно кастомер, его процессы и персонал. Опять же, возращаясь к Скраму — могу сказать что по моему опыту действительно сильный продакт овнер — это в лучшем случае в 30% случаев. А это второй ключевой компонент.

То есть имеет место регулярные попытки построить процесс при нарушении базовых принципов с предсказуемым результатом. И если на выходе каким-то чудом получается успешный результат — это в большинстве случаем вопреки, а не благодаря. Что стоит заметных дополнительных усилий, нервов, и уж никак не добавляет популярности процессу.

P.S. Скрам-фанатики мне очень напоминают адептов социализма/коммунизма. Ну, то есть идея непогрешима, а в случае фэйла — то у вас люди всегда неправильные ( «недостаточно вовлечены», my favorite -> «недостаточно эджайл», «недостаточно you name it» )

И парадокс в том, что если вдруг каким-то чудом получилось собрать вышеупомянутую команду — то выбор конкретного процесса управления разработкой перестает иметь значение, так как настолько сильная команда заделиверит хороший результат при использовании любого и

 Не соглашусь. Без процессов, вероятно перейдет в разряд «каждый синьйор сам за себя», с плохой коммуникацией, несовместимым кодом, и прочими проблемами. Нужен оч хорошие менеджер и тим лид что со скрамом что без.

то выбор конкретного процесса управления разработкой
. Без процессов, вероятно перейдет в разряд «каждый синьйор сам за себя»,

Я имел в виду не полную анархию, а то, что будь это например RUP, MSF, или вообще что-то кастомное ин-хаус, вместо скрама — результаты будут как минимум не хуже, в случае действительно сильной команды

Сеньор — это не только быстро код писать, но и в коллективе сотрудничать.

сенйор, по-польськи, — пенсіонер

Вообще, нет. Пенсионер по старости emeryt, пенсионер по инвалидности — rencista. Senior — просто старший человек, чаще всего по возрасту, но не обязательно.

Пункти про взаємозамінність членів дев тімки вже викинули зі скрам гайда

Когда и кто выкинул? Ссылка есть на это решение?

Scrum Guide, версії з 2011 по 2016:
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person;there are no exceptions to this rule;

Scrum Guide, версія 2017:
Scrum recognizes no titles for Development Team members, regardless of the work being
performed by the person;

У версії 2020 року це визначення прибрали взагалі, натомість в нотатках дописали ідею об’єднання розробників, продакт овнера і скрам майстра в одну команду:
One Team, Focused on One Product
The goal was to eliminate the concept of a separate team within a team that has led to „proxy” or „us and them” behavior between the PO and Dev Team. There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: PO, SM, and Developers.

У всіх гайдах згадується про cross-functional teams, але не уточнюється що крос-функціональним має бути кожен член команди.

Ось посилання: scrumguides.org/revisions.html
Щоб довго не шукати попередні версії: www.mitchlacey.com/...​urrent-and-past-versions

P.S. Скрам-фанатики мне очень напоминают адептов социализма/коммунизма

Внезапно!

А як же неправильний капіталізм?

Сейчас, на тренингах, среди разнозчиков заразы,
так же модно ссылаться на создателей — для убедительности, как и 10+ лет назад, когда Нокиа еще была?

вообще не понятное предложение

среди разнозчиков заразы

вы про ковид? я не хожу на офлайн тренинги и вам не рекомендую

когда Нокиа еще была?

а Нокиа на кого ссылались? на бога как создателя вселенной и нокии? к чему это? я хз на кого ссылалась нокия. вас возмутила ссылка в посте? ссылки нельзя вставлять?

от куда мне знать на кого ссылалась Нокиа? я пишу только то, о чем знаю :)

вы задали мне вопрос (там в конце вопросительный знак) и в нем что-то про ссылки в нокии, ваааабще непонятный вопрос — какие ссылки в нокии? какая зараза? при чем тут это к этому топику?

Перефразирую: когдато давно, компания люксофт(возможно заквзчик), в которой я тогда работал, оплатила нашей команде курс тренингов по скраму. Так вот — это было время, когда работать по данной методологии небыло также модно как сейчас. Во время первых занятий, в качестве убидительного успешного примера внедрение скарма тренер озвучивал компанию Нокиа, коорая в то время была жива и занимала лидирующие позици на рынке мобильных телефонов. А мой вопрос в том, что после того как нокиа не стало(не взирая на всю гибкость скрама, аджайла) компанию нокиа по прежнему успешного внедрения?
«Зараза» — это намек подсказывающий мое отношение ....

А, нет, конечно. Про Нокию все забыли )
Изначальны вопрос был немного misleading. Возможно потому что вы думаете, что скрам создали в Нокии, но это не так.

Сейчас девелоперам ничего доказывать не нужно. Скрам безальтернативно внедряется сверху вниз по приказу главного менеджера. Мнение разработчиков никого, естественно не волнует. Супер-распространители скрама поняли, что нужно не убеждать капризных девелоперов, а впаривать это дело корпоративным менеджерам с лозунгом «чтобы корова в два раза меньше ела и давала вдвое больше молока, ее нужно кормить и доить по скраму»
www.amazon.de/...​Sutherland/dp/1847941109

Книжка: «як робити роботу двічі за половину часу»

Неправильним є те, що люди з обмеженим рівнем інтелекту зробили з професії ПМа релігію.

Scrum as a silver bullet.

Буде час — напишу байку про клієнта з однієї німецькомовної країни і скрам...

Хоча сам Agile Manifesto я читав у 2003-му, як він тільки з’явився, і книжку авторів читав. Ми вже три роки з американським клієнтом працювали так, як там написано.

У нас на проекте близко mvp, и уже чувствуется, что дальше надо будет делать по-другому.

Уже все больше проë ВНЕЗАПНЫХ багов, которые появляются от нестыковки в незаметных и несущественных (для mvp) мелочах. Например, при удалении категории есть предупреждение о том, что «ща удалю и больше ее не будет», а при удалении товара такого предупреждения нет. А кнопки Edit и Delete находятся близко, одна над другой. Программисты сказали, что это не баг, бо у них не было скетчей для удаления товаров и что было устное распоряжение аналитика о том, что «да ну, тут предупреждать не надо». Ну-ну...

Уже все больше регресс. Сушествующие тесты исправно автоматят, но толку от них мало, бо и функциональные, и апи тесты написаны строго под выполнение user story, под которой они пришпилены. А стори мелкие, один happy scenario и с десяток acceptance criteria. Эти стори уже местами накладываются, а местами есть сценарии, которые находятся «между сторями». Ненормально это.

Если и есть «зло в агайле», то это обещание бизнесу «у вас после каждого релиза будет работающий софт». При этом не уточняется, что это будет плохо работающий софт, где надо действовать строго «как предписано», и нельзя сделать лишний шаг без последствий.

И обещание «это будет быстро» — тоже зло, бо ведет к искажениям восприятия. Быстро будет только мелкий фикс, а не...

Agile это прежде всего про итеративную разработку и фокус на fail fast.

В моей текущей команде первое что я сделал это убил Скрам. Скрам создавал стресс — людей просили оценивать тикеты, в конце спринта половина тикетов не сделано, в середине спринта всегда кому-то надо что-то срочно сделать или починить, куча непонятных митингов «церемоний» и так далее.

Теперь у нас Канбан и все довольны. Мы больше не оцениваем тикеты, мы просто делаем что надо сделать. Каждую неделю мы планируем, каждые две недели мы показываем демо, каждый день проводим стендапы. У нас больше нет проблемы починить баг или сделать что-то срочное «сегодня».

Когда мы начинаем новую большую фичу — мы делаем user story mapping и определяем абсолютный минимум, так называемый MVP. После того как MVP в продакшене, мы итерируем и развиваем фичу. Или мы видим что это фейл и делаем что-то другое.

Только я хочу отметить что это не про аутсорсинг. Я работаю в продуктовой компании где фокус на результат, а не на продажу жопочасов. А вообще в нормальных компаниях команды работают так как им удобно. Я думаю FAANGи хороший пример — там все по разному в разных командах.

І вірно зробив?у нас теж, коли реальна жопа з гоу лайвом кастомерв, одразу забувають про скрам і переходять на канбан. Є задача — робиш рлки не зробиш. І так далі нон стоп.

канбан

ще одна срібна куля?

Fail fast чудово реалізується в PRINCE2 через Manage by Exception.

В таком подходе могут быть свои проблемы, например с фокусом. Когда вы запланировали делать определенные вещи и есть готовый меппинг, но вылезают другие вещи, на которые нужно отвлекаться и постоянно менять фокус

А Вы, коллега, думаете что при скраме оно иначе? Приходит бизнес и говорит: надо, причем сейчас. Существует очень немного людей (а среди скраммастеров я пока вообще ни одного не видел), которые могут в этот момент показать бизнесу фигу, сославшись на процесс. Да, потом на ретроспективе поохают что, дескать, сами нам это навязали и сами же нарушают. Поохают и пойдут веслать дальше.

Да, но при Канбане даже поохать не на что будет, так как он такой процесс предполагает в какой-то степени

В скраме есть фишка что срочные задачи скидваются в беклог с высоким приоритетом. По идее сначала нужно закончить текущий спринт, а потом брать срочные задачи в спринт. Это своего рода защита от не выполнения целей спринта путем постоянных занятий срочными задачами. Как известно у бизнеса есть задачи: срочные, очень срочные, крайне срочные и «сколько и что нам нужно чтобы сделать это». Для поддержки существующих решений (не выпуска принципиально новых версий и т.п.) скрам конечно не подходит, в отличие от канбана. Если скажем отказал сервер на проде — его нужно срочно чинить, а не скидывать эту задачу в беклог и приступить к ней через неделю когда начнется новый спринт.

Найкращий скрам це канбан. Всі інші «процеси» — це можливість всяким паразитам типу скрам мастеров, продакт овнерам, куа і іншим бути на плаву і отримувати зп, поки деви тягнуть на собі весь корабель разом з присмоктаними пиявками на днищі. при чому, що кількість ахінеї для девелоперів збільшується з кількістю «сертифікатів» отриманими РО чи СМ від скам альянсу або іншим форекс-подібним пірамідам.

я був щасливчиком, який застав в 2011-2013 роках реально працюючий скрам (ну так повезло по роботі). де ми отримували вхідне демо від РО, пріоритети. Потім незалежно від цих паразитів вирішували що по часу вийде, хто що хоче чи може взяти і скільки влазить в спринт. де були проміжні демо, а фінальне завжди показував РО, а не як завжди девелопер і жнець і куа і на скрипці гравець і демку затули нам і ще тут кастомеру покажи що по чому і допиши тест план бо куа дуже занятий.

і да, якщо працюєте на галере чи аутсорснуто, то весь ваш скрам це гайно від природи. можете навіть не називати так цей процес.

Найкращий скрам це канбан

От є, умовно, команда бекендерів і команда фронтендерів. Скрізь, де на моїх очах впроваджувався канбан, все стопорилось на тому моменті, коли команди не можуть синхронізуватися.

Я не сперчаюся, що цілком можливо бути синхронізованими, але треба дотримуватись кількох умов:
1. Команди повинні бути +/- одного рівня з відносно однаковими пропорціями між умовними сеньйорами, мідлами і джунами.
2. Дуже важко слідкувати за цією синхронізацією в плані пріоритизації задач.

От тут саме agile і стає в нагоді.

Якшо ви бачили робочий kanban в подібних умовах, то розкажіть як ви це розрулювали — реально цікаво.

Что мешает этим командам быть рассинхронизированным при любой другой методологии?

Нічого, але я питав конкретно про канбан.

Ну хз, при скраме, когда фронтендеры были вместе с бэкендерами, было проще, даже если 1 бе не давал скучать 2 фе, когда фе вынесли в отдельные команды со своими ПО и несовпадающими интересами, случился адский рассинхрон

Само понятие «деления команд на фронтендеров и бэкендеров» противоречит идее аджайла. Команды должны быть сгруппированы по продукту, над которым работают, а не по технологиям. При этом в команду должны входить все роли, необходимые для ее работы. Т.е. и фронтэнд и бэкэнд и девопс и кто угодно еще.

Насчет синхронизации — по канбану нет никакой необходимости в синхронизации между командами (особенно, если они сформированы не по принципу продукта). Есть необходимость в синхронизации отдельных сторей и тасков. Т.е. эти вопросы решаются в группе 2-6 человек, а не полным составом двух команд. Деление на спринты и планирование спринта, пусть и согласованное, никакой добавочной выгоды при этом не создает, т.к. всегда лучше интегрироваться как можно быстрее, а не в конце спринта и всегда безопаснее интеграция по конкретному кейсу, чем big bang.

Допустимо, є адмінка, платіжна система і персональний кабінет. І по 4 дева на бекенді і на фронті. Якщо якась задача стопориться на фронті, і інші задачі підкидаються (і всі важливі — інакше ж не буває), то закінчується це тим, що бекенд продовжує свою роботу, а потім пулреквести висять тижнями.

Я згоден, що якісне, серйозне планування цю проблему вирішує, але компанії, де я працював раніше, вперто наступають на одні і ті ж граблі.

Очень нужно прояснить ключевой момент. Тут проблема не в планировании.

Если есть продакт-команда, но в ней двое делают только фронт, а двое — только бэкенд, то это не эджайл команда. По-факту это две не-эджайл команды, объединенных в одну условную команду непонятно зачем. Это будет проблемой и в скраме и в канбане и в любой другой методологии, претендующей на то, чтобы называться эджайл. Команда закрывает юзер-фичи, а не задачи по бэкэнду, фронтэнду или тестированию. Это ключевой момент, без которого это не эджайл, а карго культ. В скраме есть «development team» без какого-либо разделения ролей. В канбане «cell» — условно та же кросс-функциональная, самоорганизующаяся команда. В команде, организованной по эджайлу, где зона ответсвенности каждого члена команды — весь отданный им кусок продукта, описанная ситуация невозможна.

Як ви уявляєте фронт енд дева, якому дали таску накатать проксі для кафки на джаві? Або джавіст, якому треба розширити функціонал веб компонент через жс сдк. Весь цей кросфанкшіонал девелопмент як раз і придумали скамери, щоб секономити на спеціалізованих девах. Ще і роблять винними " ти ж дев, візьми зроби, у нас немає спеціалізацій"

Весь цей кросфанкшіонал девелопмент як раз і придумали скамери, щоб секономити на спеціалізованих девах. Ще і роблять винними " ти ж дев, візьми зроби, у нас немає спеціалізацій"

Нет. Его придумали и используют наиболее крутые представители индустрии. Речь о той самой Т-шейп экспертизе. У одного дева глубже познания в одной технологии, у другого в другой. Но базовые вещи, которые составляют 80% всех задач должен уметь делать каждый. Поэтому для эффективной работы не нужно, чтобы дев был во всем ас. Надо, чтобы в одном был ас, а в остальном где-то на уровне миддла.

Пример:

Дано:
Команда состоит из 4 фулл-стэк разработчиков, два из которых специализируются на фронте и 2 на бэке, в этой итерации у тебя фича, которая требует 70% работы на фронте и 30% на бэкенде.

Найти:
Как гармонизировать девелопмент, так чтобы фича была релизнута вовремя, качественно и с минимальными тех.долгами

Решение:
30% работы на бэкенде делается фулл-стэками с упором на бэкенд, 50% самой сложной работы по фронтенду — двумя фуллстэками-фронтендерами и еще 20% самой простой работы по фронтенду фуллстэками-бэкендерами.

Після слова «фулстек» далі серйозно не можна читати ваш коментар.

Как тестеров называть куа, так это бревно в жопе тебе не мешает, а как увидел фулл-стэк занозу, то тут от смеха надорвался, ага )

Дано: футбольна команда, що складається з 3-4 зірок світового рівня, десятка просто хороших гравців, тренера, лікаря, масажистів, водія автобуса

Задача: виграти чемпіонат

Рішення: 50% голів забивається зірками, 30% забивається просто звичайними гравцями, 20% найпростіших голів забивають тренер, лікар, масажисти та водій автобуса.

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

Вот адекватная формулировка вашего примера:

Дано: футбольна команда, що складається з 3-4 зірок світового рівня, десятка просто хороших гравців

Задача: виграти чемпіонат

Рішення: каждый делает ту работу, которую он делает лучше всего и делает ее на поле максимально хорошо. При необходимости поддерживает остальные функции.

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

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

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

именно потому что всех настоящих игроков разобрала профессиональная лига а вам приходится пилить свой софтвер силами фронтендера фронт-деска девопса досыпающего кофе уборщиков допиливающих бекенд и бухгалтера интегрирующего платёжную систему

Дано: футбольна команда, що складається з 3-4 зірок світового рівня, десятка просто хороших гравців

да без проблем идём смотрим сколько стоит игрок свитового ривня скажем грубо но плюс минус достоверно для нашего примера средний футбольный трансфер мировой лиги это 4-40 млн евро можно в долларах что для нашего примера не критично идём на доу и смотрим сколько имеет средний гребец даже синьор грубо $48 тыс в год из чего мы делаем некий обобщённый вывод что никаких «зирок свитового ривня» мы вообще-то себе позволить не можем и всё и больше никто никуда не бежит играть в чемпионат

и Т-шейп экспертизы

а ну да больше умных слов и йожики они колючие ))

да без проблем идём смотрим сколько стоит игрок свитового ривня скажем грубо но плюс минус достоверно для нашего примера средний футбольный трансфер мировой лиги это 4-40 млн евро можно в долларах что для нашего примера не критично идём на доу и смотрим сколько имеет средний гребец даже синьор грубо $48 тыс в год из чего мы делаем некий обобщённый вывод что никаких «зирок свитового ривня» мы вообще-то себе позволить не можем и всё и больше никто никуда не бежит играть в чемпионат

Значит ты понимаешь, что с таким бюджетом тебе место максимум в 1-2 лиге Украины. И набираешь команду соответсвенно. Трансфер игроков там будет обходиться примерно в те же деньги. Но все принципы остаются теми же, если ты хочешь хоть что-то выиграть. Командная работа, гибкость и Т-шейп экспертиза (рад, что ты смог узнать новое для себя слово. Скоро ты его не раз услышишь)

а руками может брать только вратарь
ну хоть ты тресни

Во-первых, это игровая условность, которых в реальном мире обычно не бывает.

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

Так что все остается в силе.

Речь о той самой Т-шейп экспертизе.

гагага, в С++ будуть іпать мозги всяким УБ і потім скажуть що слабо шариш в моделях пам"яті та не понімаєш достатньо ООП ООД, а то що ти кросфаншенл насрати

Весь цей кросфанкшіонал девелопмент як раз і придумали скамери, щоб секономити на спеціалізованих девах.

это не совсем так тут скорее как раз ровно на оборот фишка скрума как раз в том что весь процесс придуман для универсальных реальных синьоров для каждого из которых его прямой характеристикой есть его синьора способность самому своими только силами сделать весь проект а вся скрум методология только даёт им возможность собраться 8 синьорам и иметь некий условно рабочий уже готовый но в то же ж время достаточно гибкий фреймворк который позволял бы б прямо с каропки им 8 синьорами одновременно работать над единым проектом просто складывая свою производительность в общий котёл «8 синьоров работая вместе могут родить ребёнка за 9/8 месяцев»

візьми зроби, у нас немає спеціалізацій

аб том и речь что сам фреймворк не расчитан на средних гребцов со средней специализацией и проблема как раз не в самом фреймворке но в попытках его натянуть на этих самых «средних» уже реальных

ЗЫ: ну и опять же ж на самом деле «обще индустриальный подход» он как бы б не предполагает специализации об чём все могут на очно посмотреть на любимых всеми интервью фхтангов другое дело что при этом все прямо упускают тот не скромный факт что этими самыми интервью эти самые фхтанги отсеивают себе только самый топчик который действительно в общем смысле более или менее но «скорее универсальная боевая еденица в себе» чем «специализация» а у остальных так не то чтобы не получается но получается иметь дело с тем что есть и в общем смысле конечно получается даже если получается ну такое средненькое говно простите зато всем по ровну и по честному и в соотв. с методологиями

Т.е. все должны быть фулл-стеки?

Более правильно это называть T-shape expertise.

Та я вас прошу, называть можно как угодно, сейчас и девопс модно навешивать, и всё равно существуют отдельные SRE и прочие команды в лидерах, уж лучше давайте конкретные примеры с явками и паролями, хочется посмотреть, причём без сарказма.

Вспомните о тех самых дежурствах в Фаангах, когда обычный дев, не SRE, должен в любое время дня и ночи по звонку фиксить проблемы на проде. И там нет речи о том, чтобы фиксить только фронтенд или только бэкенд. Любой участок кода, за который отвечает вся его команда. Это и есть главный пример. Наличие отдельной службы SRE никак этому не противоречит, т.к. кто-то должен мониторить работу приложения и определять где проблема.

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

И вряд-ли подобные инциденты возникают из-за съехавшей кнопки, чтобы фе там что-то судорожно фиксил.

Если из-за съехавшей кнопке упала какая-то важная метрика, будет фиксить аж бегом. И, опять же, не фе, а Software Engineer, который отвечает за всю работу команды.

Теперь по поводу примеров...
На тебе сслыку на ротацию в Фейсбуке. Надеюсь Ctrl+F «on-call» осилишь сам
dou.ua/...​/articles/leave-facebook
Вот здесь более широкий обзор. В списке еще Google, Netflix, Spotify:
increment.com/...​on-call/who-owns-on-call

Итого, имеем, что из всего FAANG найдено доказательств на FANG. 80%, как-никак.

Если же ты хотел получить конкретные команды и имена, то ты либо тролль, либо не слишком умен. Этого не будет по очень многим причинам. И не в последнюю очередь потому, что пара-тройка частных примеров все равно не могут ничего доказать. Особенно человеку, который не намерен менять свое мнение несмотря ни на какие доказательства ;-)

Да как раз я бы удовлетворился парой примеров идеального скрама, а не теоретизированием, что принудительный онколл — это маст

то ты либо тролль, либо не слишком умен

Ясно, понятно

Да как раз я бы удовлетворился парой примеров идеального скрама, а не теоретизированием, что принудительный онколл — это маст

о, начинается обычный голимый базар. Весьма ожидаемо. Вкладываем оппоненту слова, которых он не говорил, опровергаем и ждем доказательств, которых быть не может по причине goto в начало предложения.
1. Я не говорил, что знаю случаи «идеального скрама». Только про то, что из себя представляет команда работающая по эджайлу. Идеального все равно не бывает. Но есть адекватный. В Фаангах, кстати, обычно не скрам.
2. Я не говорил, что принудительный онколл это необходимое условие эджайла в команде. Это просто свидетельство того, что команда работает по эджайлу. Если ты не отличаешь НДУ с косвенным свидетельством, то

ты либо тролль, либо не слишком умен

Ниже тебе все объяснили из первых рук. Хотя я уверен, что тебя это все равно не убедит :-)

Ок, насчет онколла я прогнал, но все равно такое утверждение не соответствует действительности. Может работать, а может и нет.

Это просто свидетельство того, что команда работает по эджайлу.

А, уже

с косвенным свидетельством

либо не свидетельством, а частью SRE процесса, ортогонального аджайлу

Ок, насчет онколла я прогнал, но все равно такое утверждение не соответствует действительности. Может работать, а может и нет.

А что ты хочешь? Математически-точное доказательство? Извини, не та область. Можешь ребят из ФААНГ, которые тут засветились допросить по каждому пункту эджайл-манифеста. Насколько оно актуально и какимим средствами реализуется, с примерами. Дальше сделаешь свои выводы. Я свои уже сделал на основании такого общения.

А, уже

без разницы. Специально для тебя сделал акцент. По сути ничего не менялось. Основная идея, что онколл это не НДУ для эджайла в команде. Хватит цепляться к словам, ближе к сути.

либо не свидетельством, а частью SRE процесса, ортогонального аджайлу

Существование SRE как процесса и впрямь ничего не доказывает. А вот участие в нем разработчиков функционала как раз является свидетельством кросс-функциональности команды и ее членов.

А что ты хочешь?

Хотя бы примера, что такое нормальный аджайл своими словами
В принципе, больше ничего.

Нормальный эджайл может существовать на всез уровнях. От команды до компании. Поэтому, чтобы было короче, опишу что такое «нормальный эджайл» в моем понимании на уровне дев-тимы:

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

— команда способна справиться с абсолютным большинством задач в своем продукте поэтому имеет право определять свой состав — т.е. убирать тех, с кем неудобно / кто не тянет, добавлять и выбирать людей и роли. (Само собой, тут есть бюджетные ограничения, однако и их команда может оспаривать, это уже цепляет гибкость на уровне групп и департаментов).

— команда отвечает за свой продукт как единое целое от начала и до конца. Варианты «я только тестирую» не подходят.

— команда в праве выбирать технологический стэк и внутренние процессы. Они не навязываются сверху.

— команда активно использует обратную связь от конечных пользователей в своей работе.

Пожалуй, что это все. Упреждая вопрос, T-shape expertise получается из сочетания малого размера команды, ее мотивированности и способности разрабатывать и поддерживать весь свой продукт. Невыполнение некоторых пунктов не обязательно означает, что эджайл уже не адекватный. Просто он менее адекватный. Четкую границу провести сложно.

небольшого числа ... мотивированных сотрудников. Т.е. тех, кто действительно озабочен тем, чтобы выпустить продукт высокого качества как можно быстрее и с наименьшим бюджетом ... приоритизурует пользователя и продукт
...
имеет право определять свой состав — т.е. убирать тех, с кем неудобно / кто не тянет, добавлять и выбирать людей и роли

Абсолютно противоположно аутсорсу, просто по его природе. Где основная задача забиллить максимальное количество часов умноженное на максимальной количество ресурсов.

— команда в праве выбирать технологический стэк и внутренние процессы. Они не навязываются сверху.

Так не бывает. Кроме желаний команды, есть еще и корпоративные стандарты, как минимум в разрезе используемых стеков.

Надо, чтобы в одном был ас, а в остальном где-то на уровне миддла.

Так не бывает. Или миддл во всем, или ас+немного. Если конечно не брать супер-ноулайф-задротов, которые выжигают глаза по 12 часов без выходных

Абсолютно противоположно аутсорсу, просто по его природе. Где основная задача забиллить максимальное количество часов умноженное на максимальной количество ресурсов.

Именно. Поэтому в аутсорсе эджайл — это редкость. Более того, не только в аутсорсе, а и в традиционном корпоративном мире. Если команда сама решает с кем работать, то как менеджеру пристроить своего родственника на теплое место? Как обозначить свой статус навязыванием методологий? Как срубить откатов на покупке ненужных тулзов и тренингов?

Кроме желаний команды, есть еще и корпоративные стандарты, как минимум в разрезе используемых стеков.

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

Так не бывает. Или миддл во всем, или ас+немного.

Бывает. Просто в аутсорсе такие люди редко задерживаются.

Поэтому в аутсорсе эджайл — это редкость.

Точно? Все проекты, в которых я участвовал и участвую декларируют свой процесс как аджайл. Иначе их трудно продать заказчику, который наслушался словесной отравы про небывалую эффективность. Мне кстати свою лычку скрам-мастера пришлось получать исключительно по этой причине

Бывает.

Нет, не бывает. Разве что на уровне единичных исключений, подтверждающих общее правило.

Точно? Все проекты, в которых я участвовал и участвую декларируют свой процесс как аджайл.

Ты точно отличаешь понятия «быть» и «казаться»? Я про быть, а не про обертку.

Нет, не бывает.

Нет, бывает. Ты где-то кроме укроаутсорса работал?

Но есть адекватный.

Наверное есть

Если взять 12 принципов agilemanifesto.org/principles.html
Наиболее анноят нарушения

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.

Agile processes promote sustainable development.

Зато церемоний обычно с избытком

Церемонии это про Скрам. В Эджайле про них ничего не сказано. Упомянута только необходимость регулярной ретроспективы, без подробностей.

Пока я о таких практика я слышал только в амазон

В MS, GoDaddy, Tableau (Salesforce) та FB таке є з мого особистого досвіду. Та і в усих інших фаангах я про таке знаю від знайомих.

если твой тим пилит сервис, то ожидай он-колл, и что будут пейджить в любое время если твой сервис лежит. Если у тебя не сервис, то может и не будет (ymmv), или лайт вариант, ака инженер неделю занимается только тем, что отвечает на инцинденты, но в рабочие дни и в рабочее время.

Ну у нас есть он колл в рабочее время для всех и некоторое количество добровольцев за прибавку к зарплате 24/7

Но называть это необходимым и достаточным условием правильного скрама я бы не стал.

он-колл самая большай херня которую я видел, особенно если у команды пара сервисов на миллионы юзеров ты просто обязан спать с телефоном и потом весь день разбирать тикеты которые пришли за ночь, а потом передать наразобранные тикиты чуваку в бангалор. В операторах мобильной связи есть специальные люди следящие за сетью 24 часа и решающие проблемы с пропажей электричества, глюками софта и железа. Количество этих людей как правило равно или даже больше количества ведущих инженеров которые софт фиксят и деплоят. Это называется экплуатация сети и она занимают львиную долю в расходах. Но фанги жлобятся нанять и обучить специальных людей для эксплуатации и используют девов за +20\30 процентов зарплаты.

Такие практики есть даже не в фангах. Другое дело что дежурный отвечает не за весь условный фейсбук с фронтендом, а только за под-проект на котором работает.Если он пилит бек какиэто данных, то за этот бек и отвечает.

Та есть. Но жаловался пипл на амазон почему-то.

вы в курсе что все фиксы в мобильном приложении нельзя сразу на прод? Изменение в мобильном приложении должны пройти как минимум ревью от Apple, как максимум canary release. Ночью это сделать нереально. Мне кажется вы неправильно понимаете cross-functional teams.
Сross-functional teams — это не значит что я должен уметь веб, андроид, iOS и ML в придачу к тому что я уже умею. Это значит что команда должна уметь сделать, задеплоить и поддерживать свою фичу

Вы отождествляете то, что не нужно.
1. Быть on-call это лишь пример, подтверждающий, что в эджайл-командах команда отвечает за продукт, а не каждый дев за исключительно свой кусок работы + существование и важность Т-шейп экспертизы. Это не значит, что команда, в которой один человек не может пофиксить любой дефект по звонку не является кросс-функциональной.
2. Наверное, если продукт команды это Android App, то у них нет on-call. И то могут быть исключения. Но мир состоит не только из мобайл разработки.

Сross-functional teams — это не значит что я должен уметь веб, андроид, iOS и ML в придачу к тому что я уже умею

По умолчанию не означает. Это отдается на откуп команде как она решит этот вопрос. Главное, чтобы вся команда работала на общий результат, а не так, что фронтендеры свое запилили и плюют в потолок, пока бэкендеры разгребают. Результат — это продукт, который может быть кому-то полезен. («фронтенд вебсайта» — это не продукт). Если сюда входит организация on-call поддержки, то это тоже делает команда с незначительной поддержкой SRE.

Т.е. в теории (когда никто не болеет, не увольняется, доступен 24/7, а поток задач такой, что нагрузка всегда одинаковая и равномерная) возможно, что команда является кросс-функциональной при том, что каждый делает только свой кусок. Однако реальная имплементация в силу малого размера команд, бас-фактора, неравномерности загрузки, необходимости поддержки и т.д. приводит к тому, что на базовом уровне нужно знать если не все, то хотя бы 40-60%, чтобы обеспечивать требования к крос-функциональности. В этом одна из составляющих гибкости, что делать надо то, что помогает команде добиться результата, а не фронтенд или бэкенд.

в любое время дня и ночи по звонку фиксить проблемы на проде

Тільки не фіксити, а робити мітігейшн. Не знаю як це правильно перекласти, але різниця в тому, що або показуєш, що проблема не суттєва і на тому все, або відкочуєш деплоймент, або міняєш налаштування — все щоб мінімізувати втрати. А фікс потім вже в робочий час як звичайну роботу пиляють.

В іншому все вірно — твоя фіча, ти її дизайнеш, імплементуєш, тестуєш, доводиш до прода і реагуєш на проблеми.

Так. Головна задача на таких чергуваннях — дотягнути до кінця зміни, постячи всякі апдейти в жіра тікетах, а потім перекинути на наступного відповідального по часовому поясі.

Головна задача на таких чергуваннях — дотягнути до кінця зміни, постячи всякі апдейти в жіра тікетах, а потім перекинути на наступного відповідального по часовому поясі

Не вміння мінімізувати проблему буде дуже помітно: рішення нема — починають до кола додавати людей, рішення все ще нема — додають менеджерів, менеджерів менеджерів і так далі. Для серйозних проблем в одному дзвінку буде кілька десятків людей з різних команд та різних дисциплін. Ще і з дата-центра когось залучать, може навіть з маркетингу щоб клієнтам повідомити. Тому ні, не вийде просто робити вигляд.

До того ж до «кінця зміни» може бути ще більше тижня — важко дотягувати скільки часу.

ну да, имелось в виду устранять проблему, без уточнения каким именно способом. Обычно тем, которое обеспечивает лучшую комбинацию скорость-риски.

Вспомните о тех самых дежурствах в Фаангах, когда обычный дев, не SRE

як там з.п. в галєрах?
коли тімліду буде в рік 500Куе, а сінйору 300Куе?

че ты себе такое придумал — изменения в софт вносятся контролируемо, большинство «фиксить проблемы на проде» это откатиться на прошлый релиз или найти и за-эскалейтить другой сервис который стал глючить, и очень редко поменять хардвер. Никто не будет чинить фронт или бекэнд на проде по звонку.

это одно из самых больший заблуждений что нажно Тшейп, в итоге Т шейпы шарят по не многу во всем и ни в чем конкретно. Немного в жаву, немного в питоне, немного в жаваскрипт, код написанный такими чуваками — это такой себе код на троечку который можна читать не напрягаясь студенту второкурснику. Даже если ты напишешь какойто питонисткий код типа a, b = b,a то тебя попросят исправить это потому что большинство команды может не знать как это работает и нада писать попроще, я тебе реально говорю все будет написанно чуть ниже середнячкового кода. Ты никогда не подымишь свой скил ни в одном языке когда работаешь в команде Тшейпа. Еще хуже когда команда тусуется между фронтом и беком — вчера ты пилил контроллер спринга а завтра ты пилишь контроллер реакта, в итоге и там и там вышло так себе + ты потратил день что бы настроить энвайремент.

То что ты описываешь не т шейп, это _ шейп какой-то

есть плохие новости. чем синиористей синиор — тем проще производимый им код. работает также и в другую сторону ;). хороший код всегда простой и скучный.

да, и добавлю по теме: скрам — ненужное и бессмысленное говно.

В скраме есть «development team» без какого-либо разделения ролей.
В команде, организованной по эджайлу, где зона ответсвенности каждого члена команды — весь отданный им кусок продукта, описанная ситуация невозможна.

проблема реальных реализаций агиле как раз и есть в том что мало кто из его реальных реализаторов на самом деле представляет себе и вообще способен представить себе на кого на самом деле эта методология расчитана

проблема как раз и состоит в том что в рамках реальных реализаций уже на реальных имеющихся человеческих ресурсах данная «дискуссия» не имеет ровным счётом никакого чисто технического смысла

отсюда и вообще и появляется и «роль скрум мастера» которая вообще исходя из оригинального скрум агиле не понятна за чем просто потому как «эта роль ругательная» (к) (тм) и прямо говорит об том что сами участники скрум агиле уже достаточно тупы чтобы самим со своими процессами не разобраться

тут не говоря уже об том что во всё тех же ж реальных реализациях агиле этого самого «скрум мастера» чем только не нагружают тут он уже и «готов всем помочь разобраться в продукте и кейзах» ... ай нет постойте а «скрум мастер» каким вообще делом к «продукту» от слова совсем?

но селяви

ЗЫ: классическая же ж реализация анекдотического же ж подхода «мышки станьте йожиками» (к) (тм)

проблема как раз и состоит в том что в рамках реальных реализаций уже на реальных имеющихся человеческих ресурсах

Фундамент эджайла — это готовность к изменениям. Начинается она с индивида. Если человек не хочет ничего менять в своей работе, то эджайла не будет, и проблема здесь не в эджайле.
Хотя, как правило, проблема не в этих людях, а в менеджменте, который внедряет эджайл по принципу украинских реформ, когда из системы пряник-кнут имплементируется только кнут. Само собой, люди не хотят просто кнута и решают противодействовать изменениям.

проблема реальных реализаций агиле как раз и есть в том что мало кто из его реальных реализаторов на самом деле представляет себе и вообще способен представить себе на кого на самом деле эта методология расчитана

Эджайл-манифест составлялся людьми на 100% имевших опыт разработки софта. Большинство из них имели большой опыт именно в технологиях, а не в руководстве. (Наверное, единственные люди без опыта разработки там были именно отцы-основатели Скрама, что многое объясняет)

Довольно забавно, что лидеры рынка софта работают по эджайлу и очень успешны. Зато в конторах-говнокодерах очень часто ставят эджайл под сомнение :-)

«деления команд на фронтендеров и бэкендеров» противоречит идее аджайла.

ну да, всі є девоПси

Команды должны быть сгруппированы по продукту, над которым работают, а не по технологиям.

вообще-то речь идёт не об технологиях но об чисто технически архитектурном нарезании разработки на слои и модули горизонтально и вертикально

другое дело если

сгруппированы по продукту, над которым работают

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

нет никакой необходимости в синхронизации между командами

прямо вырывая слова из контекста правда при этом не меняя его как такового таки да это именно то самое отсуствие архитектуры и организационной об которой я и говорил

вообще-то речь идёт не об технологиях но об чисто технически архитектурном нарезании разработки на слои и модули горизонтально и вертикально

Если нарезание горизонтальное, то это не эджайл. (За исключением если весь твой продукт помещается в один слой. Т.е. если ты делаешь сервис и это и есть весь твой продукт)

Якщо треба бекенд дев, то підходиш до нього і кажеш «зроби мені це». Він додає таску в канбан і все. Якщо дуже терміново, то хтось її одразу робить. Так само і навпаки, хтось до тебе піхдодить, бо дуже терміново треба. По канонам скама, я маю послати його бо не заплановано. В реальності ж весь цей карго культ зникає миттєво, якщо в 5 хвилинах від вас знаходиться кастомер і дійсно буде жопа.

Вопрос в размере комманд. Если комманды маленькие, то имеет смысл прсто сделать одну комманду. Если большие то, имхо, там будет «все сложно» вне зависимости скрам или канбан.

це можливість всяким паразитам типу скрам мастеров, продакт овнерам, куа і іншим бути на плаву і отримувати зп, поки деви тягнуть на собі весь корабель разом з присмоктаними пиявками на днищі

Бідненькі деви, от вже пообліплювали їх ті всі паразити, цілодобово висмоктують усю кров.

Яку користь приносить скам команда з 5 скам матерів? 0

Яку користь приносить команда з 7 куа? 0

Яку користь приносить команда з 6 Девів? ВСЮ.

Яку користь приносить скам команда з 5 скам матерів? 0

??
А де ти такі команди бачив?

Яку користь приносить команда з 7 куа? 0

Тут ти взагалі заганяєшся, бо на проектах типу фейсбука, привата наявність куа критична і може коштувати мільйони. Ти порівнюєш червоне і холодне.

Яку користь приносить команда з 7 куа? 0

Если кроме них на проекте нет никого и они ни в какую не хотят делать ничего кроме тестирования, то, пожалуй что 0. В остальных случаях это не правда.

Но если развивать мысль дальше в том же русле, то окажется, что и команда из 6 девов приносит 0 пользы, т.к. без девопса ничего у них не закрутится. Но и девопс бесполезен без сисадмина. И вообще, вся софтвер-индустрия бесполезна, потому что она не создает ни еды, ни жилья, ни бытовых товаров.

Полегче с самолюбованием, ты всего лишь кодер ;-)

QA це не про тестування, а про якість продукту в цілому. QA це чувак який раз на кілька тижнів приходить і каже:
— я ось тут поставив наш сервер на три ноди CentOS і помітив, що роботи пов’язані з викачуванням даних в основному йдуть на першу ноду, а не розподіляються рівномірно, або
— коли я підключаюся до БД то логін/пароль вводиться ось на цьому кроці, а для Machine Learning Server на іншому. Більше того — у нас UI продубльвано замість бути повторно використаним.

Ну тобто це такі специ які знають продукт, предметну область, технологій і можуть виступати як дуже технічні клієнти які володіють термінологією. І вони як правиль не приписані до команд, а працюють десь на рівні оргів чи компанії.

Это у вас в ФААНГах такое. Мы тут о более приземленных вещах, когда QA это неправильный, но часто используемый синоним слова «тестировщик». Я-то разницу понимаю, но приходится использовать терминологию собеседника, т.к. мы оба понимаем что имеется в виду. В индустриях типа Авто, Медицины и Авиации настоящий QA вообще только за рабочими процессами следит :-)

це можливість всяким паразитам типу скрам мастеров, продакт овнерам, куа

Забавно что вы упомянули QA, при том, что это единственная роль, которой нет в Скраме. В Скрам-гайде написано, что в команду входить может кто угодно, но роль на всех одна — «member of development team», как раз таки убивая традиционное деление на разработку и тестирование, а не оправдывая ее:

Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;

Bus factor при этом как раз говорит о том, что чем меньше разнообразие ролей, тем лучше. И QA — первый кем можно пожертовать без особого ущерба (если зрелость разработчиков это позволяет).

Продакт-оунер, если он компетентен незаменимый участник процесса. Поэтому тоже мимо.

Единственный, тип паразитов, которых скрам навешивает, — это скрам мастера.

А що, куа в одну ніч стають розробниками? Куди ви дінете цей натовп? На вулицю? Часто прокачаний куа стає РО. Куди інших подіти коли всучують скрам я хз.

Але все одно все перекладається на плечі розробника. РО пише якийсь бред в жіра тікеті, типу юзер сторі на 5 речень. Потім куа не може зробити тест план, бо по юзер сторі нічого не ясно, а все знає лише дев, який це зробив...тому приходиться і тп писати ще і спеки норм описувати, бо РО таке враження перманентно на якихось сінкап мітингах (самі собі танцюють).

А що, куа в одну ніч стають розробниками? Куди ви дінете цей натовп? На вулицю

А тру-синьор-девелоперами, судя по всему, рождаются :-)

Само-собой, что это идеальный, мало кому доступный вариант, чтобы команда сразу состояла из только мачурных, Т-шейпных синьоров. Но это не значит, что вариантов нет. Иногда становится вопрос построения эджайл команды из того, что есть. Есть много вариантов, как действовать. Например, сначала научить QA, который только по пользовательским тестам, писать юнит- и интеграционные. Постепенно, он начнет смотреть в код эпликейшена и разбираться в нем. Через некоторое из чистого QA появится человек, который помимо полного цикла тестирования может фиксить простые баги и делать простые имплементации. То же касается и остальных участников. По сути, единственным препятствием к этому росту является негибкость персоналий, вроде «я девелопер, и писать тесты ниже моего достоинства», и пофигистическое отношение к работе.

РО пише якийсь бред в жіра тікеті, типу юзер сторі на 5 речень.

Мухи отдельно, котлеты отдельно. Если ПО неквалифицированный или не мотивированный, то это проблема конкретного ПО, а не методологии. Ведь если 50% девелоперов зажравшиеся говнокодеры, это не значит, что разработка софта в принципе не имеет права на существование.

А що, куа в одну ніч стають розробниками?

Мені здається тут мова йде про тестерів. В bing колись так зробили — всіх тест-лідів на вулиці, всіх тестів в девелопери. Хто не потягнув тих теж через пів-року виставили.

А почему так с тест-лидами? Или типа в девелоперы сильно низко, демотивируются?

Не знаю чесно кажучи. Можливо через те, що вони вже не дуже технічні, але вже достатньо дорогі.

всяким паразитам типу скрам мастеров, продакт овнерам, куа і іншим бути на плаву і отримувати зп

Из за таких мнений, профессия куа вымерла, и тестить все терь самим девам приходиться, качество страдает итд итп :-(

Скрам плох тем, что он превращает разработчиков во взаимозаменяемых обезличенных муравьёв. Мне больше импонирует стиль, когда каждый сфокусирован на своей области и отвечает только за неё. Скрам же максимально «размазывает» гребцов по проекту, чтобы их можно было легко перетасовывать и заменять. Для бизнеса такая модель конечно же выгодна, но для комфорта самих разработчиков — нет.
Ещё скрам отвратителен засилием нелепых принудительных ритуалов и митингов.

Мне больше импонирует стиль, когда каждый сфокусирован на своей области и отвечает только за неё.

Как вы предлагаете решать проблему с bus factor ?

Не понятно что-ли? За счёт кастомера. Он подождёт пару месяцев пока новый дев будет разбираться, ну или не пару

если кастомер поймет, в чем дело, это уже будет новый дев, с новой галеры

Ну это совсем гаражный кастомер нужен, где он и владелец и с гребцами говорит напрямую, через толпу менеджеров ничего понять нельзя, просто чуть перформанс меняется

К тому же кастомер новичок должен быть, смена галеры это неокупаемая инвестиция, многие на этом обожгутся пару раз и успокаиваются

Ну это совсем гаражный кастомер нужен, где он и владелец и с гребцами говорит напрямую,

Если кастомера реально интересует состояние проекта, то да, он знает гребцов по именам, и не стесьняется общаться напрямую, когда считает нужным.
На некоторых проектах так реально и происходит.
Понятно, что если кастомеру нет особого дела до проекта и гребцов, то задержка в 1-2-6 мес его не сильно смутит.

К тому же кастомер новичок должен быть, смена галеры это неокупаемая инвестиция,

это stop-loss

Если кастомера реально интересует состояние проекта

нет, если у кастомера крупный бизнес то что ты пишешь невозможно, никто не будет участвовать в аутсорсном проекте, когда у тебя несколько тысяч работников, на это наймут менеджеров, а им уже плевать на проект, абы их КПИ высокие были

За счёт кастомера.

Именно так, и никак иначе. Пока я наёмный работник на фиксированном доходе, не зависящем от дохода бизнеса, проблемы и риски этого бизнеса не должны меня волновать и не должны решаться за МОЙ счёт.

проблему с bus factor

А это не моя проблема, и пусть её решает бизнес, который меня нанимает. А не я, и не за счёт моего комфорта. Если меня собьёт автобус — можно нанять другого разработчика и подождать, пока он въёдет в тему. Да, будет задержка и некоторая потеря денег бизнесом. Но почему меня это должно волновать? И почему эти риски должны нивелироваться за счёт некомфортных условия для меня?

Я же со своей стороны, по ка есть выбор, выбираю работу на бизнес, который эту проблему решает не за счёт меня. Всё просто.

А вообще, проблема автобуса решается не только путём «размазывания» участников проекта.

Да, будет задержка и некоторая потеря денег бизнесом. Но почему меня это должно волновать?

Вас это волновать не должно — это должно волновать ПМ, который просто не допустит

когда каждый сфокусирован на своей области и отвечает только за неё.

С другой стороны, если вы предложите внятное решение с bus factor, то вполне можно будет сфокусироваться на «свое области и отвечать только за нее».

А вообще, проблема автобуса решается не только путём «размазывания» участников проекта.

вы где-то предложили решениее?

Перевозить всех одним автобусом, а не...

Scrum зло когда в команде девелопмента 20 и более человек. Вот и сложно представить этот балаган на Дейли и т.д. Либо же отдельно 2-3 человека обсуждают, остальные ставят на фон.

Scrum зло когда в команде девелопмента 20 и более человек.

Гайд говорит, что размер команды «typically 10 or fewer people».
«20 и более человек» — уже явно не scrum.

Скажи это руководству Люксофта с их аутсорс — бодишоп энтерпрайзом. В наших реалиях в такой небольшой команде Скрам мастера убрали бы. Но лично мое мнение, что это самая бесполезная роль в команде, не более, чем «хороводник».

Скажи это руководству Люксофта с их аутсорс — бодишоп энтерпрайзом.

Можно подумать, они сами не знают.

В наших реалиях в такой небольшой команде Скрам мастера убрали бы.

В некоторых командах это «переходная роль», т.е. кто-то из команды выполняет обязанности SM втечении спринта.
Обязанности сводятся к бронированию митинг румов, контролю/напоминаниям за «соблюденим ритуалов», и писем-статусов для большого начальства.

Вот даже интересно стало.
А кто-то видел оное не в виде религии с алтарем, попами и молениями?

Я видел! Просто повезло. Галера хотела зацепить очень жирного клиента и надо было сделать образцово-показательный проект. Поэтому срочно собрали команду одних синьоров — выдернули с других проектов. Поставили самого толкового ПМа, пригласили скрам-мастера.
Работали по Скраму — при этом применяли его именно так, как нужно. С настоящим планированием, с хорошо прописанными сторями, с игрой в «покер», с подключением клиента, с полноценными демо.
Отдельным плюсом было что проект был фиксед прайс и сроки довольно сжатые. А это значит что не было никакого смысла тратить время на галерную бюрократию. Никто не требовал отчеты за каждый час, никто не устраивал пустопорожних митингов.
Сейчас вот понимаю что основной секрет успеха или неудачи Аджайла это:
«Build projects around motivated individuals.»
Когда в команде синьоры и каждый сам понимает что нужно сделать, понимает как и зачем — то все что им нужно от процесса это просто синхронизация и коммуникация.
Почему на других проектах Аджайл превращается в какой-то треш? Вот несколько причин:
1) Легаси. Когда девелопер пишет код с нуля — он берет за него ответственность. Он заботиться об архитектуре, он пишет тесты, он пристально следит на ревью что бы другие не испортили его работу. Чужой код, особенно плохо написанный — мотивирует только сделать «на отвали». Поставить костыль и спихнуть побыстрее.
2) Вайтишники — формошлепы. Когда в команде мотивированные синьоры — то ты можешь быть уверен в качестве чужого кода. Да — бывали споры что лучше использовать, но в конечном итоге общая архитектура, покрытие тестами и прочие хорошие практики сохраняются. Когда же в команду берут формошлепа, которые не понимает архитектуры, не хочет разбираться а делает по принципу «буду лепить шо попало пока не получится что-то, что можно спихнуть как результат» — то это демотивирует всех, кто старается делать хорошо. Когда же в команде один синьор, который хочет делать по-уму и 10 формошлепов — топ-перформеров, то синьор даже не успевает уследить что бы они не сделали все классы и методы паблик.
3) Заказчику похер. Когда заказчику нужен результат — он сам заинтересован смотреть демо, обсуждать стори, отвечать на вопросы. Когда это огромный ентерпрайз то обычно менеджер со стороны заказчика даже не может ответить как что должно работать. Традиционный ответ: добавляейте любые хотелки клиентов, но только так что бы ничего не поменялось. Все логично: ентерпрайз это не про результат — а про процесс попила бабла.
4) Галере нужен бесконечный проект. Если клиент платит за бесконечный багфикс — то зачем лишать себя работы? Если с каждой новой фичей растер технический долг и нужно больше времени и людей что бы добавить следующую — то это идеальный результат для галеры. Не надо ничего исправлять!

Галера хотела зацепить очень жирного клиента и надо было сделать образцово-показательный проект. Поэтому срочно собрали команду одних синьоров — выдернули с других проектов. Поставили самого толкового ПМа, пригласили скрам-мастера.

Самое смешное, что в таком случае и по водопаду и по рупу и хоть по черту лысому, но все получается в итоге хорошо.

А во всех остальных случаях — «а вы друзья, как не садитесь...»

По водопаду. В ряде случаев может и не получится, я пока еще бизнес проектов в которых не изменяются требования еще не видел ни разу, хотя такой процесс психологически всем был бы по нраву потому что все понятно нет не определенности. Возможно где-то в встроенных или военных разработках требования можно зафиксировать на срок всего проекта (хотя насколько мне известно — хрен там, есть новые разведданные и переделывай), в бизнесе — нужно сражаться с конкурентами и хотелками пользователей поэтому требования все время меняются. Самая частая причина провала проектов вовсе не в кодировании и даже не в техническом долге, а в том — что созданный софт в итоге оказался никому не нужным. По сему возникли все практики XP — т.е. метода писать софт так чтобы его можно было перерабатывать под изменившиеся требования с минимизацией трудо-затрат под эти переделки. TDD например, кстати это больше чем просто написание модульных тестов это еще и про понимание всех требований к задаче, потому что написать тесты к задаче требования к которой выясняются по ходу разработки технически весьма проблематично, экспериментальное программирование и TDD мало совместимы. Scrum — как система итеративной работы над проектом в целом т.е. относительно короткими итерациями в рамках которой течет весь SDLC: анализ->проектирование->планирование->разработка->тестирование->ввод в эксплуатацию.
Да, гибкие методологии вовсе на панацея от работы без: проработки требований, архитектуры, оценки рисков, планирования, оценки бюджетов и прочего хаоса которого всегда с избытком.

Злом воно стає тоді, коли великий начальник хоче його «шоб було» бо це «модно» і «хайпово», при цьому намагається застосовувати його всюди підряд, навіть на задачах типу «investigation», де естімейт не може бути встановлений в принципі.

Обычно те кому не нравится agile никогда на самом деле по гибкому процессу и не работали, а попали в хаос fragile, однажды с прогнозируемо-провальным результатом. С тех пор и заявляют что agile — зло. В реальности поставить процесс так как он должен работать довольно сложно.

Ну тоді навіщо процес який майже ніхто не може поставити і який приносить більше шкоди ніж користі в такому випадку.

Чому не можуть поставити? Можуть ящо знають як ставити. Головна проблема — цьому завжди чинять супротив керівники. Роблять такий Srum — де із нібито гнучких методологій радяньску ранкову п’ятихвилинку називатью стендапом. І взагалі по діаграмі Ганта відслідковують ход проекту (це в кращомувипадку), де є нібито повний перелік робіт графіки і ніби технічні єесперти і ніби аналісти самостійно без команди і пропрацювання реквайментов, UX/UI і т.і. все проєстімейтили. Це не agile — а fragile. І коли ті хто зі справжнім скрамом працював чи проходив навчання намагаються зробити справжній процесс — ось тут і починається супротив, починаючі від естімейтів на сторі від команди (які зазвичай в два три рази так більщі, або навпаки меньщі). Часто скрам мастерів такі fragile-істи просто здихуються (виживають із роботи), виходить що в замовника кожні три місяці новий скрам мастер, і потім народ звалює з таких проектів, доречно матюкаючі в слід такий agile.

У нас був ортодоксальний правильний скрам з сертифікованим скрам-мастером. І на кожний пчих у нас було по мітингу. Бо так книжка пише.І це не допомагало, а навпаки шкодило, бо люди вигорали від такого режиму.

Звучит немного как «просто вы коммунизма нормального не видели»

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

Вы на своём опыте знаете?
А то я интересовался у живых фаанговцев, ни один не сказал, что строго следуют аджайл методолгиям, может на каких-то из проектов и внедрили.

я интересовался у живых фаанговцев, ни один не сказал, что строго следуют аджайл методолгиям

Залежить від типу продукту. Для якогось Windows чи Office де цикл складає 3-5 років waterfall підходить дуже добре. В інших цілком собі використовують якість модифікації.

Windows чи Office де цикл складає 3-5 років

давно уже нет такого, релиз раз в пол года

«Строго следуют» и «эджайл» уже оксюморон. Быть гибкими это не значит жесткого привязываться к какой-то методологии. По-моему это само-собой разумеется. Важно разделять принципы и использовать их в работе.

Верно до какого-то момента, обычно затык как раз в каких-то из принципов.

В отличие от коммунизма

Северная Корея.

большинство стартапов хотя бы на первичной стадии.

Разве что. Вот тут как раз идеальная узкоприменимая сфера — бах бах и в продакшн, скорость наше все

Северная Корея.

Ага, страна к которой «от каждого по способностям, каждому по потребностям» применима более всего :-))))

Разве что. Вот тут как раз идеальная узкоприменимая сфера — бах бах и в продакшн, скорость наше все

Да нет же. Эджайл нужен любой конторе, которая занимается творческой деятельностью. Особенно, если она завязана на инновации. Там где нет эджайла — там корпоративное болото с кучей туповатых, но очень высокомерных менеджеров, которые способны только на то, чтобы мериться статусами, лизать жопу начальству и демотивировать подчиненных, больше ни на что. Такие конторы всегда уверенно движутся к своему закату.

Там где нет эджайла — там корпоративное болото с кучей туповатых, но очень высокомерных менеджеров

Вот честно говоря никогда не понимал таких радикальных противопоставлений.
ФК «Барселона» vs ФК «Колос» из села Кукуевка, других вариантов нет.

Типа как во всех скрам-рекламах обязательно приводят как альтернативу какой-то никогда не существовавший реально ватерфолл, просто созданный из пороков и темной материи, что Саурон.

А есть другой опыт? У меня не было. Т.е. были отдельные хорошие менеджеры. Но их абсолютное меньшинство. А главное, чем выше, тем их меньше.
Вообще, в чем сакральный смысл ограничения инициативы сотрудников и загона их в строгие рамки в области требующей творчества и высокой квалификации? Ну вот просто интересно.

А главное, чем выше, тем их меньше.

В любой компании так. Как известно, нет такой профессии как «хороший парень», особенно в топ-менеджменте

ограничения инициативы сотрудников и загона их в строгие рамки

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

в области требующей творчества и высокой квалификации?

Увы, к области в целом это давно не относится. Это относится от силы к 10-20% подзадач, все остальное — решение тривиальных задач по тривиальными паттернам.

Махновская вольница идеально подходит для относительно небольших иррегулярных формирований, но никак не работает для больших регулярных армий

Отвечу твоими же словами:

Опять черное против белого.

Почему если эджайл, то сразу Махновщина?
Даже в регулярных воинских формированиях существуют разные подходы. Вроде советского «сверху вниз», где все детали прорабатываются в штабе и на всех уровнях требуется их неукоснительное выполнение и немецкого, комбинированного, где ставятся цели, но на нижний уровень делегируется много свободы в отношении их достижения, а инициатива на местах поощряется. Второй включает очень много элементов эджайла. Какой из подходов эффективнее, мы все знаем по ВМВ. Соотношение потерь в диапазоне от 1:5 до 1:10.

Объясни как регулярные и нерегулярные формированиями мапятся на бизнес.

Вроде советского «сверху вниз»,
и немецкого, комбинированного,
. Какой из подходов эффективнее, мы все знаем по ВМВ

Именно. ВМВ закончилась в Берлине, а не в Москве.

Объясни как регулярные и нерегулярные формированиями мапятся на бизнес

Небольшой партизанский отряд или развед/диверсионая группа
== стартап. Набирают кого могут и считают нужным, используют что считают нужным, ни от кого не зависят, действуют как считают нужным. Решают, в основном, локальные (пусть возможно и достаточно важные) цели. Типа «завтра надо захватить плацдарм и продержаться до подхода основных сил / взорвать мост в тылу врага и отойти». Читай — подготовить MVP, срочно выкатить новую фичу на выставку и т.п.

Регулярная армия == промышленная разработка. Где гораздо важнее иметь унифицированные (пусть, возможно и более слабые индивидуально юниты), которые действуют согласно единого плана
(пусть и не идеального с точки зрения конкретного юнита), и рещают задачи вида «через три недели надо замкнуть кольцо окружения в районе города XXX / удержать фронт по реке YYY». Читай — выпустить новую мажорную версию с набором фич,синхронизированную, интегрированную и унифицированную с другими продуктами в портфолио

В реальном мире обычно это регулярная армия с небольшими отдельными отрядами спецназа.Но это именно в таком приоритете, никто не строит армию только из или по принципам спецназа (типа, каждый боец владеет всеми видами оружия, и все такое — ничего не напоминает?), это малые по количеству вспомогательные войска, решающие точечные задачи.

Какой из подходов эффективнее, мы все знаем по ВМВ
Именно. ВМВ закончилась в Берлине, а не в Москве.

Спасибо. На этом я окончу свой разговор с тобой. Ты очень ярко продемонстрировал, что рассуждаешь о тех вещах, в которых ничего не смыслишь. + еще и совок головного мозга.

. Ты очень ярко продемонстрировал, что рассуждаешь о тех вещах, в которых ничего не смыслишь. + еще и совок головного мозга.

Одна-винтовка-на-четверых, орды неграмотных тупых орков, подгоняемыех загранотрядами, против культурных цивилизованных инициативных немцев в гламурных кожаных плащах, мне тоже все понятно.

Видишь ли, это как в футболе, где не присуждают победу за красоту игры, количество обводок и пасов в одно касание. Есть только и всего один измеритель — результат на табло после окончания матча.

Если война закончилась в Берлине — значит советская система управления государством в целом и войсками в частности была более эффективной. Заметь, я не пишу — «идеальной» и «хорошей», а именно «более эффективной чем» противника, в конкретное время и в конкретных услових. И это не «совок головного мозга», а банальная логика.

Одна-винтовка-на-четверых, подгоняемыех загранотрядами

Твое знание истории ВМВ ограничивается просмотром фильма «Враг у ворот». Очень типично для школоло-экспертов.

Если война закончилась в Берлине — значит советская система управления государством в целом и войсками в частности была более эффективной.

Т.е. если 1000 человек соберутся и побьют чемпиона ММА, значит их техника круче. Ты просто маэстро логики.

орды неграмотных тупых орков

Судя по могуществу производимых тобой логических связей, ты имел в виду своих предков.

Твое знание истории ВМВ ограничивается просмотром

Насмешил :))) Хочешь посоревноваться ?

Т.е. если 1000 человек соберутся и побьют чемпиона ММА, значит их техника круче

Нет, это значит две вещи:
1. У 1000 человек хороший организатор, который смог их собрать
2. Чемпион ММА получил люлей

Судя по могуществу производимых тобой логических связей....

Юноша (или девушка) не знаю, поаккуратнее — у интернет-п$$$жа бывают последствия в реальном мире

Насмешил :))) Хочешь посоревноваться ?

С человеком, который пишет

Одна-винтовка-на-четверых, орды неграмотных тупых орков, подгоняемыех загранотрядами

?
Спасибо, я в параолимпиадах не участвую ;-)

сначала она закончилась во фронцузском селении Реймс. а уже потом, со второй попытки, на бис и по многочисленным просьбам одного усатого людоеда смогли повторить где-то под Берлином.

Что кажется странным?

Гон на технологию

Что вам нравится и считаете годным?

Работать с умными людьми

Работать с умными людьми

вот за диверсити и инклюзивити щас абыдна была

Ум не зависит от ограничения физвозможностей/пола/итд.

Архитекторы не любят scrum/agile потому что там нет такой роли как архитектор

так там і інших ролей типу девелопера, тестера, менеджера чи сантехніка. Бо це неважливо. І якщо ваш знайомий архітект не любить скрам(хоча для чого любити скрам, його тре використовувати), то він або не розуміє його і бачив погані реалізації, або помилково думає, що великий проект ось так можна взяти і зробити без фідбека

проекта все-таки участвует архитектор, просто позже уже проект менеджится по Скраму

ну да, что самым тупым темно и светлокожим гребцам дошло что делать в таске

По моему мнению, эти методологии о том, что сначала надо что-то делать, а потом подумать. Но это противоречит общей логике сознательной деятельности людей. Вначале необходима идея, концепция, механизм, технология, алгоритм, а затем реализация всего этого. Возможно, что для простых систем типа интернет магазинов и прочих систем с тривиальной ахитектурой: Web-App-Db и несложной логикой на App эти методологии и подходят, но я не вижу каким образом возможна разработка таких систем как Банковские системы, системы процессинга карт, системы управления предприятиями, системы управления реального времени в энергетике, авиации и т.д.

По моему мнению, эти методологии о том, что сначала надо что-то делать, а потом подумать. Но это противоречит общей логике сознательной деятельности людей.

Аджайл в общем — это образно говоря такой себе метод градиентного спуска, который натянули на слабо формальную песочницу огранизационной деятельности. Со всеми его сильными/слабыми сторонами и ограничениями. В локальной оптимизации per se нет ничего плохого, она как раз прекрасно укладывается в общую логику сознательной деятельности людей, и она прекрасно годится для решения огромного количества практических задач (грубо говоря там где «сделать приемлемо через месяц» лучше, чем «сделать идеально через год»). А то что сову беспардонно натягивают на глобус — ну так это не глобус виноват, и тем более не сова...

метод градиентного спуска

Годная аналогия.
А в основе две вещи: движение маленькими шагами (быстро по времени) и быстрое получение фидбэка. Но если чего-то из этого нет, то вся концепция перестает работать и превращается в набор ритуальных приседаний, которые всех только раздражают и отвлекают.
А чего-то не быть может по вполне объективным причинам. Например, система слишком сложна и её невозможно менять мелкими шагами. Либо заказчик недостаточно расторопен и фидбэка ждать придется месяцами.

сначала надо что-то делать, а потом подумать

c чего бы это ? Я бы даже сказал что agile это технология как колективно думать.

cистем как Банковские системы, системы процессинга карт, системы управления предприятиями, системы управления реального времени в энергетике, авиации и т.д.

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

«Это поэтапная работа, мы сначала делаем потом думаем»

похоже, когда ребенку дали кубики и сказали «построй башню»

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

Бизнес это воспринимает как «они за наш счет экспериментируют!»

Причиной извращенного понятия аджайла являются аутсорсы и их неумение делать фиксед прайс проекты.

Неправда, успел поработать в кучке контор разного калибру напрямую — все тоже самое что и в аутсорсе.

Проблема не столько в аутсорсах, сколько в кастомерах. Фиксед прайс — значит должно быть либо детальное ТЗ и строгие условия контракта (что как бы уже не эджайл), либо готовность заказчика резать скоуп проекта и брать ответственность за это для себя. Но это вообще не про корпоративных менеджеров-политиканов.

Я бы согласился, если бы не одно но... Сколько раз приходилось видеть, как табор под названием «дискавери» или «ассесмент» пинает у кастомера 30 дней, а потом заявляет — не, только дедикейтед тим или ТМ. В 99% случаев

В манифесте все правильно. Только это всего лишь — манифест ))) это как «мойте руки перед едой» правильная вещь, но что вы будете делать если нет воды? Разумный человек понимает зачем нужно мыть руки, какую цель это преследует и, соответственно, способен найти решение и для случая — «нет воды». Так что основное «зло» любых методологий (и манифестов) это непонимание зачем это, как оно работает, при каких условиях, где или в чем ограничения и что делать «если нет воды».

зы: Догматизм. Демагогия. И прочее, из этого же ряда.

зыы: Все зло в людях.

зззы: Добро и Зло — понятия относительные. Они определяются правилами игры, то есть договором.

Пример: нацизм в Украине — добро или зло? Могу перефразировать: наказывается или вознаграждается?

Добро и Зло — понятия относительные.

да, поэтому всегда нужно уточнять, что конкретно имеется ввиду, например, Lawful Evil или, там, Chaotic Good

С какой стороны ни смотри, а Добро и Зло — понятия относительные, и по сути определяются правилами игры. Или если тебе удобно, шаблонами восприятия. Которые нихрена не логичны, и вполне допускают трактование «Вы не понимаете, это — другое».

В любом случае нужно определение. Или как минимум сэмплы. Но сэмплами сложно решить граничные состояния, ХОТЯ и определением это сделать сложно: нужно ещё определять ЦЕЛЬ создания правил, чтобы в случае неоднозначного трактования правила можно было кастить шаблоны целью. Так оно в психологии и работает: подмена цели может очень сильно повлиять на применимость определения. И редко кто утверждает себя при постановки правила задать ещё и область определения.

Я вот считаю что микроскопы абсолютное зло, гвозди тяжело забивать, вытаскивать забитые гвозди вообще нереально!!!
Неоправданно дорого, натыкано куча левых рюшечек и перделок которые мне не нужны, но я почему-то должен за них платить!!!

Основных проблем 2:
1. применяется не там где нужно/возможно
2. применяется не так, как нужно

И как результат — тот «agile/scrum» который есть в большинестве проектов, по сути есть хаос, различной степени, который не является ни agile, ни scrum.

Аджайл таки название семейства методологий гибкой разработки. Поэтому там с ролями может быть по разному.
А вот в скраме да, нет архитектора. А еще нет тем/тех лида, мануальщика и автоматичика, девопса, аналитика и... даже девелопера :))))

„девелоперов” — в понимании обычных рядовых гребцов:
We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots. As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word „developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included.

«девелоперов» — в понимании обычных рядовых гребцов:

все очень «умные», и каждого свое «понимание»
осюда и все проблемы

ну там же прямым текстом написано, что под «девелоперами» понимаются универсальные бойцы, которые умеют все(и там частичный список скиллов перечислен). Да, такие команды бывают. Но ооочень нечасто :)

ну там же прямым текстом написано, что под «девелоперами» понимаются универсальные бойцы, которые умеют все

возможно, вы даже сможете поделиться точной ссылкой на данное утверждение?

Цитату по вашей же ссылке я привел выше.

Приведите, пожалуйста источник (ссылку в scrum guide) на

прямым текстом написано, что под «девелоперами» понимаются универсальные бойцы, которые умеют все

В описании «scrum team» я вижу

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

что говорит о кросс-функциональнсти команды, а не универсальности каждого участника — и означает, что команда в состоянии выполнить спринт собственными силами.

Цитату по вашей же ссылке я привел выше.

вы вообще скопировали левый абзац, в котором говориться о сферах приминимости scrum.

что говорит о кросс-функциональнсти команды, а не универсальности каждого участника — и означает, что команда в состоянии выполнить спринт собственными силами.

Повторюсь, спор начался из-за моего тезиса что в "в скраме нет понятия "девелопер"(и тут бы мне надо было бы написать что я подразумеваю обычного кодерка, чтобы уже совсем стало понятно)«. Что на практике зачастую приводит к логическим несостыковкам.
Например в scrumguides.org/...​rum-Guide-US.pdf#zoom=100 пишут что

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers.

что в в теории конечно же верно, но на практике зачастую приводит к эстимациям юзер сторей в «3 на дев и 2 на куа и еще полтора на БА и немного на деплоймент», причем эстимацию зачастую разные специалисты делают планнинг покером вслепую, одновременно всего скоупа стори, где люди эстимируют совершенно разные аспекты сложности и получают фиг пойми что на выходе.
Так что повторюсь, понятие «инженер, который имеет писать код» не выделено в скраме в отдельную сущность, а обобщено с любым «участником команды», с чего я и начинал.

и тут бы мне надо было бы написать что я подразумеваю обычного кодерка

А вы не подразумевайте, а читайте что написано в первоисточнике)
Возвращаясь к началу — понятие «developer» в скраме есть, надеюсь с этим вы спорить не будете.
Если бы вы написали "

и... даже кодерка :))))

то никто бы вам не возражал.

«3 на дев и 2 на куа и еще полтора на БА и немного на деплоймент»

Эстимация — отдельная дисциплина, и скрам ее не описывает. Есть много способов сделать хорошо, и еще больше — сделать плохо.

Моя претензия состояла в вашей вольной трактовке «developer — тот кто пишет код», вместо «тот, чья работа создает/увеличивает business value».

Ради интереса полез посмотреть как в официальном гайде перевели термины скрама(developers в том числе) на русский. Никак не перевели, оставили в английском написании. Достаточно спорное решение, так что занудствуя, могу аргументировать тем, что используя именно русскоязычное написание жаргонизма "девелоперы"(склоняя по падежам), в строгой трактовке, я не использовал термина Developers из терминологии Scrum. :)

Кратко о корнях ненависти к Agile:

Встречаются два еврея:
— Соломон, вам нравится Паваротти?
— Нет. Картавит, фальшивит... Не понимаю, что людям в нем нравится?!
— А где вы его успели послушать?
— Да мне Мойша напел

С Эджайлом все отлично. Нелюбить его могут только менеджеры с манией контроля, совки (люди с поломанной психикой, которым нужна сильная рука) и те, кто настолько ленивы, что не смогли осилить Эджайл манифест и понять разницу между тем, что там написано и тем пиз*ецом, который у них на проекте называется Эджайлом.

Скрам — другое дело. Это вообще с трудом можно назвать эджайлом. Но даже он, со всеми своими недостатками, не так плох, как его имплементации в реальной жизни и его яростные сторонники.

1. Тому що далі маніфесту ніхто нічого не читає.
2. Тому що вводять скрам або іншу практику не задаючи питання, яку проблему цей підхід вирішує, а тому, що всі інші так роблять.
3. Тому що на роль скрам майстра ставлять не людину з релевантним досвідом і відповідними знаннями, а Колю/Васю/Пєтю, який підходить під перші 2 пункти, або взагалі відмовляються від ролі.

Хватит путать понятия Scrum и Agile.

Достаточно того, что он не PM, может и путать, лишь бы манифест не нарушал

Одна справа коли архітектор використовує «лего конструктор» і його задача — зібрати з готових блоків великий проект. Зовсім інша справа, коли не усі блоки є (чи вони дорогі) і їх треба придумувати на ходу. Розповідати на стендапах про свої муки вибору — не дуже то і надихаюча процедура, коли це чують розробники...

Почему Scrum или Agile зло?

Потому что конкретно ты не умеешь

Чёрная книга SCRUM — обязательно к прочтению.

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

хм, а есть аудио и на англ ?

Есть же Scaled Agile Framework со спринт-трейнами по 6 спринтов, и архитект рисует дизайн на спринт трейн, и основные фичи которые ты разрабатываешь следующие 3 месяца заранее известны. А если внезапно в начале каждого спринта решать какие таски делать, то это как раз будет хаотичная разработка, где архитекту место найти тяжело.

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

Все что Scaled уже не Agile. Т.к. жестко задает формат и процессы вместо того, чтобы позволить исполнителям организовать это самим, удобным им способом.

Архитекторы не любят scrum/agile потому что там нет такой роли как архитектор. Мол, гибкая разработка приводит к отношению «мы как-то начнем с MVP и как-то налепим эту вавилонскую башню по имени проект»

Ниче непонтяно, что архитекторам мешает нарисовать архитектуру до начала спринтов, а потом сверять ее по ходу дела с тимлидами из разных комманд, корректировать итд ?
Или вы про диаграмму класов и ООД ? Так это ща не нужно, все на микросервисах.

А что плохого в ООД? Там помимо диаграммы классов есть еще пара диаграмм, которые вполне ложатся на скрум. А та же стейт машина даже вполне себе возвращается к жизни в некоторых трендах.

Дураки зло, а не подходы.

Тем не менее существуют и откровенно дурацкие подходы.

Но если организатор дурак, какой ярлык не вешай, всё равно самодурство будет

Кто не читал 12 принципов Agile Manifesto — c ними можно ознакомиться здесь

Как говорится «гладко было на бумаге»: манифест предполагает что бизнес и девелоперы будут тесно сотрудничать и делать нужные вещи. И это бы работало если бы бизнесмен четко понимал что ему нужно, а девелоперы понимали как это делать и развивать.
На практике же Agile выглядит примерно как эти «Двое из ларца»:
youtu.be/uruHnSUz7-8?t=901
Давай, говори — что хочешь сделаем! Только в итоге все месяцами месят говно и никакого ценного результата нет. Клиент платит за процесс — бесконечный процесс и получает.

Что вам кажется неправильным во всех этих Scrum/Agile подходах и почему они зло?

Потому что гибкостью оправдывают бардак! «Гибкая», нечетко сформулированная задача не может быть однозначно решена. Вместо результат получается бесконечный поиск решения. Как тот ремонт у которого есть начало — но нет конца. Поскольку все «гибкое» — то нету и четких критериев качества. В итоге работает подход «тяп-ляп и в продакшин».

И это бы работало если бы бизнесмен четко понимал что ему нужно, а девелоперы понимали как это делать и развивать.

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

Я еще не видел двух компаний в которых Scrum, Agile и т.п. означали одни и те же вещи. Каждый натягивает эту сову на глобус как он хочет.

Вот-вот. Всё сводится ко «мне Изя напел»

власне у цьому і суть. Є якийсь фреймворк, який показує свою ідею і які проблеми він може вирішити. І кожен може його взяти і підлаштувати під свої цілі.

Дивно, було би якщо всюди код на Go був би однаковий, правда ж ?

Не совсем, послушайте авторов Agile и что они думают о том, как он стал использоваться. Робер Мартин, например, уже давно ходит по подкастам/конференциям и рассказывает как манифест Agile был написан программистами для программистов, а был узурпирован project менеджерами.

Каждый натягивает эту сову на глобус как он хочет.

Щоб воно працювало треба процес підлаштовувати під наявних людей. Воно тому і має бути різним в кожній команді. Більше того — все це має з часом змінюватися відповідно до нових задач, отриманого досвіду, зміни технологій і такого іншого. Тому і потрібні експерименти, різноманітні ретро (якщо їх для цього використовують) щоб різні практики оцінити і залишити, або викинути.

Кто не читал 12 принципов Agile Manifesto — c ними можно ознакомиться здесь
agilemanifesto.org/principles.html

> Simplicity—the art of maximizing the amount of work not done—is essential.
Это взаимоисключающий параграф к гибкости на которую нацелен скрам. Хочется гибкую разработку — прийдется писать самый разный код в больших количествах.

они зло, потому, что их фанаты не обладают достаточной гибкостью ума, чтобы комбинировать различные подходы для лучшего достижения цели

это утверждение из серии «все блондинки т*пые» — необоснованное обобщение какого-то своего опыта. не годится как аргумент в цивилизованной дискуссии

Да нет, тут очень точное обозначение — «фанаты». Если человек «фанат» в таком, то это говорит о очень ограниченных умственных способностях

Количество ума у фанатов (любых) тождественно равно логарифму единицы

Подписаться на комментарии