vit_r: default (Default)
[personal profile] vit_r
Если контора говорит, что документировать не надо, или что на документацию нет времени, то это значит, что менеджмент не контролирует процесс настолько, что боится его увидеть. Пока всё "в головах" и вместо документации "это просто запомнить", невозможно наглядно продемонстрировать общее состояние дел. В принципе, это основная причина того, почему менеджмент вводит agile.

И просто отмечу для истории. На днях разобрался с agile. Понял, что в схеме должно быть не два, а четыре цикла.

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

Второй забытый тоже не учитывал за ненадобностью, но понаблюдав за потайными дискуссиями [dreamwidth.org profile] kdanilov и [dreamwidth.org profile] dennisgorelik всё-таки решил, что самоочевидное тоже должно быть описано. Потому как без него совершенно непонятно, почему люди в этом участвуют.

Рабочее название: The Cycle of Self-Satisfaction

Date: 2020-02-14 06:40 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
Извините, в какой схеме? Да, желательно это описать, т.к. это помогает калибровать восприятие.

Date: 2020-02-15 04:41 am (UTC)
dmm: (Default)
From: [personal profile] dmm
Мне кажется, это прежде всего вопрос о власти. Кому принадлежит реальная власть в компании, менеджерам или опытным инженерам, и если она делится между этими группами, то как именно. Тем более, лет 20 назад были тренды к инженерному самоуправлению.

Agile, с его унизительными спринтами, скрамами, и scrum masters, и уничтожением любых разумных показателей эффективности, заменяемых на процент тикетов, запланированных на данный спринт, которые были закрыты в этот спринт, - он даёт недвусмысленный ответ на этот вопрос - власть в таких организациях полностью принадлежит менеджерам, сильные специалисты не значат ничего, и все низведены до состояния прыжков через обруч. Последствие состоит, конечно, в том, что это - власть над руинами.
Edited Date: 2020-02-15 04:42 am (UTC)

Date: 2020-02-15 01:58 pm (UTC)
dmm: (Default)
From: [personal profile] dmm
В том, что я наблюдал, власть была очень опосредованая. Она не содержалась в agile-ритуалах. Власть состояла в том, что люди, имевшие власть, заставляли людей, не имевших власти, участвовать в agile-ритуалах. Сами они в них не участвовали...

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

Date: 2020-02-15 03:11 pm (UTC)
dmm: (Default)
From: [personal profile] dmm
Вопрос в том, отличается ли эта власть от власти пахана в лагерном бараке (с той разницей, что с физическими заточками люди не ходят, условия неплохие, и всегда можно выйти на свободу и идти на все четыре стороны).

Если не отличается, то её не очень-то хочется получать, хочется держаться в стороне, по возможности...

Date: 2020-02-15 04:16 pm (UTC)
From: [personal profile] jamhed
Отличается. Никто никому прямых указаний давать не может, личной ответственности нет, есть только "командная". Вообще сильно напоминает совок устройством: звездочки и прочие ячейки с секретарями, и надзирающими со стороны мудрыми партийцами (afaik такой надзор сейчас называется кураторством).

Date: 2020-02-15 04:51 pm (UTC)
dmm: (Default)
From: [personal profile] dmm
Это не то, что я видел в той единственной ситуации agile scrum, в которой я был (я думаю, это со мной не повторится).

Я видел ситуации полуанархии, и там никакой особой власти не было, и видел ситуации, когда был пахан, который пытался наежать (всё зависело от того, кто был tech lead of scrum meetings).

"Scrum master" пытался наезжать на всех remotely, и кому хотелось его бояться, они его боялись, но, в общем было по-фигу. Менеджеры нижнего звена уже не принимали в этом никакого прямого участия, но они были затраханы по-другому, ещё хуже (и, вместе с тем, образовывали интерфейс к этому самому agile процессу).

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

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

я не очень понимаю, как Вит предлагает "брать власть" в такой ситуации (и в чём такая власть могла бы заключаться, с учётом того, что в этой стадии развитии, фирма уже была в таком состоянии, что в ней вообще не было привлекательных ролей; it was fairly sustainable despite all this).

