В дебрях водопада
Feb. 14th, 2020 09:43 amЕсли контора говорит, что документировать не надо, или что на документацию нет времени, то это значит, что менеджмент не контролирует процесс настолько, что боится его увидеть. Пока всё "в головах" и вместо документации "это просто запомнить", невозможно наглядно продемонстрировать общее состояние дел. В принципе, это основная причина того, почему менеджмент вводит agile.
И просто отмечу для истории. На днях разобрался с agile. Понял, что в схеме должно быть не два, а четыре цикла.
С одним забытым откровенно лопухнулся. Просто сосредоточился на технической стороне дела, забыв, что фирма продаёт клиенту не решение, а мечту о решении.
Второй забытый тоже не учитывал за ненадобностью, но понаблюдав за потайными дискуссиями
kdanilov и
dennisgorelik всё-таки решил, что самоочевидное тоже должно быть описано. Потому как без него совершенно непонятно, почему люди в этом участвуют.
Рабочее название: The Cycle of Self-Satisfaction
И просто отмечу для истории. На днях разобрался с agile. Понял, что в схеме должно быть не два, а четыре цикла.
С одним забытым откровенно лопухнулся. Просто сосредоточился на технической стороне дела, забыв, что фирма продаёт клиенту не решение, а мечту о решении.
Второй забытый тоже не учитывал за ненадобностью, но понаблюдав за потайными дискуссиями
Рабочее название: The Cycle of Self-Satisfaction
no subject
Date: 2020-02-14 06:40 pm (UTC)no subject
Date: 2020-02-14 06:52 pm (UTC)no subject
Date: 2020-02-15 04:41 am (UTC)Agile, с его унизительными спринтами, скрамами, и scrum masters, и уничтожением любых разумных показателей эффективности, заменяемых на процент тикетов, запланированных на данный спринт, которые были закрыты в этот спринт, - он даёт недвусмысленный ответ на этот вопрос - власть в таких организациях полностью принадлежит менеджерам, сильные специалисты не значат ничего, и все низведены до состояния прыжков через обруч. Последствие состоит, конечно, в том, что это - власть над руинами.
no subject
Date: 2020-02-15 09:05 am (UTC)no subject
Date: 2020-02-15 01:58 pm (UTC)Так что я не очень пониманаю, как тут можно "перехватить власть в agile-ритуалах", когда власть состоит в том, чтобы смотреть снаружи в клетку зоопарка, в которой занимаются agile-ритуалами, но самим в них не участвовать.
no subject
Date: 2020-02-15 02:53 pm (UTC)no subject
Date: 2020-02-15 03:11 pm (UTC)Если не отличается, то её не очень-то хочется получать, хочется держаться в стороне, по возможности...
no subject
Date: 2020-02-15 04:16 pm (UTC)no subject
Date: 2020-02-15 04:51 pm (UTC)Я видел ситуации полуанархии, и там никакой особой власти не было, и видел ситуации, когда был пахан, который пытался наежать (всё зависело от того, кто был 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"
no subject
Date: 2020-02-15 05:07 pm (UTC)Само собой, при всей примитивности scrum (а может быть и поэтому) его часто применяют неправильно, вводя элементы и роли скрамом не предусмотренные, а часто и прямо противоречащие. Называется это подгонкой скрама под нужды заказчика. Потом, есть тонкое, но важное различие: agile это идеология, а scrum -- project management framework, можно быть agile и без скрама, и наоборот.
> я не очень понимаю, как Вит предлагает "брать власть"
Единственный способ "брать власть" это становится product owner, но тут есть засада -- product owner программировать сам не может, ему религия scrum запрещает, такие вот вилы. Отдельно взятые личности могут попытаться саботировать скрам устраивая дискуссии и требуя документации, но таких к ногтю приводят очень быстро: типа как команда решит, так и будет, а product owner помогает процессу приоритетами задач.
Собственно все управляющее воздействие в скраме исключительно через роль секретаря собраний (scrum master/product owner), не все менеджеры это понимают и не все к этому готовы, поэтому типично видеть сову натянутую на глобус, как вы описываете.
no subject
Date: 2020-02-15 05:31 pm (UTC)что, вообще говоря, 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"))...
no subject
Date: 2020-02-15 06:06 pm (UTC)extreme programming - это, вообще, дурь. В неформальном общении основатель... Ладно, не буду портить людям бизнес..
no subject
Date: 2020-02-15 07:14 pm (UTC)но у нас ничего такого не было; никакого 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...
потом, когда её продали большой бяке, всё потихоньку испортилось...
no subject
Date: 2020-02-15 11:01 pm (UTC)no subject
Date: 2020-02-16 08:42 am (UTC)Если собрать группу людей и попросить их придумать как организовать работу распределенных команд, то с большой степенью вероятности они придумают что-то подобное сами (типа всю жизнь разговаривал прозой).
Как видим, про управление в скраме ничего нет, и быть не может, по определению. Что вызывает когнитивный диссонанс у корпоративных менеджеров, типа как же так, жопа есть, а слова нет. Поэтому скрам превращается в тыкву: роли становятся должностями, заводятся другие сущности типа tech lead и product manager, а сам скрам используется как средство управления, так как других не завезли.
Что еще хуже, внезапно появились тысячи людей, которые к разработке никогда никакого отношения не имели, но с ценным мнением как именно надо разрабатывать, все эти scrum/agile коучи и тренеры. Которые проводят тренинги рассказывая по 3 дня про первый абзац этого комментария в мельчайших деталях создавая ложное впечатление тайного знания. Которого там нет и быть не может.
И еще хуже (казалось бы куда, но дна там нет), если людей, которые понятия не имеют о чем все это, посадить на соответствующие должности и дать в руки этот "framework", то они начнут придумывать оправдания и улучшения именно своей деятельности, устраивать профессиональные собрания, делиться хитростями и придумками, статьи писать, и так далее. В итоге компетентные люди, как вы пишите, разбегаются потому что работать невозможно, так как нехитрый набор разумных практик превратился в непроходимую бюрократию: чтобы изменить одну строчку кода надо непременно задачу в баклог, и обсудить на общем собрании жильцов нашего дома, потом нагородить к ней еще десять, и еще раз обсудить, и только потому что всем этим прекрасным людям заняться больше нечем.
Вопрос вот только куда бежать компетентному разработчику.
no subject
Date: 2020-02-16 09:06 am (UTC)Секрет состоит в том, что скрам был придуман для интерфейсов, и для обсуждений уровня "юзер просит подвинуть вот эту кнопку". Для таких команд скрам - самое оно.
А если надо делать компилятор, или search engine - ну какой тут может быть скрам (если конечно хотеть, чтобы что-то вообще было сделано).
***
У нас люди сначала разбежались (начальство постаралось), потом удалось как-то опять собрать разумную команду, а уж потом они это дело ввели, и тут плохая ситуацию превратилась во вполне катастрофическую (legal disclaimer above, etc.)
Но, вообще, если затевать новый бизнес, надо прямо в чартер записывать, что некоторые вещи запрещены, и что попытка протолкнуть agile рассматривается, как попытка дезорганизации работы, и за неё сразу следует увольнение (и под расписку всем новым сотрудникам).
И хорошо бы так сформулировать, чтобы компанию нельзя было продать без некоторых гарантий, что получившееся подразделение будет защищено от таких вещей (по крайней мере, сколько-то времени).
no subject
Date: 2020-02-16 10:51 am (UTC)А про юзеров это у них (scrum/agile coaches) любимая песня, особенно смешно когда они это рассказывают людям у которых ярко выраженных пользователей нет (типа network operations center). Все как в анекдоте, если бы у рыб был мех, то там водились бы блохи. Расходятся все с таких собраний обычно чувством глубокого недоумения.
no subject
Date: 2020-02-16 03:22 pm (UTC)Я вот видел, как большой человек истребил где-то 20 миллиардов долларов, но свои 30 миллионов в клюве унёс (оказывается, если правильно подойти к делу такого истребления, можно так пристроиться, чтобы формулы контракта показывали, что причитается бонус).
no subject
Date: 2020-02-16 06:22 pm (UTC)no subject
Date: 2020-02-16 04:21 pm (UTC)no subject
Date: 2020-02-17 02:22 am (UTC)Может быть Vit и скажет что-то гадостное, но этот самый Скрам пришёл из toyota production - то есть, из конвейера сборки машин. То есть, повторяющегося, отлично предсказуемого дела. Это разительно отличается от разработки, т.к. в разработке, в идеале, каждый кусок делается один раз, а риски очень велики. Нет смысла писать 333 имплементации парсера компилятора.
Это соображение, в общем, очевидно. И единственное объяснение, которое я нахожу - контора/отдел дошёл до состояния, когда наличие/отсутствие продукта никого не ебёт. Это может быть монополия, отдел на дотации или ещё что-то подобное. Могут быть какие-то хитрые попильные схемы с подрядчиком. Может быть отсутствующий/насыщенный рынок.
Поскольку продукт никому не нужен, то начинаются менеджерские игры, в которых желательно уйти от ответственности. А Agile предоставляет все возможности сделать это.
no subject
Date: 2020-02-17 06:29 am (UTC)Во-вторых, у фирмы Toyota есть опыт разработки (те же гибриды) и, в отличие от конвейера, информация по ним засекречена.
no subject
Date: 2020-02-17 05:51 pm (UTC)Ну, надо сказать, мы знаем, каково качество разработки программных решений Toyota. Так что ещё не известно, есть ли смысл копировать это.
> Так что это не "пришёл из".
Я про то, что основная идея полностью идиотская. Это как взять превосходный корабль и делать по его образу и подобию самолёт. Да, какие-то элементы можно взять, но не более - разработка ПО и сборка автомобилей отличаются кардинально по результатам.
То есть, элементы Toyota Production System, например "любой участник процесса при обнаружении ошибки конвейер останавливает" очень разумно взять. А нарезку на 2 недельные спринты, планирование на отрывных билетиках (Jira) и прочее брать не надо.
И самое печальное, что все всё понимают, но крутятся в колесе игры, фрагмент платёжной матрицы которой вы в своё время нарисовали. У меня до сих пор в закладках тот пост висит.
no subject
Date: 2020-02-17 06:49 pm (UTC)Насчёт того, что все понимают всё - это очень оптимистичный взгляд. Причём, чем выше по иерархии и чем ближе к центрам принятия решений, тем понимания меньше. Благо, сейчас разработано много тулов, предоставляющих прекрасную отчётность.
no subject
Date: 2020-02-17 10:47 pm (UTC)У нас очень камерный отдел, всё видно, если захотеть. И, надо сказать, начальство жопой чувствует, но вербализовать не может.
> И почему у них инженеры от переработки помирают.
Как гипотеза - одновременное сочетание серьёзной ответственности и "гибких методологий". То есть, люди настроены на результат, и готовы добиваться его любой ценой + частые переключения контекста, огромное количество совещаний.
no subject
Date: 2020-02-18 07:41 am (UTC)no subject
Date: 2020-02-16 06:27 pm (UTC)То, что вы описываете, напоминает попытки сделать конвейер. Разработка сложных систем, тем более в софте - это так или иначе R&D (система делается в более-менее одном экземпляре). То есть, agile в данном случае - это попытки завернуть гвоздь в стену отвёрткой.
Причём это более-менее самоочевидно для людей, занимавшихся разработкой софта. Значит, если они продвигают agile, их жизнь не зависит от продукта в среднесрочной перспективе.
> самоуправлении инженеров в небольшой компетентной команде
Это "хирургическая бригада" Брукса.
no subject
Date: 2020-02-15 06:07 pm (UTC)Нет, конечно.
В условиях отсутствия измеримых целей ловить рыбку в мутной воде может любой участник процесса.
no subject
Date: 2020-02-15 10:56 pm (UTC)no subject
Date: 2020-02-16 09:57 am (UTC)no subject
Date: 2020-02-16 06:20 pm (UTC)В рамках scrum-группы вполне можно задавать дебильные задачи и заставлять всех бегать в беличьем колесе.
> что почто все компетентные люди сбежали
Те, кто не сбежал, со временем теряют способность к концентрации и продуктивному труду. В этом большая проблема.
no subject
Date: 2020-02-16 06:27 pm (UTC)no subject
Date: 2020-02-16 06:31 pm (UTC)Да. То есть, локальный захват власти в маленькой scrum группе, а не на уровне организации.
Кмк, это происходит от того, что в среднесрочной перспективе всем насрать на результат - у менеджерской пирамиды свои игры, а толковый сеньор разработчик не заинтересован в ведении проекта "подпольными методами", т.к. так можно легко заработать выгорание (из-за адских кол-в совещаний происходит много переключений контекста, что тяжело для психики).
Я, собственно, наблюдал, как коллега чуть себе это выгорание не заработал. С тех пор занимается фигнёй.
no subject
Date: 2020-02-16 06:52 pm (UTC)no subject
Date: 2020-02-16 09:41 pm (UTC)no subject
Date: 2020-02-15 04:54 pm (UTC)no subject
Date: 2020-02-15 04:09 pm (UTC)no subject
Date: 2020-02-15 04:50 pm (UTC)product owner - это магический элемент.
no subject
Date: 2020-02-15 04:57 pm (UTC)no subject
Date: 2020-02-15 06:07 am (UTC)Хотите посмотреть на вариант, где этих циклов семь?
Посмотрите на Канбан-метод (современный, для разработки ПО, David J. Anderson, Kanban University).
И да, он не имеет прямого отношения к Agile, поскольку сосредоточен не на "гибкости", а на решении реальных задач.
no subject
Date: 2020-02-15 09:06 am (UTC)Нет, конечно.
И scrum, и kanban -- это изложение оригиналов людьми, которые скопировали ритуалы, но не поняли смысл. Обычный карго-культ.
no subject
Date: 2020-02-17 10:20 am (UTC)