Я обнаружил, что это произошло и в моей команде, хотя, возможно, он немного преувеличил ситуацию.
Scrum - это способ взять разработчика ниже среднего или плохого уровня и превратить его... в среднего разработчика. Он также отлично подходит для того, чтобы взять отличных разработчиков. и превратить их в средних разработчиков.
Все просто хотят взять что-то легкое с доски, что можно > сделать. сделать за день, чтобы было о чем отчитаться на завтрашнем ежедневном скраме. Просто все пытаются выбрать низко висящий плод. Нет стимула быть умным и тратить время на обдумывание > решений, если ничего нет. решения, если ничего не движется, что вы вообще делаете? Вы подводите команду! Скорость падает!
Я думаю, если у вас есть сложные проблемы, которые нужно решить, вы решаете их, отдавая их умным людям, а потом оставить их в покое. Вы не должны постоянно донимать их каждый день, требуя знать, что они сделали вчера и что они планируют делать сегодня. При ежедневных обновлениях где стимул для умных людей работать над трудными проблемами? Они теперь имеют тот же стимул, что и младшие разработчики; найти самые простые билеты для продвижения по всем направлениям.
Иногда мне хочется просто побыть одному и подумать над решением в течение несколько дней. Но если я так сделаю, мне нечего будет сказать на скраме. Поэтому вместо этого я выбираю историю пользователя, где цвет на фронт-энде был неправильный оттенок зеленого или орфографическая ошибка! Видите, я выбил 2 истории за один день, до обеда! Вперед!
...
Я'не полностью согласен с его словами. Например, я согласен с одним комментарием, который сказал, *это не то, что они (менеджеры) не доверяют им, это то, что они не могут добиться результата без постоянного контроля.
Когда великий разработчик становится средним разработчиком, всегда есть множество причин, но я считаю, что ежедневный scrum может быть одной из причин. Так как же предотвратить этот побочный эффект скрам-собраний?
Я также понял, что это легче сказать, чем сделать, но мне нравится видеть, как другие видят эту проблему.
----- обновление -----
Прочитав все ответы, которые я получил на данный момент, я понял, что мне нужно добавить некоторую информацию, чтобы сделать мой вопрос более актуальным.
Но прежде чем я начну это делать, я хочу повторить слова Мартина Маата, которые он привел в своем ответе: "Сам факт, что так много людей чувствуют необходимость сказать что-то об этом, является показателем разочарования, которое вызывает Scrum."
Я полностью согласен! Когда я впервые задал этот вопрос, я уже ожидал, что некоторые ответы будут "oh, you don't do scrum right!"
Некоторые поправки, которые я хотел бы внести в свой первоначальный вопрос, таковы,
Не позволяйте Scrum стать процессом, который подавляет все остальное. Я и мои друзья, которые являются частью команд Scrum, не являются его поклонниками. Причина в том, что, будучи единственным процессом, у которого есть специальный менеджер, он обычно сгибает и ломает все остальные процессы и становится всеобъемлющим процессом, в котором вы не делаете ничего последовательно, кроме ритуалов Scrum и того, чтобы эти ритуалы Scrum казались успешными. Проблемы со Scrum следующие:
Как предотвратить превращение великих разработчиков в средних?
Делая это правильно. Все те ужасные истории, которые я читаю, будь то ваши или другие ответы, говорят мне только об одном: эти люди делали это неправильно. И я понимаю, это трудно. Очень легко набросать несколько правил и заставить их выполнять, но это не Scrum. Scrum - это формирование самоорганизующейся команды. Это не работает с каждым человеком и не работает в каждом созвездии. Но это основа, а все, что вы видите, - результат того, что вы не являетесь командой.
Представьте себе 11 человек, которым вручили руководство по футболу и сказали, что тренировка проходит каждый день в течение пятнадцати минут около 10 утра в конференц-зале №5. Как вы думаете, это то, что делает хорошую футбольную команду? А что если эти 11 человек были действительно хорошими, профессиональными игроками? Все равно нет команды? Нет. Даже Кристиано Роналдо рано или поздно стал бы "середняком" с такой "командой". Но это не вина футбола. Просто так нельзя строить команду.
Scrum строится на том, что вы - команда. В команде неважно, сделали ли вы вчера "билет". В команде вы договариваетесь о том, какова ваша цель (т.е. определение понятия "сделано"), а затем стремитесь достичь ее. Вместе.
Великий разработчик не станет ни на йоту менее великим, если будет разговаривать со своей командой по 5 минут в день. Великолепный разработчик станет незаинтересованным, если он будет вынужден участвовать в плохо управляемом процессе, который предусматривает ежедневное собрание, на котором он отчитывается перед своим менеджером о том, выполнил он тикет или нет.
Ежедневное собрание, на котором вы рассказываете менеджеру, что вы сделали вчера, и пытаетесь вписать это в какую-то произвольную схему производительности - это не Scrum. Это хорошо известный антипаттерн. Кто-то может назвать это Scrum и сказать, что в руководстве по Scrum говорится, что вы должны проводить ежедневные встречи, но это будет такой же настоящий Scrum, как и Народная демократическая республика, которая на самом деле является демократической республикой для народа.
Как и в командных видах спорта, в Scrum необходимо, чтобы участники были командой. Если они просто участники, которые стремятся поднять свой статус, показывая, сколько сюжетных точек они сделали или сколько голов забили, они всегда проиграют команде, которая работает вместе, а не рядом друг с другом или друг против друга.
Как же предотвратить превращение великих разработчиков в середнячков? Нанимайте командных игроков. Великих, средних, неважно, потому что реальная команда победит случайное собрание якобы "великих" участников в любой день. Я не говорю, что это легко. Но в этом и заключается суть Scrum.
Я думаю, что проблема и в вашей ситуации, и в тексте, который вы цитируете, заключается в том, что ежедневный scrum каким-то образом превратился в соревнование, кто выполнил больше тикетов. Является ли количество тикетов, которые выполняют ваши разработчики, самой важной метрикой, по которой их судят/оценивают? Не принимая во внимание сложность/объем работы тикета?
Ежедневный scrum должен быть не соревнованием, а (коротким) собранием, где каждый рассказывает о том, что он делает в данный момент, с какими проблемами сталкивается и смотрит/обсуждает, могут ли они помочь друг другу.
Помимо этого, к Scrum не следует относиться как к священному писанию. Нет ничего плохого в том, что менеджер назначает определенные задачи/билеты наиболее старшим/подходящим людям.