×Закрыть

Agile, который мы потеряли

Золотые слова, Федор Бенедиктович Ryan Singer:

„Agile was originally about uncertainty and learning, but ‚true’ agile didn’t survive agile’s growth. Agile today means high-frequency waterfall. Companies merely changed the color of the dress.
Agile became synonymous with ‚speed’ because of sprints, velocity, etc. But speed isn’t the real problem. The real problems are doing the wrong thing, building to a spec, unfocused resource allocation, etc.
People seek something like ‚agile’ because they recognize they aren’t good at delivering software. Cycle alone don’t fix anything. There needs to be a feedback loop that allows requirements to change. Aka learning.
If you aren’t allowed to change the requirements of what you’re building as you go, working in cycles won’t help you. The purpose of working iteratively is to change direction without starting over.”

В эпоху когда всех вокруг учат „делать скрам” остаются еще островки благоразумия.
Встречался ли вам на украинских галерах такой agile или карго-культ победил?

LinkedIn

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

Не потеряли, а правильнее сказать «ниасилили». Agile, как и любые другие lean technology, требуют зарезать одну священную корову: бюрократию. То есть избавиться от туевой хучи убийственно тупорылых ритуалов, равно как и от людей которые этой деятельностью страдают.

Вот взять, вызвать «хэпинесс-менеджера» на ковёр, и сказать:
— Детка, у нас всё кончено, ты уволена.
Это эджайл. А стэндапинг в митинг руме про шнэлинг шнэлинг говнокодинг — это факинг кармадрочинг, а не эджайл.

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

Стид та скрам якийсь...

Раз уж подняли эту тему, то Agile — это прилагательное.

Agile was originally about uncertainty and learning, but ‚true’ agile didn’t survive agile’s growth
Гибкая была изначально о неопределенности и обучении, но «настоящая»
гибкая не пережила роста гибкой.

Бред же.

www.youtube.com/watch?v=a-BOSpxYJ9M

Ну если так переводить, то конечно бред

Так даже если не переводить :). Я для наглядности перевел. Видео автора манифеста о гибкой разработке не смотрели?

не смотрел, но вы бы хоть написали что именно в том видео на 45 минут привлекло ваше внимание? Цитата, или там ссылка на точное время?
Как-то не хочется просто бросаться смотреть любое видео на 45 минут. Я может гляну его позже, но вы бы сопроводили бы линку описанием для чего она.

вы бы хоть написали что именно в том видео на 45 минут привлекло ваше внимание?

Так я, ведь, и написал :)

Там в самом начале, вот: youtu.be/a-BOSpxYJ9M?t=646. Все выступление стоит проссмотра, на самом деле.

Не потеряли, а правильнее сказать «ниасилили». Agile, как и любые другие lean technology, требуют зарезать одну священную корову: бюрократию. То есть избавиться от туевой хучи убийственно тупорылых ритуалов, равно как и от людей которые этой деятельностью страдают.

Вот взять, вызвать «хэпинесс-менеджера» на ковёр, и сказать:
— Детка, у нас всё кончено, ты уволена.
Это эджайл. А стэндапинг в митинг руме про шнэлинг шнэлинг говнокодинг — это факинг кармадрочинг, а не эджайл.

Неверно глаголешь, Матроскин.

„Agile software development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.[1] It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.[2] ”

Как видишь, ничего об устранении бюрократии не сказано. Но сказано об изменении подхода (в сравнении с водопадом).

ваш бюрократический коммент очень важен для вас

шнэлинг шнэлинг говнокодинг

Хочу теперь такую футболку

Вот взять, вызвать «хэпинесс-менеджера» на ковёр, и сказать:
— Детка, у нас всё кончено, ты уволена.

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

А потом уборщице столы отмывать с нижней стороны.

Вообще-то её наняли не для этого. А для хэпинесса нанимателю. Это очень древняя профессия.

Мощно задвинул, выражаю решпектование

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

Главное не говорить им что значит слово «скрам».

Agile was originally about uncertainty and learning.... Agile today means high-frequency waterfall. Companies merely changed the color of the dress.

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

А он и не должен это решать, не для этого создавался

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

А можно подробнее.
Тот же XP — это про качество системы. В аджайл-манифесте было что-то про отношения с заказчиком.

Ни одна методология не решит проблемы если специалист гавно, зафакапить можно даже 2+2