сначала так не было, но потом они довели до того, что почто все компетентные люди сбежали, а потом они ввели вот это, чтобы уже никто не мог ничего толкового делать... "this is a pure fiction, any similarity to any actually existing entity is purely accidental and unintentional - legal disclaimer"

Date: 2020-02-15 05:07 pm (UTC)
From: [personal profile] jamhed
> Это не то, что я видел в той единственной ситуации agile scrum

Само собой, при всей примитивности scrum (а может быть и поэтому) его часто применяют неправильно, вводя элементы и роли скрамом не предусмотренные, а часто и прямо противоречащие. Называется это подгонкой скрама под нужды заказчика. Потом, есть тонкое, но важное различие: agile это идеология, а scrum -- project management framework, можно быть agile и без скрама, и наоборот.

> я не очень понимаю, как Вит предлагает "брать власть"

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

Собственно все управляющее воздействие в скраме исключительно через роль секретаря собраний (scrum master/product owner), не все менеджеры это понимают и не все к этому готовы, поэтому типично видеть сову натянутую на глобус, как вы описываете.

Date: 2020-02-15 05:31 pm (UTC)
dmm: (Default)
From: [personal profile] dmm
ну вот моё неформальное впечатление, что agile бывает разный, что scrum - самый частый, и наименее подходящий для серьёзных проэктов с высокой сложностью софта с длинными циклами...

что, вообще говоря, agile можно делать хорошо (например, облегчённая и неформальная версия extreme programming двадцатилетней давности, которая во многом была предтечей agile, но основывалась на самоуправлении инженеров в небольшой компетентной команде, а не была навязана сверху в огромной клоаке, она работала очень неплохо, и, во всяком случае, никаких яркий патологий там не было)...

а как дело доходит до agile scrum, навязанного менеджментом, так мы начинаем видеть разнообразнейшие патологии, вплоть до "раз мы agile, то мы уже test driven, поэтому можно обойтись и без тестов" (это, всё же, крайний случай, про такое я только слышал, но дезорганизацию производства при переходе от неформального extreme programming light к agile scrum видел своими глазами ("this is a pure fiction, any similarity to any actually existing entity is purely accidental and unintentional - legal disclaimer"))...

Date: 2020-02-15 07:14 pm (UTC)
dmm: (Default)
From: [personal profile] dmm
да, сколько я понимаю, там есть всякие проблемы, с extreme programming... а большая часть agile - это чистый карго-культ...

но у нас ничего такого не было; никакого agile манифеста не было, и не было никаких показателей, связанных с этим процессом, а было вот что: source control, continuous integration, ticket system to keep track of things, good test coverage, continuous testing, internal usenet news, translation of commit diffs right into appropriate usenet groups, informal code review (but there were always people willing to double-check commits), occasional pair programming (very rare). Our own datacenter run by a few extremely competent people...

и авторитетность инженеров при обсуждениях - чисто по уровню компетентности... meetings were usual (pre-agile classical), we tried to make sure they are not too frequent... core hours (noon-4pm), flexible otherwise... no open space, shared 2-3 person offices instead... очень это было неплохо, while the company stayed small and independent...

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

Date: 2020-02-15 11:01 pm (UTC)
From: [personal profile] jamhed
Agile and scrum как феншуй, полезное оттуда очевидно, а не очевидное бесполезно. Смешно и больно это видеть, на самом деле.

Date: 2020-02-16 08:42 am (UTC)
From: [personal profile] jamhed
Я немного мысль разверну. Скрам это про то, что задачи надо записывать в журнал (backlog), и этим задачам расставить приоритеты. Потом над этим баклогом коллективно думать (backlog refinement), а по результатам думания задачи оценить типа "сложно", "не очень сложно", "вообще фигня", и т.д. После чего выбирать посильные задачи оптимизированные по паре (приоритет, сложность), и типа решать в отведенный период времени (2 недели, спринт). По окончании спринта посмотреть что из задуманного сделано, а что не сделано и почему. Rinse, repeat. Соответственно очевидные роли: расставлять в баклоге приоритеты (product owner), и секретарь собраний (scrum master), что бы собрания в хаос не превращались.

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

