Comments 177
Вот интернет децентрализуют и не будет никаких команд ,это как если обезьянам выдать по клавиатуре ,то они вряд ли когда напишут на дисплее слово "Банан" .
как если обезьянам выдать по клавиатуре, то они вряд ли когда напишут на дисплее слово «Банан»Если дать обезьянам достаточно времени, то они точно напишут и «Банан» и текст драмы Шекспира «Гамлет».
Понять что они написали Гамлет просто, понять что они написали нужный код невозможно https://en.wikipedia.org/wiki/Halting_problem
Коллеги как-то работали, да и мои проблемы особо не влияли на их работу. А столько "я" потому что в основе статьи лежит не анализ процессов а анализ моей реакции на процессы.
Имхо, на этим можно было бы и закончить статью, да и все обсуждение :)
А про «я» извините, очень уж бросается в глаза
Несмотря на то что в скрам гайде написано что скрам это фреймворк, несмотря на то что коучи делали особый акцент на то что скрам это фреймворк, несмотря на то что все вокруг считают его фреймворком и используют как фреймворк, скрам не ведёт себя как фреймворк. Он ведёт себя как стандарт. Тот у кого недостаточно опыта с программными фреймворками и стандартами ни за что не ощутит разницу между этими концептами в контексте неформального взаимодействия между людьми. Я считаю именно эту ошибку в определении главной ложью скрама
Гениально! Спасибо. Теперь, благодаря вам и я знаю, что именно меня в скраме смущает.
Хочу спросить, были-ли у вас подобные наблюдения? (абзац ниже)
При использовании скрам, информированность коллег, о состоянии дел в проекте в целом и в его частях, должна расти, однако этого не происходит. Время на информирование тратится больше, а информация отскакивает от сотрудников, в связи с тем что они в ней не заинтересованы, пока эта информация не станет им нужна. И тут они тратят время на её поиск и коммуникации с вами. Т.е. это исключительно человеческий фактор. Кол-во коммуникаций возросло, польза от коммуникаций уменьшилась.
Нет, с таким не сталикался. Могу посоветовать спрость в профильном сообществе. Найти такие сообщества можно например здесь.
Вангую вал коментов в стиле "Да у тебя просто нормального SCRUM-мастера не было!".
Короче, стыд и скрам.
Фраза про карго-культ крайне уместна. При всём моём уважении к набору инструментов Agile это превратилось действительно в культ, а на коучей у меня вообще аллергия выраженная.
Товарищь Мартин (который Боб) очень хорошо в своём чистом Agile описал ситуацию с сертификацией коучей и т.п., в двух словах - мракобесие.
Придумайте звездолёт и сразу появится армия коучей, которые за большую сумму научат вас как правильно им управлять
в двух словах - мракобесие
Это одно слово ;)
Придумайте звездолёт и сразу появится армия коучей, которые за большую сумму научат вас как правильно им управлять
Дело в том, что в итоге они не научат вас управлять звездолетом, но предложат свой "концептуальнй процесс обучения управлению звездолетом", благодаря которому каждый сможет стать пилотом. А на претензии типа почему мой звездолет до сих пор не летает, всегда есть ответ, что проблема в вас, ибо вы неправильно следовали этому процессу.
Тут недавно вспоминали про Clubhouse, так там всё это быстренько прокрутилось за полгода, что ли))
Чуть больше конкретики не помешало бы. Например,
"На место настоящих инструментов пришли суррогаты". Что за инструменты, какие были, какие стали, на основании каких признаков сделан соответствующий вывод.
"Разговоры о скраме выглядят шаблонно, люди используют одинаковые слова и бывает произносят их в одинаковом порядке. Контекст вообще неясен. Зачем об этом разговаривать вообще. Есть спринт, есть задачи, их надо делать, проставлять пометки соответствующие. В каком месте тут появляется разговор и для чего вообще. Необязательно знать, как устроена машина, чтобы на ней ездить. А кондуктору в автобусе необязательно знать устройство ДВС для выполнения своих обязанностей.
" Скрам мастера и коучи не помогают мне решать проблемы". Какого рода проблемы тут могут возникать, это проблемы организации процесса или самого процесса или чего проблемы. От участника процесса ничего не требуют в целом, кроме выполнения задач в спринте, или у вас не так?
"Я не могу воевать с группой из нескольких десятков человек, которая ещё и владеет правилами игры". Почему вообще настала необходимость воевать, а не договариваться? Виноват ли скрам, что вы не хотите или не умеете работать в команде?
"Я потерял контроль над своим компонентом". У вас командная разработка или индивидуальная? Про какой контроль идет речь? Если исходный код компонента лежит в общем доступе, это достаточный контроль или какой еще нужен?
И самое главное, как вы раньше-то работали. Как стало понятно, а как было? Заголовок кликбейт, в статье про это вообще ничего нет, кроме того, что вам кажется. Без конкретики это какой-то клуб джентльменов получается.
Совет, если текст статьи прогнать через спеллчекер, он будет читаться полегче.
Справедливые замечания, но если не слишком придираться, то посыл автора понятен и относится не только к "скаму", а к любым внедрениям разных методологий разработки, в надежде на то, что это автоматически приведет к желаемому результату. В отрыве от контекста и конкретной команды людей, попытка топорного внедрения практик, которые выработались в совершенно другой команде, как минимум выглядит странно. Вообще не факт, что выделенные подходы и практики не являются просто побочными элементами процесса и сами по себе ничего не стоят.
По моему субъективному мнению - "Кадры решают все!". Если у вас получилось собрать слаженную команду, то можно выбирать что угодно - cкрамы, аджайлы, канбаны и рассказывать как хорошо это работает. А если у вас в команде все плохо, то тупые "внедрения" врядли исправят проблему. Как говорилось в известной басне:
"А вы, друзья, как ни садитесь, все в музыканты не годитесь" (c)
Хотя, как во всем, здесь бывают исключения, но на то они и исключения)
Я намеренно убрал конкретику, когда начинаешь описывать детали процессов, они тянут друг-друга за собой. В итоге у меня получалось подробное описание процессов проекта, а это не то чем я хотел поделиться. Кроме того после описания процессов, следовало бы их проанализировать и найти ошибки а я не могу этого сделать. Я заметил что мой анализ скатывается в необоснованные обвинения и отказался от этого. Проблемы на проекте это повод задуматься, причина в стойком ощущении что со скрамом что-то не так.
На первый взгляд набор инстументов не изменился команды, дейли, ретро, планирование, беклог, это было до трансформации это никуда не делось после. В каждом инструменте зменилось что-то внутри, в качестве примера приведу команду. до трансформации это были люди собравшиеся вместе для решения конкретных задач, команду собирали тимлид и менеджер, мы понимали что делаем и зачем. В рамках трансформации же команды перетряхнули, для того чтобы добиться кроссфункциональности и на месте сработавшейся команды собравшейся по своей воле, появилась группа людей оказавшаяся вместе по случайности.
Моей основной проблемой было несоответствие моих навыков и желаний моей новой работе. Если бы мне предложили такие условия на собесе, я бы отказался.
Это подводка к мысли о том что скрам не определяет процесс работы, только отдельные ограничения. Да, не надо знать строение двс, но было бы неплохо знать что такое руль, педали, коробка передач, а также быть в курсе пдд. Нельзя просто посадить человека в машину и ждать что он доедет сам.
Когда ты единственный недовольный из нескольких десятков человек, это не ощущается как обсуждение проблем с людьми, это ощущается как противостояние коллективу. Как дёрнуть стоп-кран остановив поезд целиком. Так можно сделать но после этого придётся объясниться.
Я больше не могу класть задачи по компоненту в беклог(только на самое дно) я не мог выдвигать задачи на планирование, не мог брать их в спринт, я был занят чем угодно кроме того что умел.
за мысль о спеллчекере спасибо)
Я намеренно убрал конкретику,
Без конкретики стало непонятно и поэтому неубедительно. Мы можем выбрать какой-то один аспект и разобрать?
Нельзя просто посадить человека в машину и ждать что он доедет сам.
В моем представлении скрам мастера должны быть инструктами по вождению. Куда ехать определяет команда, но как половчее переключать передачи может подсказать скрам мастер.
Когда ты единственный недовольный из нескольких десятков человек,
Вы были единственным недовольным, для остальных это работало, да?
Я больше не могу класть задачи по компоненту в беклог(только на самое дно)
То есть можете, но их приоретизацией (по гайду) должна заниматься команда в соответствии с ценностью, да?
я был занят чем угодно кроме того что умел.
Задач по вашей компетенции не было, они были низкоприоритетными или как?
Если встать на точку зрения владельцв продукта, вы бы так же приоретизировали?
Можно специфический пример?
я не предоставлю конкретику, в этом задумка статьи - абстрагироваться от событий, оставив только реакцию на них
в этом и дело, я тоже так думал, а мой опыт показал что скрам-мастер больше похож на инспектора дорожной полиции, он не учит водить он проверяет соответствие твоей манеры вождения общепринятому стандарту. а водить учит тимлид/архитектор/менеджер
у них получалось работать, выглядело так как будто им норм.
там сложнее получилось, реальное влияние на приоритеты было только у ПО. Человека который раньше получал пользу от моей работы не было среди них.
ума не приложу как бы я приоретизировал на их месте
я не предоставлю конкретику, в этом задумка статьи - абстрагироваться от событий, оставив только реакцию на них
Васе больно
Почему? Петя агрессивно по мнению Васи себя повел
А что именно сделал Петя?
Не скажу
Как из таких сведений извлечь для себя какую-то пользу или хотя бы понять причины и следствия?
реальное влияние на приоритеты было только у ПО
По гайду за ПО последнее слово, но совещательный голос может быть у каждого. По гайду, ПО должен обхяснить цель продукта. Вы пробовали как-то аргументировать почему ваши PBI более ценны с точки зрения цели и надо делать их а не то, что выбрал ПО?
реальное влияние на приоритеты было только у ПО. Человека который раньше получал пользу от моей работы не было среди них.
Это правильно. Вам зарплату платит не этот конкретный человек, а фирма, которая не считает нужным обеспечить ему пользу.
Вот все, что вы описали, это не проблемы внедрения SCRUM\Agile.
Все, что вы описали - это ваше субъективное восприятие ситуации. Ваша зона комфорта разрушена, адаптироваться не получилось. Я так понимаю, поезд никакой не остановился, он просто поехал без вас, что вас совсем не устроило.
Попробуйте сменить фокус восприятия, он у вас смещен и из-за этого получаюются сплошные противоречия. Например,
"Я больше не могу класть задачи по компоненту в беклог(только на самое дно)".
превращается в
"Я могу класть задачи по компоненту в беклог, но меня не устраивает, что их приоритезируют подобным образом"
"На первый взгляд набор инстументов не изменился команды, дейли, ретро, планирование, беклог, это было до трансформации это никуда не делось после"
превращается в
"Инструменты работают, но применяются неправильно по моему мнению".
По идее хорошо бы прийти к ПМу (любому начальнику) и с ним поговорить для начала, выяснить что происходит. Но, как понимаю, и тут не сложилось, только вы почему-то в этом вините всех вокруг, а должны спросить в первую очередь с себя. Ведь если бы процессы были сломаны и все было так плохо и все не работало, проект был бы нежизнеспособен и закрыт. Чего, очевидно не случилось, просто вы ушли.
С таким отношением неважно какую метдологию подставить в заголовок, всегда все будет плохо.
Надо менять отношение, вы в меньшинстве так или иначе, с ветряными мельницами бороться такое себе занятие.
Разным людям подходит разный способ работы. Возможно этому человеку скрам просто не подходит (или сочитание скрама и задач). Возможно, он хочет работать не на конечный результат, а полировать конкретный компонент и не важно что заказчику нужно сейчас.
Может ему подойдет какое-то место, где целая команда занимается таким компонентом. Или заказчику не нужен результат, а надо потратить деньги.
Но это очень поверхностное впечатление и я бы без конкретики не делал выводов.
да, это правда, поезд пошёл без меня, я смирился и перестал пытаться его остановить, позже я сошёл как только был готов. думаю от этого стало лучшие и мне и проекту. Да, моё мнение ненадёжно и субъективно, однако я не считаю его вредным для проекта, скорее недоработанным. Я не виню всех вокруг себя, наоборот я пытаюсь этого избежать. Мне кажется что компромиссный вариант, который устроил бы всех, мог быть достигнут но этого не произошло.
А какой бы он был?
у меня его нет, только вера в его существование и накопленный опыт для того чтобы не упустить момент в следующий раз
Если у вас был скрам, то в него встроены механизмы обратной связи от daily scrum где можно сказать что мешает работать до ретроспективы, которая специально предназначена для исправления процесса. В данном случае их можно использовать для выработки компромисса. Вы пытались обсудить это с командой?
По вашему тексту я вижу что вы общались с мастерами, но не вижу взаимодействия с другими людьми.
Я вижу например, претензию к тому, что у вас были навыки которые не использовались в то же время вам назначали работу для которой у вас было недостаточно навыков. К тому же у вас отобрали владение компонентов но назначили владельцем кода компонента.
Как я понимаю, эти вещи взаимосвязанны - из-за депреоритезации работ над компонентом, который вы знаете вы занимались какой-то другой работой. Причем вас это не устраивало а всех остальных да (то есть ваша производительность была нормальной с их точки зрения?).
Теоретически я вижу два выхода из этого:
Назначать вам задачи на компонент (а еще вы хотите выполнять роль PO для него - решать что делать и когда)
Вам доучиться чтобы быть эффективным на этих новых задачах
Из того, что вы написали, непонятно, почему именно задачи были депреоритизированы. Непонятно, общались ли вы с PO чтобы выработать общее понимание приоритетов и стоимости задач ("если бы вы мне дали вон ту задачу, я принес бы пользу вон тому пользователю").
То есть непонятно, была ли попытка сторон понять друг друга и выработать этот самый компромисс. Она была?
Автор, а Вы ценности scrum разделяете? Приверженность, сфокусированность, открытость, уважение и смелость?
В частности, между строк читается, что своих коллег вы не уважали и совместно работать с ними над общими задачами были не готовы. Я прав?
В этом случае опытный скрам-мастер не стал бы включать Вас в скрам-команду, а использовал как внешний сервис.
Но в одном Вы правы, скрам не является методологией разработки ПО (или описанным SDLC).
И авторы скрама предполагают, что скрам команда самостоятельно создаст такую методологию, пользуясь принципами. А вот осилить это могут только достаточно зрелые компании.
Если по результатам дейли вы не готовы отложить свою задачу и переключиться на помощь коллеге - дейли (а значит и скрам) вам не нужны.
Если по результатам спринта у вас нет готового к продакшину инкремента - скрам вам не нужен.
Если план команды разработки расписан на кварталы вперед и не пересматривается при получении обратной связи - скрам вам не подходит.
К сожалению, авторы скрама не описали его область применения. И большинство скрам-коучей этого не делают. Поэтому очень часто его внедряют там, где он не подходит для продукта и/или команды. Т.ч.на счет карго-культа Вы правы.
P.S.
Роль скрам-мастера - научить команду правильно взаимодействовать (внутри себя, с владельцем продукта, с заказчиками и прочими заинтересованными лицами). И если брать аналогию с тренером, то задача тренера как раз сделать из отдельных игроков команду и подобрать для них оптимальную тактику на игру. "Порядок бьет класс".
Автор, а Вы ценности scrum разделяете? Приверженность, сфокусированность, открытость, уважение и смелость?
А как это, разделять ценности? Как мне определить разделяю ли я их, каков критерий? Как тому кто хочет научиться уважению перейти от декларативного концепта уважения к процедурной последовательности действий сливающейся в проявление уважения?
В частности, между строк читается, что своих коллег вы не уважали и
совместно работать с ними над общими задачами были не готовы. Я прав?
Моё нежелание работать над общими задачами появилось не сразу а после нескольких неудачных попыток. А откуда у вас взялась мысль о том что я не уважал своих коллег?
В этом случае опытный скрам-мастер не стал бы включать Вас в скрам-команду, а использовал как внешний сервис.
Такой вариант меня бы вполне устроил.
И авторы скрама предполагают, что скрам команда самостоятельно создаст
такую методологию, пользуясь принципами. А вот осилить это могут только
достаточно зрелые компании.
Ну или не создаст, о том и речь. Скрам это не инструмент достижения цели а рамки ограничиющие выход за пределы некоторой области внутри которой предположительно находится решение.
Роль скрам-мастера - научить команду правильно взаимодействовать (внутри
себя, с владельцем продукта, с заказчиками и прочими заинтересованными
лицами). И если брать аналогию с тренером, то задача тренера как раз
сделать из отдельных игроков команду и подобрать для них оптимальную
тактику на игру. "Порядок бьет класс".
Мой опыт свидетельствует о том что чистый скрам-мастер не может помочь команде во взаимодейтсвии. Он может только выполнять ритуалы. Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером. И это выглядит не как тренерство а как судейство. Об этом я и написал.
А как это, разделять ценности? Как мне определить разделяю ли я их, каков критерий? Как тому кто хочет научиться уважению перейти от декларативного концепта уважения к процедурной последовательности действий сливающейся в проявление уважения?
Ценности - это из области Ваших внутренних убеждений. Разделять ценности - принимать решения и действовать в соответствии с ними. Например, если с планирования спринта Вы уходите с мыслью "мне за спринт надо реализовать такую-то фичу в моем компоненте", а не "мы за спринт должны достичь такой-то цели", то приверженность - это не про Вас. Уважение - признать, что коллега имеет право на свое собственное мнение, право его высказывать, право на поддержку, право совершить ошибку в той же мере, что и Вы.
А откуда у вас взялась мысль о том что я не уважал своих коллег?
Я сразу написал, что это не более, чем предположения. Но в статье не упоминается, что Вы демострировали желание работать над общими задачами или обсуждать с командой проблемы скрам на ретро, фраза про тим-лида, компетенции которого никуда не делись, косвенно говорит, что у остальных членов команды компетенции развиты слабее.
Скрам это не инструмент достижения цели а рамки ограничиющие выход за пределы некоторой области внутри которой предположительно находится решение.
Для меня скрам - это способ решения проблем, например, избавление от "функциональных колодцев". Или обеспечение прозрачности статуса в долгосрочных проектах (через спринты).
С тем, что он не явлвется методологией (или универсальным инструментом), я не спорю.
Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером.
Это Ваш опыт, я его не оспариваю. Работа скрам-мастера не в том, чтобы предложить лучшее решение проблемы и защитить его, а в том, чтобы собрать нужных людей и провести встречу так, чтобы в результате появилось решение. Нужен ли для этого инженерный опыт? Сомневаюсь. Скрам-мастер не принимает решения, агрументы должны быть понятны команде, а не ему.
Но скажу честно, на практике не сталкивался со скрам-мастерами без технического бэкграунда.
Он может только выполнять ритуалы.
Ритуалы на начальном этапе - это Сю в Сю-Ха-Ри. Проверенный на протяжении веков путь к мастерству. Я видел многих, которые начинали с Ри и фейлились.
Ценности - это из области Ваших внутренних убеждений. Разделять ценности - принимать решения и действовать в соответствии с ними. Например, если с планирования спринта Вы уходите с мыслью "мне за спринт надо реализовать такую-то фичу в моем компоненте", а не "мы за спринт должны достичь такой-то цели", то приверженность - это не про Вас. Уважение - признать, что коллега имеет право на свое собственное мнение, право его высказывать, право на поддержку, право совершить ошибку в той же мере, что и Вы.
Я ничего не имею против ценностей. Я недоволен методом их изложения. Просто задекларировать ценность недостаточно. Нужно уметь эту ценность реализовать самому и научить ей других а этого в скраме нет. Я не получал негатива от команды и команда уважала моё право совершать ошибки. Но для того чтобы эти ошибки прекратились этого было недостаточно. Цель ведь не в том чтобы придерживаться какой-либо ценности а в том чтобы извлекать из этой ценности пользу, например прекращеие ошибок. Я проявлял приверженность, и активно участвовал в процессе трансформации, поначалу и довольно долго это держалось на вере, но время прошло, вера закончилась, проблемы остались. Какой смысл от приверженности бесполезного в новых условиях человека?
Ещё пример распада ценности без изменения последовательности действий. Когда ты просишь человека проявить открытость, например спрашивая чем ты можешь ему помочь. Ты как бы берёшь обязательство ему помочь. Если ты ему не помог, один раз, нестрашно. Но если это происходит постоянно или ещё хуже если ни один такой вопрос не привёл к решению. Ценность открытости скрывавшаяся за предложением помощи рассыпается, на её месте возникает ощущение пассивного давления. Цель осталось прежней, средство реализации осталось прежним а эффект со временем изменился.
Я сразу написал, что это не более, чем предположения. Но в статье не
упоминается, что Вы демострировали желание работать над общими задачами или обсуждать с командой проблемы скрам на ретро, фраза про тим-лида, компетенции которого никуда не делись, косвенно говорит, что у остальных членов команды компетенции развиты слабее.
Нежелание возникло не сразу, это шло постепенно. Заявлением о необходимости тимлида в команде я не пытаюсь принизить других её членов. Тимлид в моём представлении не водит коллег за ручку, а лишь иногда подстраховывает когда те не могут решить проблему сами.
Для меня скрам - это способ решения проблем, например, избавление от
"функциональных колодцев". Или обеспечение прозрачности статуса в
долгосрочных проектах (через спринты).
Рад за вас, я не ощутил его как способ решения проблем, а скорее как набор норм который воспринимается как инструмент но им не является.
Ритуалы на начальном этапе - это Сю в Сю-Ха-Ри. Проверенный на
протяжении веков путь к мастерству. Я видел многих, которые начинали с
Ри и фейлились.
То что я видел не было похоже на Сю. Когда ты делаешь сю, у тебя и измеримый результат должен появится, совпадающий с результатом мастера по искомому критерию, рано или поздно. Я же не увидел результата, а продолжать повторять то что не приносит результата без каких либо изменений я не видел смысла.
Проверенный на протяжении веков путь к мастерству.Ну и какой выхлоп у этого метода? Сколько идёт дальше Сю?
Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером
Опять же: не будет скрам мастер решать технические задачи. Опять вы вместо того чтобы идти за помощью в решением технических проблем, идете к СМ, который понятия не имеет что за проблема. Он скорее психолог, поможет разобраться в себе, поможет вам обратиться к команде, чтоб не подставить их, ведь вы можете провалить спринт.
Чистый скрам мастер не может помочь команде во взаимодействии
Это его работа, пересчитайте скрамгайд
- коучит участников команды в части самоуправления и кросс-функциональности;
- помогает Scrum Team фокусироваться на создании Increments с высокой ценностью,
соответствующих определению готовности;
- способствует устранению препятствий, мешающих прогрессу Scrum Team; а также,
- убеждается в том, что все события Scrum происходят, позитивны, продуктивны и не
выходят за рамки ограничений по времени.
По-моему автор четко, в самом начале, дал понять, что будет излагать собственные ощущения. Какая разница какой контекст и конкретика? Он делится тем, что было с ним, анализирует и делает выводы. И тем более, не предлагает помочь разобраться.
Тогда заголовок был бы слегка другой, не находите? Автор делает какое-то громкое заявление, но по факту ничем его не подтверждает, кроме собственных ощущений. Что соответственно вводит в заблуждение читателей, зачем?
Я нашёл то, что меня беспокоило и явно обозначил что считаю главной ложью скрама, а именно несоответствие определения скрама и того как он ощущается в реальности. А громкий заголовок нужен чтобы привлечь внимание)
Так вы в себе сначала разберитесь, в ваших высказываниях сплошные противоречия.
Например,
Я больше не могу класть задачи по компоненту в беклог(только на самое дно).
Как у вас получается одновременно и могу, и не могу? И на основании этого вы делаете выводы какие-то, очевидно тоже противоречивые, сдобрив всю историю кликбейтом, в чем сами и признаетесь ) ну, акей.
Я больше не могу класть задачи по компоненту в беклог(только на самое дно). Как у вас получается одновременно и могу, и не могу?
Хорошо, вы меня подловили, формально я мог создавать задачи в беклоге, но смысла делать это я не увидел, цель ведь не в том чтобы просто создать задачу а в том чтобы выполнить доработу по этой задаче. И потом, в чём принципиальная разница между тем чтобы класть задачи на дно беклога или не класть вообще? Ни в том ни в другом случае они не будут сделаны. Так как я не могу обосновать бизнес-ценность, они наврядли будут учтены при планировании. Это не значит что мои задачи не имеют бизнес-ценности, это значит что я не могу её оценить. Они могут просто пропасть из беклога при очередном "причёсывании".
И на основании этого вы делаете выводы какие-то, очевидно тоже противоречивые
Я делаю выводы на основе тех данных которые у меня есть. Я бы рад использовать что-то более надёжное но не могу. Однако, я верю что даже такие выводы могут кому-то помочь, поэтому я ими и поделился.
сдобрив всю историю кликбейтом, в чем сами и признаетесь
Я сомневался, делать его кликбейтным или нет, решил сделать. Лучше кликбейтный заголовок который привлечёт внимание чем неприметный который отобъёт желание даже просто открыть статью.
Про скрам мастера часто говорится, что он не решает "мои проблемы"
А он и не должен, если честно. ваши проблемы могут решить ваши однокомандники, но вы их видимо за программистов не считаете, раз идете к СМ(который часто вообще не из IT)
тем более если считаете, что в продукте есть "мой код", за которого вы отвечаете. Поэтому выше был комментарий про излишнее "я". И это не про "моя реакция на события и положение", это отсутствие понимания командной работы.
У вас хорошее понимание процессов скрам, но твердое неверие в идеи командой работы, коллективной ответственности, и т.д.
Однокомандники не могут решить все проблемы. То что я не жду от них решения не означает что я не считаю их программистами, это означает что я не вижу в их руках рычагов влияния на ситуацию. Я не скрывал своих проблем, но это не привело к изменениям. К скрам-мастерам я обращался потому что до трансформации многие из них были менеджерами.
Я готов работать в команде и я делал это пока мог. Я не готов работать в команде которая не нуждается в моих услугах. Мне просто нечего им предложить. Да и зачем, когда можно найти команду я буду полезен таким какой я есть?
Я верю в идею командной работы и верю в идею коллективной ответственности, хоть и не до конца их понимаю. Я лишь заявляю что скрам - не является инструментом их построения. Он является лишь стандартом описывающим черты команд которые смогли это построить раньше в своих условиях.
Я верю в идею командной работы и верю в идею коллективной ответственности, хоть и не до конца их понимаю. Я лишь заявляю что скрам - не является инструментом их построения.
С этим я не согласен, он как раз является инструментом построения эффективного взаимодействия для команды профессионалов, которые разделяют ценности скрама.
Он является лишь стандартом описывающим черты команд которые смогли это построить раньше в своих условиях.
Все верно, авторы скрама как раз где-то писали, что обощали опыт сложившихся успешных команд.
Но скрам-гайд не описывает трансформацию, т.е. переход от иерархической структуры к скраму. И ничего не говорит про методологию разработки ПО или инженерные практики.
Я имел некоторый опыт во внедрении скрама в небольшую команду. Результат оцениваю как "слегка положительный", команда оценивала его как "нейтральный". Хотя и гайд 2020 года стал более коротким и "менее предписательным" (так в нём написано), всё равно пришлось сократить его до 1й страницы (не меняя сути), выкинув новояз.
Тем не менее, чувствуются противоречия. 15-минутных встреч хватает впритык даже на минимальном размере команды. В отдельных специфичных обстоятельствах скрам перестаёт работать, хотя указывается, что он "подходит всем". С другой стороны, скрам вполне работает, если иногда пропускать ежедневные встречи (но формально это перестаёт быть скрамом). Самоуправление в команде часто лишь на словах самоуправление. Роль скрам-мастера (хотя мне приходилось исполнять эту роль), кажется, создана лишь с целью создания рабочих мест скрам-мастерам сектанты какие-то. Как реализуется scrum of scrums во времени, я так и не понял.
В целом, вещь рабочая, но нельзя относиться ко скраму восторженно.
«Вы можете изменить компоненты скрама но результат такой модификации скрамом являться не будет»
Кажется, это проговаривается лишь для того, чтобы скрамом (тм) не называли всякую чушь, во избежание "Да, мы делали этот ваш Торт (тм) по вашему рецепту, но вместо сахара положили перец. Говно ваш Торт (тм)!" Насколько это помогает, не могу судить.
Подозреваю, изощрёнными способами можно испортить даже процесс, формально соответствующий всем правилам. И всегда можно сказать "вы просто не умеете готовить скрам", "нормального скрам-мастера вам надо" и т.п.
"Видоизмененный скрам не есть скрам", с одной стороны, звучит логично, а с другой звучит как догма. Мужики тем самым заявляют, что их скрамгайд это очень точно выверенный скелет, на который нам остаётся лишь нарастить мяса. Перелом же одной косточки приведёт к поломке всего организма. Единственная моя претензия - это невероятно смелое заявление.
В скраме нет слов "подходит всем". В начале скрам гайда есть вполне чёткое определение фреймворка, вот оно: "Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." То есть если вам не нужно создавать ценность, или у вас нет потребности в адаптационных решениях, или у вас нет сложных проблем - вам его использовать, в целом, не надо.
Не нужно резать скрам гайд, вы из него вот это вот, например, вырезаете, потом такие разговоры.
В скраме нет слов "подходит всем".
И правда нет, тут я ошибочно запомнил фразу "... Scrum применяется не только при разработке программных продуктов, для которой он изначально создавался, но и во многих других областях, ...". Смысл не тот.
Не нужно резать скрам гайд
Увы, неподготовленному человеку скрам гайд (особенно русский перевод) непонятен. Одни термины используются прежде, чем они определены, другие нужно гуглить. За утверждением "Скрам - прост" следуют ~15 страниц описания. Даже сокращённый рассказ занимает больше пары минут - в двух словах не объяснить, что это такое.
Иронично, но позиция по этим вопросам также отражена в скрам гайде.
"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 - довольно щадяще.
Как методология Agile несостоятельна.
Я даже не поленился и открыл ссылку. Правда сразу и закрыл, Не такой методологии Agile
Сложно с таким спорить.
Я тоже не поленился и перешел. Автор анализирует манифест, но строчки "То есть, не отрицая важности того, что справа,мы всё-таки больше ценим то, что слева.", он почему-то не заметил.
Автор - Классический скрам коуч
Я потерял контроль над своим компонентом, но получил титул владельца исходного кода этого компонента. Когда титула не было, контроль был.
Право коммита у Вас забрали, что ли? Я не понимаю как разработчик, и тем более с "титулом владельца" может потерять контроль над компонентом. Если я вижу проблему в своём или чужом компоненте - я её всегда могу исправить, прямым коммитом или мерж-реквестом. Мерж-реквест отклонён без адекватной аргументации и предложений по улучшению? До свидания такой проект.
Можно отнять право пушить в мастер или, например, пушить без одобрения двух других людей. Это часть процесса, более того, я понимаю, почему такие правила могут иметь право на жизнь в сложившемся проекте.
Но я бы это отнёс к проблемам роста продукта в целом – когда от него начинает зависеть слишком многое, даже выпуск следующей мажорной версии может не помочь, "раньше было лучше, правильный винамп – это 2.70"
Приходиться догадываться. Автор не приводит никаких конкретных примеров - только обобщения непонятно чего
я потерял возможность класть задачи по компоненту в беклог(только на самое дно), выдвигать задачи на планирование, брать в спринт, тратить какие-либо ресурсы на него, даже своё время, потому что оно было занято задачами с бОльшим приоритетом в рамках спринта
Может быть клиентам в данный момент жизненного цикла проекта работа по вашему компоненту уже нафиг не нужна, а выходить из круга комфорта крайне не хочется? Скрам то тут при чём?
Так проблема в том, что клиент часто сам не понимает чего он хочет. Особенно если речь идёт о каком-то локальном "владельце процесса" который не видит всей картины и не понимает, что его "большая красная кнопка" может подождать. Для этого нужны архитекторы и тимлиды, а скрам заменяет все бессмысленным танцем с бубном.
Всё это в руках ПО
Вы - разработчик. Теперь половина претензий отпадает к скраму. Потому что вы возомнили себя владельцем продукта
Во-первых, я бы отделял вот всю эту мишуру типа "коучей, сертификации, определений" от самого скрама. Скрам-то более или менее ещё использовать можно, а вот первое - просто способ выкачивания денег из слабых духом.
Во-вторых, не понятно почему автор тревожит то, что изменив что-то в скраме, это перестанет называться скрамом. Ну, перестанет. И что? Мы вон из скрама выкинули процентов 40 и добавили процентов 20 - и ничего, продукт живёт и релизится уже не один год. Никто не умер.
Есть ощущение, что вам просто поставили нереальные сроки и нагрузили сверх всякой меры. И тут уже неважно - ватерфло, аждайл или скрам, все одно будет стыд и срам.
дело не в объёме нагрузки а в её типе, меня посадили заниматься тем что я не хотел и не мог, отодвинув то что я хотел и мог.
Скрам - это не про то, что хочется ВАМ. Скрам - это про то, что ожидают в каждой конкретной итерации стейкхолдеры (в конечном итоге бизнес). Это ни хорошо ни плохо. Это реальность. Бизнес платит разработчикам с продаж и не шибко заботится о техническом долге. Задача разработчиков доносить до бизнеса и про технический долг. Самое простое - отвоевать % времени под задачи из технического долга и самостоятельно этим временем распоряжаться. Но это небольшой процент. Дай разработчику власть - и он будет в своей тёплой песочнице рефакторить 100% времени.
не согласен, работу над проектом (по скраму или нет) я считаю компромиссом между бизнесом и инженерами, как инженеры должны помнить о целесообразности своих доработок для бизнеса, так и бизнес должен понимать что запущенные инженерные проблемы могут подкосить их бизнес-модель.
так и бизнес должен понимать что запущенные инженерные проблемы могут подкосить их бизнес-модель.
То есть это не комромисс, а подчинённость интересам бизнеса, только долгосрочным, да?
Нет, это явно компромисс а не подчинённость. У бизнеса свои интересы, у наёмных инженеров - свои. Часть этих интересов пересекается, что позволяет бизнесу и инженеру договориться о взаимовыгодном сотрудничестве для решения проблемы в интересах пользователя и извлечения выгоды (необязательно денег) из этого решения. Перекос в любую из сторон создаст проблемы, просто проявляться они будут по-разному.
Приведите, пожалуйста, пример проблемы, созданной из-за несоблюдения интересов наемных инженеров, но никак не затрагивающих интересы бизнеса.
Я тут вижу только три варианта:
Инженеры действуют в интересах бизнеса напрямую - делают фичи, фиксят баги
Инженеры действуют в интересах бизнеса опосредованно (рефакторят код, чтобы его потом проще было менять, т.е. уменьшают стоимость и время пукта 1 в будущем)
Инженеры занимаются инженирингом just for fun - хобби проект, рефакторинг модуля, который все равно выкинут через неделю и заменят сторонним решением, оптимизация како-то процесса, который не находится в узком месте и никогда не будет
Третье я бы классифицировал как хобби за деньги и на оборудовании работодателей. Это не плохо, но должно быть согласовано и рассматриваться как часть пакета компенсации (зарплата, ДМС, льготы на обслуживание у работодателя и т.п.)
Если инженеры действуют в интересах бизнеса то бизнес обладает полнотой информации и ответственнустью за принятия решений - инженер может только рассказать про возможные варианты последствий решения (Если сейчас не отрефактрим, то потом будет в 10 раз труднее менять).
Почему-то многие считают, что Скрам == Agile. Есть достаточно много различных путей, чтобы повысить гибкость и адаптационную способность ИТ-продуктов и это далеко не всегда Скрам.
Вообще-то Скрам имеет весьма узкую область эффективного использования с кучей ограничений. Agile тоже не всесилен, хотя область использования таких подходов и шире.
Начинать надо не с фреймворков, методик и методов, а с понимания, что для решения достаточно большого класса задач не подходит ни иерархическая, ни матричная система управления. Во многих случаях для решения задач, не имеющих единой оптимальной стратегии решения (к которым относится и разработка ПО) наиболее эффективвной оказывается сетецентрическая система управления на основе множества автономных команд, с общими, или синхронизированными целями. Вот тогда и появляются Agile подходы.
Я, если честно, категорически не могу понять пользу скарам коучей в современной разработке. Саму методологию, если выжать из нее всю воду, можно уместить на паре страниц. При этом современный инженер с легкостью жонглирует добрым десятком инструментов (языки, фреймворки, СУБД и т.д. и т.п.), по каждому из которых можно написать несколько талмудов, безо всякой воды.
Так объясните мне пожалуйста, зачем на полном серьезе учить этой примитивщине современного инженера? Дайте ему эти 2 листочка с описанием методологии - и он за 10 минут освоит материал. Нет же - нужно устраивать часовые лекции, извращенные тренинги, и внедрять в команду религиозных деятелей, которые рьяно будут следить за соблюдением 10 куцых заповедей.
Почему у нас тогда нет ООП коучей, SOLID коучей ну или каких нибудь реляционных коучей? Где наша свобода вероисповедания?!!!
Радует, что есть люди с трезвой головой и добрым сердцем. Сегодняшний скрам - это корпоративная религия. А т.к. внутренние дела компаний редко беспокоят простых граждан, политиков и военных, то в этой сфере процветает свобода, разнообразие и, надеюсь, местами естественный отбор. И ровно как к упомянутым 10 заповедям сегодня прилагается бесчислинное количество томиков и десятки "настоящих" конфессий, так и к скрамам прилагаются толпы проповедников. Слава роботам, мы побороли мировой голод и можем заниматься хоть скрамами, хоть пастарианством. Сегодня можно руководствоваться правилом "не нравится -не ешь". Что и сделал в итоге автор. Посоветовать могу лишь меньше рефлексировать и просто принять - люди разные в отдельном, но очень похожие в общем.
YAGNI коуча, пожалуйста
Так скрам не содержит инструкции как, например, проводить ретроспективу, что делать, если решения принимаются, но не проводятся в жизнь и так далее. Он не содержит подробных инструкций и методик.
Всякие мастера и коачи по идее должны помогать команде организоваться, следить за настроением в команде, стараться чтобы все были услышанными.
Практически, как я понимаю тут как со школьным психологами - знающих свое дело надо поискать
Сотни тысяч инженеров по всему миру, разговаривающих на разных языках, воспитанные в разных культурах с разным менталитетом сумели выработать четкие, красивые и изящные принципы и инструменты современной разработки. Создали Open Source движение. Выработали культуру свободного распространения идей и технологий. И что по вашему, эти люди не в состоянии самостоятельно выстроить процесс разработки в отдельно взятой команде без пригляда попа в рясе? Вы это серьезно?
Вы рассмотрели все опенсурс проекты или только выжившие?
Хороший поп имхо тоже типа психолога
Я правильно понимаю, что наличие умерших open source проектов убедительно доказывает полную неспособность инженеров договориться между собой и выстроить процесс разработки? И только чтение святых молитв из Agile манифеста помогает недалеким инженеришкам добиваться хоть каких то скромных успехов?
Берём пару инженеров и даём им делать что им хочется и магия, они договариваются. Все таки общение у людей в генах. Добавляем менеджера и вуаля, те же инженеры уже договориться не могут. Тоже магия.
Разоблачение фокуса, возможно, в границах и зонах отвественности, которые все понимают по разному. Одно все понимают одинаково - кто-то за их границей им теперь что-то должен. Менеджер должен понятно задачу поставить, тестер найти все баги и описать подробно, коллега обязан писать понятный код, а начальник зп поднимать и так далее. Особняком стоят люди с внутренней мотивацией, которые просто делают что нужно, не глядя на формальные и выдуманные границы. На них все и держится.
Там везде много разных документов, есть еще Трудовой Кодекс, он вообще всем помогает. OpenSource проекты, это тоже коммерческие проекты. Просто монетизируются они по-другому.
Да нет, некоторые инженеры договорятся, некоторые - нет. Можно ли как-то увеличить вероятность того, что они договорятся и выпустят то, что нужно заказчику - вот вопрос.
Не только чтение молитв, есть куча методик как аджайл так и нет. Вы же читали "мифческий человекомесяц", да?
То, что в мире есть опенсорс означает, что некоторое количество инженеров, которые смогли договориться и пилить эти проекты. Но это не означает, что модно взять любую группу инженеров и они договорятся друг другом о том, как делать работу нужную заказчику. В таком случае как раз и могут быть полезны люди которые организуют работу этих инженеров.
Вы весьма своеобразно трактуете мои высказывания. Я где нибудь говорил о том, что не нужны менеджеры проектов и аналитики? Не припоминаю такого. Наоборот, я, как инженер "старой школы", выступаю за максимальную формализацию процесса разработки, вплодь до написания ТЗ.
Я, на самом деле, даже против самого скрама не выступаю. Я лишь выступаю против возведения скарама в религиозный культ. Когда инженеров пинками гоняют на лекции и тренинги, когда в команду внедряют коучей, единственная задача которых, следить за тем, пришел ли инженер Ваня на ретроспективу или нет. Когда любая попытка оптимизировать процесс разработки упирается в религиозные запреты вида "тогда это будет не скрам". Когда отдельно взятые проджект менеджеры на полном серьезе заявляют, что нам не нужны проектирование и согласования, ибо у нас все само гибко вызреет - надо только следовать процессу. Я выступаю против откровенных трутней, которые обосновывают свою ценность религиозными завываниями. А по факту являются просто бесполезным балластом.
Наоборот, я, как инженер "старой школы", выступаю за максимальную формализацию процесса разработки, вплодь до написания ТЗ.
У меня есть печальный опыт согласования Т.З. с заказчиком на протяжении 22 месяцев. Саму доработку мы оценили в 6 человеко-месяцев (и 4 месяца по срокам).
Скрам стал востребован в эпоху дот-комов, когда выпустить сайт или приложение и посмотреть на реакцию пользователей оказалось быстрее и эффективнее, чем написать Т.З.и пройти по стандартной модели SDLC.
VK - как пример (изначально LAMP, который решал проблемы масштабирования и производительности по мере появления пользователей.
А вот начали бы с Т.З. под текущую аудиторию, до сих пор писали бы.
У меня у самого есть истории как успеха так и провала работы по ТЗ. И со скрамом видел и победы и поражения. Серебрянной пули не существует. К каждому проекту нужно подходить индивидуально.
По поводу скрама. Мое наблюдение - он по-настоящему хорошо работает только в том случае, если есть сильный Product Owner. Если у владельца продукта в голове сложилась хорошо продуманная и логически "замкнутая" концепция продукта, и если продакт хорошо идет на контакт с командой (в идеале он должен быть доступен 24*7) - то можно и нужно пропустить стадии формального согласования, и попытаться "выстрелить" с помощью скрама. В остальных случаях "выстрел", с большой долей вероятности, окажется прямо себе в ногу.
И еще, вы точно уверены, что нужен отдельный человек, который будет следить за тем, соблюдает ли инженер Ваня договоренности по процессу разработки или нет? Если уж наш Ваня такой безответственный товарищ, то почему в команде нет отдельных людей, которые следят за тем, следует ли Ваня устоявшимся практикам разработки кода? Которые, кстати, на порядок более сложные, чем Agile методологии. Как я уже говорил в начале. ООП коуч. SOLID коуч. И т.д. и т.п. Если нам к Ване нужно приставить десяток коучей, то нахрена вообще нам нужен такой Ваня?
Пора писать "Повесть о том, как один разработчик десять agile-коучей прокормил".
Как вы определили, что их нет? Они есть, но не везде, как и коачи.
Есть консалтинг по инженерным практикам, есть инжениринг/техлиды которые выполняют те же функции. Есть практики, типа код ревью, которые поддерживают соблюдение устоявшихся соглашений.
Гайд определяет набор ролей, но не требует, чтобы это были отдельные люди.
Ревью проводят другие инженеры, которые и сами пишут код. Это, кстати, очень полезный процесс (если опять таки проводить его с умом) - улучшается качество кода, распространяются знания по команде. Отдельно взятого человека, который занимался бы только тем, что следит за соблюдением инженерных практик, я за более чем 20 лет работы ни разу не встречал. Пришел ли инженер Ваня на ретроспективу, может легко проконтролировать тимлид или менеджер проекта (тут меня сильно удивляет сам факт того, что Ваню в таком простом деле вообще нужно контролировать. Если нужно, то не проще ли Ваню "попросить на выход"?). Времени и сил на это много не надо. И, кстати, тот же тимлид вполне взрослый человек, чтобы самостоятельно принять решение, а нужна ли сама ретроспектива команде или нет? И не волноваться о том, будет ли процесс скрамом если он ее отменит.
Просто не надо забывать, что методологии созданы для нас, а не мы для методологий. Конечная цель - выдать качественный продукт за приемлимые сроки и бюджет. А соблюли ли мы при этом методологию или нет - абсолютно неважно.
А видел разных "ответственных за" которые ревьюили код. Я слышал о техническом консалтинге - приходит человек, организует разработку, включая технические практики, когда наладилось уходит.
По организационным практикам часто то же самое. Например ведение собрания и организация процессов.
Скрам мастер в гайде это роль, а не человек, возможность ее совмещения не апрещается, хотя в сети есть мнения на этот счет.
А соблюли ли мы при этом методологию или нет - абсолютно неважно.
Совершенно верно. Неважно как сделан салат, главное чтобы был вкусным. Но при этом есть и рецепты.
Отдельно взятого человека, который занимался бы только тем, что следит за соблюдением инженерных практик, я за более чем 20 лет работы ни разу не встречал.
А Вам приходилось внедрять безопасную разработку (SSDLC)? Или сертифицироваться по ISO 27001?
Это все, к сожалению, не отменяет сотен тысяч инженеров, у которых ни с того ни со всего "потерялся контроль над компонентом" (что бы это ни значило). И они сразу отправились "воевать с группой из нескольких десятков человек".
К сожалению (или к счастью), ситуация такова, что люди все разные, подходы к работе тоже широко варьируются. Кто-то выгорел, кто-то устал, кто-то испытывает личную непрязнь, кто-то просто саботирует процесс, плетет интриги, кто-то беспринципный карьерист. Что предлагаете с ними делать?
Вот смотрите. Давайте возьмем религиозные заповеди. "Не убий, не укради, не прелюбодействуй". Что плохого в этих заповедях? Да ровным счетом ничего! Любой разумный человек, прочитав их скажет - хорошие правила, давайте их придерживаться! Только какое отношение к этим простым, разумным и прекрасным в своей сути правилам имеет церковь со своей историей насилия и мракобесия?
То же самое и со скрамом. Нет ничего плохого в тех идеях, которые предлагает Agile методология. Напротив, в ней много хороших и полезных по своей сути вещей. Но, какое отношение к этим идеям имеют расплодившиеся корпоративные религиозные деятели, которые за формой не видят содержания? И для которых процесс важнее результата.
Те проблемы, которые вы описали, есть в любом человеческом коллективе. И, так же, как и заповеди "не убий, не укради, не прелюбодействуй", Agile методологии МОГУТ улучшить ситуацию. Но вот религиозные деятели, которые паразитируют на этих методологиях ситуацию улучшить в принципе не способны.
Предлагаю не мешать сюда религию.
Факт, всем нужен процесс, всем нужен контроль, что он выполняется. Бизнес хочет понимать, на что он тратит деньги. Исполнители должны понимать, что от них хочет бизнес. И это зачастую настолько далекие друг от друга люди, что без посредника они просто не договорятся. И чем сложнее процессы, тем сложнее схемы и тем больше посредников. Плохо, когда это превращается в карго-культ. Но, как правило, бизнес - это не дурак и все такие вещи рано или поздно исчезают. Либо исчезает несмышленый бизнес. Дураков тратить деньги в никуда очень мало ))
Как правило, секты очень эффективны, там как раз все за идею.
Рабочий коллектив сложнее, там кто-то за идею, кто-то за деньги, кто-то комбинирует. И это нормально!
Давайте возьмем религиозные заповеди.
Опасно, но давайте.
"Не убий, не укради, не прелюбодействуй". Что плохого в этих заповедях? Да ровным счетом ничего! Любой разумный человек, прочитав их скажет - хорошие правила, давайте их придерживаться!
А, ну можно и закончить, скрам мастера видно из далека. Любой разумный человек, прочитав их скажет - правила плохие, давайте не будем заниматься этим бредом.
Наши предки сотни тысяч лет прелюбодействуют. И все занимаются этим сейчас. "До брака нини" это мем очень забавный, но к реальности отношения не имеющий.
Не убий это вообще без коментариев. Что-то из разряда подставь другую щеку. Пришли убивать меня, мое красть, мою дочь прелюбодействовать, а должен просто брать и смотреть, ведь мне сказано не убий?
Видишь человека который против всего плохого, за все хорошее, то знай, это личинка скрам-мастера.
«До брака нини» это мем очень забавный, но к реальности отношения не имеющий.
Потому что «не прелюбодействуй» это не вступай в связь с тем/той, кто в браке или если сам в браке, а не про «До брака нини».
Причины почему это общественно вредно понятны — во-первых, это нарушение тех добровольных обещаний, что были даны при заключении брака, во-вторых, множество людей было убито ревнивыми мужьями и женами, в-третьих, брак это про совместное воспитание детей (в-первую очередь), которое ставится под угрозу при таких изменах.
То есть с точки зрения логики — сначала разойтись с текущим партнером, а потом уже заводить новые связи, вполне логично.
Не убий это вообще без коментариев.
Там не просто «не убий», а «не убий ближнего своего», то есть это правило не относится к врагам из других народов (на войне, к примеру), к преступникам и тем кто пытается тебя убить/ограбить и т.п.
По сути, можно перефразировать как «нельзя убиват людей из своего социального сообщества, если они не пытаются убить или ограбить вас (что исключает их из членов вашего же сообщества)» — что вполне разумно для любой группы людей.
Потому что «не прелюбодействуй» это не вступай в связь с тем/той, кто в браке или если сам в браке, а не про «До брака нини».
Эм, нет, одна из трактовок до брака нини. Иногда трактуется вообще, как секс для удовольствия. Но обычно, прелюбодействовать, это в общем-то, просто секс между людьми которые не связаны браком.
По сути, можно перефразировать как «нельзя убиват людей из своего социального сообщества, если они не пытаются убить или ограбить вас (что исключает их из членов вашего же сообщества)» — что вполне разумно для любой группы людей.
Нельзя. Во первых у вас сказано "не убий", а во вторых, насколько мне известно, про ближнего своего это уже из пояснинений, а не из самих заповедей. Но самое главное, третье, ничего не сказано про отношение к вам. Сказано про близость, очевидно родственную, а про то что убивать нападающих на вас, вы уже додумали. А как мы знаем, все модификации скрама скрамом не являются.
UPD: Но вообще не понятно зачем я продолжаю спорить о терминологии, если всетаки мой поинт был в другом. А именно, в том, что не все что "любой разумный человек одобрит". Нет, не любой. Даже не близко к этому.
Не нужно смешивать Agile и Scrum. Идеи Agile сами по себе вполне разумны и не очерчивают настолько четких границ. Другое дело Scrum - шаг вправо или влево и это уже не Scrum. Я знаю про Scrum-мастеров/тренеров, но ничего не слышал про Agile-мастеров.
помогать команде организоваться, следить за настроением в команде, стараться чтобы все были услышанными.
Работа для engineering manager, нет?
Почему у нас тогда нет ООП коучей, SOLID коучей ну или каких нибудь реляционных коучей?
Ошибаетесь, они просто зовутся не коучами, а евангелистами)
В большинстве Agile-фреймворков есть роль, в задачи которой входит сопровождение правильного использования этой методологии:
Scrum = Scrum Master
XP = XP coach
Lean software development = Lean Master
DSDM Atern = DSDM coach
Нет явно выделенной роли в Crystal family и в Kanban. Но и то в последнем может быть "Agile coach".
Зачем они там нужны? Потому что "легко понять, сложно внедрить".
Удивительно, но несмотря на триллионы которые вкладываются в айти никто не проводит реальные исследования насчёт того какая методология разработки или фреймворк - лучше, быстрее и дешевле. Почему бы не провести тестирование и выяснить это?
Религия существует не для того, чтобы вы были эффективными. А существует она для того, чтобы вами манипулировать. А для того, чтобы вами манипулировать, от вас требуется слепая вера. Так что все эти ваши исследования и тестирования - это чистой воды ересь!
Вопрос нужно ставить по другому. Одно дело, когда кучка относительно образованных и интеллектуально развитых людей манипулирует огромной голодной и безграмотной серой массой. И совсем другое дело, когда кучка совершенно безграмонных людей с помощью слепой веры пытается манипулировать интеллектуальной элитой. В первом случае польза очевидна, а во втором как то не очень.
Потому что эти триллионы и так приносят неплохие прибыли. Вот как станет вопрос улучшить "двс" на полпроцента, тогда и задумаются.
Для правильного исследования надо подобрать несколько полностью одинаковых команд, и заставить их разработать один и тот же продукт. Возьмётесь?
Ну препараты же как-то испытывают на неодинаковых людях
На многотысячных выборках, и даже там их делят на когорты.
Хорошо, тысячу неодинаковых команд, распределить по методологиям рандомизированно желательно с плацебо-методологиями. Теперь давайте оценим себестоимость такого исследования
А мне кажется как раз это и происходит, просто результат этого эксперимента не принимается- что это не работает так как обещает. А только при подходящего для этого случаях. Что не может быть правилом .
Так приведите ссылку на исследование зачем "кажется"? Кто и где этот эксперимент проводил?
Вы, я и другие...просто это никак в лаборатории, это своего рода социальный эксперимент. Зачем вам таким придирчевым быть?! Проще надо быть..
Неа, это будет наблюдение а не эксперимент. Это принципиальная разница - невозможность рандомизации.
Но даже на хорошее наблюдение не тянет.
Рандомный интернетный чувак не осилит прочитать несколько страничек и понять что ему подсунули не скрам под именем скрама. И он будет молчать когда все хорошо и жаловаться когда все плохо.
Потому что методологии зависят в первую очередь от требований к продукту и, что ещё существеннее, темпов их изменения. Один COVID дал изрядного пинка под пятую точку всему ритейлу и ресторанному бизнесу - пинка достаточного, чтобы те методы, которые до сих пор работали, вдруг оказались недостаточно эффективными.
Это в первую очередь касается, конечно, материальных процессов типа доставки, но и IT-поддержка, и "витринная" часть - то, что видят клиенты на сайтах - тоже должны были перестроиться как минимум не медленнее конкурентов.
Просто там еще рядом толпа трудноуловимых вещей рядом. И в итоге TPS с канбаном взлетает в Tойоте, но не взлетает на западе и начинают говорить, что это японский менталитет. А потом он взлетает в американских заводах Тойоты и проваливается в (кажется, могу наврать с брендом) Hitachi и уже не совсем понятно, что говорить.
Яркий пример TPS в Европе - Porsche годов 1995-2003
Изучите что было до и что стало
На самом деле есть 4 примера компаний из запада, которые смогли принять философию и добиться примерно того же результата, что и Тойота. Это из книги "бережливое производство"
Так я не про то, что TPS не работает на западе, я про то, что исследования не работают. Если Тойота может это сделать с любыми людьми, как вы дополнили и Porsche может, а с теми же изначальными японцами Hitachi не может.
И вот спрашивается, TPS работает или нет, какое еще исследование и с каким бюджетом нужно проводить?
А статистика по успешности ИТ проектов, которая ежегодно публикуется все так же даёт равные трети на успели почти в срок, превысили бюджет и/или срок, сфелились до упора. Без выделения успешных/провальных методологий разработки проектов.
Основная проблема скрама, как по мне, что он монополизирован менеджерами, и ими модифицирован в интересах менеджеров, хотя изначально он был создан как средство для упрощения жизни разработчиков, тестировщиков и прочих производительных сотрудников (если мы говорим про айти).
Это значит, что из скрама выбросили фиксированные спринты, четкие скоупы, запрет на добавление задач в середину спринта, задачи без четкого и видимого результата, минимизацию коммуникации вне митингов, концентрацию на важных фичах и т.п.
Зато оставили ежедневные митинги, 90% которых - это отчетность, переэстимейты, и объяснения, почему предыдущие эстимейты были неправильные (в 80% - потому что менеджеры их и продавили).
В общем, больше контроля богу контроля, и меньше планирования, потому что это же скрам, у нас гибкий процесс, вот тебе еще фича за день до конца спринта, а почему ты не успел предыдущие, ты же "сам" эстимейтил?
Это значит, что из скрама выбросили фиксированные спринты, четкие скоупы, запрет на добавление задач в середину спринта, задачи без четкого и видимого результата, минимизацию коммуникации вне митингов, концентрацию на важных фичах и т.п.
Запрета добавления задач в середине спринта в последней версии скрама нет (есть оговорка - "можно добавлять, если это не повредит качеству выполнения ранее добавленных задач"), запрета на коммуникацию вне митинга тоже нет. Если менеджер не умеет в приоритеты и ничего не знает о разработке, скрам вряд ли поможет.
Основная проблема скрама, как по мне, что он монополизирован менеджерами, и ими модифицирован в интересах менеджеров, хотя изначально он был создан как средство для упрощения жизни разработчиков, тестировщиков и прочих производительных сотрудников (если мы говорим про айти).
Насколько я понял из гайда, скрам нужен для поставки качественного программного обеспечения точно в срок, реагирования на изменение требований, прозрачности прогресса разработки. Это цели менеджеров. Разработчикам от внедрения скрама быть может станет проще, если например из-за скрама менеджеры откажутся от чайка-менеджмента или других порочных практик. Но изначально это инструмент организации работы, так что он больше для менеджеров.
скрам не ведёт себя как фреймворк. Он ведёт себя как стандарт. Тот у кого недостаточно опыта с программными фреймворками и стандартами ни за что не ощутит разницу между этими концептами в контексте неформального взаимодействия между людьми. Я считаю именно эту ошибку в определении главной ложью скрама.
Framework - это вообще "сруб". Можно ли тягать брёвна из сруба, чтобы построить дом? Можно, но сруб это разрушит. Не надо подменять англоязычные термины своими программистскими определениями. И, конечно же, золотое правило: читайте документацию в оригинале, а не в переводе.
Это лучший перевод. Какие ещё есть варианты? Каркас? Остов? Именно перевод "framework" как "сруб" показывает: это будет основой, но это же будет и ограничением, которое невозможно переделать "под корень". Отрасль не та, но свойства отлично совпадают.
Вот автор воспринимает "framework" как класс программных продуктов; скорее всего, даже не думал о других значениях, и возмущается, что свойства у SCRUM не те. Привёл такой перенос свойств к неверному восприятию общего термина.
Да я воспринимаю фреймворк как класс программных продуктов, потому что предметной областью моей работы является разработка программных продуктов. Откровенно говоря до вашего комментария я не знал что фреймворк можно перевести не только как каркас но и как рамки. Это несколько меняет мою позицию, но не отменяет проблемы. Слово "фреймворк" содержит оба смысла, как каркас так и ограничение. Слово "стандарт" же фокусируется на ограничении, соответствии чего-то эталону. Я по-прежнему считаю что оно лучше отражает суть.
Любое слово похоже на стандарт, так как есть набор критериев, обозначать ли им явление или нет.
Допустим вы выпускаете каркасы домов (ну или набор чертежей для производства каркасов) под названием "Сетунь-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) и что от них ожидается, а не просто набор практик.
Я раньше так думал но нет, не сходится, скрам-гайд не содержит каркаса дома. Нету в нём "Сетунь-3".В нём есть только описание того что в скрам-доме есть стены, крыша, окна, двери, что ходить надо через двери, смотреть лучше через окна. Это круто но этого не достаточно для постройки дома на основе такого "фреймворка". Для постройки дома нужны навыки проектирования, инструменты, материалы, умение с ними работать, знание СНИПов. А в скрам-гайде этого нет. поэтому он и не дотягивает до фреймворка а годится только как стандарт.
Вот ещё аналогия: нельзя написать приложение на JPA, JPA это только стандарт, логику реализует реализация этого стандарта, например Hibernate. Твой код останется совместимым с JPA если выкинуть Hibernate из приложения но работать он перестанет.
Для постройки дома нужны навыки проектирования, инструменты, материалы, умение с ними работать, знание СНИПов
Каркас дома это не дом - посмотрите на картинку. Для постройки дома на основании каркаса нужны материалы для стен и прочее. В каркасе нельзя жить.
В случае скрама есть дополнительная информация - книжки и люди.
Как я понимаю, со скрам мастерами так же как и с психологами. Окончания ВУЗа недостаточно чтобы он был гарантировано полезен. Вот, напрмимер, статья про то, как человек их собеседовал и сколько он отсеял
Да, каркас дома это не дом, но каркас дома это часть реализации дома, элемент его конструкции, физический объект, если использовать готовый каркас то часть работ можно будет не делать оперевшись на готовое. Скрам же это не каркас, это описание каркаса, его стандарт. Если каркас можно чем-то обшить, например сайдингом. То описание каркаса обшить не получится. Я поймал себя на мысли что пытаюсь обшить сайдингом стандарт не имеющий физического воплощения а сайдинг почему то падал на землю вместо того чтобы висеть на каркасе. Об этой несостыковке я и попытался рассказать.
Если каркас можно чем-то обшить, например сайдингом. То описание каркаса обшить не получится.
В области информации каркас и есть описание. И так же как обшиание сайдингом (не знаю, обшивают ли на самом деле или как-то прикрепляют панели, а сайдинг это уже не то) требует сайдинга и навыков а не только каркаса (я, например, не смогу без дополнительного обучения), так же каркаса процесса недостаточно чтобы им овладеть.
Предствьте что Скрам это программный фрефмворк вот с таким кодом
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 взяли в спринт либо вы бы могли сказать почему их не взяли.
Вы пришли к тому же примеру что я привёл в статье, там где я говорю о том что скрам напоминает интерфейс из языков программирования. А реализацию этого интерфейса предстоит реализовать команде вместо того чтобы переиспользовать дефолтную реализацию которая могла бы быть предоставлена фреймворком. Детали реализации, такие как практики не являются частью интерфейса и сильно зависят от контекста конкретной команды и могут не иметь смысла в тех или иных ситуациях, для правильного их использования требуется опыт, которым обладают сильные профильные специалисты например инженеры и/или менеджеры, скрам-мастер же сам по себе таким опытом не обладает и поэтому не может подстраховать команду если та не справится.
Не совсем. Скрам не является интерфейсом. Скрам содержит код игрового цикла, который требует наличия реализации интерфейса.
Скрам мастер это разновидность менеджера, по крайней мере так метание считают.
Опытный мастер - опытный менеджер. Неопытный мастер - неопытный менеджер. Как и любой менеджер он не обязан быть специалистом в чем-то ещё, чтобы быть полезным но это ему поможет.
https://www.scrum.org/resources/blog/scrum-master-manager
Скрам описан через набор артефактов, событий и ценностей, он не содержит цикл, цикл реализует команда, скрам лишь декларирует факт наличия цикла. Скрам декларирует события но не описывает как именно их реализовать, какую последовательность действий выполнить чтобы успешно провести событие, какие проблемы могут возникнуть в процессе и как их решить, всё это должна знать команда. Скрам декларирует ценности но не показывает как именно их проявлять, это ответственность команды. Если команда не имеет достаточно опыта для реализации закдекларированных в скраме концептов, скрам им не поможет, и скрам-мастер не подстрахует.
Опытный мастер - опытный менеджер. Неопытный мастер - неопытный
менеджер. Как и любой менеджер он не обязан быть специалистом в чем-то
ещё, чтобы быть полезным но это ему поможет.
Так всё таки скрам-мастеру нужны навыки менеджера? а если разработчики не понимают как оценивать задачи из-за того что не знают как именно будут их решать? Чистый скрам-мастер в такой ситуации сможет прежложить в лучшем случае менее точную систему оценки, вместо часов сторипоинты или размеры футболок. Менеджер предложит оформить задачу как исследовательскую и отказаться от её оценки, ограничившись лимитом времени на исследование. Тимлид же засчёт технических навыков и опыта может подсказать решение тем самым устранив неопределённость при оценке вместо борьбы с её симптомами.
скрам лишь декларирует факт наличия цикла.
Это и есть "содержать цикл". Программа тоже не выполняется сама, она декларирует наличие цикла. Чтобы его выполнить нужен какой-то интерпретатор - компьютер или человек может в уме выполнить.
а если разработчики не понимают как оценивать задачи из-за того что не знают как именно будут их решать?
Скрам мастер должен умет учить команду как ей самоуправляться. Один из аспектов самоуправления - умение планировать. Соответственно, он должен знать техники планирования.
Менеджер предложит оформить задачу как исследовательскую и отказаться от её оценки
Да. Это называется spikes. Это как раз один из приемов оценки. Такой же как и использование менее точных единиц измерения. По ссылке еще про backlog refinement.
Тимлид же засчёт технических навыков и опыта может подсказать решение тем самым устранив неопределённость при оценке вместо борьбы с её симптомами.
Тимлид может как иметь так и не иметь технических навыков. эксперт по технологиям может как быть так и не быть тимлидом.
Задача тимлида организовать получение этих знаний из специалиста, если он есть или другим образом, если его нет. Задача скрам мастера - научить команду саму организовывать получение знаний
Прочитал только треть статьи. Я нифига не разраб, я руководитель группы аналитиков много лет. И из жизненного опыта могу сказать только одно - когда самоцелью делают инструмент, результат обвалится как пить дать. Один из принципов agile в какойбы то ни было области - клиентоориентированность. А не мантры
Есть мнение, что SCRUM и AGILE это фичи, придуманные, чтобы тупо подольше водить за нос заказчика. Конечный результат или будет или нет, зато за каждый шаг, совершённый по пути к нему, сделанный демонстративно по обрядово-культовым стандартам, можно содрать подороже. А то, что шаг сам по себе не шибко то и ценен, скрыть под красивыми словами.
И совесть не мучает, и цена выше. Как там реально командра разработки внутри работает, задолбали их внутри эти обряды или нет, не так уж и важно. Как справедливо написали выше, есть нормальная команда - её сложно испортить всякой хернёй (хотя и можно, видел такое), нет нормальной команды - остается только продвавать воздух Заказчику, типа спринтов и посиделок.
ЧВС неумехам повышает, полных бездельников на "важную роль" брать позволяет, околорелигиозную бурную деятельность вокруг с хорошей такой капитализацией (коучи, конвенции и прочая шняга) создает? Создает. Проблему безработицы в итоге решает. Платим за весь это маскрад мы, потребители и бизнес. Никогда не доделанные кривые "Продукты" по завышенной стоимости. За репутацию отрасли, как производителей "херак - херак и в продакшн" спасибо именно этим двум вещам.
PS Абсолютную чушь продавать сложно, некое рациональное зерно в них есть, конечно. Но для людей с трезвым мышлением это зерно и так очевидно, не обязательно его в религию заворачивать.
Для себя вынес следующее про скрам: это странная игра, в которую обожают играть менеджеры, поэтому ты от нее никуда не денешься. Раньше все боролся, задавал неудобные вопросы... но проще относиться как к чужой блажи и просто выполнять необходимый минимум вещей, которые от тебя ждут. А работу свою строить так как тебе удобно
Обычно теряется зерно методологии – тесное взаимодействие и помощь разработчикам, проекту, и заказчику. Всё делается чтобы двигать проект и деловые отношения вперед, и методология, метрики, они помогают это делать, но это не цель. Можно работать и без них.
Проблема в том, что это очень общие слова, и наличие процессов часто начинает преобладать над реальной пользой от них. Вот поставили спринт две недели (как обычно), а от этого накрылся релизный пайп, ребята не успевают, и начал разваливаться обычный процесс. Вот зачем такой процесс нужен? Начинайте изучать процессы, делать инкрементальные изменения, отлаживайте, но не рушьте.
Поэтому я воспринимаю методологии как набор идей, как можно двигаться к лучшую сторону, как отлавливать проблемы по ходу и решать их, а не набор принципов которые можно применить и "все пойдет бодрячком". Нет, потому что первичен проект, и если есть проблемы, то хоть 1000 раз наложи правила, ничего не взлетит, потому что проект в них не вписывается, и поэтому правила диктуются проектом, а не проекту диктуются правила. Корень – проект.
Вот поставили спринт две недели (как обычно), а от этого накрылся релизный пайп, ребята не успевают, и начал разваливаться обычный процесс.
Формально, скрам гайд допускает спринты до месяца. Почему выбрали 2 недели - вопрос к менеджерам, а не к скраму. Возможно, старый релизный цикл показался кому-то слишком долгим. Возможно, взяли некоторый "разумный" (но оказалось, не разумный) минимум, чтобы можно было быстрее внедрять задачи в продакшен. Ведь если менеджеру в начале спринта придёт в голову Идея, при спринте в 1 месяц она будет реализована в лучшем случае через 2 месяца - к концу следующего спринта. А при спринте в 2 недели - через месяц, это конечно долго, но ещё можно дождаться. С другой стороны, при спринте в 1 неделю на планирование и ретроспективу может уйти 2 дня из 5, и это выглядит не очень эффективно.
Скрам - это не стандарт.
Скрам - это не методология.
Скрам - это не фреймворк.
Скрам - это не Agile.
Скрам - это говно.
Больше скрама богу скрама. Один раз я попал на такой семинар. Стал скрам - мастером в последствии.
Сколько боли, сочувствую вам. Надеюсь, в будущем вам будут попадаться люди, которые смогут объяснить и направить в более подходящем для вас русле. Жаль, что вы воспринимаете рабочий процесс как битву за себя - вполне можно найти компанию, где рабочие процессы больше подходят под ваш темперамент и мировоззрение.
Читал первую половину статьи автора, возмущался, что он что-то перечисляет, но не приводит конкретных примеров. Но как дошел до второй части, понял, что примеры и не нужны. Автор молодец, познал дзен. Если ему подобранные определения в скраме мешали понять скрам, то ничего страшного, если в итоге он заменил их на свои. Всё-таки скрам - это аджайл. Ну и в топку коучей с их каргокультом.
Я бы от скрама оставил только состав команды и ритуалы с необходимостью их выполнения. Запланированные ритуалы отвечали бы за итеративность, На ретро вносили бы изменения в свою работу. Пусть это бы ломало "гайды", но если оно крякает как утка и ведет себя как утка, то пусть это будет утка (пусть это будет скрам).
Роль скрам-мастера можно, и, наверное, нужно, отдать тим лиду: это его задача как servant leader. В принципе в этом и есть функция скрам-мастера наряду с модерированием встреч. Со временем, если мы говорим о самоорганизованной команде, встречи модерировать больше не придется, останется привычная многим роль тимлида. Рассматривайте архитектора как одного из заинтересованных лиц, пусть он через продакт овнера влияет на беклог. Ну или отдайте роль продакт овнера архитектору.
В общем, карго-культ в топку. Оправдывайте себя тем, что скрам - это аджайл, а по аджайлу важнее люди, а не процессы.
Когда люди пытаются использовать стандарт как фреймворк единственное что они могут это следовать за нормами стандарта упуская из виду реализацию. Так, по моему мнению, и возникает карго-культ.
Часто использую понятие "карго-культ" в IT. Однако в моем понимании это по большей части следование моде, диктуемой "великими" брендами, бездумное и неоправданное использование навязываемых технологий и инноваций, и как индикатор -- полное отсутствие критики и критического мышления.
Это далеко не новость, к сожалению. Об это ещё лет 5+ назад на каждом углу кричал James Coplien, который по сути один из самых известных "популяризаторов" скрама в айти.
На текущий момент, всё это чистой воды коммерция. Людям придумали новые роли, в индустрии создали искусственный страх, что без этих ролей продукт не взлетит, и вот теперь мы имеем, что имеем. Толпы паразитов, цель которых, создать видимость хоть какой-то деятельности.
Но, бывают и исключения. Я работал с очень хорошими и полезными скрам-мастерами в хорошо организованном скрами, вот только все они были из разработки, или от бизнеса - бывшие девелоперы и бизнес-аналитики. "Чистые"-скрамы - это, конечно же, абсолютно бесполезные существа.
А есть ещё всякие крутые штуки, типа SAFe, где вообще миллион "менеджеров", и девелопмент где-то на задворках. Менеджмент дривен девелопмент, мать его.
Насчёт малополезности коучей я согласна. Они будто не помощники, а надзорный орган, который следит, чтобы вы оставались в рамках.
Но в целом в статье очень много личного мнения и размышлений, при этом нет никакой конкретики, и ситуацию невозможно проанализировать. Можно только согласиться или не согласиться с автором на основании своего личного опыта. Невозможно проанализировать -> невозможно сделать выводы -> низкая практическая значимость текста. А заголовок - громкий.
Хотя один вывод, пожалуй, мы можем сделать: при возникновении проблем лучше их обсудить (с руководителем, с командой).
Скрам придумали для менеджмента исследований, открытий чего-то нового, рисерча. Когда ты седня не знаешь, что будет дальше, потому что первый раз идешь по этой тропе. Он поэтому и гибкий, что ты не знаешь, что будет завтра и надо менять планы на лету.
По сути это неэффективный костыль, который позволяет идти наощупь, когда темно.
Проблема в том, что его используют и когда светло, оссобеено забавно звучит скрам из каких нить сберов-яндексов. Где всё распланировано на год вперёд, бюджеты выделены, фронт работ известен. А ты идешь наощупь)
Скрамом просто прикрывают некомпетентность, когда всё сроки сорваны, нифига не сделано, ты объявляешь фичу по изменению цвета кнопка, офигенно научным исследованием, делающимся впервые)
С моей точки зрения мнение автора который утверждает что скрам - это стандарт, и относиться к нему надо как к стандарту а не как к руководству к действию очень похоже на реальность. Давайте вспомним такого зверя как ЕСКД, с одной стороны это конечно стандарт и его надо придерживаться, но если Вы мне покажете чертеж с соблюдением ВСЕХ требований стандарта, я очень удивлюсь, тем не менее все разумные требования стандарта все соблюдают. Так и скрам - это стандарт некоторой технологии разработки (есть и другие технологии!) и в нем есть разумные(обязательные) требования и желательные требования. Несоблюдение обязательных требований означает что Вы нарушаете выбранную вами технологию и ничего больше. Либо соблюдайте либо выбирайте другую технологию. С моей точки зрения автор высказал очень правильную мысль: Скрам - это стандарт технологии разработки но никак не учебник и не указатель. Возвращаясь к ассоциации с чертежом - стандарт говорит что допуск надо указывать таким и только таким образом, но ничего не говорит какой именно допуск нужно выбрать. Так и скрам говорит "Есть такая технология работы, если она Вас устраивает - делайте то то и тогда то. Не устраивает - ищите другую технологию, но не нарушайте эту"
Отличный анализ и выводы. Это типичный пример того, почему скрам не agile - внедряторы делают все для процесса и игнорируют людей, команду - прямое игнорирование принципов agile, но т.к. внедряется скрам то всем всё равно. Всё должно быть с точностью до наоборот.
Ещё огромная проблема это то, что кому попало выдают сертификаты скрам-мастеров. Это просто бизнес, но в итоге люди как роботы повторяют мантры и процесс разработки начинает игнорировать мнение команды в угоду следования процессу.
Странно, что ещё никто не запостил винрарное видео на тему:
Тяп-ляп и в продакшн
Ничего не могу сказать по теме, но как классно автор излагает! Умение доходчиво и увлекательно выразить мысль 80-ого уровня!
Автор столкнулся с тем, что инструмент не стал решением, а стал проблемой. Это нормально. Далеко не все инструметы являются решением всех проблем, даже если кто-то так считает. Например, есть фанаты идеологемы "если у вас есть молоток, то все проблемы вам представляются гвоздем", но очевидно, что молотком сложно вывернуть шуруп (а забить его вполне можно, с печальными последствиями).
Так и превращение SCRUM и AGILE в "универсальный молоток" автор наблюдал на своей шкуре.
Некое обожествление той или иной технологии (на манер религии, как верно написали выше) всегда выгодно только тем, кто её продает, а не тем, кто этим пользуется.
Спасибо автору за поднятую тему.
Тема вечно актуальная :)
У нас менеджмент достаточно здраво находит баланс через формулировку: мы не следуем какому-то фреймворку, мы из разных стандартов будем пробовать те практики, которые, как нам кажется на примере других команд, могут улучшить наши процессы. Если проба показала, что для конкретной команды это не работает, то ищем следующее решение. А это можно попробовать с другой команды (другой набор личных качеств людей, другой продукт), либо вовсе отказаться, т.к. ни одна практика не является "священной".
Вот так можно скрестить здравый смысл с "опытом предков".
Отличная статья! Спасибо вам за проделанную мыслительную работу!
Никакой конкретики, сплошная вода.
Пришли злобные скрамщики, что-то сделали ("но я не скажу что изменилось, т.к. это не важно")
И все стало плохо.
Худшая статья из тех, что я читал на Хабре.
Никакой конкретики, сплошная вода.
Пришли злобные скрамщики, что-то сделали ("но я не скажу что изменилось, т.к. это не важно")
Эта статья не про конкретику и не про анализ решений принимаемых в рамках проекта. Я избегаю конкретики не потому что она не важна, а потому что не могу ей поделиться не рассказав слишком много. Кроме того я не могу её правильно проанализировать.
И все стало плохо.
Плохо стало не всё и не для всех, я описал свой опыт. Статья рассчитана на людей которые испытывают то же что и я. Она для тех кто понимает что у них что-то идёт не так и это как-то связано со скрамом, но не могут сформулировать мысль.
Худшая статья из тех, что я читал на Хабре.
Рад что мне удалось вас впечатлить)
Скрам сам по себе не работает, работают люди. И иногда они работают так что Скрам не помогает, а вредит. И поменяй им методологию, думаю суть происходящего не поменяется. Предвижу что в IT все еще предстоит осознание того что субъективная, культурная, личностная, групповая, корпоративная динамика - это почва проекта, а многие ее выносят за скобки в лучшем случае и гадят в нее в худшем.
Главная ложь SCRUM. Откуда берётся карго-культ