Ни одна методология не решит проблемы если специалист гавно, зафакапить можно даже 2+2

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

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

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

Его используют потому что это самый простой но хорощо продуманный итерационный метод вот и все.

«Просто потому», что другого слова не знают — это точнее... хотя Agile — это даже не метод, а общий подход к решению определенного класса задач. В кризисное время таким «подходом для дурака» становится lean development, причем все клиенты свято убеждены, что экономится именно бабло.

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

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

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

Вот как раз скрам позволяет отложить проблемы с кодом и качеством на потом. ... А потом эти проблемы надо будет решать в уже сданом коде (условно на продакшене).
И проблема тут в том, что заказчику фичи важнее качества. Качество — это нечно само собой разумеющееся. Качество — это интерес команды, но поскольку комманда получает ЗП не за решение а за время, то этот интерес не очень проявляется.

комманда получает ЗП не за решение а за время, то этот интерес не очень проявляется

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

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

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

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

В предположении, что команда __постоянно__ лажает, что контора __не большая__, что заказчик сделает определенные шаги. То есть в теории вы правы, а на практике, что-то я не слышал чтобы закрылся хоть одна из ТОП-5 контор в Украине.

В принципе, вменяемому заказчику можно продать и рефакторинг (в виде тасков) тоже.

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

Если компания продуктовая, ей ещё проще — т.к. решение о рефактринге принимается внутри компании, а затраты закладываются в цену продукта.

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

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

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

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

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

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

Да, и в чем этот заказчик заинтересован? В том чтобы его заказчик как можно быстрее получил качественный (не требующий доработок) продукт?

А все эти скрамовские запросы на прямое общение команды с конечными заказчиками — это в детский сад с единорогами. :)

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

Да, и в чем этот заказчик заинтересован?

Менеджер кодерков заинтересован во многом. В том числе и в рефакторинге (по многим соображениям).

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

Менеджер кодерков заинтересован во многом. В том числе и в рефакторинге (по многим соображениям).

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

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

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

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

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

За последствия «тяп-ляп» (как то, сложность последующих изменений и прочие нехорошести) — ответственность нести будет именно менеджер. Потому, он заинтересован (если не дурак).

С этим знанием, менеджер может получить «добро» на рефакторинг от своей компании (исполнителя) за счёт компании Либо компания даже может запросить оплату дополнительных часов работы от заказчика, именно на рефакторинг. Из моего (немаленького) опыта на проектах — такое чаще работает, чем не работает.

Что касается противопоставления «же» — оно касалось вашего сравнения скрама с «ускореннмым водопадом». Это несравнимыe вещи, т.к. «уcкоренные водопады» существуют лишь у тех, кто не в ладах с терминологией.

не решит проблемы криво написанного кода, плохого тестирования, наплевательского отношения к клиенту
Он их не решит, но выявит на очень ранней стадии
дёшево «тяп-ляп и в продакшн» (без каких-либо ошибок! но, к примеру, с кучей копипасты)

Очень интересная формулировка «без каких-либо ошибок!» :)
Я то думал что мы начали как раз с того что нам нужно выявить «плохое тестирование» и «низкокачественный код». Как скрам помогает выявить на ранних этапах?

Как скрам помогает выявить на ранних этапах?

dou.ua/...​rums/topic/22261/#1223396

dou.ua/...​rums/topic/22261/#1223396

Этот комаент не отвечает на вопрос «как?». Без скрама у «заказчика» (а как оказалось в вашем понимании — это просто менеджер) нет возможности увидеть проблемы?

нет возможности увидеть проблемы?

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

Скрам оказался востребован именно, из-за 1) ориентированности не на продукт, как монолит, а на фичи 2) скоротечность реализации фич — соответственно, радикальное (в сравнении с водопадом) сокращение времени фидбэка о производительности/способности тима.

Вот как раз скрам позволяет отложить проблемы с кодом и качеством на потом. ... А потом эти проблемы надо будет решать в уже сданом коде (условно на продакшене).

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