Как видим, про управление в скраме ничего нет, и быть не может, по определению. Что вызывает когнитивный диссонанс у корпоративных менеджеров, типа как же так, жопа есть, а слова нет. Поэтому скрам превращается в тыкву: роли становятся должностями, заводятся другие сущности типа tech lead и product manager, а сам скрам используется как средство управления, так как других не завезли.

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

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

Вопрос вот только куда бежать компетентному разработчику.
Edited Date: 2020-02-16 08:55 am (UTC)

Date: 2020-02-16 09:06 am (UTC)
dmm: (Default)
From: [personal profile] dmm
У меня даже более короткое впечатление. С одной стороны, серьёзный проект плохо нарезается на (двух)недельные согласованные кванты. С другой стороны, на планирование этих квантов и отчетность по ним тратится слишком много времени. Естественное разбиение проекта на подзадачи (включая дизайн, и всякое такое) очень сильно искажается необходимостью нарезать именно так, чтобы впихивалось в эти спринты (и ещё чтобы с гарантией делалось, ведь единственный официальный показатель - это процент выполнения запланированного).

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

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

***

У нас люди сначала разбежались (начальство постаралось), потом удалось как-то опять собрать разумную команду, а уж потом они это дело ввели, и тут плохая ситуацию превратилась во вполне катастрофическую (legal disclaimer above, etc.)

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

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

Date: 2020-02-16 10:51 am (UTC)
From: [personal profile] jamhed
Вот кстати интересный момент, купить успешную компанию и внедрить там agile со скрамом как описано выше. Компетентные разработчики разбегаются, но вот в чем профит? У нас что-то похожее проделали, но я смотрю с другого конца и несколько со стороны, но вот кого спросить, даже это невозможно выяснить. Типа само случилось.

А про юзеров это у них (scrum/agile coaches) любимая песня, особенно смешно когда они это рассказывают людям у которых ярко выраженных пользователей нет (типа network operations center). Все как в анекдоте, если бы у рыб был мех, то там водились бы блохи. Расходятся все с таких собраний обычно чувством глубокого недоумения.
Edited Date: 2020-02-16 10:54 am (UTC)

Date: 2020-02-16 03:22 pm (UTC)
dmm: (Default)
From: [personal profile] dmm
Это вообще часто так бывает - уроды хотят захватить власть (или просто заработать), и их не волнует какой будет ущерб, и останется ли вообще что-нибудь. Agile - это просто частный случай (Вит много писал про их "бизнес-модель" - чаще всего это всё варианты на тему "украсть и убежать", но если удастся некоторое время посидеть над всем этим до того, как придётся бежать, это ещё лучше.)

Я вот видел, как большой человек истребил где-то 20 миллиардов долларов, но свои 30 миллионов в клюве унёс (оказывается, если правильно подойти к делу такого истребления, можно так пристроиться, чтобы формулы контракта показывали, что причитается бонус).

Date: 2020-02-16 06:22 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
Это называется утилизация или рейдерский захват - устроить пожар в доме, чтобы вынести золотое кольцо. Все 90-е в РФ - это ровно то же самое.

Date: 2020-02-16 04:21 pm (UTC)
dmm: (Default)
From: [personal profile] dmm
В частности, главной целью покупки-продажи любой организации обычно является попилить бонусы, связанные с такой транзакцией, причитающиеся руководству обоих организаций, участвующих в процессе. Если бы можно было каждый день одно и тоже подразделение приобретать, потом продавать, и каждый день собирать бонус, это бы им всем нравилось больше всего...

