Всем привет. Меня зовут Рома, я-разработчик. За короткое время, в одной команде, на одном проекте, я поработал в трёх разных вариациях скрама. Ощущались они по-разному, и каждый новый вариант нравился мне меньше предыдущего. В этой статье я поделюсь своим опытом и выводами.
Дисклеймер
Эта статья не имеет под собой надёжной основы. Думайте о ней как об эвристике, результате субъективного анализа личного негативного опыта.
Я намеренно абстрагировался от проекта. Вместо этого я сосредоточусь на своих мыслях и ощущениях. Я сделал так по нескольким причинам:
У меня недостаточно опыта, чтобы оценивать управленческие решения.
Моя точка зрения субъективна.
Статья имеет негативный оттенок. Я не хочу никому навредить, а также не хочу ни от кого зависеть при её написании.
Условия на проекте и опыт читателя всё равно будут отличаться от моих.
Забегая вперёд, скажу что источник проблем я нашёл за пределами проекта.
Рефлексирую
Вот несколько мыслей и ощущений которые у меня возникали. Так я попытался описать дискомфорт, который чувствовал в процессе работы, после того как начались изменения.
На место настоящих инструментов пришли суррогаты, которые не выполняют свою функцию, и единственная причина их существования — формальное удовлетворение требований скрама. Ни один из них меня не устраивает, но сделать с ними я ничего не могу.
Разговоры о скраме выглядят шаблонно, люди используют одинаковые слова и бывает произносят их в одинаковом порядке. Коллеги которые прошли сертификацию чеканят определения как по бумажке слово в слово. При этом в разных компаниях и у разных команд результаты работы разные. Даже у меня на одном проекте было несколько разных интерпретаций скрама и результаты сильно отличались. Из-за этого я ощутил что не могу отличить опытных людей от тех, кто только пытается казаться таким.
Скрам мастера и коучи не помогают мне решать проблемы. Если попытаться добиться от них чётких шагов для решения проблемы поделившись симптомами, они начинают уходить от ответа или выдают в качестве отписки неадаптированную или вообще рандомную практику и предлагают пробовать. Мне не подходит то, что они предлагают. Общение заканчивается когда я теряюсь и не могу больше задавать вопросы, а не когда моя проблема решена.
Я не могу воевать с группой из нескольких десятков человек, которая ещё и владеет правилами игры. Да и нужно ли? Возможность влиять на процессы формально декларируется, в реальности мне недоступна. Меня просто сминают сложность и неопределённость, помноженные на скорость изменений.
Я потерял контроль над своим компонентом, но получил титул владельца исходного кода этого компонента. Когда титула не было, контроль был. Часть процессов была целенаправленно деконструирована, в рамках трансформации, остальное обвалилось следом.
Я проваливаю задачу за задачей. То что нужно проекту, и то что я умею окончательно перестало пересекаться, я больше не на своё месте.
Распад мотивации. Я больше не приношу пользу но трачу ресурсы и не могу с этим ничего сделать. Я это понимаю, люди вокруг это понимают, но ничего не меняется. Так не может вечно продолжаться.
Положившись на веру в пользу изменений, я сам приложил руку к уничтожению того, что считал важным. И теперь сожалею об этом.
Анализирую
В общем с проекта я капитулировал. Но я решил не забывать об этом опыте и извлечь из него пользу. Деваться от скрама всё равно некуда, рано или поздно я снова с ним столкнусь. Отчётливее всего я ощутил поддельность новых процессов, они выглядят как процессы, задуманы как часть фреймворка и даже как-то взаимосвязаны. Тем не менее, я недоволен. Я считаю, что они не выполняют свою функцию, а поскольку сломанные элементы ещё связаны друг с другом, проблемы в одном элементе начинают влиять на другой элемент, в котором есть ещё и свои проблемы, окончательно запутывая ситуацию. Почему я не могу отделаться от ощущения что я, все эти профессиональные разработчики вокруг меня, архитекторы, менеджеры, скрам-мастера и коучи, что вся наша работа мало того что не приносит пользы, а может и приносит вред?
Иногда я прокручивал в голове те или иные воспоминания, между делом, когда нечем было заняться. Спустя где-то полгода после увольнения, идя по улице, я думал и пытался найти причину моего дискомфорта. Я так делал и раньше но не мог ни за что зацепиться. Но в этот раз, вместе с ощущением поддельности процессов, пустой оболочки вместо настоящего инструментария, в голове всплыла фраза: «Вы можете изменить компоненты скрама но результат такой модификации скрамом являться не будет». Так говорят, когда при внедрении скрама команда понимает что он им не до конца подходит и предлагает изменить его. Коучи, во время обучения, делали ударение на том, что скрам это фреймворк, не методология управления, не подход а именно фреймворк, в таком виде это можно прочитать в скрам-гайде. Это считается очень важной деталью и подаётся с особым акцентом. Здесь что-то не так. Где вы видели чтобы в другом настоящем программном фреймворке было так написано? И звучало бы это как-то так: «Да вы можете использовать не все модули Spring в своём приложении или изменить их, но такое приложение считаться Spring-приложением не может». Это же бред! В этом что-то есть но пока непонятно что.
Прошло ещё несколько дней, я снова вернулся рассуждению, и следом пришла мысль: «Эта фраза звучит знакомо, я её слышал раньше, про что ещё так можно сказать?». Так говорят про стандарты. Если думать о скраме, не как о фреймворке, а как о стандарте, то многое встаёт на свои места: «Вы можете изменить детали реализации своих процессов, отойдя от стандарта скрама, но тогда ваши процессы не будут считаться реализацией скрама». Теперь это имеет смысл. Процессы не становятся хуже или лучше если отойти от скрама, они просто перестают быть скрамом. Вот она, нестыковка которая мне не давала покоя. Несмотря на то что в скрам гайде написано что скрам это фреймворк, несмотря на то что коучи делали особый акцент на то что скрам это фреймворк, несмотря на то что все вокруг считают его фреймворком и используют как фреймворк, скрам не ведёт себя как фреймворк. Он ведёт себя как стандарт. Тот у кого недостаточно опыта с программными фреймворками и стандартами ни за что не ощутит разницу между этими концептами в контексте неформального взаимодействия между людьми. Я считаю именно эту ошибку в определении главной ложью скрама. Когда люди пытаются использовать стандарт как фреймворк единственное что они могут это следовать за нормами стандарта упуская из виду реализацию. Так, по моему мнению, и возникает карго-культ.
Делаю выводы
На что же может повлиять ошибка в определении скрама? Это изменение заставило меня взглянуть под новым углом на многие вещи, которые доставляли мне дискомфорт. Я совершенно по-другому построил бы своё поведение, вместо поддержки изменений и слепой веры в их пользу, я бы активно сопротивлялся. Даже если бы из этого ничего не вышло, я бы потратил меньше ресурсов, своих и чужих, впустую. Дальше я опишу отдельные детали которые встали на своё место после обнаружения источника проблем.
Когда я листал скрам-гайд, я испытывал ощущение что с ним что-то не так. Когда читаешь что-то что называется гайд, ожидаешь описание последовательности действий, и эта последовательность должна приводить к воспроизводимому положительному результату. Как гайд по рпг, где написано какие статы и скиллы нужно прокачать, а также как ими пользоваться чтобы тащить. А в скрам-гайде нет никакой последовательности действий, там только перечисление концептов скрама, их определений и взаимосвязей. Это не имело смысла, до мысли о том что скрам это не фреймворк, а стандарт. У стандартов нет гайдов, у стандартов есть спецификации. Неважно как именно ты реализуешь стандарт, важно чтобы твоя реализация удовлетворяла спецификации. Скрам-гайд вводит читателя в заблуждение ещё до того как тот его откроет. Скрам-гайд это не гайд по скраму, это не гайд к скраму, это вообще не гайд, это спецификация стандарта «SCRUM».
Переформулирую определение скрама, чтобы оно совпадало с тем что получилось у меня. Скрам - это стандарт, который сложился у команд, работавших над тем чтобы приносить больше ценности через адаптивные решения для сложных проблем. Я пришёл к выводу что спецификация стандарта без информации о том как была достигнута его реализация практически бесполезна при построении процессов. Под видом гибкости фреймворка мы получаем неопределённость реализации, ограниченную рамками стандарта.
Скрам, по принципу работы, напомнил мне интерфейс в языках программирования. Он формализует внешний контракт, на который удобно завязываться внешним компонентам, будь то руководители, менеджеры, скрам-мастера, другие команды или что-то ещё. Поэтому он им так нравится. При этом, внутренняя реализация остаётся неопределённой, при неумелом обращении это делает его бесполезным и обременяющим для инженеров.
Структура скрам гайда выглядит иронично. Авторы рассказывают о том что скрам основан на эмпирическом подходе, о том что знания происходят из опыта, об итеративности и сборе знаний в процессе работы, как всё это важно. А потом берут и декларативно описывают концепты скрама, игнорируя путь, который привёл к формулированию этих концептов. Какие ошибки привели к появлению того или иного артефакта? Какие пробемы могут возникнуть в ходе реализации артефакта? Как их избежать? Ничего из этого в «гайде» нет. Можно понять почему так сделано, ведь проекты разные и пути будут разные, непонятно какой толк в таком «гайде». Я напираю на скрам-гайд, но и другие книжки по скраму, в которые я заглядывал, структурированы так же.
Скрам-гайд толкает читателя на неправильный путь, подменяя индукцию (выявление отдельных проблем, и построение обобщённого решения) на дедукцию (выделение отдельных шагов из обобщённого решения которое когда-то привело другую команду к успеху).
Аджайл-коучи и скрам-консультанты это не наставники, они не учат строить скрам, они продают стандартизацию под видом улучшения. Эти ребята с радостью помогут откинуть все старые процессы и заменить их суррогатами, их совершенно не волнует то как ты будешь работать в новых условиях и сможешь ли вообще, это не их проблемы а твои. Их критерий успеха — соответствие процессов стандарту скрама а не нуждам команды. У меня сложилось впечатление что аджайл-коучей используют не для помощи в переходе от старого к новому а для создания повода к такому переходу. И метод создания такого повода заключается в принуждении через уничтожение альтернатив. Когда речь идёт о коуче (тренере) ожидаешь что он научит тебя тому чего тебе не хватает для работы Приведу в пример плавание: учитель научит держаться на воде, расскажет о разных техниках, подберёт самую простую, будет страховать во время практики. Коуч же учит плавать выбрасывая из лодки. После чего он будет, сидя в лодке, предлагать тебе практики в надежде что ты с их помощью адаптируешься к новым условиям и выплывешь сам. Я не адаптировался. Мне не следовало позволять выкидывать себя из лодки.
Скрам-мастер, не совмещающий эту роль с какой-либо другой прикладной ролью, это не помощник. Скрам-мастер не помогает работать по скраму, он следит чтобы процессы, по которым работает команда, оставались скрамом. Он не расширяет возможности новыми инструментами а ограничивает их рамками стандарта. Такой человек с радостью введёт 15 минутное ежедневное дейли и будет следить чтобы лимит времени не был превышен. Будет ли это событие полезно - не его проблема. Он профасилитирует любую встречу но не поможет добиться цели этой встречи, если команда не справляется. Фасилитация будет заключаться в следовании стандартному шаблону этой встречи. Проблем добавляет название роли, если в русском языке мастер означает профессионал, знаток своего дела то в оригинале это повелитель, господин, в общем это человек навязывающий свою волю. Я долго думал каким же словом лучше заменить master. Ни английское master ни русское мастер, по моему мнению, не отражают сути. В итоге я остановился на слове арбитр. Проведу аналогию с футболом. Если тимлид, архитектор и менеджер(нацеленный на качество) это тренеры и такие люди могут научить полезным именно тебе приёмам, продумать тактику и стратегию, а главное тренер работает в интересах команды, ему важна победа, то скрам-мастер это арбитр, он следит чтобы никто не трогал мяч руками, назначает пенальти, объявляет перерыв, ему плевать победит твоя команда или нет. Если тренеру дать команду шахматистов он научит их играть в футбол, после работы с ним они станут намного сильнее чем были раньше, арбитр же заставит их играть по правилам и на этом всё. Поэтому команде которая справляется отдельный скрам-мастер не нужен, а команде которая не справляется он не поможет.
На курсах скрам-мастеров похоже не учат работать по скраму, вместо этого студентов стандартизируют. И когда ученик зазубрит спецификацию, в знак соответствия стандарту, он получит сертификат. Решать проблемы после этого он лучше не начнёт.
Я часто встречал фразу о том что в скраме тимлиды не нужны, ведь описании «фреймворка» их нет, есть только команда разработки. Это выглядит странно, работу тимлида нельзя выкинуть, он останется сильным разработчиком с опытом в управлении и будет использовать эти навыки на пользу команде и будет сильно влиять на успех, возможно этот человек и является создателем проекта. Но если думать о скраме как о стандарте, то ситуация выглядит иначе. Скрам как стандарт не регламентирует наличие тимлида в команде, это не означает что тимлида в команде не должно быть, это значит что тимлид существует вне контектста скрама, одновременно с командой разработки. Если команда разработки это консепт внешнего контракта скрама то тимлид это элемент внутренней реализации этого контракта, именно на его плечах держится большая часть работы позволяющей продакт овнеру и скрам-мастеру абстрагироваться от деталей состава команды.
Говорят что скрам это одна из штук которые легко освоить но тяжело овладеть в совершенстве. Если же держать в голове что скрам это стандарт, то всё выглядит иначе. Профессионалом ты становишься после того как целиком зазубрил стандарт. Всё, после этого можно претендовать на позицию скрам-мастера и успешно работать. Беда в том что этих знаний недостаточно для того чтобы построить процессы. Именно эта неточность выглядит как владение скрамом не в совершенстве. Знания по решению проблем уже не входят в предметную область стандарта скрама. Это навыки тимлида/архитектора/менеджера. Теперь мне понятно откуда вокруг так много скрам-мастеров занимающихся только скрамом и почти не выходящих за его пределы.
Чтобы построить хорошие процессы не нужно строить скрам, нужно решать проблемы. И через какое-то время сверившись со скрам-гайдом обнаружить что получился скрам (или не получился, ведь цель была не в нём).
Комментарии (162)
First_Light
10.02.2022 16:51+36Вангую вал коментов в стиле "Да у тебя просто нормального SCRUM-мастера не было!".
rustler2000
10.02.2022 17:09+10Как на скраме можно проваливать задачу за задачей? 100 пудов микромэнеджмент кто-то внедрил - был вотерфол сдал вотербординг.
yatsenko-ihor
11.02.2022 00:39+4что то у 90% знакомых так же. Видимо "тяжело найти, легко потерять и невозможно забыть"
RhelasTgav
10.02.2022 17:15+41Фраза про карго-культ крайне уместна. При всём моём уважении к набору инструментов Agile это превратилось действительно в культ, а на коучей у меня вообще аллергия выраженная.
Товарищь Мартин (который Боб) очень хорошо в своём чистом Agile описал ситуацию с сертификацией коучей и т.п., в двух словах - мракобесие.
Придумайте звездолёт и сразу появится армия коучей, которые за большую сумму научат вас как правильно им управлять
Throwable
11.02.2022 12:59+6Придумайте звездолёт и сразу появится армия коучей, которые за большую сумму научат вас как правильно им управлять
Дело в том, что в итоге они не научат вас управлять звездолетом, но предложат свой "концептуальнй процесс обучения управлению звездолетом", благодаря которому каждый сможет стать пилотом. А на претензии типа почему мой звездолет до сих пор не летает, всегда есть ответ, что проблема в вас, ибо вы неправильно следовали этому процессу.
spacediver
11.02.2022 15:34Тут недавно вспоминали про Clubhouse, так там всё это быстренько прокрутилось за полгода, что ли))
sn00p
10.02.2022 17:20+42Чуть больше конкретики не помешало бы. Например,
"На место настоящих инструментов пришли суррогаты". Что за инструменты, какие были, какие стали, на основании каких признаков сделан соответствующий вывод.
"Разговоры о скраме выглядят шаблонно, люди используют одинаковые слова и бывает произносят их в одинаковом порядке. Контекст вообще неясен. Зачем об этом разговаривать вообще. Есть спринт, есть задачи, их надо делать, проставлять пометки соответствующие. В каком месте тут появляется разговор и для чего вообще. Необязательно знать, как устроена машина, чтобы на ней ездить. А кондуктору в автобусе необязательно знать устройство ДВС для выполнения своих обязанностей.
" Скрам мастера и коучи не помогают мне решать проблемы". Какого рода проблемы тут могут возникать, это проблемы организации процесса или самого процесса или чего проблемы. От участника процесса ничего не требуют в целом, кроме выполнения задач в спринте, или у вас не так?
"Я не могу воевать с группой из нескольких десятков человек, которая ещё и владеет правилами игры". Почему вообще настала необходимость воевать, а не договариваться? Виноват ли скрам, что вы не хотите или не умеете работать в команде?
-
"Я потерял контроль над своим компонентом". У вас командная разработка или индивидуальная? Про какой контроль идет речь? Если исходный код компонента лежит в общем доступе, это достаточный контроль или какой еще нужен?
И самое главное, как вы раньше-то работали. Как стало понятно, а как было? Заголовок кликбейт, в статье про это вообще ничего нет, кроме того, что вам кажется. Без конкретики это какой-то клуб джентльменов получается.
Совет, если текст статьи прогнать через спеллчекер, он будет читаться полегче.
nick1612
11.02.2022 02:02+5Справедливые замечания, но если не слишком придираться, то посыл автора понятен и относится не только к "скаму", а к любым внедрениям разных методологий разработки, в надежде на то, что это автоматически приведет к желаемому результату. В отрыве от контекста и конкретной команды людей, попытка топорного внедрения практик, которые выработались в совершенно другой команде, как минимум выглядит странно. Вообще не факт, что выделенные подходы и практики не являются просто побочными элементами процесса и сами по себе ничего не стоят.
По моему субъективному мнению - "Кадры решают все!". Если у вас получилось собрать слаженную команду, то можно выбирать что угодно - cкрамы, аджайлы, канбаны и рассказывать как хорошо это работает. А если у вас в команде все плохо, то тупые "внедрения" врядли исправят проблему. Как говорилось в известной басне:
"А вы, друзья, как ни садитесь, все в музыканты не годитесь" (c)
Хотя, как во всем, здесь бывают исключения, но на то они и исключения)
nagaevr Автор
11.02.2022 09:31+6Я намеренно убрал конкретику, когда начинаешь описывать детали процессов, они тянут друг-друга за собой. В итоге у меня получалось подробное описание процессов проекта, а это не то чем я хотел поделиться. Кроме того после описания процессов, следовало бы их проанализировать и найти ошибки а я не могу этого сделать. Я заметил что мой анализ скатывается в необоснованные обвинения и отказался от этого. Проблемы на проекте это повод задуматься, причина в стойком ощущении что со скрамом что-то не так.
На первый взгляд набор инстументов не изменился команды, дейли, ретро, планирование, беклог, это было до трансформации это никуда не делось после. В каждом инструменте зменилось что-то внутри, в качестве примера приведу команду. до трансформации это были люди собравшиеся вместе для решения конкретных задач, команду собирали тимлид и менеджер, мы понимали что делаем и зачем. В рамках трансформации же команды перетряхнули, для того чтобы добиться кроссфункциональности и на месте сработавшейся команды собравшейся по своей воле, появилась группа людей оказавшаяся вместе по случайности.
Моей основной проблемой было несоответствие моих навыков и желаний моей новой работе. Если бы мне предложили такие условия на собесе, я бы отказался.
Это подводка к мысли о том что скрам не определяет процесс работы, только отдельные ограничения. Да, не надо знать строение двс, но было бы неплохо знать что такое руль, педали, коробка передач, а также быть в курсе пдд. Нельзя просто посадить человека в машину и ждать что он доедет сам.
Когда ты единственный недовольный из нескольких десятков человек, это не ощущается как обсуждение проблем с людьми, это ощущается как противостояние коллективу. Как дёрнуть стоп-кран остановив поезд целиком. Так можно сделать но после этого придётся объясниться.
Я больше не могу класть задачи по компоненту в беклог(только на самое дно) я не мог выдвигать задачи на планирование, не мог брать их в спринт, я был занят чем угодно кроме того что умел.
за мысль о спеллчекере спасибо)
ApeCoder
11.02.2022 10:43+7Я намеренно убрал конкретику,
Без конкретики стало непонятно и поэтому неубедительно. Мы можем выбрать какой-то один аспект и разобрать?
Нельзя просто посадить человека в машину и ждать что он доедет сам.
В моем представлении скрам мастера должны быть инструктами по вождению. Куда ехать определяет команда, но как половчее переключать передачи может подсказать скрам мастер.
Когда ты единственный недовольный из нескольких десятков человек,
Вы были единственным недовольным, для остальных это работало, да?
Я больше не могу класть задачи по компоненту в беклог(только на самое дно)
То есть можете, но их приоретизацией (по гайду) должна заниматься команда в соответствии с ценностью, да?
я был занят чем угодно кроме того что умел.
Задач по вашей компетенции не было, они были низкоприоритетными или как?
Если встать на точку зрения владельцв продукта, вы бы так же приоретизировали?Можно специфический пример?
nagaevr Автор
11.02.2022 13:00+2я не предоставлю конкретику, в этом задумка статьи - абстрагироваться от событий, оставив только реакцию на них
в этом и дело, я тоже так думал, а мой опыт показал что скрам-мастер больше похож на инспектора дорожной полиции, он не учит водить он проверяет соответствие твоей манеры вождения общепринятому стандарту. а водить учит тимлид/архитектор/менеджер
у них получалось работать, выглядело так как будто им норм.
там сложнее получилось, реальное влияние на приоритеты было только у ПО. Человека который раньше получал пользу от моей работы не было среди них.
ума не приложу как бы я приоретизировал на их месте
ApeCoder
11.02.2022 13:15+1я не предоставлю конкретику, в этом задумка статьи - абстрагироваться от событий, оставив только реакцию на них
Васе больно
Почему? Петя агрессивно по мнению Васи себя повел
А что именно сделал Петя?
Не скажу
Как из таких сведений извлечь для себя какую-то пользу или хотя бы понять причины и следствия?
реальное влияние на приоритеты было только у ПО
По гайду за ПО последнее слово, но совещательный голос может быть у каждого. По гайду, ПО должен обхяснить цель продукта. Вы пробовали как-то аргументировать почему ваши PBI более ценны с точки зрения цели и надо делать их а не то, что выбрал ПО?
Lissov
11.02.2022 17:53реальное влияние на приоритеты было только у ПО. Человека который раньше получал пользу от моей работы не было среди них.
Это правильно. Вам зарплату платит не этот конкретный человек, а фирма, которая не считает нужным обеспечить ему пользу.
sn00p
11.02.2022 11:20+2Вот все, что вы описали, это не проблемы внедрения SCRUM\Agile.
Все, что вы описали - это ваше субъективное восприятие ситуации. Ваша зона комфорта разрушена, адаптироваться не получилось. Я так понимаю, поезд никакой не остановился, он просто поехал без вас, что вас совсем не устроило.
Попробуйте сменить фокус восприятия, он у вас смещен и из-за этого получаюются сплошные противоречия. Например,
"Я больше не могу класть задачи по компоненту в беклог(только на самое дно)".
превращается в
"Я могу класть задачи по компоненту в беклог, но меня не устраивает, что их приоритезируют подобным образом""На первый взгляд набор инстументов не изменился команды, дейли, ретро, планирование, беклог, это было до трансформации это никуда не делось после"
превращается в
"Инструменты работают, но применяются неправильно по моему мнению".
По идее хорошо бы прийти к ПМу (любому начальнику) и с ним поговорить для начала, выяснить что происходит. Но, как понимаю, и тут не сложилось, только вы почему-то в этом вините всех вокруг, а должны спросить в первую очередь с себя. Ведь если бы процессы были сломаны и все было так плохо и все не работало, проект был бы нежизнеспособен и закрыт. Чего, очевидно не случилось, просто вы ушли.
С таким отношением неважно какую метдологию подставить в заголовок, всегда все будет плохо.
Надо менять отношение, вы в меньшинстве так или иначе, с ветряными мельницами бороться такое себе занятие.ApeCoder
11.02.2022 11:32Разным людям подходит разный способ работы. Возможно этому человеку скрам просто не подходит (или сочитание скрама и задач). Возможно, он хочет работать не на конечный результат, а полировать конкретный компонент и не важно что заказчику нужно сейчас.
Может ему подойдет какое-то место, где целая команда занимается таким компонентом. Или заказчику не нужен результат, а надо потратить деньги.
Но это очень поверхностное впечатление и я бы без конкретики не делал выводов.
nagaevr Автор
11.02.2022 12:40да, это правда, поезд пошёл без меня, я смирился и перестал пытаться его остановить, позже я сошёл как только был готов. думаю от этого стало лучшие и мне и проекту. Да, моё мнение ненадёжно и субъективно, однако я не считаю его вредным для проекта, скорее недоработанным. Я не виню всех вокруг себя, наоборот я пытаюсь этого избежать. Мне кажется что компромиссный вариант, который устроил бы всех, мог быть достигнут но этого не произошло.
ApeCoder
11.02.2022 12:58А какой бы он был?
nagaevr Автор
11.02.2022 13:12у меня его нет, только вера в его существование и накопленный опыт для того чтобы не упустить момент в следующий раз
ApeCoder
11.02.2022 18:44Если у вас был скрам, то в него встроены механизмы обратной связи от daily scrum где можно сказать что мешает работать до ретроспективы, которая специально предназначена для исправления процесса. В данном случае их можно использовать для выработки компромисса. Вы пытались обсудить это с командой?
По вашему тексту я вижу что вы общались с мастерами, но не вижу взаимодействия с другими людьми.
Я вижу например, претензию к тому, что у вас были навыки которые не использовались в то же время вам назначали работу для которой у вас было недостаточно навыков. К тому же у вас отобрали владение компонентов но назначили владельцем кода компонента.
Как я понимаю, эти вещи взаимосвязанны - из-за депреоритезации работ над компонентом, который вы знаете вы занимались какой-то другой работой. Причем вас это не устраивало а всех остальных да (то есть ваша производительность была нормальной с их точки зрения?).
Теоретически я вижу два выхода из этого:
Назначать вам задачи на компонент (а еще вы хотите выполнять роль PO для него - решать что делать и когда)
-
Вам доучиться чтобы быть эффективным на этих новых задачах
Из того, что вы написали, непонятно, почему именно задачи были депреоритизированы. Непонятно, общались ли вы с PO чтобы выработать общее понимание приоритетов и стоимости задач ("если бы вы мне дали вон ту задачу, я принес бы пользу вон тому пользователю").
То есть непонятно, была ли попытка сторон понять друг друга и выработать этот самый компромисс. Она была?
RationalBot
11.02.2022 22:31+2Автор, а Вы ценности scrum разделяете? Приверженность, сфокусированность, открытость, уважение и смелость?
В частности, между строк читается, что своих коллег вы не уважали и совместно работать с ними над общими задачами были не готовы. Я прав?
В этом случае опытный скрам-мастер не стал бы включать Вас в скрам-команду, а использовал как внешний сервис.
Но в одном Вы правы, скрам не является методологией разработки ПО (или описанным SDLC).
И авторы скрама предполагают, что скрам команда самостоятельно создаст такую методологию, пользуясь принципами. А вот осилить это могут только достаточно зрелые компании.
Если по результатам дейли вы не готовы отложить свою задачу и переключиться на помощь коллеге - дейли (а значит и скрам) вам не нужны.
Если по результатам спринта у вас нет готового к продакшину инкремента - скрам вам не нужен.
Если план команды разработки расписан на кварталы вперед и не пересматривается при получении обратной связи - скрам вам не подходит.
К сожалению, авторы скрама не описали его область применения. И большинство скрам-коучей этого не делают. Поэтому очень часто его внедряют там, где он не подходит для продукта и/или команды. Т.ч.на счет карго-культа Вы правы.
P.S.
Роль скрам-мастера - научить команду правильно взаимодействовать (внутри себя, с владельцем продукта, с заказчиками и прочими заинтересованными лицами). И если брать аналогию с тренером, то задача тренера как раз сделать из отдельных игроков команду и подобрать для них оптимальную тактику на игру. "Порядок бьет класс".
nagaevr Автор
12.02.2022 14:15Автор, а Вы ценности scrum разделяете? Приверженность, сфокусированность, открытость, уважение и смелость?
А как это, разделять ценности? Как мне определить разделяю ли я их, каков критерий? Как тому кто хочет научиться уважению перейти от декларативного концепта уважения к процедурной последовательности действий сливающейся в проявление уважения?
В частности, между строк читается, что своих коллег вы не уважали и
совместно работать с ними над общими задачами были не готовы. Я прав?Моё нежелание работать над общими задачами появилось не сразу а после нескольких неудачных попыток. А откуда у вас взялась мысль о том что я не уважал своих коллег?
В этом случае опытный скрам-мастер не стал бы включать Вас в скрам-команду, а использовал как внешний сервис.
Такой вариант меня бы вполне устроил.
И авторы скрама предполагают, что скрам команда самостоятельно создаст
такую методологию, пользуясь принципами. А вот осилить это могут только
достаточно зрелые компании.Ну или не создаст, о том и речь. Скрам это не инструмент достижения цели а рамки ограничиющие выход за пределы некоторой области внутри которой предположительно находится решение.
Роль скрам-мастера - научить команду правильно взаимодействовать (внутри
себя, с владельцем продукта, с заказчиками и прочими заинтересованными
лицами). И если брать аналогию с тренером, то задача тренера как раз
сделать из отдельных игроков команду и подобрать для них оптимальную
тактику на игру. "Порядок бьет класс".Мой опыт свидетельствует о том что чистый скрам-мастер не может помочь команде во взаимодейтсвии. Он может только выполнять ритуалы. Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером. И это выглядит не как тренерство а как судейство. Об этом я и написал.
RationalBot
12.02.2022 21:50+1А как это, разделять ценности? Как мне определить разделяю ли я их, каков критерий? Как тому кто хочет научиться уважению перейти от декларативного концепта уважения к процедурной последовательности действий сливающейся в проявление уважения?
Ценности - это из области Ваших внутренних убеждений. Разделять ценности - принимать решения и действовать в соответствии с ними. Например, если с планирования спринта Вы уходите с мыслью "мне за спринт надо реализовать такую-то фичу в моем компоненте", а не "мы за спринт должны достичь такой-то цели", то приверженность - это не про Вас. Уважение - признать, что коллега имеет право на свое собственное мнение, право его высказывать, право на поддержку, право совершить ошибку в той же мере, что и Вы.
А откуда у вас взялась мысль о том что я не уважал своих коллег?
Я сразу написал, что это не более, чем предположения. Но в статье не упоминается, что Вы демострировали желание работать над общими задачами или обсуждать с командой проблемы скрам на ретро, фраза про тим-лида, компетенции которого никуда не делись, косвенно говорит, что у остальных членов команды компетенции развиты слабее.
Скрам это не инструмент достижения цели а рамки ограничиющие выход за пределы некоторой области внутри которой предположительно находится решение.
Для меня скрам - это способ решения проблем, например, избавление от "функциональных колодцев". Или обеспечение прозрачности статуса в долгосрочных проектах (через спринты).
С тем, что он не явлвется методологией (или универсальным инструментом), я не спорю.
Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером.
Это Ваш опыт, я его не оспариваю. Работа скрам-мастера не в том, чтобы предложить лучшее решение проблемы и защитить его, а в том, чтобы собрать нужных людей и провести встречу так, чтобы в результате появилось решение. Нужен ли для этого инженерный опыт? Сомневаюсь. Скрам-мастер не принимает решения, агрументы должны быть понятны команде, а не ему.
Но скажу честно, на практике не сталкивался со скрам-мастерами без технического бэкграунда.
Он может только выполнять ритуалы.
Ритуалы на начальном этапе - это Сю в Сю-Ха-Ри. Проверенный на протяжении веков путь к мастерству. Я видел многих, которые начинали с Ри и фейлились.
nagaevr Автор
13.02.2022 12:11+1Ценности - это из области Ваших внутренних убеждений. Разделять ценности - принимать решения и действовать в соответствии с ними. Например, если с планирования спринта Вы уходите с мыслью "мне за спринт надо реализовать такую-то фичу в моем компоненте", а не "мы за спринт должны достичь такой-то цели", то приверженность - это не про Вас. Уважение - признать, что коллега имеет право на свое собственное мнение, право его высказывать, право на поддержку, право совершить ошибку в той же мере, что и Вы.
Я ничего не имею против ценностей. Я недоволен методом их изложения. Просто задекларировать ценность недостаточно. Нужно уметь эту ценность реализовать самому и научить ей других а этого в скраме нет. Я не получал негатива от команды и команда уважала моё право совершать ошибки. Но для того чтобы эти ошибки прекратились этого было недостаточно. Цель ведь не в том чтобы придерживаться какой-либо ценности а в том чтобы извлекать из этой ценности пользу, например прекращеие ошибок. Я проявлял приверженность, и активно участвовал в процессе трансформации, поначалу и довольно долго это держалось на вере, но время прошло, вера закончилась, проблемы остались. Какой смысл от приверженности бесполезного в новых условиях человека?
Ещё пример распада ценности без изменения последовательности действий. Когда ты просишь человека проявить открытость, например спрашивая чем ты можешь ему помочь. Ты как бы берёшь обязательство ему помочь. Если ты ему не помог, один раз, нестрашно. Но если это происходит постоянно или ещё хуже если ни один такой вопрос не привёл к решению. Ценность открытости скрывавшаяся за предложением помощи рассыпается, на её месте возникает ощущение пассивного давления. Цель осталось прежней, средство реализации осталось прежним а эффект со временем изменился.
Я сразу написал, что это не более, чем предположения. Но в статье не
упоминается, что Вы демострировали желание работать над общими задачами или обсуждать с командой проблемы скрам на ретро, фраза про тим-лида, компетенции которого никуда не делись, косвенно говорит, что у остальных членов команды компетенции развиты слабее.Нежелание возникло не сразу, это шло постепенно. Заявлением о необходимости тимлида в команде я не пытаюсь принизить других её членов. Тимлид в моём представлении не водит коллег за ручку, а лишь иногда подстраховывает когда те не могут решить проблему сами.
Для меня скрам - это способ решения проблем, например, избавление от
"функциональных колодцев". Или обеспечение прозрачности статуса в
долгосрочных проектах (через спринты).Рад за вас, я не ощутил его как способ решения проблем, а скорее как набор норм который воспринимается как инструмент но им не является.
Ритуалы на начальном этапе - это Сю в Сю-Ха-Ри. Проверенный на
протяжении веков путь к мастерству. Я видел многих, которые начинали с
Ри и фейлились.То что я видел не было похоже на Сю. Когда ты делаешь сю, у тебя и измеримый результат должен появится, совпадающий с результатом мастера по искомому критерию, рано или поздно. Я же не увидел результата, а продолжать повторять то что не приносит результата без каких либо изменений я не видел смысла.
S-e-n
13.02.2022 15:50Проверенный на протяжении веков путь к мастерству.
Ну и какой выхлоп у этого метода? Сколько идёт дальше Сю?
ilnuribat
12.02.2022 21:54Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженеромОпять же: не будет скрам мастер решать технические задачи. Опять вы вместо того чтобы идти за помощью в решением технических проблем, идете к СМ, который понятия не имеет что за проблема. Он скорее психолог, поможет разобраться в себе, поможет вам обратиться к команде, чтоб не подставить их, ведь вы можете провалить спринт.
Чистый скрам мастер не может помочь команде во взаимодействии
Это его работа, пересчитайте скрамгайд
- коучит участников команды в части самоуправления и кросс-функциональности;
- помогает Scrum Team фокусироваться на создании Increments с высокой ценностью,
соответствующих определению готовности;
- способствует устранению препятствий, мешающих прогрессу Scrum Team; а также,
- убеждается в том, что все события Scrum происходят, позитивны, продуктивны и не
выходят за рамки ограничений по времени.
HemulGM
11.02.2022 12:20+3По-моему автор четко, в самом начале, дал понять, что будет излагать собственные ощущения. Какая разница какой контекст и конкретика? Он делится тем, что было с ним, анализирует и делает выводы. И тем более, не предлагает помочь разобраться.
sn00p
11.02.2022 12:58+2Тогда заголовок был бы слегка другой, не находите? Автор делает какое-то громкое заявление, но по факту ничем его не подтверждает, кроме собственных ощущений. Что соответственно вводит в заблуждение читателей, зачем?
nagaevr Автор
11.02.2022 13:17+1Я нашёл то, что меня беспокоило и явно обозначил что считаю главной ложью скрама, а именно несоответствие определения скрама и того как он ощущается в реальности. А громкий заголовок нужен чтобы привлечь внимание)
sn00p
11.02.2022 13:30-1Так вы в себе сначала разберитесь, в ваших высказываниях сплошные противоречия.
Например,
Я больше не могу класть задачи по компоненту в беклог(только на самое дно).
Как у вас получается одновременно и могу, и не могу? И на основании этого вы делаете выводы какие-то, очевидно тоже противоречивые, сдобрив всю историю кликбейтом, в чем сами и признаетесь ) ну, акей.nagaevr Автор
12.02.2022 18:32+2Я больше не могу класть задачи по компоненту в беклог(только на самое дно). Как у вас получается одновременно и могу, и не могу?
Хорошо, вы меня подловили, формально я мог создавать задачи в беклоге, но смысла делать это я не увидел, цель ведь не в том чтобы просто создать задачу а в том чтобы выполнить доработу по этой задаче. И потом, в чём принципиальная разница между тем чтобы класть задачи на дно беклога или не класть вообще? Ни в том ни в другом случае они не будут сделаны. Так как я не могу обосновать бизнес-ценность, они наврядли будут учтены при планировании. Это не значит что мои задачи не имеют бизнес-ценности, это значит что я не могу её оценить. Они могут просто пропасть из беклога при очередном "причёсывании".
И на основании этого вы делаете выводы какие-то, очевидно тоже противоречивые
Я делаю выводы на основе тех данных которые у меня есть. Я бы рад использовать что-то более надёжное но не могу. Однако, я верю что даже такие выводы могут кому-то помочь, поэтому я ими и поделился.
сдобрив всю историю кликбейтом, в чем сами и признаетесь
Я сомневался, делать его кликбейтным или нет, решил сделать. Лучше кликбейтный заголовок который привлечёт внимание чем неприметный который отобъёт желание даже просто открыть статью.
ApeCoder
12.02.2022 19:22+1Так как я не могу обосновать бизнес-ценность, они наврядли будут учтены при планировании.
Вот это интересно. А почему вы не можете обосновать бизнес ценность? Вы делаете какие-то задачи не зная зачем? Или вы считаете что надо посчитать с точностью до копейки?
ilnuribat
11.02.2022 21:34Про скрам мастера часто говорится, что он не решает "мои проблемы"
А он и не должен, если честно. ваши проблемы могут решить ваши однокомандники, но вы их видимо за программистов не считаете, раз идете к СМ(который часто вообще не из IT)
тем более если считаете, что в продукте есть "мой код", за которого вы отвечаете. Поэтому выше был комментарий про излишнее "я". И это не про "моя реакция на события и положение", это отсутствие понимания командной работы.
У вас хорошее понимание процессов скрам, но твердое неверие в идеи командой работы, коллективной ответственности, и т.д.
nagaevr Автор
12.02.2022 18:09+1Однокомандники не могут решить все проблемы. То что я не жду от них решения не означает что я не считаю их программистами, это означает что я не вижу в их руках рычагов влияния на ситуацию. Я не скрывал своих проблем, но это не привело к изменениям. К скрам-мастерам я обращался потому что до трансформации многие из них были менеджерами.
Я готов работать в команде и я делал это пока мог. Я не готов работать в команде которая не нуждается в моих услугах. Мне просто нечего им предложить. Да и зачем, когда можно найти команду я буду полезен таким какой я есть?
Я верю в идею командной работы и верю в идею коллективной ответственности, хоть и не до конца их понимаю. Я лишь заявляю что скрам - не является инструментом их построения. Он является лишь стандартом описывающим черты команд которые смогли это построить раньше в своих условиях.
RationalBot
12.02.2022 22:03+2Я верю в идею командной работы и верю в идею коллективной ответственности, хоть и не до конца их понимаю. Я лишь заявляю что скрам - не является инструментом их построения.
С этим я не согласен, он как раз является инструментом построения эффективного взаимодействия для команды профессионалов, которые разделяют ценности скрама.
Он является лишь стандартом описывающим черты команд которые смогли это построить раньше в своих условиях.
Все верно, авторы скрама как раз где-то писали, что обощали опыт сложившихся успешных команд.
Но скрам-гайд не описывает трансформацию, т.е. переход от иерархической структуры к скраму. И ничего не говорит про методологию разработки ПО или инженерные практики.
Akon32
10.02.2022 17:46+4Я имел некоторый опыт во внедрении скрама в небольшую команду. Результат оцениваю как "слегка положительный", команда оценивала его как "нейтральный". Хотя и гайд 2020 года стал более коротким и "менее предписательным" (так в нём написано), всё равно пришлось сократить его до 1й страницы (не меняя сути), выкинув новояз.
Тем не менее, чувствуются противоречия. 15-минутных встреч хватает впритык даже на минимальном размере команды. В отдельных специфичных обстоятельствах скрам перестаёт работать, хотя указывается, что он "подходит всем". С другой стороны, скрам вполне работает, если иногда пропускать ежедневные встречи (но формально это перестаёт быть скрамом). Самоуправление в команде часто лишь на словах самоуправление. Роль скрам-мастера (хотя мне приходилось исполнять эту роль), кажется, создана лишь с целью создания рабочих мест скрам-мастерам
сектанты какие-то. Как реализуется scrum of scrums во времени, я так и не понял.В целом, вещь рабочая, но нельзя относиться ко скраму восторженно.
«Вы можете изменить компоненты скрама но результат такой модификации скрамом являться не будет»
Кажется, это проговаривается лишь для того, чтобы скрамом (тм) не называли всякую чушь, во избежание "Да, мы делали этот ваш Торт (тм) по вашему рецепту, но вместо сахара положили перец. Говно ваш Торт (тм)!" Насколько это помогает, не могу судить.
Подозреваю, изощрёнными способами можно испортить даже процесс, формально соответствующий всем правилам. И всегда можно сказать "вы просто не умеете готовить скрам", "нормального скрам-мастера вам надо" и т.п.
MrGrey13
10.02.2022 19:36+6"Видоизмененный скрам не есть скрам", с одной стороны, звучит логично, а с другой звучит как догма. Мужики тем самым заявляют, что их скрамгайд это очень точно выверенный скелет, на который нам остаётся лишь нарастить мяса. Перелом же одной косточки приведёт к поломке всего организма. Единственная моя претензия - это невероятно смелое заявление.
chateau
11.02.2022 11:20В скраме нет слов "подходит всем". В начале скрам гайда есть вполне чёткое определение фреймворка, вот оно: "Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." То есть если вам не нужно создавать ценность, или у вас нет потребности в адаптационных решениях, или у вас нет сложных проблем - вам его использовать, в целом, не надо.
Не нужно резать скрам гайд, вы из него вот это вот, например, вырезаете, потом такие разговоры.Akon32
11.02.2022 13:11В скраме нет слов "подходит всем".
И правда нет, тут я ошибочно запомнил фразу "... Scrum применяется не только при разработке программных продуктов, для которой он изначально создавался, но и во многих других областях, ...". Смысл не тот.
Не нужно резать скрам гайд
Увы, неподготовленному человеку скрам гайд (особенно русский перевод) непонятен. Одни термины используются прежде, чем они определены, другие нужно гуглить. За утверждением "Скрам - прост" следуют ~15 страниц описания. Даже сокращённый рассказ занимает больше пары минут - в двух словах не объяснить, что это такое.
chateau
11.02.2022 14:28+1Иронично, но позиция по этим вопросам также отражена в скрам гайде.
"Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless."...и, в целом, для системы управления 15 страниц это буквально ничто по объёму. Вспоминая PMBook или тот же SAFe - довольно щадяще.
ramil_trinion
10.02.2022 18:44-9Как методология Agile несостоятельна.
sn00p
10.02.2022 19:19+2Я даже не поленился и открыл ссылку. Правда сразу и закрыл,
Не такой методологии AgileСложно с таким спорить.
Goctha
10.02.2022 21:35+1Я тоже не поленился и перешел. Автор анализирует манифест, но строчки "То есть, не отрицая важности того, что справа,мы всё-таки больше ценим то, что слева.", он почему-то не заметил.
sn00p
10.02.2022 22:04Там в целом все прекрасно. Даже неглядя на то, что автор просто поленился вычитать статью, показав сразу всем, как он относится к основному инструменту своей работы.
А ведь он книги пишет и кто-то это покупает ))
tangro
10.02.2022 20:25Я потерял контроль над своим компонентом, но получил титул владельца исходного кода этого компонента. Когда титула не было, контроль был.
Право коммита у Вас забрали, что ли? Я не понимаю как разработчик, и тем более с "титулом владельца" может потерять контроль над компонентом. Если я вижу проблему в своём или чужом компоненте - я её всегда могу исправить, прямым коммитом или мерж-реквестом. Мерж-реквест отклонён без адекватной аргументации и предложений по улучшению? До свидания такой проект.
NetBUG
10.02.2022 22:51+1Можно отнять право пушить в мастер или, например, пушить без одобрения двух других людей. Это часть процесса, более того, я понимаю, почему такие правила могут иметь право на жизнь в сложившемся проекте.
Но я бы это отнёс к проблемам роста продукта в целом – когда от него начинает зависеть слишком многое, даже выпуск следующей мажорной версии может не помочь, "раньше было лучше, правильный винамп – это 2.70"
ApeCoder
10.02.2022 23:36+6Приходиться догадываться. Автор не приводит никаких конкретных примеров - только обобщения непонятно чего
nagaevr Автор
11.02.2022 09:22+2я потерял возможность класть задачи по компоненту в беклог(только на самое дно), выдвигать задачи на планирование, брать в спринт, тратить какие-либо ресурсы на него, даже своё время, потому что оно было занято задачами с бОльшим приоритетом в рамках спринта
usego
11.02.2022 09:48Может быть клиентам в данный момент жизненного цикла проекта работа по вашему компоненту уже нафиг не нужна, а выходить из круга комфорта крайне не хочется? Скрам то тут при чём?
eugene08
11.02.2022 10:59+3"Кто деньги платит тот и танцует" - вам платят за то что вы делаете те фичи которые нужны здесь и сейчас, не понимаю, что тут может не нравиться. Полная свобода будет на своем проекте, только там деньги не платят.
shopoloff
11.02.2022 18:05Так проблема в том, что клиент часто сам не понимает чего он хочет. Особенно если речь идёт о каком-то локальном "владельце процесса" который не видит всей картины и не понимает, что его "большая красная кнопка" может подождать. Для этого нужны архитекторы и тимлиды, а скрам заменяет все бессмысленным танцем с бубном.
ilnuribat
12.02.2022 15:08+2Всё это в руках ПО
Вы - разработчик. Теперь половина претензий отпадает к скраму. Потому что вы возомнили себя владельцем продукта
tangro
10.02.2022 20:29+5Во-первых, я бы отделял вот всю эту мишуру типа "коучей, сертификации, определений" от самого скрама. Скрам-то более или менее ещё использовать можно, а вот первое - просто способ выкачивания денег из слабых духом.
Во-вторых, не понятно почему автор тревожит то, что изменив что-то в скраме, это перестанет называться скрамом. Ну, перестанет. И что? Мы вон из скрама выкинули процентов 40 и добавили процентов 20 - и ничего, продукт живёт и релизится уже не один год. Никто не умер.
BioHazzardt
10.02.2022 20:52+3Во-первых, я бы отделял вот всю эту мишуру типа «коучей, сертификации, определений»
ИМХО использовать коучей все равно, что использовать гадалок. Говорят много, денег просят немеряно, а толку — х*й да маленько
GospodinKolhoznik
10.02.2022 21:00+1Есть ощущение, что вам просто поставили нереальные сроки и нагрузили сверх всякой меры. И тут уже неважно - ватерфло, аждайл или скрам, все одно будет стыд и срам.
nagaevr Автор
11.02.2022 09:41дело не в объёме нагрузки а в её типе, меня посадили заниматься тем что я не хотел и не мог, отодвинув то что я хотел и мог.
usego
11.02.2022 09:55+3Скрам - это не про то, что хочется ВАМ. Скрам - это про то, что ожидают в каждой конкретной итерации стейкхолдеры (в конечном итоге бизнес). Это ни хорошо ни плохо. Это реальность. Бизнес платит разработчикам с продаж и не шибко заботится о техническом долге. Задача разработчиков доносить до бизнеса и про технический долг. Самое простое - отвоевать % времени под задачи из технического долга и самостоятельно этим временем распоряжаться. Но это небольшой процент. Дай разработчику власть - и он будет в своей тёплой песочнице рефакторить 100% времени.
nagaevr Автор
12.02.2022 13:16не согласен, работу над проектом (по скраму или нет) я считаю компромиссом между бизнесом и инженерами, как инженеры должны помнить о целесообразности своих доработок для бизнеса, так и бизнес должен понимать что запущенные инженерные проблемы могут подкосить их бизнес-модель.
ApeCoder
12.02.2022 15:18+1так и бизнес должен понимать что запущенные инженерные проблемы могут подкосить их бизнес-модель.
То есть это не комромисс, а подчинённость интересам бизнеса, только долгосрочным, да?
nagaevr Автор
12.02.2022 17:42Нет, это явно компромисс а не подчинённость. У бизнеса свои интересы, у наёмных инженеров - свои. Часть этих интересов пересекается, что позволяет бизнесу и инженеру договориться о взаимовыгодном сотрудничестве для решения проблемы в интересах пользователя и извлечения выгоды (необязательно денег) из этого решения. Перекос в любую из сторон создаст проблемы, просто проявляться они будут по-разному.
ApeCoder
13.02.2022 12:50Приведите, пожалуйста, пример проблемы, созданной из-за несоблюдения интересов наемных инженеров, но никак не затрагивающих интересы бизнеса.
Я тут вижу только три варианта:
Инженеры действуют в интересах бизнеса напрямую - делают фичи, фиксят баги
Инженеры действуют в интересах бизнеса опосредованно (рефакторят код, чтобы его потом проще было менять, т.е. уменьшают стоимость и время пукта 1 в будущем)
Инженеры занимаются инженирингом just for fun - хобби проект, рефакторинг модуля, который все равно выкинут через неделю и заменят сторонним решением, оптимизация како-то процесса, который не находится в узком месте и никогда не будет
Третье я бы классифицировал как хобби за деньги и на оборудовании работодателей. Это не плохо, но должно быть согласовано и рассматриваться как часть пакета компенсации (зарплата, ДМС, льготы на обслуживание у работодателя и т.п.)
Если инженеры действуют в интересах бизнеса то бизнес обладает полнотой информации и ответственнустью за принятия решений - инженер может только рассказать про возможные варианты последствий решения (Если сейчас не отрефактрим, то потом будет в 10 раз труднее менять).
Klpsm
10.02.2022 21:35Почему-то многие считают, что Скрам == Agile. Есть достаточно много различных путей, чтобы повысить гибкость и адаптационную способность ИТ-продуктов и это далеко не всегда Скрам.
Вообще-то Скрам имеет весьма узкую область эффективного использования с кучей ограничений. Agile тоже не всесилен, хотя область использования таких подходов и шире.
Начинать надо не с фреймворков, методик и методов, а с понимания, что для решения достаточно большого класса задач не подходит ни иерархическая, ни матричная система управления. Во многих случаях для решения задач, не имеющих единой оптимальной стратегии решения (к которым относится и разработка ПО) наиболее эффективвной оказывается сетецентрическая система управления на основе множества автономных команд, с общими, или синхронизированными целями. Вот тогда и появляются Agile подходы.
ermadmi78
10.02.2022 22:03+40Я, если честно, категорически не могу понять пользу скарам коучей в современной разработке. Саму методологию, если выжать из нее всю воду, можно уместить на паре страниц. При этом современный инженер с легкостью жонглирует добрым десятком инструментов (языки, фреймворки, СУБД и т.д. и т.п.), по каждому из которых можно написать несколько талмудов, безо всякой воды.
Так объясните мне пожалуйста, зачем на полном серьезе учить этой примитивщине современного инженера? Дайте ему эти 2 листочка с описанием методологии - и он за 10 минут освоит материал. Нет же - нужно устраивать часовые лекции, извращенные тренинги, и внедрять в команду религиозных деятелей, которые рьяно будут следить за соблюдением 10 куцых заповедей.
Почему у нас тогда нет ООП коучей, SOLID коучей ну или каких нибудь реляционных коучей? Где наша свобода вероисповедания?!!!
dimalu85
10.02.2022 22:55+5Радует, что есть люди с трезвой головой и добрым сердцем. Сегодняшний скрам - это корпоративная религия. А т.к. внутренние дела компаний редко беспокоят простых граждан, политиков и военных, то в этой сфере процветает свобода, разнообразие и, надеюсь, местами естественный отбор. И ровно как к упомянутым 10 заповедям сегодня прилагается бесчислинное количество томиков и десятки "настоящих" конфессий, так и к скрамам прилагаются толпы проповедников. Слава роботам, мы побороли мировой голод и можем заниматься хоть скрамами, хоть пастарианством. Сегодня можно руководствоваться правилом "не нравится -не ешь". Что и сделал в итоге автор. Посоветовать могу лишь меньше рефлексировать и просто принять - люди разные в отдельном, но очень похожие в общем.
AndreySinelnikov
10.02.2022 23:20+3YAGNI коуча, пожалуйста
Kreastr
11.02.2022 09:15+2YAGNI-коучи ужасно нестабильная материя. Как только сами усваивают материал - самоустраняются.
ApeCoder
10.02.2022 23:41+2Так скрам не содержит инструкции как, например, проводить ретроспективу, что делать, если решения принимаются, но не проводятся в жизнь и так далее. Он не содержит подробных инструкций и методик.
Всякие мастера и коачи по идее должны помогать команде организоваться, следить за настроением в команде, стараться чтобы все были услышанными.
Практически, как я понимаю тут как со школьным психологами - знающих свое дело надо поискать
ermadmi78
10.02.2022 23:51+12Сотни тысяч инженеров по всему миру, разговаривающих на разных языках, воспитанные в разных культурах с разным менталитетом сумели выработать четкие, красивые и изящные принципы и инструменты современной разработки. Создали Open Source движение. Выработали культуру свободного распространения идей и технологий. И что по вашему, эти люди не в состоянии самостоятельно выстроить процесс разработки в отдельно взятой команде без пригляда попа в рясе? Вы это серьезно?
ApeCoder
10.02.2022 23:54-4Вы рассмотрели все опенсурс проекты или только выжившие?
Хороший поп имхо тоже типа психолога
ermadmi78
11.02.2022 00:02+8Я правильно понимаю, что наличие умерших open source проектов убедительно доказывает полную неспособность инженеров договориться между собой и выстроить процесс разработки? И только чтение святых молитв из Agile манифеста помогает недалеким инженеришкам добиваться хоть каких то скромных успехов?
andreyverbin
11.02.2022 00:14+5Берём пару инженеров и даём им делать что им хочется и магия, они договариваются. Все таки общение у людей в генах. Добавляем менеджера и вуаля, те же инженеры уже договориться не могут. Тоже магия.
Разоблачение фокуса, возможно, в границах и зонах отвественности, которые все понимают по разному. Одно все понимают одинаково - кто-то за их границей им теперь что-то должен. Менеджер должен понятно задачу поставить, тестер найти все баги и описать подробно, коллега обязан писать понятный код, а начальник зп поднимать и так далее. Особняком стоят люди с внутренней мотивацией, которые просто делают что нужно, не глядя на формальные и выдуманные границы. На них все и держится.
sn00p
11.02.2022 00:18+5Задача менеджера - транслировать хотелки бизнеса в понятный всем план действий. У бизнеса хотелки простые - заработать побыстрее, снизив издержки побольше. В этом кроется противоречие, потому что фонд заработной платы - это издержки.
sn00p
11.02.2022 00:15Там везде много разных документов, есть еще Трудовой Кодекс, он вообще всем помогает. OpenSource проекты, это тоже коммерческие проекты. Просто монетизируются они по-другому.
ApeCoder
11.02.2022 10:51Да нет, некоторые инженеры договорятся, некоторые - нет. Можно ли как-то увеличить вероятность того, что они договорятся и выпустят то, что нужно заказчику - вот вопрос.
Не только чтение молитв, есть куча методик как аджайл так и нет. Вы же читали "мифческий человекомесяц", да?
bars_arseniy
11.02.2022 11:26Зачем вы передёргиваете?
То, что в мире есть опенсорс означает, что некоторое количество инженеров, которые смогли договориться и пилить эти проекты. Но это не означает, что модно взять любую группу инженеров и они договорятся друг другом о том, как делать работу нужную заказчику. В таком случае как раз и могут быть полезны люди которые организуют работу этих инженеров.ermadmi78
11.02.2022 12:11+2Вы весьма своеобразно трактуете мои высказывания. Я где нибудь говорил о том, что не нужны менеджеры проектов и аналитики? Не припоминаю такого. Наоборот, я, как инженер "старой школы", выступаю за максимальную формализацию процесса разработки, вплодь до написания ТЗ.
Я, на самом деле, даже против самого скрама не выступаю. Я лишь выступаю против возведения скарама в религиозный культ. Когда инженеров пинками гоняют на лекции и тренинги, когда в команду внедряют коучей, единственная задача которых, следить за тем, пришел ли инженер Ваня на ретроспективу или нет. Когда любая попытка оптимизировать процесс разработки упирается в религиозные запреты вида "тогда это будет не скрам". Когда отдельно взятые проджект менеджеры на полном серьезе заявляют, что нам не нужны проектирование и согласования, ибо у нас все само гибко вызреет - надо только следовать процессу. Я выступаю против откровенных трутней, которые обосновывают свою ценность религиозными завываниями. А по факту являются просто бесполезным балластом.
RationalBot
12.02.2022 22:21Наоборот, я, как инженер "старой школы", выступаю за максимальную формализацию процесса разработки, вплодь до написания ТЗ.
У меня есть печальный опыт согласования Т.З. с заказчиком на протяжении 22 месяцев. Саму доработку мы оценили в 6 человеко-месяцев (и 4 месяца по срокам).
Скрам стал востребован в эпоху дот-комов, когда выпустить сайт или приложение и посмотреть на реакцию пользователей оказалось быстрее и эффективнее, чем написать Т.З.и пройти по стандартной модели SDLC.
VK - как пример (изначально LAMP, который решал проблемы масштабирования и производительности по мере появления пользователей.
А вот начали бы с Т.З. под текущую аудиторию, до сих пор писали бы.
ermadmi78
13.02.2022 01:23+1У меня у самого есть истории как успеха так и провала работы по ТЗ. И со скрамом видел и победы и поражения. Серебрянной пули не существует. К каждому проекту нужно подходить индивидуально.
По поводу скрама. Мое наблюдение - он по-настоящему хорошо работает только в том случае, если есть сильный Product Owner. Если у владельца продукта в голове сложилась хорошо продуманная и логически "замкнутая" концепция продукта, и если продакт хорошо идет на контакт с командой (в идеале он должен быть доступен 24*7) - то можно и нужно пропустить стадии формального согласования, и попытаться "выстрелить" с помощью скрама. В остальных случаях "выстрел", с большой долей вероятности, окажется прямо себе в ногу.
ermadmi78
11.02.2022 12:33+1И еще, вы точно уверены, что нужен отдельный человек, который будет следить за тем, соблюдает ли инженер Ваня договоренности по процессу разработки или нет? Если уж наш Ваня такой безответственный товарищ, то почему в команде нет отдельных людей, которые следят за тем, следует ли Ваня устоявшимся практикам разработки кода? Которые, кстати, на порядок более сложные, чем Agile методологии. Как я уже говорил в начале. ООП коуч. SOLID коуч. И т.д. и т.п. Если нам к Ване нужно приставить десяток коучей, то нахрена вообще нам нужен такой Ваня?
Ta_Da
11.02.2022 12:42+1Пора писать "Повесть о том, как один разработчик десять agile-коучей прокормил".
ApeCoder
11.02.2022 12:49Как вы определили, что их нет? Они есть, но не везде, как и коачи.
Есть консалтинг по инженерным практикам, есть инжениринг/техлиды которые выполняют те же функции. Есть практики, типа код ревью, которые поддерживают соблюдение устоявшихся соглашений.
Гайд определяет набор ролей, но не требует, чтобы это были отдельные люди.
ermadmi78
11.02.2022 13:12+1Ревью проводят другие инженеры, которые и сами пишут код. Это, кстати, очень полезный процесс (если опять таки проводить его с умом) - улучшается качество кода, распространяются знания по команде. Отдельно взятого человека, который занимался бы только тем, что следит за соблюдением инженерных практик, я за более чем 20 лет работы ни разу не встречал. Пришел ли инженер Ваня на ретроспективу, может легко проконтролировать тимлид или менеджер проекта (тут меня сильно удивляет сам факт того, что Ваню в таком простом деле вообще нужно контролировать. Если нужно, то не проще ли Ваню "попросить на выход"?). Времени и сил на это много не надо. И, кстати, тот же тимлид вполне взрослый человек, чтобы самостоятельно принять решение, а нужна ли сама ретроспектива команде или нет? И не волноваться о том, будет ли процесс скрамом если он ее отменит.
Просто не надо забывать, что методологии созданы для нас, а не мы для методологий. Конечная цель - выдать качественный продукт за приемлимые сроки и бюджет. А соблюли ли мы при этом методологию или нет - абсолютно неважно.
ApeCoder
11.02.2022 19:19А видел разных "ответственных за" которые ревьюили код. Я слышал о техническом консалтинге - приходит человек, организует разработку, включая технические практики, когда наладилось уходит.
По организационным практикам часто то же самое. Например ведение собрания и организация процессов.Скрам мастер в гайде это роль, а не человек, возможность ее совмещения не апрещается, хотя в сети есть мнения на этот счет.
А соблюли ли мы при этом методологию или нет - абсолютно неважно.
Совершенно верно. Неважно как сделан салат, главное чтобы был вкусным. Но при этом есть и рецепты.
RationalBot
12.02.2022 22:26Отдельно взятого человека, который занимался бы только тем, что следит за соблюдением инженерных практик, я за более чем 20 лет работы ни разу не встречал.
А Вам приходилось внедрять безопасную разработку (SSDLC)? Или сертифицироваться по ISO 27001?
sn00p
11.02.2022 00:05Это все, к сожалению, не отменяет сотен тысяч инженеров, у которых ни с того ни со всего "потерялся контроль над компонентом" (что бы это ни значило). И они сразу отправились "воевать с группой из нескольких десятков человек".
К сожалению (или к счастью), ситуация такова, что люди все разные, подходы к работе тоже широко варьируются. Кто-то выгорел, кто-то устал, кто-то испытывает личную непрязнь, кто-то просто саботирует процесс, плетет интриги, кто-то беспринципный карьерист. Что предлагаете с ними делать?
ermadmi78
11.02.2022 00:20+11Вот смотрите. Давайте возьмем религиозные заповеди. "Не убий, не укради, не прелюбодействуй". Что плохого в этих заповедях? Да ровным счетом ничего! Любой разумный человек, прочитав их скажет - хорошие правила, давайте их придерживаться! Только какое отношение к этим простым, разумным и прекрасным в своей сути правилам имеет церковь со своей историей насилия и мракобесия?
То же самое и со скрамом. Нет ничего плохого в тех идеях, которые предлагает Agile методология. Напротив, в ней много хороших и полезных по своей сути вещей. Но, какое отношение к этим идеям имеют расплодившиеся корпоративные религиозные деятели, которые за формой не видят содержания? И для которых процесс важнее результата.
Те проблемы, которые вы описали, есть в любом человеческом коллективе. И, так же, как и заповеди "не убий, не укради, не прелюбодействуй", Agile методологии МОГУТ улучшить ситуацию. Но вот религиозные деятели, которые паразитируют на этих методологиях ситуацию улучшить в принципе не способны.
sn00p
11.02.2022 00:32-2Предлагаю не мешать сюда религию.
Факт, всем нужен процесс, всем нужен контроль, что он выполняется. Бизнес хочет понимать, на что он тратит деньги. Исполнители должны понимать, что от них хочет бизнес. И это зачастую настолько далекие друг от друга люди, что без посредника они просто не договорятся. И чем сложнее процессы, тем сложнее схемы и тем больше посредников. Плохо, когда это превращается в карго-культ. Но, как правило, бизнес - это не дурак и все такие вещи рано или поздно исчезают. Либо исчезает несмышленый бизнес. Дураков тратить деньги в никуда очень мало ))
Как правило, секты очень эффективны, там как раз все за идею.
Рабочий коллектив сложнее, там кто-то за идею, кто-то за деньги, кто-то комбинирует. И это нормально!ermadmi78
11.02.2022 00:37+6>> Дураков тратить деньги в никуда очень мало ))
Блажен, кто верует! ;)
sn00p
11.02.2022 01:14Но ведь, если в бизнесе есть дураки, почему их не может быть среди инженеров?
ermadmi78
11.02.2022 01:32+2Дураки есть везде. Только вот умным людям слушать их не надо! Умные люди на то и умные, чтобы играть по своим правилам. Собственно в этом и заключается основной посыл моих сегодняшних высказываний. Спокойной ночи!
goldrobot
11.02.2022 08:47Давайте возьмем религиозные заповеди.
Опасно, но давайте.
"Не убий, не укради, не прелюбодействуй". Что плохого в этих заповедях? Да ровным счетом ничего! Любой разумный человек, прочитав их скажет - хорошие правила, давайте их придерживаться!
А, ну можно и закончить, скрам мастера видно из далека. Любой разумный человек, прочитав их скажет - правила плохие, давайте не будем заниматься этим бредом.
Наши предки сотни тысяч лет прелюбодействуют. И все занимаются этим сейчас. "До брака нини" это мем очень забавный, но к реальности отношения не имеющий.
Не убий это вообще без коментариев. Что-то из разряда подставь другую щеку. Пришли убивать меня, мое красть, мою дочь прелюбодействовать, а должен просто брать и смотреть, ведь мне сказано не убий?
Видишь человека который против всего плохого, за все хорошее, то знай, это личинка скрам-мастера.
vedenin1980
11.02.2022 13:46Тут у вас очевидное не понимание этих правил.
«До брака нини» это мем очень забавный, но к реальности отношения не имеющий.
Потому что «не прелюбодействуй» это не вступай в связь с тем/той, кто в браке или если сам в браке, а не про «До брака нини».
Причины почему это общественно вредно понятны — во-первых, это нарушение тех добровольных обещаний, что были даны при заключении брака, во-вторых, множество людей было убито ревнивыми мужьями и женами, в-третьих, брак это про совместное воспитание детей (в-первую очередь), которое ставится под угрозу при таких изменах.
То есть с точки зрения логики — сначала разойтись с текущим партнером, а потом уже заводить новые связи, вполне логично.Не убий это вообще без коментариев.
Там не просто «не убий», а «не убий ближнего своего», то есть это правило не относится к врагам из других народов (на войне, к примеру), к преступникам и тем кто пытается тебя убить/ограбить и т.п.
По сути, можно перефразировать как «нельзя убиват людей из своего социального сообщества, если они не пытаются убить или ограбить вас (что исключает их из членов вашего же сообщества)» — что вполне разумно для любой группы людей.goldrobot
11.02.2022 14:25Потому что «не прелюбодействуй» это не вступай в связь с тем/той, кто в браке или если сам в браке, а не про «До брака нини».
Эм, нет, одна из трактовок до брака нини. Иногда трактуется вообще, как секс для удовольствия. Но обычно, прелюбодействовать, это в общем-то, просто секс между людьми которые не связаны браком.
По сути, можно перефразировать как «нельзя убиват людей из своего социального сообщества, если они не пытаются убить или ограбить вас (что исключает их из членов вашего же сообщества)» — что вполне разумно для любой группы людей.
Нельзя. Во первых у вас сказано "не убий", а во вторых, насколько мне известно, про ближнего своего это уже из пояснинений, а не из самих заповедей. Но самое главное, третье, ничего не сказано про отношение к вам. Сказано про близость, очевидно родственную, а про то что убивать нападающих на вас, вы уже додумали. А как мы знаем, все модификации скрама скрамом не являются.
UPD: Но вообще не понятно зачем я продолжаю спорить о терминологии, если всетаки мой поинт был в другом. А именно, в том, что не все что "любой разумный человек одобрит". Нет, не любой. Даже не близко к этому.
masterito
12.02.2022 13:16Не нужно смешивать Agile и Scrum. Идеи Agile сами по себе вполне разумны и не очерчивают настолько четких границ. Другое дело Scrum - шаг вправо или влево и это уже не Scrum. Я знаю про Scrum-мастеров/тренеров, но ничего не слышал про Agile-мастеров.
Alendorff
12.02.2022 18:45помогать команде организоваться, следить за настроением в команде, стараться чтобы все были услышанными.
Работа для engineering manager, нет?
nick1612
11.02.2022 02:18+4Почему у нас тогда нет ООП коучей, SOLID коучей ну или каких нибудь реляционных коучей?
Ошибаетесь, они просто зовутся не коучами, а евангелистами)
tjx
11.02.2022 07:12-2В большинстве Agile-фреймворков есть роль, в задачи которой входит сопровождение правильного использования этой методологии:
Scrum = Scrum Master
XP = XP coach
Lean software development = Lean Master
DSDM Atern = DSDM coach
Нет явно выделенной роли в Crystal family и в Kanban. Но и то в последнем может быть "Agile coach".
Зачем они там нужны? Потому что "легко понять, сложно внедрить".
Nacreous1991
10.02.2022 22:16+1Удивительно, но несмотря на триллионы которые вкладываются в айти никто не проводит реальные исследования насчёт того какая методология разработки или фреймворк - лучше, быстрее и дешевле. Почему бы не провести тестирование и выяснить это?
ermadmi78
10.02.2022 22:44+14Религия существует не для того, чтобы вы были эффективными. А существует она для того, чтобы вами манипулировать. А для того, чтобы вами манипулировать, от вас требуется слепая вера. Так что все эти ваши исследования и тестирования - это чистой воды ересь!
Вопрос нужно ставить по другому. Одно дело, когда кучка относительно образованных и интеллектуально развитых людей манипулирует огромной голодной и безграмотной серой массой. И совсем другое дело, когда кучка совершенно безграмонных людей с помощью слепой веры пытается манипулировать интеллектуальной элитой. В первом случае польза очевидна, а во втором как то не очень.
dimalu85
10.02.2022 22:56+1Потому что эти триллионы и так приносят неплохие прибыли. Вот как станет вопрос улучшить "двс" на полпроцента, тогда и задумаются.
Revertis
10.02.2022 23:25+1Для правильного исследования надо подобрать несколько полностью одинаковых команд, и заставить их разработать один и тот же продукт. Возьмётесь?
Nacreous1991
11.02.2022 01:11Ну препараты же как-то испытывают на неодинаковых людях
ApeCoder
11.02.2022 10:54Хорошо, тысячу неодинаковых команд, распределить по методологиям рандомизированно желательно с плацебо-методологиями. Теперь давайте оценим себестоимость такого исследования
Myclass
11.02.2022 20:31А мне кажется как раз это и происходит, просто результат этого эксперимента не принимается- что это не работает так как обещает. А только при подходящего для этого случаях. Что не может быть правилом .
ApeCoder
11.02.2022 20:33Так приведите ссылку на исследование зачем "кажется"? Кто и где этот эксперимент проводил?
Myclass
11.02.2022 21:44Вы, я и другие...просто это никак в лаборатории, это своего рода социальный эксперимент. Зачем вам таким придирчевым быть?! Проще надо быть..
ApeCoder
11.02.2022 22:33Неа, это будет наблюдение а не эксперимент. Это принципиальная разница - невозможность рандомизации.
Но даже на хорошее наблюдение не тянет.
Рандомный интернетный чувак не осилит прочитать несколько страничек и понять что ему подсунули не скрам под именем скрама. И он будет молчать когда все хорошо и жаловаться когда все плохо.
ApeCoder
11.02.2022 22:41Вот, кстати, какое-то исследование в качестве примера https://www.researchgate.net/publication/304269511_A_statistical_analysis_of_the_effects_of_Scrum_and_Kanban_on_software_development_projects
Полный текст недоступен бесплатно но заключение можно почитать.
K0styan
11.02.2022 10:56Потому что методологии зависят в первую очередь от требований к продукту и, что ещё существеннее, темпов их изменения. Один COVID дал изрядного пинка под пятую точку всему ритейлу и ресторанному бизнесу - пинка достаточного, чтобы те методы, которые до сих пор работали, вдруг оказались недостаточно эффективными.
Это в первую очередь касается, конечно, материальных процессов типа доставки, но и IT-поддержка, и "витринная" часть - то, что видят клиенты на сайтах - тоже должны были перестроиться как минимум не медленнее конкурентов.
vindy123
11.02.2022 11:54Популярные книжки Дейла Карнеги о том, как приобрести друзей, продавались и безо всяких этих ваших тестов-шместов, чё вы лодку раскачиваете, а? Вам лично чего, больше всех надо, да? Бизнес идет, шерсть стрижется.
Ndochp
11.02.2022 15:27Просто там еще рядом толпа трудноуловимых вещей рядом. И в итоге TPS с канбаном взлетает в Tойоте, но не взлетает на западе и начинают говорить, что это японский менталитет. А потом он взлетает в американских заводах Тойоты и проваливается в (кажется, могу наврать с брендом) Hitachi и уже не совсем понятно, что говорить.
ilnuribat
13.02.2022 01:56+1Яркий пример TPS в Европе - Porsche годов 1995-2003
Изучите что было до и что стало
На самом деле есть 4 примера компаний из запада, которые смогли принять философию и добиться примерно того же результата, что и Тойота. Это из книги "бережливое производство"
Ndochp
13.02.2022 13:28Так я не про то, что TPS не работает на западе, я про то, что исследования не работают. Если Тойота может это сделать с любыми людьми, как вы дополнили и Porsche может, а с теми же изначальными японцами Hitachi не может.
И вот спрашивается, TPS работает или нет, какое еще исследование и с каким бюджетом нужно проводить?
А статистика по успешности ИТ проектов, которая ежегодно публикуется все так же даёт равные трети на успели почти в срок, превысили бюджет и/или срок, сфелились до упора. Без выделения успешных/провальных методологий разработки проектов.
indestructable
10.02.2022 23:23+8Основная проблема скрама, как по мне, что он монополизирован менеджерами, и ими модифицирован в интересах менеджеров, хотя изначально он был создан как средство для упрощения жизни разработчиков, тестировщиков и прочих производительных сотрудников (если мы говорим про айти).
Это значит, что из скрама выбросили фиксированные спринты, четкие скоупы, запрет на добавление задач в середину спринта, задачи без четкого и видимого результата, минимизацию коммуникации вне митингов, концентрацию на важных фичах и т.п.
Зато оставили ежедневные митинги, 90% которых - это отчетность, переэстимейты, и объяснения, почему предыдущие эстимейты были неправильные (в 80% - потому что менеджеры их и продавили).
В общем, больше контроля богу контроля, и меньше планирования, потому что это же скрам, у нас гибкий процесс, вот тебе еще фича за день до конца спринта, а почему ты не успел предыдущие, ты же "сам" эстимейтил?
Akon32
11.02.2022 01:44Это значит, что из скрама выбросили фиксированные спринты, четкие скоупы, запрет на добавление задач в середину спринта, задачи без четкого и видимого результата, минимизацию коммуникации вне митингов, концентрацию на важных фичах и т.п.
Запрета добавления задач в середине спринта в последней версии скрама нет (есть оговорка - "можно добавлять, если это не повредит качеству выполнения ранее добавленных задач"), запрета на коммуникацию вне митинга тоже нет. Если менеджер не умеет в приоритеты и ничего не знает о разработке, скрам вряд ли поможет.
Основная проблема скрама, как по мне, что он монополизирован менеджерами, и ими модифицирован в интересах менеджеров, хотя изначально он был создан как средство для упрощения жизни разработчиков, тестировщиков и прочих производительных сотрудников (если мы говорим про айти).
Насколько я понял из гайда, скрам нужен для поставки качественного программного обеспечения точно в срок, реагирования на изменение требований, прозрачности прогресса разработки. Это цели менеджеров. Разработчикам от внедрения скрама быть может станет проще, если например из-за скрама менеджеры откажутся от чайка-менеджмента или других порочных практик. Но изначально это инструмент организации работы, так что он больше для менеджеров.
Loggus66
11.02.2022 00:05-4скрам не ведёт себя как фреймворк. Он ведёт себя как стандарт. Тот у кого недостаточно опыта с программными фреймворками и стандартами ни за что не ощутит разницу между этими концептами в контексте неформального взаимодействия между людьми. Я считаю именно эту ошибку в определении главной ложью скрама.
Framework - это вообще "сруб". Можно ли тягать брёвна из сруба, чтобы построить дом? Можно, но сруб это разрушит. Не надо подменять англоязычные термины своими программистскими определениями. И, конечно же, золотое правило: читайте документацию в оригинале, а не в переводе.
uoak
11.02.2022 07:10+2Вы прямо уверены в слове "сруб" для перевода framework , или может это у вас опечатка какая-то ?
Loggus66
12.02.2022 02:45Это лучший перевод. Какие ещё есть варианты? Каркас? Остов? Именно перевод "framework" как "сруб" показывает: это будет основой, но это же будет и ограничением, которое невозможно переделать "под корень". Отрасль не та, но свойства отлично совпадают.
Вот автор воспринимает "framework" как класс программных продуктов; скорее всего, даже не думал о других значениях, и возмущается, что свойства у SCRUM не те. Привёл такой перенос свойств к неверному восприятию общего термина.
nagaevr Автор
12.02.2022 13:27Да я воспринимаю фреймворк как класс программных продуктов, потому что предметной областью моей работы является разработка программных продуктов. Откровенно говоря до вашего комментария я не знал что фреймворк можно перевести не только как каркас но и как рамки. Это несколько меняет мою позицию, но не отменяет проблемы. Слово "фреймворк" содержит оба смысла, как каркас так и ограничение. Слово "стандарт" же фокусируется на ограничении, соответствии чего-то эталону. Я по-прежнему считаю что оно лучше отражает суть.
ApeCoder
12.02.2022 15:58Любое слово похоже на стандарт, так как есть набор критериев, обозначать ли им явление или нет.
Допустим вы выпускаете каркасы домов (ну или набор чертежей для производства каркасов) под названием "Сетунь-3". Кто-то покупает ваши каркасы, навешивает на них каки-нибудь панели и получается готовый дом.
Потом вдруг люди начинают жаловаться что "Сетунь-3" непрочный отстой.
Вы расследуете причины и выясняете, что покупатели решили что часть балок им не нужно, и решили их отпилить, но готовые дома все равно называют "сделано на базе Сетунь-3" потому, что "Сетунь-3" это раскрученная марка и модно в определенных кругах.
Вы добавляете в инструкцию слова "Вы можете производить любые модификации, только, пожалуйста, на называйте результат "Сетунь-3"".
Фактически, с программными фреймворками та же ситуация - если вы переделаете Spring и будете называть свой фреймворк тоже Spring это приведет к путанице.
Програмные фреймворки в отличие от библиотек, это то, что вызывает ваш код => код должен подчиняться каким-то ограничениям (реализовывать предопределенные фремворком интерфейсы, например), а в библиотеках вы просто пользуетесь набором иструментов из коробки (или как если бы вам поставляли набор балок для вашего каркаса вместо самого каркаса)
In a framework, all the control flow is already there and there are many predefined white spots that we should fill out with our code.
Фактически как и скрам, которые определяет некоторые события и артефакты (control flow) и что от них ожидается, а не просто набор практик.
nagaevr Автор
12.02.2022 17:23Я раньше так думал но нет, не сходится, скрам-гайд не содержит каркаса дома. Нету в нём "Сетунь-3".В нём есть только описание того что в скрам-доме есть стены, крыша, окна, двери, что ходить надо через двери, смотреть лучше через окна. Это круто но этого не достаточно для постройки дома на основе такого "фреймворка". Для постройки дома нужны навыки проектирования, инструменты, материалы, умение с ними работать, знание СНИПов. А в скрам-гайде этого нет. поэтому он и не дотягивает до фреймворка а годится только как стандарт.
Вот ещё аналогия: нельзя написать приложение на JPA, JPA это только стандарт, логику реализует реализация этого стандарта, например Hibernate. Твой код останется совместимым с JPA если выкинуть Hibernate из приложения но работать он перестанет.ApeCoder
12.02.2022 18:09Для постройки дома нужны навыки проектирования, инструменты, материалы, умение с ними работать, знание СНИПов
Каркас дома это не дом - посмотрите на картинку. Для постройки дома на основании каркаса нужны материалы для стен и прочее. В каркасе нельзя жить.
В случае скрама есть дополнительная информация - книжки и люди.
Как я понимаю, со скрам мастерами так же как и с психологами. Окончания ВУЗа недостаточно чтобы он был гарантировано полезен. Вот, напрмимер, статья про то, как человек их собеседовал и сколько он отсеял
nagaevr Автор
12.02.2022 18:59Да, каркас дома это не дом, но каркас дома это часть реализации дома, элемент его конструкции, физический объект, если использовать готовый каркас то часть работ можно будет не делать оперевшись на готовое. Скрам же это не каркас, это описание каркаса, его стандарт. Если каркас можно чем-то обшить, например сайдингом. То описание каркаса обшить не получится. Я поймал себя на мысли что пытаюсь обшить сайдингом стандарт не имеющий физического воплощения а сайдинг почему то падал на землю вместо того чтобы висеть на каркасе. Об этой несостыковке я и попытался рассказать.
ApeCoder
13.02.2022 13:21Если каркас можно чем-то обшить, например сайдингом. То описание каркаса обшить не получится.
В области информации каркас и есть описание. И так же как обшиание сайдингом (не знаю, обшивают ли на самом деле или как-то прикрепляют панели, а сайдинг это уже не то) требует сайдинга и навыков а не только каркаса (я, например, не смогу без дополнительного обучения), так же каркаса процесса недостаточно чтобы им овладеть.
Предствьте что Скрам это программный фрефмворк вот с таким кодом
public static void main() { IScrumTeam team = this.GetScrumTeam(); while (true) { var backlog = team.GetBacklog(); team.RefineBacklog(backlog); var sprintBacklog = team.GetSprintBacklog(backlog); team.DoBacklog(sprintBacklog, timeout: team.GetSprintLenght())() team.ReviewSprint(); var processChanges = team.PerformRetrospective(sprint); } }IScrumTeam это абстрактный интерфейс - задача конкретной команды его реализовать. Чтобы ее написать, надо знать алгоритмы, которые распространяются отдельно либо можете придумать самостоятельно, если готовые не устраивают.
Например, для backlog refinement надо знать техники декомпозиции PBI и для приоретизации тоже есть техники.
В вашем случае мне непонятно, почему скрам мастера не помогли.
По идее, их задача помось скоммуницировать команде - подружить вас с PO чтобы он смог вам обяснить почему не берутся в спринт предложенные вами изменения либо чтобы вы объяснили PO, почему их надо взять. PO мог бы помочь с определением бизнес-ценности того, что вы хотели сделать (например, поговорить с заинтересованными лицами) и тогда или бы PBI взяли в спринт либо вы бы могли сказать почему их не взяли.
KirillChe
11.02.2022 07:13+3Прочитал только треть статьи. Я нифига не разраб, я руководитель группы аналитиков много лет. И из жизненного опыта могу сказать только одно - когда самоцелью делают инструмент, результат обвалится как пить дать. Один из принципов agile в какойбы то ни было области - клиентоориентированность. А не мантры
grumbler70
11.02.2022 08:25+2Есть мнение, что SCRUM и AGILE это фичи, придуманные, чтобы тупо подольше водить за нос заказчика. Конечный результат или будет или нет, зато за каждый шаг, совершённый по пути к нему, сделанный демонстративно по обрядово-культовым стандартам, можно содрать подороже. А то, что шаг сам по себе не шибко то и ценен, скрыть под красивыми словами.
И совесть не мучает, и цена выше. Как там реально командра разработки внутри работает, задолбали их внутри эти обряды или нет, не так уж и важно. Как справедливо написали выше, есть нормальная команда - её сложно испортить всякой хернёй (хотя и можно, видел такое), нет нормальной команды - остается только продвавать воздух Заказчику, типа спринтов и посиделок.
ЧВС неумехам повышает, полных бездельников на "важную роль" брать позволяет, околорелигиозную бурную деятельность вокруг с хорошей такой капитализацией (коучи, конвенции и прочая шняга) создает? Создает. Проблему безработицы в итоге решает. Платим за весь это маскрад мы, потребители и бизнес. Никогда не доделанные кривые "Продукты" по завышенной стоимости. За репутацию отрасли, как производителей "херак - херак и в продакшн" спасибо именно этим двум вещам.
PS Абсолютную чушь продавать сложно, некое рациональное зерно в них есть, конечно. Но для людей с трезвым мышлением это зерно и так очевидно, не обязательно его в религию заворачивать.
dimskiy
11.02.2022 09:00+5Для себя вынес следующее про скрам: это странная игра, в которую обожают играть менеджеры, поэтому ты от нее никуда не денешься. Раньше все боролся, задавал неудобные вопросы... но проще относиться как к чужой блажи и просто выполнять необходимый минимум вещей, которые от тебя ждут. А работу свою строить так как тебе удобно
yakimchuk-ry
11.02.2022 09:17+1Обычно теряется зерно методологии – тесное взаимодействие и помощь разработчикам, проекту, и заказчику. Всё делается чтобы двигать проект и деловые отношения вперед, и методология, метрики, они помогают это делать, но это не цель. Можно работать и без них.
Проблема в том, что это очень общие слова, и наличие процессов часто начинает преобладать над реальной пользой от них. Вот поставили спринт две недели (как обычно), а от этого накрылся релизный пайп, ребята не успевают, и начал разваливаться обычный процесс. Вот зачем такой процесс нужен? Начинайте изучать процессы, делать инкрементальные изменения, отлаживайте, но не рушьте.
Поэтому я воспринимаю методологии как набор идей, как можно двигаться к лучшую сторону, как отлавливать проблемы по ходу и решать их, а не набор принципов которые можно применить и "все пойдет бодрячком". Нет, потому что первичен проект, и если есть проблемы, то хоть 1000 раз наложи правила, ничего не взлетит, потому что проект в них не вписывается, и поэтому правила диктуются проектом, а не проекту диктуются правила. Корень – проект.
Akon32
11.02.2022 10:35Вот поставили спринт две недели (как обычно), а от этого накрылся релизный пайп, ребята не успевают, и начал разваливаться обычный процесс.
Формально, скрам гайд допускает спринты до месяца. Почему выбрали 2 недели - вопрос к менеджерам, а не к скраму. Возможно, старый релизный цикл показался кому-то слишком долгим. Возможно, взяли некоторый "разумный" (но оказалось, не разумный) минимум, чтобы можно было быстрее внедрять задачи в продакшен. Ведь если менеджеру в начале спринта придёт в голову Идея, при спринте в 1 месяц она будет реализована в лучшем случае через 2 месяца - к концу следующего спринта. А при спринте в 2 недели - через месяц, это конечно долго, но ещё можно дождаться. С другой стороны, при спринте в 1 неделю на планирование и ретроспективу может уйти 2 дня из 5, и это выглядит не очень эффективно.
oleg40a
11.02.2022 09:58+7Скрам - это не стандарт.
Скрам - это не методология.
Скрам - это не фреймворк.
Скрам - это не Agile.
Скрам - это говно.
diogen4212
11.02.2022 10:05+1Как человек, пострадавший от скрама, могу сказать, что единственный путь — сменить работу, которая не нравится.
Не скажу, что выводы автора изменили что-то в моём отношении к скраму, но если ему стало легче, когда он осознал и высказал всё это — можно только за него порадоваться. Я в целом не верю, что людей можно в чём-то переубедить, особенно начальство (бизнес, менеджеры — не важно, как их зовут), которое приняло решение «работаем так и никак иначе».dimskiy
11.02.2022 17:59Куда бы вы не пошли, даже в стартап на 5 столов - будет все та же игра в скрам, увы :) Исключения очень редки
kest70
11.02.2022 10:57Больше скрама богу скрама. Один раз я попал на такой семинар. Стал скрам - мастером в последствии.
chateau
11.02.2022 11:03Сколько боли, сочувствую вам. Надеюсь, в будущем вам будут попадаться люди, которые смогут объяснить и направить в более подходящем для вас русле. Жаль, что вы воспринимаете рабочий процесс как битву за себя - вполне можно найти компанию, где рабочие процессы больше подходят под ваш темперамент и мировоззрение.
Smerig
11.02.2022 11:34Читал первую половину статьи автора, возмущался, что он что-то перечисляет, но не приводит конкретных примеров. Но как дошел до второй части, понял, что примеры и не нужны. Автор молодец, познал дзен. Если ему подобранные определения в скраме мешали понять скрам, то ничего страшного, если в итоге он заменил их на свои. Всё-таки скрам - это аджайл. Ну и в топку коучей с их каргокультом.
Я бы от скрама оставил только состав команды и ритуалы с необходимостью их выполнения. Запланированные ритуалы отвечали бы за итеративность, На ретро вносили бы изменения в свою работу. Пусть это бы ломало "гайды", но если оно крякает как утка и ведет себя как утка, то пусть это будет утка (пусть это будет скрам).
Роль скрам-мастера можно, и, наверное, нужно, отдать тим лиду: это его задача как servant leader. В принципе в этом и есть функция скрам-мастера наряду с модерированием встреч. Со временем, если мы говорим о самоорганизованной команде, встречи модерировать больше не придется, останется привычная многим роль тимлида. Рассматривайте архитектора как одного из заинтересованных лиц, пусть он через продакт овнера влияет на беклог. Ну или отдайте роль продакт овнера архитектору.
В общем, карго-культ в топку. Оправдывайте себя тем, что скрам - это аджайл, а по аджайлу важнее люди, а не процессы.
Throwable
11.02.2022 12:41+1Когда люди пытаются использовать стандарт как фреймворк единственное что они могут это следовать за нормами стандарта упуская из виду реализацию. Так, по моему мнению, и возникает карго-культ.
Часто использую понятие "карго-культ" в IT. Однако в моем понимании это по большей части следование моде, диктуемой "великими" брендами, бездумное и неоправданное использование навязываемых технологий и инноваций, и как индикатор -- полное отсутствие критики и критического мышления.
mfenderov
11.02.2022 13:20Это далеко не новость, к сожалению. Об это ещё лет 5+ назад на каждом углу кричал James Coplien, который по сути один из самых известных "популяризаторов" скрама в айти.
На текущий момент, всё это чистой воды коммерция. Людям придумали новые роли, в индустрии создали искусственный страх, что без этих ролей продукт не взлетит, и вот теперь мы имеем, что имеем. Толпы паразитов, цель которых, создать видимость хоть какой-то деятельности.
Но, бывают и исключения. Я работал с очень хорошими и полезными скрам-мастерами в хорошо организованном скрами, вот только все они были из разработки, или от бизнеса - бывшие девелоперы и бизнес-аналитики. "Чистые"-скрамы - это, конечно же, абсолютно бесполезные существа.
А есть ещё всякие крутые штуки, типа SAFe, где вообще миллион "менеджеров", и девелопмент где-то на задворках. Менеджмент дривен девелопмент, мать его.
MartaD
11.02.2022 13:59Насчёт малополезности коучей я согласна. Они будто не помощники, а надзорный орган, который следит, чтобы вы оставались в рамках.
Но в целом в статье очень много личного мнения и размышлений, при этом нет никакой конкретики, и ситуацию невозможно проанализировать. Можно только согласиться или не согласиться с автором на основании своего личного опыта. Невозможно проанализировать -> невозможно сделать выводы -> низкая практическая значимость текста. А заголовок - громкий.
Хотя один вывод, пожалуй, мы можем сделать: при возникновении проблем лучше их обсудить (с руководителем, с командой).
dididididi
11.02.2022 14:15Скрам придумали для менеджмента исследований, открытий чего-то нового, рисерча. Когда ты седня не знаешь, что будет дальше, потому что первый раз идешь по этой тропе. Он поэтому и гибкий, что ты не знаешь, что будет завтра и надо менять планы на лету.
По сути это неэффективный костыль, который позволяет идти наощупь, когда темно.
Проблема в том, что его используют и когда светло, оссобеено забавно звучит скрам из каких нить сберов-яндексов. Где всё распланировано на год вперёд, бюджеты выделены, фронт работ известен. А ты идешь наощупь)
Скрамом просто прикрывают некомпетентность, когда всё сроки сорваны, нифига не сделано, ты объявляешь фичу по изменению цвета кнопка, офигенно научным исследованием, делающимся впервые)
uoak
11.02.2022 14:28ну вот я не знаю деталей про computer science, но многие физики прекрасно без скрама справлялись и справляются. Например, атомную бомбу делали без явно выраженного скрама вроде бы, и у нас и в США. Хотя там хватало и менеджерских и фундаментальных проблем, и непредсказуемости. Не могу себе представить как какой-нибудь выпускник курсов скрам-мастера за 2 недели объяснял бы Энрико Ферми, как организовывать очистку урана.
Другое дело , что в атомных проектах была настолько высокая концентрация квалифицированных специалистов, что, как мне кажется, работал некий "стихийный agile", для которого были не нужны никакие манифесты и четкие frameworks. Наверное, было бы интересно сравнить их подходы с современными. Ну там может вместо daily просто была традиция пить кофе с утра в определенное время...
semennikov
11.02.2022 14:54С моей точки зрения мнение автора который утверждает что скрам - это стандарт, и относиться к нему надо как к стандарту а не как к руководству к действию очень похоже на реальность. Давайте вспомним такого зверя как ЕСКД, с одной стороны это конечно стандарт и его надо придерживаться, но если Вы мне покажете чертеж с соблюдением ВСЕХ требований стандарта, я очень удивлюсь, тем не менее все разумные требования стандарта все соблюдают. Так и скрам - это стандарт некоторой технологии разработки (есть и другие технологии!) и в нем есть разумные(обязательные) требования и желательные требования. Несоблюдение обязательных требований означает что Вы нарушаете выбранную вами технологию и ничего больше. Либо соблюдайте либо выбирайте другую технологию. С моей точки зрения автор высказал очень правильную мысль: Скрам - это стандарт технологии разработки но никак не учебник и не указатель. Возвращаясь к ассоциации с чертежом - стандарт говорит что допуск надо указывать таким и только таким образом, но ничего не говорит какой именно допуск нужно выбрать. Так и скрам говорит "Есть такая технология работы, если она Вас устраивает - делайте то то и тогда то. Не устраивает - ищите другую технологию, но не нарушайте эту"
mkardash
11.02.2022 14:56Отличный анализ и выводы. Это типичный пример того, почему скрам не agile - внедряторы делают все для процесса и игнорируют людей, команду - прямое игнорирование принципов agile, но т.к. внедряется скрам то всем всё равно. Всё должно быть с точностью до наоборот.
Ещё огромная проблема это то, что кому попало выдают сертификаты скрам-мастеров. Это просто бизнес, но в итоге люди как роботы повторяют мантры и процесс разработки начинает игнорировать мнение команды в угоду следования процессу.
Zifix
11.02.2022 15:31+2Странно, что ещё никто не запостил винрарное видео на тему:
Тяп-ляп и в продакшн
Pi-man
11.02.2022 16:05Ничего не могу сказать по теме, но как классно автор излагает! Умение доходчиво и увлекательно выразить мысль 80-ого уровня!
Chip1961
12.02.2022 13:32Автор столкнулся с тем, что инструмент не стал решением, а стал проблемой. Это нормально. Далеко не все инструметы являются решением всех проблем, даже если кто-то так считает. Например, есть фанаты идеологемы "если у вас есть молоток, то все проблемы вам представляются гвоздем", но очевидно, что молотком сложно вывернуть шуруп (а забить его вполне можно, с печальными последствиями).
Так и превращение SCRUM и AGILE в "универсальный молоток" автор наблюдал на своей шкуре.
Некое обожествление той или иной технологии (на манер религии, как верно написали выше) всегда выгодно только тем, кто её продает, а не тем, кто этим пользуется.
sparhawk
А почему столько «я»? Скрам же про команды вроде? Что по вашим вопросам думали другие члены команд?
chinakz
Вот интернет децентрализуют и не будет никаких команд ,это как если обезьянам выдать по клавиатуре ,то они вряд ли когда напишут на дисплее слово "Банан" .
bgBrother
bjornd
Понять что они написали Гамлет просто, понять что они написали нужный код невозможно https://en.wikipedia.org/wiki/Halting_problem
nagaevr Автор
Коллеги как-то работали, да и мои проблемы особо не влияли на их работу. А столько "я" потому что в основе статьи лежит не анализ процессов а анализ моей реакции на процессы.
sparhawk
Спасибо за ценное уточнение. Если ваши задачи не влияют на задачи коллег, а их задачи на ваши, то есть взаимодействие минимальное, то смысл всех Скрам-ритуалов сразу пропадает. Вернее, статус, планирование как процессы важны, наверное, но совершать их, сгоняя кучу людей на митинг, нет никакого смысла.
Имхо, на этим можно было бы и закончить статью, да и все обсуждение :)
А про «я» извините, очень уж бросается в глаза
thatsme
Гениально! Спасибо. Теперь, благодаря вам и я знаю, что именно меня в с
краме смущает.Хочу спросить, были-ли у вас подобные наблюдения? (абзац ниже)
При использовании скрам, информированность коллег, о состоянии дел в проекте в целом и в его частях, должна расти, однако этого не происходит. Время на информирование тратится больше, а информация отскакивает от сотрудников, в связи с тем что они в ней не заинтересованы, пока эта информация не станет им нужна. И тут они тратят время на её поиск и коммуникации с вами. Т.е. это исключительно человеческий фактор. Кол-во коммуникаций возросло, польза от коммуникаций уменьшилась.
nagaevr Автор
Нет, с таким не сталикался. Могу посоветовать спрость в профильном сообществе. Найти такие сообщества можно например здесь.