Я не то имел в виду. В реале это выглядит так: некий вполне успешный манагер узнает
от знакомого, что допустим таблетки «факитол» помогают избавить животных от глистов, а Agile — улучшить качество ПО. Манагер щелкает пальчиками, обЪявляет команде, что теперь они работают по-новому, по Agile-у, а его пекинесу ветеринар регулярно заталкивает в пасть факитол. Команда девов в полном афуе потому, что релиз теперь в конце спринта длиной в неделю, а не просто в конце недели, и сопсно «вот и все, что было». Собачка благополучно сдыхает, потому что приятель такой дозой лечил своих племенных бычков. Т.е. мяхко гря некомпетентность и следование тенденции, что якобы «Agile может все» , привела к закономерному результату. И к появлению новой легенды «Agile не может нифуя» :(
Благодать не приходит сама ни от слова «осанна!», ни от слова «Agile», а токмо через людской труд. Опять же, гвозди забивать можно молотком, обухом топора, но пробуют и напильником, и пресс-папье, и, как говорят, микроскопом тоже. То есть, на самом деле, так или иначе работает любой подход, даже «выстрелил и забыл» :8) вопрос в сфере использования и эффективности. Agile — это прекрасное решение для коммерческих продуктов, точка. А на Марс спринтами не долетим.

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

Понравилось про Марс, хорошо подмечено

Встречался ли вам на украинских галерах такой agile или карго-культ победил?

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

Если «галера» — это аутсорс, то «high-frequency waterfall» — это самое простое и удобное средство, с точки зрение компании. Заказчик чувствует что «он кому-то нужен», а у исполнителя есть возможность (не все и не всегда ей пользуются) прикрыть свою Ж, если заказчик начинает менять планы каждый день.
Если «галера» — это «рекрутинговое агентсов + коворкинг» именуемое у нас аутстафф, то тут все зависти от конкретого проекта, но «high-frequency waterfall» удобен по тем же причинам что и в аутсорс.
Если «галера» — это __большая__ продуктовая компания, коих у нас нет, то там могут решать проблемы с бюрократией.

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

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

Скрам нормально работает когда вся команда 5-10 человек, с учетом людей от бизнеса.

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

Команда понимает о чем вообще проект

иногда этот момент самый сложный

If you aren’t allowed to change the requirements of what you’re building as you go, working in cycles won’t help you.

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

Та там в цитате детсад на детсаду. :)

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

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

в пожарном порядке разгребающих писанину детсадовцев за хороший рейт.

тоесть ты по факту должен их во всем публично поддерживать!))

тоесть ты по факту должен их во всем публично поддерживать!))

Да. Но при этом, меня корёжит от несовершенства окружающего мира. :)

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

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

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

Аха-ха просто. Где-то так происходит, конечно. Но на одном из предыдущих мест работы потратил 2 месяца на фичу, о которой потом подумали и решили — а на кой она нужна. В релиз фича так и не ушла... Далеко не везде так, но случается. При этом православный скрам, да.

о которой потом подумали и решили — а на кой она нужна. В релиз фича так и не ушла

Иногда так бывает, если фича получилась «сырая». Т.е. когда выпустить продукт с ней будет проблематичнее — чем похерить на фичу (несмотря на потраченный баблос) и выдать продукт без неё.
Может, дело не в скраме? :)

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

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

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

Именно. Но большинство комманд заменяет нормальный вариант карго-культом

2 месяца разработки (т.е. 8 недель или ~3 спринта) без ревью, что получается из фичи — это дело не в команде, а в каком-то сверх-либеральном заказчике.

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

Кста не ревью а демо

Вроде, демо в рамках «спринт ревью», если мне не изменяет склероз. :)

А затем уже «спринт рестроспектива» — когда команда заседает и решает, как прошёл спринт.

Скрамбат же

Дело зачастую именно в скраме. Потому что Спринты — превращаются в Марафон, без реальной рефлексии для уточнения траектории на основе приобритенных знаний во время работы.

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

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

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

Это нормально. Спринты не для приобретения знаний, а для выдачи фич. За которые платят деньги.

Знания приобретаются в детсадах/школах/прочих учебных заведениях — и без каких-либо спринтов... :)

Да! Все правильно. И вообще непонятно, почему нельзя программы сразу без багов писать?

Слова не мальчика, но скрам-эксперта. :)

Как хайп пройдёт — скрам-эксперты отправятся по базарам, лифчиками торговать.

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

