Comments 44
В реальности программист работает не на себя, как в приведенном примере Уэджвуда, а на компанию, соответственно основным выгодоприобреталем оказываются собственники компании.
Что остается Мастеру? Признание со стороны окружающих? Нет. Код в подавляющем большинстве компаний закрыт под NDA.
Большинство людей в команде являются ремесленниками, и как естественное их качество, упомянутое в статье, это следование традициям, сопротивление новшествам и сохранение статус-кво. Случайно появившийся в команде Мастер без сильнейшей административной поддержки будет отторгнут командой.
Теперь представим уникальный случай когда в команде много мастеров. Рабочий вариант? Нет. У каждого мастера свое целостное видение, и их энергия будет тратиться в бесконечных обсуждениях, дискуссиях, согласованиях, отставания своей правоты перед начальством которое мало что понимает в предмете.
Поэтому для больших проектов не уйти от разделения труда и иерархии по степени мастерства. Приносимая scrum демократия работает очень плохо именно потому что большинство голосов отдаются общепринятому и всем удобному варианту. В одной команде может быть один человек разбирающийся в технологии X, другой в технологии Y и третий в технологии Z, и каждый из них при попытке привнести что-то новое в то в чем они являютя наиболее компетентными будут оказываться в меньшинстве при голосовании. Пример из жизни если что 🙂
Приносимая scrum демократия работает очень плохо именно потому что большинство голосов отдаются общепринятому и всем удобному варианту.
Да, тирания большинства -- страшная вещь.
Пример из жизни если что 🙂
Жиза. :-)
"тирания большинства -- страшная вещь". Вот серьёзно, не понимаю откуда вы это берете? Какая может быть "тирания" в небольшой группе компетентных специалистов различного профиля, объединенных общей целью?
Вот серьёзно, не понимаю откуда вы это берете?
Как гласит достаточно известная цитата Аптона Синклера: "It is difficult to get a man to understand something when his salary depends on his not understanding it."
Из своего многолетнего опыта работы в командах, следующим Scrum-культу. Замечу так же, что в роли разработчика, -- предполагаю, что вы, будучи служителем культа, не замечаете совершенно очевидных недостатков этого подхода.
Какая может быть "тирания" в небольшой группе компетентных специалистов различного профиля, объединенных общей целью?
О, опять этот пафос. "Скованных одной цепью, связанных одной целью", не иначе.
Внезапно далеко не все специалисты в группе одинаково компетентны. Так же имеет место специализация. По ускоспециализированным вопросам неспециалисты переголосовывают специалистов -- просто берут числом, предпочитая менее удачные инженерные решения, которые потом приводят к переделыванию и исправлению ошибок.
Только, пожалуйста, не надо говорить, что это был "ненастоящий коммунизм Scrum" и что "пока что настоящий коммунизм Scrum ещё ни в одной стране команде не был построен".
Приведите практический пример, пожалуйста. Какой-нибудь реальный кейс по решению scrum командой задачи, когда «По ускоспециализированным вопросам неспециалисты переголосовывают специалистов -- просто берут числом, предпочитая менее удачные инженерные решения, которые потом приводят к переделыванию и исправлению ошибок».
Без проблем -- но в общих деталях, т.к. NDA и анонимность.
Есть серверный enterprise solution, вторая его итерация (первая итерация очень старая и на другом языке программирования). Для его работы требуются данные, хранимые в реляционной БД. Часть данных генерируется пользователем локально. Другая часть данных должна быть получена с сервера разработчиков этого солюшена используя REST API и должна регулярно синхронизироваться (т.е. в выдаче API появляются новые записи -- они должны добавляться, если в выдаче API записи исчезают -- они должны удаляться из локальной БД).
Как это было сделано в первой итерации солюшена в БД: две колонки с ID записи. Одна колонка -- локальный ID с автоинкрементом, вторая колонка -- внешний ID, как он есть в выдаче API. Если запись локальная -- вторая колонка пустая. Из-за этого страшная путаница в коде, несколько инцидентов с использованием неверной колонки в коде и в миграциях БД.
Предлагаемое решение для новой итерации солюшена: сделать одну колонку c уникальным ID в БД, имплементировать какой-нибудь способ для различения локальных и внешних записей (префиксы, например).
Альтернативный вариант: оставить всё как было в предыдущей итерации проекта, но это снова означает путаницу в коде и ожидается, что из-за этого опять будут инциденты с данными на пользовательских системах.
Состав команды: номинально, все fullstack-инженеры. Фактически -- есть специализация: фронтендищики и бэкендщики, плюс разделение на тех, кто в основном работает над серверным API и тех, кто больше работает над солюшном для клиентских машин. Также представлены инженеры всех уровней опыта (от стажёра до сениоров). Команда работает по скраму: скрам-мастер, спринты, груминг, скрам-покер, ретроспективы и всё такое.
На груминге на обсуждение выносятся оба варианта. Бэкендщики и работающие в основном над пользовательским солюшеном голосуют за вариант сделать как-нибудь нормально, чтобы без путаницы (в их числе тим-лид команды). Фронтендщики и те, кто над обеими итерациями пользовательского солюшна работали не очень активно, голосуют за вариант "не надо ничего менять, это всё сложно, мы не понимаем зачем это".
В итоге большинством голосов побеждает вариант "ничего не менять". Тим-лид команды, к слову, говорит: "Я поддерживаю нормальное решение, но если большинство команды решило ничего не менять, то ничего менять не будем". Через год в одном из апдейтов нового солюшна из-за путаницы с колонками в новый солюшн привносится баг, приводящий к проблемам с синхронизацией и потерей данных на стороне пользователя -- успешно пролетев мимо интеграционных и юнит-тестов со 100% покрытием кода и обязательного код-ревью. По итогу гневные суппорт-тикеты от пользвователей, эмерженси-фиксы и всё такое.
Ок, а как по вашем должно было бы все проходить?
Нет, погодите, вот давайте только пока не будем стрелу переводить. Вы попросили привести практически пример -- я привёл. Вот теперь вы потрудитесь объяснить, как так вышло, что команда честно выполняла все ритуалы, предписанные сектой божественного Scrum'а, членом которой вы являетесь, а к триумфу Мастерских Мастеров это почему-то не привело. Почему?
Вы же наверняка знаете, что такое "карго-культ"? Если нет -- то почитайте сами на досуге. Так вот, Scrum -- это тоже карго-культ. Туземцы строят взлётно-посадочные полосы и диспетчерские вышки из гов земли и палок, а самолёты с грузом почему-то не прилетают. И тут так же: и стендапы, и ретроспективы, и груминг, и прочий скрам-покер, -- а где положительный результат-то?
Весь мозг своими безумными ритуалами проели, а внезапно выясняется, что результат зависит не от ритуалов, а от навыков конкретных людей, которые выполняют конкретные задачи и принимают конкретные решения.
Есть такой термин, как карго-scrum, когда данный фреймворк рассматривается только как набор определенных событий, не углубляясь в его суть.
Но давайте все таки будем последовательными и выслушаем ваше мнение о том, как на сам деле (то есть правильно с вашей точки зрения) должно было бы все проходить в вашем кейсе, чтобы по итогу не получить "гневные суппорт-тикеты от пользвователей, эмерженси-фиксы и всё такое".
А, ну то есть это всё-таки был "неправильный коммунизм Scrum"? Но вот вы-то, конечно, знаете, как сделать правильный Scrum?
По моему мнению не нужно было играть в эти глупые ритуалы. Голосование по принципу простого большинства по техническим вопросам смысла не имеет. Нужно было отдать принятие решений людям, обладающим наибольшей экспертизой в предметной области: фронтендщики принимают решения по фронтенду, бэкендщики -- по бэкенду. А для развития экспертизы в смежных компетенциях нужно использовать задачи без подводных камней.
Да, судя по вашим реакциям и тому, что вы пишите в комментариях, от Scrum вы взяли только названия событий (и листья для самолета).
Если паяльник держать не с той стороны, то его эксплуатация может вызывать сильную боль. Ну и, как следствие, желание потом писать про эту боль на Habr. Хотя вроде бы паяльник - это просто инструмент, созданный для определенных целей.
Пока мы не закопались еще глубже, хочу отметить, что в Scrum уделяется большая важность экспертному мнению и если команды испытывает в нем недостаток, то ей перед принятием каких-либо решений необходимо запросить доп.консультацию у специалистов. Ну и на практике, если команда оценивает какую-то задачу, то всегда учитывается мнение того, чей функционал является в ней ведущим, а не просто «большинством голосом». Да и вообще про «голосование» в Scrum гайде например нет ни слова. Без понятия откуда вы это берете.
Но давайте будем более предметными и последовательными. Правильно ли я понял из вашего ответа по кейсу, что если дать возможность: «фронтендщики принимают решения по фронтенду, бэкендщики -- по бэкенду» то в результате их деятельности через год никогда не будет тех проблем, о которых вы писали выше?
Да, судя по вашим реакциям и тому, что вы пишите в комментариях, от Scrum вы взяли только названия событий (и листья для самолета).
Конечно, это именно я во всём виноват -- потому, что я грешник и недостаточно сильно веровал в Scrum. И да, и Scrum-master тоже был ненастоящий, а сделанный из палок и листьев. А вот вы -- молодец! Настоящий, истинный, непорочный и непогрешимый! :-)
что в Scrum уделяется большая важность экспертному мнению
Я уже высказал вам своё экспертное мнение, что Scrum -- это культ, и вам надо с ним завязывать. Пожалуйста, уделите внимание :-)
Да и вообще про «голосование» в Scrum гайде например нет ни слова. Без понятия откуда вы это берете.
Вы сами недавно в другой ветке комментариев рассказывали про "уравнение труда", "коммандную организацию" и предпочитали их "иерархичному взаимодействию". В кейсе имеем как раз то, за что вы агитируете -- решения принимаются коммандно. Но т.к. практике результаты не совпадают с вашими фантазиями о всеобщем равенстве и благорастворении, вы тут же переобуваетесь и говорите "в Scrum этого вообще нет, откуда это вы взяли".
Но давайте будем более предметными и последовательными. Правильно ли я понял из вашего ответа по кейсу, что если дать возможность: «фронтендщики принимают решения по фронтенду, бэкендщики -- по бэкенду» то в результате их деятельности через год никогда не будет тех проблем, о которых вы писали выше?
Да, конечно, давайте будем предметными и последовательными и опять не будем стрелу переводить. Вы же носитель истинного знания о том, как должен работать божественный Scrum -- вот и потрудитесь рассказать глупым туземцам, как должно было работать принятие решений в этом кейсе по настоящему, правильному Scrum'у.
Но почему бы и нет, отвечу вам и на ваш вопрос тоже: избежать проблем удалось бы с гораздо более высокой вероятностью. И нет, абсолютно всех проблем избежать бы действительно не удалось. Однако, возникшие проблемы при таком способе принятия решений были бы результатом решений, принятых исполнителями, а не навязанными посторонними людьми. Для инженера ситуация "я принял неверные технические решения и из-за этого возникли пробемы" гораздо более предпочтительна ситуации "мне пришлось выполнять решения, навязанные мне посторонними людьми, с которыми я не согласен". В первой ситуации человек исправляет свои ошибки, учится на них и на этом ситуация исчерпана, тогда как во второй -- возникает неразрешаемый конфликт и отсутствует возможность для обучения. Странно, что вы сами не понимаете таких базовых вещей про мотивацию отдельных людей и их взаимодействие в команде. В вашем священном писании про это не написано?
.
Как я уже писал много раз в этом странном диалоге: Scrum — это не религия, а инструмент. Его кто-то может любить, кто-то считать не удобным. Но, как и любой инструмент в разных руках он может либо причинить пользу, либо вред. И у него, как у каждого инструмента есть инструкция по эксплуатации. Если вы ее не читаете перед началом работ, то вероятность получения вреда резко возрастает.
Опять же не стоит ожидать, что какой-либо метод организации труда сразу решит все ваши проблемы. Ну и же винить только его во всех ваших бедах.
Вы пишите: "Вы сами недавно в другой ветке комментариев рассказывали про "уравнение труда", "коммандную организацию" и предпочитали их "иерархичному взаимодействию. В кейсе имеем как раз то, за что вы агитируете -- решения принимаются коммандно."
Поиск командного решение не равно «голосование». Да, команда должна сама решить, как она будет выполнять работу, учитывая при этом все вводные, наличие у кого-то в команде узкой экспертизы, например. И я уже приводил пример по этому поводу.
Ну и, кажется, вы неправильно прочитали мой комментарий. Я спрашивал вас: «Какой формат управления и организации труда для вас более приемлем?»
И судя по тому, что вы так усердно боритесь с фреймворком в основе которого лежит командное взаимодействие, а также уважение к экспертному мнению каждого участника команды, то вероятно вы предпочитаете более классические схемы: типа «я начальник – ты дурак». Меньшое зло «двух иерархичных систем»?)
С другой стороны дальше вы вроде пишите весьма правильные (с моей точки зрения) слова: «Для инженера ситуация "я принял неверные технические решения и из-за этого возникли пробемы" гораздо более предпочтительна ситуации "мне пришлось выполнять решения, навязанные мне посторонними людьми, с которыми я не согласен». Вроде это как раз в духе Scrum. Решения по реализации принимают сами исполнители.
И возможно, в вашем кейсе, если бы ситуация сложилась чуть по-другому, и позиция другого тимлида (или менеджера) была бы: оставляем все как есть. А команда настояла бы на другом (нормальном) решении, которое положительно бы сказалось на качестве. То сейчас вы был писали в кометах: «Scrum – сила»? )
Как я уже писал много раз в этом странном диалоге: Scrum — это не религия, а инструмент.
Религия, внезапно, это тоже инструмент.
Поиск командного решение не равно «голосование». Да, команда должна сама решить, как она будет выполнять работу, учитывая при этом все вводные, наличие у кого-то в команде узкой экспертизы, например.
Хорошая попытка съехать с темы, но нет. Сначала вы не верили, что неспециалисты могут переголосовать специалистов и возмущались на тему "тирании большинства". Цитирую вас: "Вот серьёзно, не понимаю откуда вы это берете?" Я так понимаю, теперь вы поверили в тиранию большинства, но продолжаете съезжать с темы: работа должна быть командной, но не голосование. Хорошо, а что именно? Расскажите.
И я уже приводил пример по этому поводу.
Какой? Приведите ещё раз. Или у вас клавиши Ctrl+C на клавиатуре сломались?
Ну и, кажется, вы неправильно прочитали мой комментарий. Я спрашивал вас: «Какой формат управления и организации труда для вас более приемлем?»
Нет, это либо вы неправильно написали, либо опять пытаетесь съехать с темы. Вы спросили: "Чтобы ответить на эти вопросы, надо сперва понять, что вы пытаетесь противопоставить Scrum? Если не он, то что?" -- и я вам ответил: агностический подход, без всяких ритуалов и священных писаний.
И судя по тому, что вы так усердно боритесь с фреймворком в основе которого лежит командное взаимодействие, а также уважение к экспертному мнению каждого участника команды, то вероятно вы предпочитаете более классические схемы: типа «я начальник – ты дурак». Меньшое зло «двух иерархичных систем»?)
Это очень смешно слышать от вас, учитывая, что это именно вы и ваш хвалёный Scrum работаете по схеме "я начальник -- ты дурак". На все проблемы у вас один универсальный ответ: Scrum это инструмент, вы не читали инструкцию, вы неправильно им пользуетесь, вы хейтер и вообще Scrum у вас был из листьев и палок и т.д. по тексту. При этом, сами объяснять, в чём именно проблема вы отказываетесь. Уже третий раз спрашиваю: хорошо, раз вы так прекрасно умеете этим инструментом пользоваться, расскажите как надо было делать. Но нет, внезапно никакого ответа у вас нет и вы продолжаете повторять "вы неправильно пользуетесь".
Вроде это как раз в духе Scrum. Решения по реализации принимают сами исполнители.
Т.е. вы сами не уверены, в духе Scrum это или нет? Вы уж там определитесь наконец. Я вот не знаю, у меня же Scrum из листьев и палок и вообще я инструкцию не читал.
И возможно, в вашем кейсе, если бы ситуация сложилась чуть по-другому, и позиция другого тимлида (или менеджера) была бы: оставляем все как есть. А команда настояла бы на другом (нормальном) решении, которое положительно бы сказалось на качестве. То сейчас вы был писали в кометах: «Scrum – сила»? )
Если бы бабушка была дедушкой. Но внезапно выяснилось, что если бабушка будет применять Scrum, то дедушкой она не станет.
И уже в третий раз повторяю свой вопрос, вы по жизни в Scrum кто? Разработчик, Scrum-Master или Product-Owner?
Обо мне написано в моем профиле. Я, выражая свои мысли, не прячусь за noname аватаром.
И для продолжения этого диалога мне бы все-таки хотелось, чтобы он держалась в конструктивном русле. И был более предметным. А то ваша манера вести диалог (со всей это религиозной примесью) больше напоминает крестовый поход, чем профессиональное мнение.
Отвечая на мой комментарий выше, вы, кажется, очень спешили, поэтому полностью проигнорировали его смысл. Давайте немного подрезюмирую, чтобы быть ближе к предмету диалога:
Scrum – это фреймоворк (не религия) организации деятельности команд для совместной их работы в условиях высокой неопределённости. В его основе лежит эмпиризм и деятельность кроссфункциональных команд (не более 10 человек), построенной на принципе самоорганизации.
Это подразумевает, что только сама команда решает, как ей делать ее работу и сама несет ответственность за результаты своей совместной деятельности.
Никто не навязывает команде решений по технической стороне реализации взятых задач. (только сами исполнители решают, как им делать их работу). Но команда может запросить экспертное мнение от узких специалистов или обратиться за поддержкой к техлидам по различим направлениям. Более того только сама команда определяет свою нагрузку на каждую итерацию, используя для этого эмпирические данные.
РО только определяет приоритетность тех или иных задач, основываясь на своих исследованиях, и помогает команде разораться в бизнесовой стороне вопроса. Для команды он скорее бизнес партнёр, с которым они также объединены одной целью.
Scrum мастер не руководит командой, а помогает ей в развитии самоорганизации и повышении качества внутренних и внешних коммуникаций. В Альфа банке роль командного Scrum мастера выполняет (совмещает) один из участников команды разработки.
Scrum – весьма сбалансированный инструмент, который однако не исключает интеграцию других практик. И является для них обёрткой (ну или коммуникационным каркасом). Но как и любой инструмент при не правильной эксплуатации, или поверхностном понимании, он может причинить больше вреда, чем пользы. Что в большинстве случаев и является причиной негатива.
Например, когда от Scrum берется только название событий (и формируется карго Scrum), но при этом команду лишают возможности самоорганизации. Процветает микроменеджмент. Или игнорируется суть итерационного инкрементного подхода.
Также стоит отметить, что Scrum применим не везде. Он, как и другие Agile фреймворки создавался в первую очередь для области разработки, так как она относится к среде с высокой неопределённость. И другие подходы, построенные на классических принципах организации труда сильно сказывались на итоговом качестве программных продуктов. Очень хорошо по этой теме написал Роберт Мартин («дядя Боб»). Кстати, так как он являлся инициатором встречи, на которой был подписан Agilе манифест, то его вопле можно назвать отцом Agile.
У каждого из нас свой профессиональный опыт. Я начинал, как инженер и потом перешел в управление. Мне приходилось работать в различных коллективах, с различными подходами к организации труда. В Agile я пришел уже достаточно зрелом возрасте, имея за спиной весьма солидный опыт работы в организациях, где процессы были построены на принципах классического менеджмента.
И по моему мнению, которое я и отразил в этой статье, принципы на которых построен Scrum (и которые раскрыты в Agilе манифесте) формируют рабочую среду с самым хорошим микроклиматом, и способствуют профессиональному развитию специалистов, вовлеченных в свою деятельность.
У вас, как я понимая, было по другому
Обо мне написано в моем профиле.
Замечательно. Не прошло и трёх дней, как вы всё-таки решили написать, что вы Scrum-Master.
Я, выражая свои мысли, не прячусь за noname аватаром.
А зря. И что теперь?
Отвечая на мой комментарий выше, вы, кажется, очень спешили, поэтому полностью проигнорировали его смысл.
Это вы полностью проигнорировали мой комментарий и продолжаете съезжать с темы.
Давайте немного подрезюмирую, чтобы быть ближе к предмету диалога:
Мне кажется вы не вполне понимаете смысл слово "подрезюмировать", но да ладно. Давайте я тоже подрезюмирую:
Scrum -- религиозное верование, обладающими следующими признаками:
Вера в сверхъестественную силу Scrum;
Имеет священное писание (Manifesto of Agile Software Development);
Имеет набор магических ритуалов (стендапы, груминг, ретроспективы, Scrum-покер и т.д.);
Отправлением культа занимается духовенство (Scrum-Master).
Основная цель Scrum -- повышение ЧСВ Scrum-Master'а.
Правила Scrum:
Scrum всегда работает и помогает прийти к успешному успеху;
Если Scrum не работает -- см. пункт 1, и вообще это был ненастоящий Scrum, а Scrum из листьев и палок, и пользовались вы им неправильно, и инструкцию не читали, и вообще "сам дурак" :-)
Приветствую вас, товарищи скрам-мастера и любители зачеркивать коммунизм ) Как же много вы пишете... Взял для разбора одно сообщение, ибо всё даже прочитать непросто.
Позвольте поучаствовать
1. Вы пытаетесь выяснить правду в переписке, в которой это сделать невозможно. Чат - не тот формат, в котором раскрывается истина. А вот холивары здесь процветают. Но я всё равно здесь, каюсь...
2. «что вы Scrum-Master» - это роль в команде, а не что-то, характеризующее компетенции или хотя бы мнение человека. Бессмысленно привязывать к этому дальнейшее рассуждение.
3. «кажется вы не вполне понимаете смысл слово "подрезюмировать"» - это и многое другое всего лишь манипуляция. Эти приёмы не ведут к истине, и засоряют обсуждение.
4. «Scrum -- религиозное верование» - некорректное утверждение. Scrum это инструмент, вокруг которого появилась религия. Есть те, кто умеют им пользоваться, и эти люди разбираются в вопросе, в целом (проектное управление и другие инструменты, связанные не только со Scrum’ом). Есть те, кто не разбирается в вопросе, и для них Scrum и прочее - это магия. Отсюда и религия.
5. «Вера в сверхъестественную силу Scrum» - Вы нарушаете законы логики, ибо из факта существования такой веры не следует равенство одного другому.
6. «Имеет священное писание (Manifesto of Agile Software Development)» - у Scrum’а есть гайд. Манифест не является священным писанием. Команды могут работать по гайду вообще не прочитав манифест. Тут совсем уж мимо.
7. «Имеет набор магических ритуалов» - про магию я уже сказал. А если встречи оказались бесполезными, стоит задуматься, не схватили ли вы всей командой паяльник за жало, как приводили пример выше.
8. «Отправлением культа занимается духовенство (Scrum-Master)» - духовенство это система (обычно, иерархичная структура). Scrum - инструмент, который может применить любой без всяких сертификатов. Просто взять и использовать.
9. «Основная цель Scrum -- повышение ЧСВ Scrum-Master'а» - фу таким быть ))) но если уж честно, такие кейсы я тоже встречал. В эту роль попадают обычные люди, а люди разные. Но опять же, если уберёте обиды и добавите логику, писать такое перестанете.
10. «Scrum всегда работает» - многие так и думают. Но это можно приписать любому подходу.
А теперь резюме )
Карго-культ - это этап зрелости (команды, человека, системы). Не все от него переходят к осознанному состоянию.
Странно при всей структурности Вашего рассуждения выше наблюдать такие грубые логические ошибки. Это объясняется только умышленной подменой или болезненным опытом. Не буду раскрывать дальше эту тему без надобности, но оба варианта говорят о том, что эти утверждения ошибочны.
НО соглашусь, вокруг Scrum’а есть муар загадышности, который навеян не им и ему же вредит.
Предвкушая вот эти «Ага, он тоже скрам-мастер!!!» Нет. Я не скрам-мастер. Я радиомеханник и программист с опытом работы как по классическим методам, так и по «гибким». Я уважаю Scrum... но не больше, чем PMBoK, Agile, Kanban и самодельные костыли, когда всё это применяется прямыми руками.
Как же много вы пишете... Взял для разбора одно сообщение, ибо всё даже прочитать непросто.
Вы напрасно берётесь читать с конца, вы пропустили много важного контекста в беседе и у вас из-за этого ко мне ниже будут претензии.
Вы пытаетесь выяснить правду в переписке, в которой это сделать невозможно. Чат - не тот формат, в котором раскрывается истина. А вот холивары здесь процветают. Но я всё равно здесь, каюсь...
Интернет и холивары созданы друг для друга. :-)
«что вы Scrum-Master» - это роль в команде, а не что-то, характеризующее компетенции или хотя бы мнение человека. Бессмысленно привязывать к этому дальнейшее рассуждение.
Безусловно характеризует. Как вы можете понять, я категорически против Scrum'а, и ни при каких обстоятельствах Scrum-Master'ом например я бы не стал. Соответственно, человек, который является Scrum-Master'ом, так или иначе разделяет это религиозное учение.
«кажется вы не вполне понимаете смысл слово "подрезюмировать"» - это и многое другое всего лишь манипуляция. Эти приёмы не ведут к истине, и засоряют обсуждение.
Вы это пишете только потому, что поленились прочитать предыдущие сообщения в дискуссии. Вместо ответа на заданные вопросы собседеник пишет "резюме" на две страницы текста, на вопросы никак не отвечающие. Резюме должно быть кратким, отсюда и замечание.
«Scrum -- религиозное верование» - некорректное утверждение. Scrum это инструмент, вокруг которого появилась религия. Есть те, кто умеют им пользоваться, и эти люди разбираются в вопросе, в целом (проектное управление и другие инструменты, связанные не только со Scrum’ом). Есть те, кто не разбирается в вопросе, и для них Scrum и прочее - это магия. Отсюда и религия.
Вы хотя бы признаёте, что религия имеет место -- уже хорошо. По моему мнению, те люди, которые действительно разбираются в вопросе, осознают проблему с религиозной составляющей, отходят от догматичности и перестают агитировать за Scrum. Вместо этого они занимаются работой, а не восхвалением Scrum.
«Вера в сверхъестественную силу Scrum» - Вы нарушаете законы логики, ибо из факта существования такой веры не следует равенство одного другому.
Scrum описывает всевозможные процессы, техники и приёмы и обещает улучшение при их использовании. Однако, дело не в процессах и не в техниках, а в людях. Собственно поэтому я и говорю о вере в сверхъестественную силу Scrum.
«Имеет священное писание (Manifesto of Agile Software Development)» - у Scrum’а есть гайд. Манифест не является священным писанием. Команды могут работать по гайду вообще не прочитав манифест. Тут совсем уж мимо.
Вы и правда думаете, что есть какие-то команды, которые работают по Scrum и не читали Agile Manifesto? Но ОК, чтобы вы не обижались, я не вижу никаких проблем в том, чтобы Scrum Guide тоже причислить к священному писанию. Agile Manifesto -- это примерно как Ветхий Завет, а Scrum Guide -- как Новый Завет.
«Имеет набор магических ритуалов» - про магию я уже сказал. А если встречи оказались бесполезными, стоит задуматься, не схватили ли вы всей командой паяльник за жало, как приводили пример выше.
Ну да, когда магические ритуалы не срабатывают -- значит вы в них недостаточно верили и вообще что-то неправильно сделали. Именно такой логикой в магии оно и объясняется.
«Отправлением культа занимается духовенство (Scrum-Master)» - духовенство это система (обычно, иерархичная структура). Scrum - инструмент, который может применить любой без всяких сертификатов. Просто взять и использовать.
Пожалуйста, сделайте мне одолжение, загляните в словарь или энциклопедию и посмотрите там определение слова "духовенство". Также, возможно вы не в курсе, но среди религиозных сект есть те, которые имеют духовенство (например, все доминирующие деноминации авраамических религий) и те, которые духовенства не имеют -- у них нет специальных людей, занимающихся отправлением культа. Среди христианских деноминаций это, например, беспоповцы, квейкеры и прочие амиши. Так вот, Scrum -- это религия, которая духовенство имеет. Scrum-Master -- это человек, который занимается отправлением Scrum-культа.
«Основная цель Scrum -- повышение ЧСВ Scrum-Master'а» - фу таким быть ))) но если уж честно, такие кейсы я тоже встречал. В эту роль попадают обычные люди, а люди разные. Но опять же, если уберёте обиды и добавите логику, писать такое перестанете.
Опять-таки, я рад, что вы хотя бы признёте, что проблема имеет место. По моему мнению, приличный и уважаемый человек Scrum-Master'ом быть не может. Фу или не фу -- ну сорян, такой личный опыт, имею право иметь мнение.
«Scrum всегда работает» - многие так и думают. Но это можно приписать любому подходу.
В третий раз, вы хотя бы признёте, что проблема имеет место -- это уже прогресс.
Карго-культ - это этап зрелости (команды, человека, системы). Не все от него переходят к осознанному состоянию.
А вот я бы сказал, что к осознанности приходит подавляющее меньшинство. И им никакая религия не нужна, будь то Scrum или что-то ещё.
Странно при всей структурности Вашего рассуждения выше наблюдать такие грубые логические ошибки.
Ошибками они являются только по вашему мнению, на некоторые проблемы в том, что написали вы -- я тоже вам указал.
Это объясняется только умышленной подменой или болезненным опытом.
Аж пичот! :-)
Не буду раскрывать дальше эту тему без надобности, но оба варианта говорят о том, что эти утверждения ошибочны.
Хорошая попытка, но нет.
НО соглашусь, вокруг Scrum’а есть муар загадышности, который навеян не им и ему же вредит.
Прогресс, прогресс! Одобряю.
Предвкушая вот эти «Ага, он тоже скрам-мастер!!!» Нет. Я не скрам-мастер.
Ну и слава Богу. :-)
А при чём тут scrum? Как говорится в манифесте "Люди и их взаимодействие важнее процессов и инструментов". Так вот, scrum - инструмент. Без адекватного обсуждения и здравого смысла не получится результата. Ни scrum, ни Будда, ни другие аватары в этом не помогут неведомой магией.
Напомню, scrum - это фреймворк. Он не делает работу за вас. Он даёт рельсы. А вот вагонетки с золотом таскать всё ещё надо самим. И если вы то сталкиваетесь, то хватаетесь за чужую вагонетку, тут не рельсы виноваты. Голову включать надо.
Как вообще можно догадаться принимать решение по технической реализации путём голосования? Только аргументы и их опровержение даёт результат. Остальное (демократия или призыв к авторитету) - эт всё от лукавого (+5 мне в карму за отсылку к религии)
А при чём тут scrum? Как говорится в манифесте "Люди и их взаимодействие важнее процессов и инструментов". Так вот, scrum - инструмент. Без адекватного обсуждения и здравого смысла не получится результата. Ни scrum, ни Будда, ни другие аватары в этом не помогут неведомой магией.
Вы ж меня сами буквально только что убеждали, что манифест к Scrum'у отношения не имеет. :-)
Напомню, scrum - это фреймворк. Он не делает работу за вас. Он даёт рельсы. А вот вагонетки с золотом таскать всё ещё надо самим. И если вы то сталкиваетесь, то хватаетесь за чужую вагонетку, тут не рельсы виноваты. Голову включать надо.
Да-да-да, когда Scrum не работает -- то это был неправильный, ненастоящий Scrum из листьев и палок. Спасибо, это мы уже выяснили.
Как вообще можно догадаться принимать решение по технической реализации путём голосования? Только аргументы и их опровержение даёт результат. Остальное (демократия или призыв к авторитету) - эт всё от лукавого (+5 мне в карму за отсылку к религии)
Не знаю, вот догадались как-то. Scrum это как-то запрещает? Автор статьи вот например вообще в тиранию большинства не верил, собственно для этого и был приведён пример.
Вы ж меня сами буквально только что убеждали, что манифест к Scrum'у отношения не имеет. :-)
где? там, где я сказал, что команда может запуститься без манифеста? ну это уже подмена фактов. Не надо навешивать то, чего я не говорил. Нормально же общались.
А здесь я привел цитату из манифеста в качестве ценности, которую разделяю. Я не говорил, что это из скрама, не говорил, что скрам и agile не связаны. Но они не одно целое. Можно найти связи скрама с PRINCE2, а при желании (и, возможно, шизофрении) с левым ботинком на правой ноге. Но это никак не складывается в логическую цепочку.
сделайте мне одолжение, загляните в словарь или энциклопедию и посмотрите там определение слова "духовенство"
Много пафоса. Во-первых, мы говорили про религию, а не духовенство. Во-вторых, смысл был не в том, что любая религия имеет четкую структуру. Если применять Ваш подход, то религией можно назвать и молоток, и гвоздь, и черешню. Кроме того, терминология этой области знаний не так конкретна, чтобы её можно было использовать для параллелей.
Да-да-да, когда Scrum не работает -- то это был неправильный, ненастоящий Scrum из листьев и палок. Спасибо, это мы уже выяснили.
Напомню, скрам - инструмент. Как молоток может не работать? Правильно, только в кривых руках или там, где нужен не молоток. Перестаньте воспринимать скрам, как кого-то кто должен думать за вас. Рассуждения из этой цитаты бессмысленны. Скрам не бывает правильным или неправильным. Бывают ошибки в его применении. И основная из них - вера в магию.
И, пожалуй, последнее, что я Вам скажу (если не появится стоящих аргументов):
Фанатичная позиция против скрама столь же абсурдна и непрофессиональна, как фанатичная позиция за скрам. Вы много сказали о скрам-мастерах, которые вслепую топят за скрам. Но при этом, переняли на себя их же минусы и слабости. Вы отторгаете инструмент сам по себе в отрыве от конкретных областей их применения. Эта позиция не может быть правильной или, хотя бы, логичной.
приличный и уважаемый человек Scrum-Master'ом быть не может
если приличие и уважение требует от меня отказаться от здравого смысла, то я, пожалуй, оставлю такое уважение Вам и неадекватным скрам-мастерам. Хотя, почему "и"? В контексте Вашего рассуждения, Вы - "скрам-мастер".
P.s.: коллеги (ну, мне так кажется), а давайте просто делать работу хорошо? и применять молоток там, где надо забивать гвозди, а скрам там, где он причинит пользу, а не название.
где? там, где я сказал, что команда может запуститься без манифеста? ну это уже подмена фактов. Не надо навешивать то, чего я не говорил. Нормально же общались.
Вы в одном месте пишете: "у Scrum’а есть гайд. Манифест не является священным писанием. Команды могут работать по гайду вообще не прочитав манифест. "
В другом месте вы пишете: "А при чём тут scrum? Как говорится в манифесте "Люди и их взаимодействие важнее процессов и инструментов"".
Если можно работать по Scrum не читая манифест, то какая тогда разница, что написано в манифесте? Зачем вы приводите цитату из манифеста в дискуссии про Scrum? Вы мне всё пытаетесь про ошибки логики рассказывать, а у вас-то с логикой что?
Во-первых, мы говорили про религию, а не духовенство.
Цитирую, что вы написали: "8. «Отправлением культа занимается духовенство (Scrum-Master)» - духовенство это система (обычно, иерархичная структура)."
Т.е. вы сначала пытаетесь меня исправлять относительно термина "духовенство", а потом говорите, что мы не про "духовенство" говорим. Ну алё, "нормально же общались". Духовенство -- это не система, а служители религиозного культа.
Во-вторых, смысл был не в том, что любая религия имеет четкую структуру.
А в чём?
Если применять Ваш подход, то религией можно назвать и молоток, и гвоздь, и черешню. Кроме того, терминология этой области знаний не так конкретна, чтобы её можно было использовать для параллелей.
Вы сами с большим удовольствием занимаетесь подменой. Молоток, гвоздь и черешню по моей логике назвать религией нельзя: они не обладают ритуалами, духовенством и священным писанием.
Напомню, скрам - инструмент. Как молоток может не работать? Правильно, только в кривых руках или там, где нужен не молоток.
Нет, не правильно. Если у вас кривой молоток, то и работать он тоже будет криво. Если у вас молоток из пластмассы -- то работать он будет плохо. И вообще, вы даже аналогию правильную привести не можете. Какой же Scrum инструмент? По заверениям адептов Scrum, это фреймворк, а не методология, т.е. это чёртеж молотка. Молоток по этому чертежу вы сами сначала должны сделать. При этом чертёж не полный, а его чтением занимается человек, который начинает этот чертёж обожествлять. Причём обожествляет он не молоток, а именно чертёж.
И, пожалуй, последнее, что я Вам скажу (если не появится стоящих аргументов): Фанатичная позиция против скрама столь же абсурдна и непрофессиональна, как фанатичная позиция за скрам. Вы много сказали о скрам-мастерах, которые вслепую топят за скрам. Но при этом, переняли на себя их же минусы и слабости. Вы отторгаете инструмент сам по себе в отрыве от конкретных областей их применения. Эта позиция не может быть правильной или, хотя бы, логичной.
Имеете право так думать.
Если можно работать по Scrum не читая манифест, то какая тогда разница, что написано в манифесте? Зачем вы приводите цитату из манифеста в дискуссии про Scrum? Вы мне всё пытаетесь про ошибки логики рассказывать, а у вас-то с логикой что?
поясню за логику )
цепочка строится с обратной стороны:
- решение кейса я вижу в том, что люди должны были не голосовать, а приводить аргументы;
- это описано в манифесте. Он не является частью скрама, но я разделяю его ценности.
- хоть Agile не часть скрама, но люди создавшие скрам, тоже придерживались ценностей манифеста.
- эта цепочка не говорит о том, что скрам здесь должен был спасти ситуацию. Скрам не про все кейсы на свете.
Я говорил про бесполезность голосования в кейсе и про то, что скрам к такому голосованию не призывает (или покажите мне это в гайде). Это всё.
исправлять относительно термина "духовенство"
согласен. Термин я не верно использовал. Однако, вся эта концепция сравнения с религией себя не оправдывает. Есть фреймворк, который задаёт вектор работы (основной сценарий). Вокруг него образовался карго-культ. В этом мы, вроде, сошлись. Но Вы приравниваете этот культ к самому фреймворку. Вот здесь логика рассыпается, на мой взгляд. Если кто-то (не будем показывать пальцем, древним простительно) увидел солнце и придумал бога Ра (например), можно усомниться в этом боге или даже заявить, что его зовут Толиком... но заявлять, что солнца нет - сомнительно.
религия имеет четкую структуру.
А в чём?
В том, что для использования инструмента (скрама) не обязательно становиться фанатиком и даже принимать ценности манифеста. Прежде всего, это механизм.
они не обладают ритуалами, духовенством и священным писанием.
так и скрам не обладает. Поэтому я и привел их в пример. Далее буду сокращать термины, прошу без необходимости не углубляться.
- встречи - это не ритуалы. Ритуал проводится прежде всего ради символизма и значения. А в скраме встречи имеют назначение. У каждой есть свой артефакт.
- духовенство - люди, занимающиеся служением в рамках веры. Скрам-мастера не про склонение к вере. Они инструктора по фреймворку (если в рамках этого сравнения говорить). Вы же не предлагаете всех педагогов и тренеров к религиозным фанатикам отнести?
- священное писание - с чего бы гайду быть священным? Если изолированной команде, не заразившуюся карго-культом, дать скрам-гайд, они кинутся ему поклоняться? Их скрам-мастер потребует молиться на эти пять листочков? Да если им не сказать, что кто-то перегибает, они прочитают гайд, как инструкцию для чайника (не чайникОВ). И кстати, вполне вероятно, что "чайник" принесет им много пользы. Но это уже зависит от них.
"у вас кривой молоток <...> молоток из пластмассы "
Если молоток из пластмассы, то это инструмент не для гвоздей. Верните игрушку в песочницу, дети порадуются. Если кривой, то хозяин не следит за своим инструментом и все отбитые пальцы на его совести.
чтением занимается человек, который начинает этот чертёж обожествлять.
снова искажение. Мы определились уже, что такие кейсы - ошибка и скрам к этому не призывает. Вы докидываете в сценарий внешние факторы, которых в предмете спора нет.
По заверениям адептов Scrum, это фреймворк, а не методология, т.е. это чёртеж молотка.
Фреймворк и методология - сущности одного порядка. По сути, алгоритмы с различной степенью детализации. Молоток и его чертёж - таким соответствием не обладают. Вы не правы в этой аналогии.
Молоток по этому чертежу вы сами сначала должны сделать. При этом чертёж не полный
Представим, что с этим сравнением можно работать... исключительно в контексте этой части цитаты. Если мы готовим инструкцию по производству конкретной модели молотка, нам надо указать и целевые характеристики (вес, распределение массы и т.д.), и способ производства. А если мы хотим научить создавать разные молотки (по форме, массе и т.д.) - странно будет выдавать "полную" инструкцию. Кроме того, эта неполнота и напоминает о том, что это не "лекарство от всех болезней".
Имеете право так думать
Слабая позиция. Вы отстаиваете своё мнение только до того момента, когда его не опровергли? А когда аргументы закончились, чтобы не признавать позицию оппонента вспоминаете, что у каждого своё мнение? Что ж, можете повторить эту фразу на все мои аргументы сразу. И будем считать, что последнее слово осталось за Вами )
А вообще, спасибо (серьёзно), было весело.
Я говорил про бесполезность голосования в кейсе и про то, что скрам к такому голосованию не призывает (или покажите мне это в гайде). Это всё.
ОК. На случай если вы не прочитали все комментарии: кейс был по заказу автора статьи на тему "тирания большинства", автор так же выступает за "коммандное принятие решений". В кейсе Scrum-команда которая для принятия решений использует голосования (почему так решили -- не знаю, но коммандно же).
встречи - это не ритуалы. Ритуал проводится прежде всего ради символизма и значения. А в скраме встречи имеют назначение. У каждой есть свой артефакт.
Даже авторы Scrum изначально эти встречи называли "Scrum-ритуалами" или "Scrum-церемониями". Опять-таки, есть ли у ритуала назначение или нет -- зависит от точки зрения. Со стороны Scrum-культиста -- конечно имеет. С моей точки зрения -- нет. Надо ли устраивать дейлик? Нет, каждый день одно и то же, толку мало, отвлекает от работы. Если у кого-то есть что сказать -- они итак об этом всегда пишут в чате.
духовенство - люди, занимающиеся служением в рамках веры. Скрам-мастера не про склонение к вере. Они инструктора по фреймворку (если в рамках этого сравнения говорить).
Поп -- это инструктор по Библии, имам -- инструктор по Корану, а раввин -- инструктор по Талмуду. Scrum-Master безусловно склоняет к Scrum-фреймворку. Человек, у которого роль называется "Scrum-Master" не может не склонять к Scrum, работа у него такая.
Вы же не предлагаете всех педагогов и тренеров к религиозным фанатикам отнести?
Вы же большой друг логики. Всех -- нет. Если учитель физики на уроках читает только из учебника по физике -- то не нужно. Если учитель физики начинает читать из Талмуда -- то нужно.
священное писание - с чего бы гайду быть священным? Если изолированной команде, не заразившуюся карго-культом, дать скрам-гайд, они кинутся ему поклоняться? Их скрам-мастер потребует молиться на эти пять листочков?
У команды, не заразившейся Scrum-культом, нет Scrum-мастера. Если у команды есть Scrum-Master -- то да, он будет склонять к поклонению Scrum-гайда.
Если молоток из пластмассы, то это инструмент не для гвоздей. Верните игрушку в песочницу, дети порадуются. Если кривой, то хозяин не следит за своим инструментом и все отбитые пальцы на его совести.
Вы спросили как молоток может не работать -- я вам ответил как. Между тем, пластмассовым молотком можно забивать пластмассовые гвозди. А погнуть молоток довольно трудно, с чего вы взяли, что за ним плохо ухаживают? Может это брак производства. :-)
Фреймворк и методология - сущности одного порядка.
Вы знаете, лично я с этим мнением в общем-то согласен, но вы только всяким фанатам Scrum об этом не говорите. Они настаивают на том, что это именно фреймворк и ни в коем случае не методология.
Слабая позиция. Вы отстаиваете своё мнение только до того момента, когда его не опровергли? А когда аргументы закончились, чтобы не признавать позицию оппонента вспоминаете, что у каждого своё мнение?
Дело в том, что в моём понимании ваши "аргументы" таковыми не являются. Вы рассказываете всякие субъективные вещи про непрофессиональность и про неправильность позиции, про отказ от здравого смысла и аппелируете к тому подобным сугубо личным взглядам. Там, где я работаю, нет критерия "нельзя быть против Scrum, чтобы считаться профессионалом". Что вы считаете правильным и неправильным, профессиональным и непрофессиональным -- это ваше личное дело, представление о здравом смысле у всех внезапно тоже разные. Я вот считаю, что практиковать Scrum -- верх непрофессионализма и вообще это неправильно. По вашей логике -- ну всё, я вас опроверг, живите теперь с этим. :-)
Моя позиция в сущности к следующему: если вы делаете что-то Agile-подобное с короткими итерациями и state-of-the-art практиками разработки типа CI/CD -- ОК, никаких проблем. Как только в команде завёлся Scrum-Master -- всё, приехали, у вас завелись культисты. Это категорически неприемлемо. Единственная приемлемая для меня версия Scrum -- без Scrum-Master'а (но тогда это уже не Scrum), только тогда я готов поверить, что не будет склонения ко всякому Scrum-культизму.
А вообще, спасибо (серьёзно), было весело.
Обращайтесь. :-)
На случай если вы не прочитали все комментарии: кейс был по заказу автора
я не говорил, что с кейсом что-то не то. В этом контексте не важно, почему именно Вы его привели, т.к. я говорил о решении и о том, что скрам тут не мешает быть адекватным. Scrum-команда в этом кейсе поступила неэффективно. Тут мы, вроде, сошлись. Зачем к этому возвращаться - не понятно.
авторы Scrum изначально эти встречи называли "Scrum-ритуалами" или "Scrum-церемониями"
в скрам-гайде этого нет. Т.е. аргумент в том, что кто-то где-то когда-то неофициально что-то сказал, поэтому мы берем описанный в конкретном документе фреймворк и присваиваем неприсущее? да, я всё ещё за логику.
Практика использования этих слов действительно есть. Вот только у них есть не только религиозный, но и светский контекст.
Цель использования этих терминов никак не связана с культом. Это должно было подчеркнуть сонаправленность и обязательность поддержания ритма и т.д. (стараюсь излагать кратко)
есть ли у ритуала назначение или нет -- зависит от точки зрения
Если событие описано в документе как часть общей системы и назначение обозначено, можно сколько угодно кричать, что "у каждого свое мнение". Про все эти "свои мнения" я уже отвечал
Со стороны Scrum-культиста -- конечно имеет. С моей точки зрения -- нет.
Безусловно. Но как я уже говорил, кроме фанатичных диаметрально противоположных позиций, есть целый спектр адекватных. Я нигде не утверждал, что с Вашей точки зрения скрам прекрасен. Я говорю о том, что для честного рассуждения, говоря о скраме (или о чем угодно) надо говорить о скраме. Вы же постоянно приписываете ему то, что растет вокруг.
Надо ли устраивать дейлик? Нет, каждый день одно и то же, толку мало, отвлекает от работы. Если у кого-то есть что сказать -- они итак об этом всегда пишут в чате.
Любое подобное рассуждение в отрыве от контекста бессмысленно. И да, я всё ещё про логику. Ответить на вопрос о необходимости встреч можно только зная ситуацию в деталях. А с этим багажом Вам лучше идти к фанатикам на другой стороне. Они порадуются )
Поп -- это инструктор по Библии, имам -- инструктор по Корану, а раввин -- инструктор по Талмуду.
притянуто за уши. Нет такого соответствия. При таком масштабе упрощения много можно намоделировать.
Scrum-Master безусловно склоняет к Scrum-фреймворку. Человек, у которого роль называется "Scrum-Master" не может не склонять к Scrum, работа у него такая.
Голословные и безосновательные утверждения. Я неоднократно бывал в роли скрам-мастера и часто предлагал другие практики там, где это было необходимо. Тут вспоминается Максим Дорофеев: "В этом мире не все везде и всегда, а кое-что иногда и местами".
Да сама формулировка, приравнивающая всех людей по признаку участие в командной роли - крайне не логична.
Если учитель физики на уроках читает только из учебника по физике -- то не нужно. Если учитель физики начинает читать из Талмуда -- то нужно.
Так я Вам про это и говорил. По Вашим рассуждениям, учебник по физике - священное писание преподавателя. А некоторые педагоги посвящают себя физике куда больше большинства священников.
А если рассмотреть текущее Ваше утверждение, так скрам-мастер тоже из Талмуда не читает.
У команды, не заразившейся Scrum-культом, нет Scrum-мастера. Если у команды есть Scrum-Master -- то да, он будет склонять к поклонению Scrum-гайда.
снова голословные заявления. Я - пример обратного. И знаю множество других примеров. То, что Вам попадались исключительно такие "товарищи", не даёт права равнять к ним всех.
Хотя моя первая встреча со скрам-мастером - это анекдот, который я не устаю рассказывать. Человек был максимально неадекватным фанатиком, который даже не понимал, что написано в гайде, но требовал следовать его идеям.
Между тем, пластмассовым молотком можно забивать пластмассовые гвозди.
Когда я попросил вернуть игрушки в песочницу, не думал, что Вы будете в этой песочнице играть с пластмассовыми гвоздями )
А погнуть молоток довольно трудно, с чего вы взяли, что за ним плохо ухаживают? Может это брак производства. :-)
Трудно. Но я гнул. А когда у БМП броню снимали, ключ размером с руку в клочья порвали. Что должно было доказать это "довольно трудно"? Если молоток трудно погнулся, я либо заменю его, либо отремонтирую. С браком производства в виде погнутого молотка я товар не куплю. Это и есть уход за инструментом: чинить то, что ломается, менять то, что не чинится.
Вы знаете, лично я с этим мнением в общем-то согласен, но вы только всяким фанатам Scrum об этом не говорите. Они настаивают на том, что это именно фреймворк и ни в коем случае не методология.
"сущности одного порядка" - не одно и то же. Я говорил о том, что есть вещи одного типа (категории). Так мы можем сравнивать между собой Библию и Талмуд, равина с попом. А сравнивать молоток и его чертеж, это как Библию с равином, а зеленое с горячим.
И да, скрам - не методология. Это я могу обосновать. Но данный диалог о другом, поэтому предлагаю не уходить от темы.
в моём понимании ваши "аргументы" таковыми не являются.
везде, где Вы не соглашались с моими аргументами, я встречался с контраргументами. А здесь не встретил. Отсюда и вывод.
непрофессиональность и про неправильность позиции, про отказ от здравого смысла и аппелируете к тому подобным сугубо личным взглядам.
не-не-не... я говорю о них, как о способах выбрать правильное решение. Это не сугубо личные взгляды, а рассуждения о предметах и их взаимосвязях.
Там, где я работаю, нет критерия "нельзя быть против Scrum, чтобы считаться профессионалом". Что вы считаете правильным и неправильным, профессиональным и непрофессиональным -- это ваше личное дело, представление о здравом смысле у всех внезапно тоже разные. Я вот считаю, что практиковать Scrum -- верх непрофессионализма и вообще это неправильно. По вашей логике -- ну всё, я вас опроверг, живите теперь с этим. :-)
а вот это уже "сугубо личный взгляд". Как вы смогли вообще в рамках одного сообщения обвинить меня в этом и тут же все аргументы свести к тому, что у конкретного человека, в конкретной компании иначе? Я же нигде не говорил, что у вас там не так. Мы в этом и сошлись. Но я говорю о самом фрейворке, а Вы доказываете его непригодность там, где одни фанатики (скрам-мастера, видимо) порождают других фанатиков. Вот это и называется частным случаем. Который, кстати, не доказывает ничего в контексте общего предмета обсуждения.
В целом, до сего момента были объективные замечания, на которые я дал ответы. На все, насколько могу судить.
Но заявления о том, что все скрам-мастера всегда такие-то, а если завелся скрам-мастер, то всегда будет вот так то... это не серьезно и объективно не заслуживает внимания. Продолжение диалога неминуемо приведет к повторению тех же обвинений... утверждению, что кто-то там плохие потому, что они как-то называются... и т.д.
Полагаю, диалог себя исчерпал. Желаю Вам встретить наконец адекватного скрам-мастера (хотя бы одного) и заметить это до того, как Вы навешаете на него ярлыков.
По поводу работы на компанию - я согласен. Это одна из причин по которой стартапы работаю на скоростях, недоступных энтерпрайзу. Но одна из задач Scrum как и заключается в создании таких небольших команд - мини стартапов внутри большого энтерпрайза. Где общие командные цели не размываются, а четко коррелируют с личными достижениями.
Признание - это конечно мощный мотиватор, но он присутствует и в командной работе тоже. Например: профессиональное признание коллег, благодарность за помощь в достижении общего результата мотивируют не хужу публичности. Хотя и для этой цели в Альфе проводится множество различных конференций, где также можно широко заявить о себе, как о профессионале.
Далее по пунктам:
Я не согласен, что “случайно появившийся в команде Мастер” будет отвергнут командой. Практика показывает обратное: он начинает лидировать различные процессы. И Scrum для этого создает благотворную почву. И, да, у нас такой сотрудник получает всю необходимую поддержку. Так как мы в Альфе умеем ценить и компетентность и вовлеченность. А роль командного scrum-мастера у нас выполняет кто-то из команды разработки (аналитик, разработчик, QA).
Все заточено на то, чтобы развивать энтузиазм и давать расти Мастерам. И поверьте каждый сотрудник с таким типом мышления видит в другом Мастере не конкурента, а надежного партнера, разделяющего его ценности. А споры - это неотъемлемая часть творческого процесса. И их отсутствие - это как раз признак дисфункции команды.
Другой вопрос, что в небольшом сплоченном коллективе (численность команды в среднем 6-8 человек) они носят конструктивный характер и желание достичь общей цели, а “отстаивания своей правоты перед начальством”. Да и начальства у scrum команды как такового нет. Задача РО в определении того, что сейчас надо делать. А как и за сколько определяет только сама команда.
По поводу иерархии и разделения компетентности: какие еще голосования, в которых “наиболее компетентные будут оказываться в меньшинстве”? Где они (голосования) должны проводиться?
Разработка давно уже ушла от создание профильных команд (отдельно бэк, отделано фронт, отдельно QA) и специализированных отделов со строгой иерархией.
*Как решались проблемы бесшовной программных продуктов отлично описал как раз дядя Боб.
Сейчас золотой стандарт - это кроссфункциональное команды (до 10 человек), объединяющие специалистов различных специализаций. Которые только совместными усилиями могут сделать что-то завершенное и ценное для бизнеса. И задача этих специалистов на планировании каждой итерацией четко сбиться кто, как и что будет делать по своему профилю, чтобы достичь этой цели. А для этого очень важно видеть целостность процесса и четко понимать те запросы, которые решает разрабатываемый функционал. О чем и написано в статье.
Но одна из задач Scrum как и заключается в создании таких небольших команд - мини стартапов внутри большого энтерпрайза.
Не поясните что это значит и как это выгдядит? Разработчикам выделятся доля от прибыли проекта в котором они учавствуют или может быть они становятся совладельцами исходников?
профессиональное признание коллег, благодарность за помощь в достижении общего результата мотивируют не хужу публичности
Так как мы в Альфе умеем ценить и компетентность и вовлеченность.
Я понял, "в нашем деле главное реклама",
может кто-то и поверит 🙂
Скажите, а как у вас проводится оценка сложности задачи в кросс-функциональных командах, тоже тестеры и дизайнеры дают свою оценку сложности задачи для бэк-а и фронтенда?
Про дизайнеров скорее нет (по крайней мере в моих командах), а вот QA обязательно! Тестирование – это неотъемлемая часть процесса разработки, так же как и код ревью, например. Поэтому его объем и сложность обязательно должны быть учтены на этапе планирования и включены в оценку задачи.
Но чтобы это сделать правильно, надо сперва разобраться в принципах работы с относительной системой оценивания. На Habr есть несколько очень грамотных статей по этому вопросу.
Мастера не просто хотят выполнять задачи — они стремятся влиять на процесс и результаты (помните пункт 3 выше?). И Scrum предоставляет им такую возможность.
А если они не по Scrum работают -- то на процесс и результаты у них возможности влиять нет? Абсолютно в любом процессе исполнитель влияет на процесс и продукт.
Работа по Scrum объединяет команду, создавая среду для активного сотрудничества и шаринга знаний. Для Мастеров это возможность не просто работать в команде, а шанс учиться у коллег и делиться своими знаниями.
А если они не по Scrum работают -- то у них нет возможности для сотрудничества? Опять-таки, "возможность не просто работать в комманде" и "шанс учиться у коллег" есть абсолютно при любом процессе.
Scrum позволяет получать регулярную качественную обратную связь непосредственно от пользователей продукта, благодаря чему можно своевременно вносить изменения, непрерывно улучшая.
А другие процессы как-то запрещают получать обратную свзять? Какие, например? И вообще, вы пишете, что Scrum "позволяет получать" обратную связь, но это далеко не означает, что вы её получите в действительности.
За всё, что делает команда, отвечает только вся команда целиком. И каждый в ответе друг перед другом. А это означает, что успехи и неудачи в решении любой задачи воспринимаются как общие достижения или провал.
Это какая-то очень странная максима, которая совершенно очвидно не может работать в реальной жизни. Т.е. если условный программист Вася ушёл в запой и не пришёл на работу, то отвечает тоже вся команда? Прикольно вы придумали. А о зарплате как такая команда как договаривается? У неё свой профсоюз с коллективным договором? Ведь все ж в ответе друг перед другом.
А если у вас иначе, то может просто перестанете называть «это» Scrum?
Из вышеизложенных вами пунктов получается, что Scrum -- это только про круговую поруку, т.к. другие пункты никак не исключаются другими процессами и являются возможными какой бы процесс вы не использовали.
Что Scrum даёт Мастерам?
Лишнюю головную боль.
Чтобы ответить на эти вопросы, надо сперва понять, что вы пытаетесь противопоставить Scrum? Если не он, то что?
Если это другие Agilе фреймворки, то, например, в ХР сокращение цикла обратной связи – это один из базовых приемов. А Канбан стимулирует развитие культуры взаимопомощи и погружению в смежные компетенции.
Другой вопрос, что современный Scrum, являясь коммуникационным каркасом, который «помогает создавать ценность с помощью адаптивных решений комплексных проблем». И служит обёрткой для существующих практик, давно уже впитал в себя множество различных лучших решений от других фреймворков. Просто бери и пользуйся.
*
И да, «если условный программист Вася ушёл в запой и не пришёл на работу, то отвечает тоже вся команда». За итоговый результат, не за Васю. Потом уже, на ретроспективе, команд сама решит по пути ей дальше с Васей или нет.
И поверьте мне (был у меня в практике очень похожий случай), если Вася получит свой второй шанс, то он будет, цитирую: «ночью если надо буду работать, чтобы только больше не подвести ребят». Ведь наша ответственность перед маленьким слаженным коллективом профессионалов больше, чем перед любым «начальником».
Хотя, как я уже писал: не все готовы принять этот вызов. И некотором действительно для работы необходим «строгий, но справедливый» босс, и четкие БТ)
Если не он, то что?
Scrum или смерть! (см. "Православие или смерть!")
Scrum -- это система религиозных верований и ритуалов, а вы -- религиозный фундаменталист и служитель Scrum-культа. В отличие от вас, я -- агностик, я не следую никакой религии, и соответственно я противопоставляю агностический подход Scrum'у и прочим тому подобным верованиям.
Мне совершенно очевидно, почему вы выбрали именно Scrum. Scrum -- это достаточно организованная система религиозных верований. Отличительная черта Scrum как религиозной доктрины -- это то, что в религиоведении называется термином "посвящённое духовенство", т.е. выделяется отдельный класс людей, занимающихся отправлением культа. В случае Scrum -- это Scrum-master (в других верованиях это называется другим словом, например "поп", "раввин" или "имам").
Собственно, в священном писании вашей секты (Agile Manifesto) изложен его основной этический и философский принцип: "Individuals and interactions over processes and tools", но вы его либо не понимаете, либо отказываетесь принять. Вместо этого вы занимаетесь фетишизацией процесса (ну и заодно используете свой статус служителя культа для повышения своего социального статуса).
Если это другие Agilе фреймворки, то, например, в ХР сокращение цикла обратной связи – это один из базовых приемов.
Вот именно. Приём настолько простой и очевидный, что никакого смысла следовать вашему культу нет. История точно такая же, как и с другими релизиозными верованиями. Например, авраамические религии запрещают воровать и убивать -- и что бы вы думали? Подавляющее число людей, которые им не следуют, никого не убивают и не грабят -- потому что это "базовый приём" нормальной человеческой морали.
А Канбан стимулирует развитие культуры взаимопомощи и погружению в смежные компетенции.
Сам по себе Канбан ничего не стимулирует. Ключевым аспектом в развитии смежных компетенций является способ распределения задач между исполнителями. Если задачи распределяются кем-то из команды -- то всё зависит от того, как этот человек их распределит. Если исполнители сами выбирают, чем они хотят заниматься, то далеко не факт, что они сами захотят смежные компетенции развивать: люди как биолгический вид выезжают на гиперспециализации и по факту стратификация навыков так или иначе возникает на всех сложных проектах.
Просто бери и пользуйся.
Нет, спасибо. И вы лучше завязывайте.
За итоговый результат, не за Васю. Потом уже, на ретроспективе, команд сама решит по пути ей дальше с Васей или нет.
Это чистой воды идеализм и реальные организации так не работают. Решать будет менеджер, а не команда. В любой команде есть только один человек, который имеет полномочия принимать решения, связанные с наймом и увольнениями. Этот человек может консультироваться с другими членами команды и принимать их мнение во внимание, но принимает решения именно он и делает это единолично.
Хотя, как я уже писал: не все готовы принять этот вызов.
О, "вызов"! Вызов судьбы, не иначе? :-) Оставьте уже этот юношеский пафос. Да, не все хотят быть в вашей секте со странными ритуалами, промыванием мозгов и круговой порукой.
Честно говоря, меня немного пугает то, что вы сравниваете Scrum c религией. Давайте все-таки смотреть на вещи чуть проще.
Это просто инструмент, позволяющий решать сложные комплексные задачи за счет итерационного, инкрементного подхода. Основой которого являются самоорганизованые команды.
Для меня лично формат командного взаимодействия предпочтительней иерархичному. Поэтому я и задал вопрос, на который вы так и не ответили: что вы предлагаете на замену Scrum? Какой формат управления и организации труда для вас более приемлем?
Если правильно понял, ваш собеседник намекает, что не нужно быть христианином, чтобы делать свою работу хорошо)
Лично я не настолько подавлен scrum-ом (возможно, потому что у нас в команде отсутствует культист и, как следствие, имеем только планирование и дейлики). Дейлики, кстати, вообще норм) И Jira вообще инструмент замечательный.
Но если не будет Scrum, никто же не останется в вакууме. Роадмап есть, бэклог есть, вопрос только, зачем эти церемонии с делением его на спринты? Приоритеты ПО расставил, ну и погнали)
Ну склонность проводить параллели с религией как раз у тех, кто не за, а против)
Для меня Scrum – это надежный практический инструмент организации деятельности команд при работе в неопределенной среде. Он отлично сочетается с практиками Kanban, OKR, инженерными практиками XP (кстати принципы командой оценки в SP пришли к нам именно из XP).
А если все-таки заглянуть в Scrum гайд, то можно прочесть следующее: фреймворк позволяет применять различные процессы, техники и методы. Scrum служит оберткой для действующих практик, или подсвечивать их ненужность.
Но, к сожалению, хейтеры не любят читать про объект своих нападок, предпочитая экстраполировать свой субъективный опыт, основанный на весьма поверхностном знании предмета.
Извините, а вы не могли бы уточнить -- а я правильно помню, что буквально вчера у вас в вашем профиле было написано "Scrum-fan" или "Scrum-фанат"? А вот сегодня уже не написано. Что случилось? Вы перестали быть фанатом Scrum? :-) Или мне всё это приснилось?
Ещё я вас в другой ветке комментариев спрашивал, а вы мне так и не ответили: вы сами какую роль в Scrum'е выполняете? Вы разработчик, Scrum-master или Product-Owner? Пожалуйста, ответьте -- я считаю, что это очень важный момент в этой дискуссии.
Но, к сожалению, хейтеры не любят читать про объект своих нападок, предпочитая экстраполировать свой субъективный опыт, основанный на весьма поверхностном знании предмета.
К сожалению, сектанты не любят, когда их секту критикуют, и считают всех, кто с ними не согласен, "хейтерами".
Скрытый текст
Честно говоря, меня немного пугает то, что вы сравниваете Scrum c религией. Давайте все-таки смотреть на вещи чуть проще.
А меня пугает, что вы состоите в этой секте и даже этого не осознаёте.
Для меня лично формат командного взаимодействия предпочтительней иерархичному.
Ваша роль какая в этом взаимодействии? Вы разработчик, Scrum-master или Product Owner?
Поэтому я и задал вопрос, на который вы так и не ответили: что вы предлагаете на замену Scrum? Какой формат уравнения и организации труда для вас более приемлем?
Я не считаю, что Scrum приводит к уравнению в организации труда. Scrum-master и Product Owner имеют гораздо большее влияние на процесс, чем собственно разработчики, и занимают более высокий уровень в иерархии организации труда, который они используют для того, чтобы диктовать правила. "Все животные равны, но некоторые равнее" -- это как раз про Scrum.
Из двух иерархических систем я предпочитаю ту, в которой нету культизма и странных ритуалов.
Человечество благодарно Вэджвуду на 10% за керамику и вклад в технологию, на 10% за инновационный маркетинг и на 80% за то что он был дедом Дарвина. )
Про ремесло и искусство, AI и немного о Scrum