Date: 2020-02-17 02:22 am (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
> Секрет состоит в том, что скрам был придуман для интерфейсов, и для обсуждений уровня "юзер просит подвинуть вот эту кнопку". Для таких команд скрам - самое оно.

Может быть Vit и скажет что-то гадостное, но этот самый Скрам пришёл из toyota production - то есть, из конвейера сборки машин. То есть, повторяющегося, отлично предсказуемого дела. Это разительно отличается от разработки, т.к. в разработке, в идеале, каждый кусок делается один раз, а риски очень велики. Нет смысла писать 333 имплементации парсера компилятора.

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

Поскольку продукт никому не нужен, то начинаются менеджерские игры, в которых желательно уйти от ответственности. А Agile предоставляет все возможности сделать это.
Edited Date: 2020-02-17 02:23 am (UTC)

Date: 2020-02-17 05:51 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
> Во-вторых, у фирмы Toyota есть опыт разработки (те же гибриды) и, в отличие от конвейера, информация по ним засекречена.

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

> Так что это не "пришёл из".

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

То есть, элементы Toyota Production System, например "любой участник процесса при обнаружении ошибки конвейер останавливает" очень разумно взять. А нарезку на 2 недельные спринты, планирование на отрывных билетиках (Jira) и прочее брать не надо.

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

Date: 2020-02-17 10:47 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
> Насчёт того, что все понимают всё - это очень оптимистичный взгляд.

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

> И почему у них инженеры от переработки помирают.

Как гипотеза - одновременное сочетание серьёзной ответственности и "гибких методологий". То есть, люди настроены на результат, и готовы добиваться его любой ценой + частые переключения контекста, огромное количество совещаний.

Date: 2020-02-16 06:27 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
> ну вот моё неформальное впечатление, что agile бывает разный, что scrum - самый частый, и наименее подходящий для серьёзных проэктов с высокой сложностью софта с длинными циклами...

То, что вы описываете, напоминает попытки сделать конвейер. Разработка сложных систем, тем более в софте - это так или иначе R&D (система делается в более-менее одном экземпляре). То есть, agile в данном случае - это попытки завернуть гвоздь в стену отвёрткой.

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

> самоуправлении инженеров в небольшой компетентной команде

Это "хирургическая бригада" Брукса.

Date: 2020-02-15 10:56 pm (UTC)
From: [personal profile] jamhed
Это говорит только о том что вас там не было.

Date: 2020-02-16 06:20 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
> как Вит предлагает "брать власть" в такой ситуации

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

> что почто все компетентные люди сбежали

Те, кто не сбежал, со временем теряют способность к концентрации и продуктивному труду. В этом большая проблема.

Date: 2020-02-16 06:31 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
> Вариантов масса. Вплоть до "нам срочно нужно функциональное программирование".

Да. То есть, локальный захват власти в маленькой scrum группе, а не на уровне организации.

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

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

Date: 2020-02-16 09:41 pm (UTC)
ext_646638: (Default)
From: [identity profile] rdia.livejournal.com
Ну весь проект спасти и не было нужно - это почти монополист, завалится очень нескоро. Коллега успешно прокурировал один большой подпроект. Там не было ничего сложного, просто занудное ведение "бухгалтерии". Но, по-факту, он изобрёл нечто вроде сетевого графика (project network), в рамках которого направлял усилия других хомячков.

Date: 2020-02-15 04:09 pm (UTC)
From: [personal profile] jamhed
Не может, на то есть scrum master, за порядком следить. А product owner быстро объяснит что является приоритетом.
Edited Date: 2020-02-15 04:10 pm (UTC)

Date: 2020-02-15 04:57 pm (UTC)
From: [personal profile] jamhed
Скрам-мастеру суть видеть не положено, ему положено следить за тем что бы на митингах были кто надо, и обсуждения протекали определенным образом, их этому специально обучают. Вот если народ обсуждать отказывается, тогда у скрам-мастера проблема, но и тогда у него есть пара тузов в рукаве. Наука это нехитрая, и работает по площадям.

Date: 2020-02-15 06:07 am (UTC)
From: (Anonymous)
Из "двух циклов Обратной связи" делаю предположение, что речь о Scrum.

Хотите посмотреть на вариант, где этих циклов семь?
Посмотрите на Канбан-метод (современный, для разработки ПО, David J. Anderson, Kanban University).

И да, он не имеет прямого отношения к Agile, поскольку сосредоточен не на "гибкости", а на решении реальных задач.

Date: 2020-02-17 10:20 am (UTC)
From: (Anonymous)
Очень интересно узнать про оригиналы. Особенно про оригинал Scrum.

Profile

vit_r: default (Default)
vit_r

January 2026

S M T W T F S
    12 3
45678910
11121314151617
18192021222324
25262728293031

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 5th, 2026 12:24 pm
Powered by Dreamwidth Studios