Вообще удивительно, что многие кто комментирует воспринимает слово learning и new knowledge сугубо однобоко как hard-skills программиста.
После спринта инкремент выкатывается в прод, и можно вполне себе увидеть как и что идёт, сделать какие-либо выводы что и как работает, куда двигаться дальше, что можно улучшить/изменить/выкинуть/переделать

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

Заказчик попробует и увидит. При чём тут кодерки, к «как лучше и что переделать»?

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

Когда подумали тогда и выкинули, в чем проблема?
В статье о том что подумали но не выкинули, чего не бывает

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

Это решать стейкхолдерам, поняли позже — щит хепендс, к статье это не имеет никакого отношения

Даже не знаю, какую часть статьи процитировать...

The real problems are doing the wrong thing, building to a spec, unfocused resource allocation, etc

Наверное эту.

Вы нарушили методологию получили ауткам, все закономерно

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

оригинальный пост именно о том, что методологию начали нарушать все чаще и чаще

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

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

плач что мы мол ниче менять в беклоге не можем, не дают

Ну да. Ведь программист лучше знает, что нужно заказчику. :)

Наш диалог начинает напоминать мне историю про мудрецов и слона :)

Даже в Идеальном Скраме никто и никогда не говорил, что разработчик может сам решать что ему делать. Поправьте если ошибаюсь.

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

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

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

Я бы не сказал, что это учёба. И что на это закладывается какое-то отдельное время.

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

Может, это конечно неудачная цитата — но в ней слово «learning» встрeчается столько же раз, как и «working». Что может намекать о предпочтениях — обучаться вместо работы, за счёт заказчика.

Соглашусь, что learning вместо working — ересь какая-то. Что не отменяет того, что они вполне могут сосуществовать. Конечно, баланс при этом однозначно в сторону working.

Соглашусь, что learning вместо working — ересь какая-то.

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

Типа, работать и выдавать на гора фичи это слишком скучно — другое дело, чему-нибудь новому учиться. :)

Это детский сад, но стал частым в расслабленных, избалованных деньгами сферах.

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

Это реально только если разработчик сам себе и заказчик. А так быстрее разработчики запилят фичу чем станет понятно что она не нужна. Имхо.

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

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

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

становится понятно, что эта самая спека — хyйня ненужная или просто неправильная?

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

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

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

А потом, квалифицированные кодерки могут в мире софта сделать, практически, всё.

Конечно спека, бизнес важен а не чувства тех кому платят за работу, надо менять/исключать таску с подачи стейкхолдеров/продакт оунера, но не девов
Так в чем проблема то, вы знаете тех кто вам скажет — Да плиз, делай за мои деньги то что мне не нужно и после демо будет выкинуто? Я таких не знаю
Статья о том что оказывается 2+2=4, хотя все и так это знают

надо менять/исключать таску с подачи стейкхолдеров/продакт оунера, но не девов

это бесспорно, не об этом речь. Программисты это часть команды продукта, а не отдельная каста, и продакт оунер — отдельная, которые соединяются только при помощи спеки.

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

та ну,если это не стартап то у девов не может быть хотелок, как и у тестировщиков

Под хотелками , я подразумевал как раз критерии приёмки и особенности имплементации:)

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

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

а по идее продукт оунер / аналитик должен быть частью команды

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

И взаимодействие должно быть двунаправленным уже на этапе формирования хотелок.

Это вообще об чём-то видимо прямо относящемуся к «почему потеряли» здесь «хотелок» от команды что ли?

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

— всё это хорошо работает в детсадовской разработке, на которых госзаказчик списывает (ака дерибанит) госбаблос и не задаёт вопросов. Подозреваю, ентот самый Ryan — оттуда.

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

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

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

А «продакт оунер» в идеалистическом скраме — ничего не имеет права с командой сделать. Имеет право лишь получать пинки от начальства, за зафэйленные командой задачи.

В общем, детсад. :)

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

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

Скрам-мастер тоже не может, т.к. в мире идеалистического аджайла — скрам мастер 1) всегда на стороне команды 2) (естественно) выступает медиатором между «продакт оунером» и командой.
На команду давить не имеет права.

Если скрам мастер всего лишь консультант на проекте — есть ПМ, который на всем точно так же держит руку. 95% команд что я видел — ПМ выполнял обязанности скрам мастера, и вот тут попробуй заяви ему про его полномочия)

1) всегда на стороне команды

Очень скользкое утверждение.
Если рассматривать биполярный мир без гранулярности — команда вс стейкхолдер — ок, допустим.
С точки зрения — ленивые\тупые\дохлые члены команды вс скрам мастер? да он первым их зарепортит стекйхолдеру на замену, нужны ему придурки в команде, ога

ПМ выполнял обязанности скрам мастера

Это уже переход из детского сада идеалистичского аджайла — в реалистический (и полезный) аджайл. :)

Полностью согласен
Так ведь Аджайл\Скрам декларирует роли которые нужны для процесса, он не говорит что какие то классические роли внутри команды нужно заменить или исключить, это паралельные структуры которые всегда идут вместе, как вертикальная и горизонтальная структуры компаний
Нужен скрам мастер? ок, мастером не может быть член команды и продакт оунер, значит либо сторонний консультант либо менеджер команды, вот и все варианты. и менеджер даже не будучи мастером никуда не денется
как и тех\тим лиды никуда не делись в скраме, это паралельные струткуры

мастером не может быть член команды

Насколько я помню, «по книжке», как раз, наоборот — скрам-мастер это не какая-то отдельная «должность», а роль, которую берёт на себя кто-то в команде. То, что в реалиях украинского аутсорса эту роль стали отдавать ПМам — говорит, скорее, о кардинальном непонимании сути и предназначения скрам-мастера.

Член команды (дев куа по) не может взять на себя роль скрам мастера, конфликт интересов

Я бы так однозначно не утверждал. В agile тусовке было множество споров по этому поводу, и у каждой из опций (скрам-мастер как отдельно выделенный человек vs. скрам-мастер, совмещающий эту роль с разработкой или тестированием) есть свои сторонники и противники.

Официальный scrum guide ничего не говорит по этому поводу.

Мне вот это, кстати, всегда было интересно. Обычно скрам-команда это 5-7 человек. Что в таком случае делает выделенный на фулл-тайм скрам-мастер? Вот в чем его работа заключается?

Если это выделенный человек без функциональной позиции типа пм, то обычно он скрамит 3-5 команд в компании

Что в таком случае делает выделенный на фулл-тайм скрам-мастер? Вот в чем его работа заключается?

Хернёй страдает. Есть такая работа. :)

Ты просто завидуешь сперва добейся. (к) (тм)

он менеджит ЧТО делать, он не менеджит как\когда\кому\сколько
единственное исключение — если ему нравится и достаточно опыта — он иногда решает КАК что-то сделать и включает это в спеку, но это не золотое правило

он менеджит ЧТО делать, он не менеджит как\когда

Мне, всё же, кажется, что «когда» в смысле «к какому дедлайну вот эта конкретная фича должна быть готова» — ПО таки менеджит путём корректного расставления приоритетов в бэклоге, разве нет?

Да, когда тут затесалась не в тему

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

Эджайл, это напротив, снижение неопределённости — при увеличении энтропии (из-за «итераций»).

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

Эджайл, это напротив, снижение неопределённости — при увеличении энтропии (из-за «итераций»).

Я не очень понял что это значит.
Википедия:

Информацио́нная энтропи́я — мера неопределённости или непредсказуемости некоторой системы

Получается что: «Эджайл, это напротив, снижение неопределённости — при увеличении меры неопределённости или непредсказуемости некоторой системы (из-за „итераций“).»

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

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

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

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

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

При водопаде продукт и бюджет расписываются на месяцы (как правило, годы) вперёд. Может быть, где-то в очень крупных проектах (типа, разработки/реализации нового Боинга) такое ещё и существует — но в мире обычных софтовых проектов (каких 99.99%) уже нет.
Отсюда и аджайл.

но в мире обычных софтовых проектов (каких 99.99%) уже нет.
Отсюда и аджайл.

Об этом, как я это понимаю, и говорится в самом первом предложении:

Agile was originally about uncertainty and learning, but ‚true’ agile didn’t survive agile’s growth.
about uncertainty and learning

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

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

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

А еще потому, что позволяет прикрыть жопу менеджерам, потому что «ну мы же работаем в режиме высокой неопределенности», а в вотерфоле завалив проект отмазаться не получится ;-)

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

По водопаду уже мало кто из заказчиков готов работать. Т.к. работа по водопаду означает 1) заказчик оплачивает анализ и планирование разработки продукта 2) заказчик подписывается на оплату разработки от начала и до релиза (минимальная итерация в водопаде), с запретом на добавление новых фич, т.к. такое добавление ломает разработанный в п.1) план/бюджет.

Возможно, так до сих пор разрабатываются/строятся атомные подводные лодки или пассажирские самолёты — но не софт.

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

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

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

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

Если итерация длится несколько недель (а не полгода и более), а разработка заточена на фичи (а не на продукт, в целом) — то тaки аджайл. :)

А просто итерационная разработка назвать нельзя?

Уверен? Может таки помер?

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

Если вотерфол разбить на недельные итерации вместо полугодовых

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

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

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

Итерации могут длиться и несколько недель, если необходимо.

Ну да. Как правило, 2-3 недели.

Что и когда определяет Product Owner. Сколько — команда, так как команда делает оценку всех тасок и если команда видит что работы больше чем они реально успеют за спринт, то нет смысла общать PO что они сделают больше — это нереалистичное обещание от которого никто не выиграет когда сроки зафейлятся. И команда сама рапределяет задачи из беклога — это вполне логично, ведь им самим их выполнять, а не PO, скрам-мастеру или еще кому-то там кому захотелось покомандовать.

Самая удачная реализация скрама на проекте, какую я видел, была примерно такая:
— тим по 7-15 чел
— у каждого тима по архитекту (т.к. тим отвечает за фичи из определённой подсистемы)
— архитекты согласовывают общий дизайн системы друг с другом и являются посредниками между своими тимами и маркетингом (маркетинг владеет бизнес-требованиями)
— соответственно, архитекты являются и ПО для тима
— в тимах так же есть скрам-мастера — но они «играющие» участники тима (т.е. не только организовывают процесс, но и кодят)
— реализация каждой фичи состоит из 1) дизайна 2) реализации 3) написания тестов. тдд не пользовалось. Лишь после того, как дизайн (умл-диаграммы) согласовывался с архитектом (он же по), начиналась реализация

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

За исключением вот этого пункта

архитекты являются и ПО для тима

всё, что описано выше, внезапно, и является правильной «фэн-шуйной» организацией Agile разработки на большом проекте :)

При этом, полагаю, для нетипичного распределения ролей «ПО == архитект» были свои причины. А также, рискну предположить, что, в реальности, архитекторы были, всё же, скорее, proxy Product Owner’ами, просто с очень хорошим пониманием предметной области, чтобы не согласовывать решения с бизнесом по каждой мелочи.

Добавлю ещё деталей, с того же проекта. :)

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

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

— архитект, в принципе, мог сам и покодить — но реально у него до этого руки не доходили (хоть и явно почёсывались :) )

П.С. проект на порядка 200+ чел одних лишь разработчиков (с соответствующим количеством подситем/тимов) на 4+ лет, общий бюджет порядка 250 млн.

П.С. проект на порядка 200+ чел одних лишь разработчиков (с соответствующим количеством подситем/тимов) на 4+ лет, общий бюджет порядка 250 млн.

Серьёзно так по 250к на разработчика выходит хорошо пилят грамотно доходчиво без агиле такое (бюджет) распилить ну никак ))

Туда ещё затраты на инфраструктуру вошли. Плюс, проект слегка затянулся — типа, планировали закончить за 4 года, а получилось за 6+ (правда, в последние годы меньшими силами).
Сторонних подрядчиков было не особо много.

Кстати, вот на XP Days было интересная дискуссия про эстимейты. Стори поинт — это по сути размер задачи, а не время ее выполнения. Это как километры. Один пробежит за три минуты, другой — за 10. Длина километра от этого ведь не меняется.

— Я пробегу этот киломметр за 5 минут.
— Я пробегу этот километр за 3 минуты.
— Беги.

А еще лучше взять усреднненое значение (нет).

Дык, с подрядчиком обсуждаешь фронт работ на очередные 3 месяца, с таким-то бюджетом. В чём считать таски, которые за этот бюджет планируются?
В чём-то виртуальном, не захочeт ни одна из сторон — т.к., потом начнутся драмы...

Вот эту штуку вроде как для таких случаев применяют — en.wikipedia.org/wiki/Function_point

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

Эти поинты ведь — чуть ли не после каждого спринта пересчитываются. :)
Если по скрам-науке. А если уже не по науке — то проще в часах...

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

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