Почему и по каким причинам разработчикам может не понравиться «ежедневная схватка»? [закрыто]

В проведении ежедневных схваток есть такие преимущества, как:

1. Команда скоординирована друг с другом
2. Все знают, сколько заданий было выполнено
3. Диаграмма Burndown становится все более и более полной
4. Панель задач обновлена
5. Это не так долго, 15 минут никого не убьют

Однако в последнее время (после 6 месяцев внедрения и использования scrum) я чувствую, что наши разработчики больше не любят scrum ежедневно. Люди просто обновляют доску задач, не объясняя достаточно, и кажется, что им это надоело. Я вижу, что когда по какой-то причине мы этого не держим, они вроде бы становятся очень счастливыми.

Я просто не знаю, что может быть не так с этим. Есть ли какие-либо причины, упомянутые где-то в отношении недостатков, которые могут иметь «ежедневные схватки» для команды? Что может быть причиной того, что разработчики устали от ежедневных ссор?

У меня был опыт участия в команде «SCRUM» с несколькими работодателями. Мне кажется, что менеджеры выбирают «ежедневную скупую встречу» в качестве основного пункта SCRUM и ставят ее в качестве цели, вместо того, чтобы иметь то, что она есть: средство для достижения более эффективного цикла разработки .

Очень быстро 15-минутные собрания превратились в 45-минутные собрания, обновления были неэффективными, потому что люди были бы заняты зеванием и думали «когда мы уже можем идти» вместо того, чтобы слушать других, и это также нарушало бы рутину людей (я, например, сова, и выход на работу в 9 утра на эту дурацкую встречу каждый день - достаточно веская причина, чтобы я бросил работу).

Когда менеджеры берут какую-то идею, которая может быть полезной при правильном применении, и доводят ее до крайности, они получают полную противоположность ожидаемым результатам. Лично я считаю, что чем больше встречаюсь, тем меньше работаю. У меня есть 2 регулярных встречи в неделю в моем календаре, и я обычно пропускаю одну из них. Встречи для менеджеров, оставьте разработчиков делать свою работу.

Я уверен, что будет много энтузиастов SCRUM, которые скажут: «Но это так замечательно» - ну, сохрани, я все это слышал.

Я считаю, что ежедневно вставать скучно и бесполезно, если я чувствую, что в этом нет ничего особенного. Есть несколько вещей, которые могут снизить полезность ежедневного простоя.

• Информация, которой мы делимся, никогда не касается и не затрагивает меня.
• Отсутствие коллективного владения и все всегда работают над своими проектами.
• Отсутствие командного общения вне стенда.
• Отсутствие видимого или сообщаемого прогресса.
• Отсутствие информации для обмена.

Это просто не в моей голове, но всегда есть более вероятные причины.

Возможно, вам следует просто спросить разработчиков, почему они не интересуются? Если вы хотите больше / лучше общения, это должно начаться с вас.

Некоторые из проблем, с которыми сталкиваются ежедневные встречи SCRUM:

• те, которые длятся слишком долго. Вы не хотите, чтобы в этих ежедневных делах был какой-то менеджер, потому что они являются основной причиной подобных проблем. Посмотрите, как обычно они используют кресло (да, отстаивать это значит соблазнять людей быстро)
• необходимость услышать о ком-то (или двух или трех разработчиках), который подробно описывает любую изолированную проблему, которую он имеет, вместо того, чтобы он решил запланировать еще одну реальную встречу позже, чтобы обсудить ее с заинтересованными
• тупые часы. Эти встречи не должны быть утром: вы не говорите о том, что вы сделали вчера, и не решаете, что вы будете делать сегодня; вы говорите о том, что вы сделали между прошлым и этим, и решаете, что вы будете делать до следующего.
• отсутствие владения приложением для разработчиков. SCRUM работает, если разработчики не рассматриваются как обезьяны кода. Первым признаком того, что процесс идет не так, является то, что разработчики не оценивают, сколько времени потребуется, чтобы что-то сделать.
• опять тупые часы. Если часть команды начала работать над некоторыми вещами и находится «в зоне», когда происходит ежедневное, это становится проблемой. Хорошее время, чтобы проводить их каждый день, это когда никто не должен работать (например, после обеда или непосредственно перед тем, как начать некоторые обсуждения во время обеда).

Время является убийцей для многих. Программистам нравится кодировать поздно, спать поздно и приходить после утреннего ажиотажа. Быть в офисе в назначенное время - слишком рано для них. И слишком поздно для тех, кто может прийти раньше и начать работать уже.

Поток - другая проблема. Программист в потоке с некоторой функцией будет работать до поздней ночи, идти домой и возвращаться заряженным и готовым продолжать. Наличие встречи с главным образом не связанными вопросами может отвлечь его.

Мое наблюдение слишком часто, что эти встречи для менеджеров должны выглядеть и чувствовать, что они действительно что-то делают, а не полезны для команды и проекта.

Например, команде поручено сделать серию коротких исправлений ошибок в разных проектах. Они действительно работают не как команда, а как отдельные люди. Тем не менее, поскольку политика компании / департамента требует этого, руководитель / руководитель группы в любом случае проводит ежедневное совещание. Все, что можно сделать, - это потратить 15 с лишним минут на бесполезную встречу и отвлечься на 15-30 минут отвлечения внимания и недостатка производительности до и после встречи.

Теперь я видел, как схватка была успешной в проекте, у которого были сжатые сроки и требовала много координации между людьми, работающими над различными частями. В этом контексте это была отличная система. Но в контексте «мы проводим собрание, потому что мы скромный / проворный магазин, и это то, что мы должны делать», это действительно может быть отстой.

Убедитесь, что никто не монополизирует собрание.

Если 4 из разработчиков убирают с толку в течение 5 минут, а следующие 10 минут тратятся на то, чтобы выслушать лидера команды, рассказывающего обо всех удивительных , удивительных новых разработках, которые он сделал, большинство из которых не являются ни удивительными, ни настолько удивительными как он думает, людям очень быстро станет скучно.

Отойдите на минутку и подумайте о своей команде:

• Они работают эффективно?
• Выполнены ли задачи в срок?
• Является ли код надежным и хорошо написанным?
• Команда гарантирует, что ничто не падает через трещины?
• Координирует ли команда себя, чтобы они не дублировали работу и не наступали друг другу на пальцы?

Если вы отвечаете на все эти вопросы «Да», возможно, вам следует подумать о том, почему вы хотите, чтобы в вашей команде была занятая работа, такая как ежедневные встречи, ежедневные графики и доски задач. Какую ценность это добавляет? Вы хотите генерировать бюрократические данные исключительно для собственного удовольствия или вы пытаетесь сделать команду более продуктивной?

Произошло ли снижение производительности с тех пор, как прекратились ежедневные беспорядки, или все идет так же, как и раньше? Если ничего не изменилось, зачем продолжать встречи?

15 минут. Означает ли это, что эти 15 минут (плюс время на подготовку к ним) передают достаточно новой и полезной информации между членами команды, чтобы повысить производительность команды на предстоящий день более чем на 15 минут? Если бы не было такого количества полезного скрам-контента каждый день, члены команды, вероятно, думали бы, что они добьются гораздо большего прогресса в достижении целей, если они выйдут из этого собрания как можно скорее и вернутся к работе.

Если вы просто хотите регулярно обновлять доску и диаграммы, поместите черновые копии в вики.

Я бы посоветовал вам провести ретроспективное совещание, чтобы посмотреть «Что прошло хорошо» и «Что не прошло хорошо» и посмотреть, считают ли разработчики ежедневное совещание по стандартизации самой тратой времени. Тогда вам нужно будет немного реорганизовать его.

Мой личный опыт:

• Цель - узнать, что мы делаем сегодня и где мы были вчера. Вместо того, чтобы придерживаться повестки дня, он переходит к техническому обсуждению блокировщиков между двумя людьми, а остальным 15 скучно. Определите проблему, но обсудите снаружи
• Люди не попадают в зал заседаний вовремя, и это становится циклом, сделанным некоторыми нарочно. Поэтому Мастеру Скрама нужно спокойно поговорить с ними вне собрания, чтобы убедиться, что они начинаются и заканчиваются вовремя.
• Мы уже обновляем обновленные таблицы вне собрания Scrum, так что это не является основной целью ежедневного противостояния.

Сопротивление наступает, когда: 1) Они используются, чтобы заставить людей спешить в течение 9 утра. Это дополнительный стресс, когда поезд опаздывает. 2) Плохое руководство схватками. Лидер должен говорить людям, чтобы они брали вещи в автономном режиме, а не заставляли людей стоять и слушать то, что не влияет на них. 3) Бесценный контент. Это снова проблема руководства схватки. Предполагается, что он станет форумом для устранения узких мест, проблем траектории и возможного сотрудничества. Что на самом деле происходит, так это то, что все просто говорят, что они ожидают от работы в этот день, что бесполезно или неинтересно никому другому. 4) Стоять. Я не буду стоять Логика стояния заключалась в том, что это побуждает людей быть краткими. Люди на самом деле просто гремят независимо.

Я много раз справлялся и участвовал в схватках. Основная причина, по которой разработчики не любят scrum:

• Поскольку они управляются очень плохим мастером схватки, если это превращается в 45 минут, ваш мастер схватки должен улучшить управление схваткой.
• Самая большая и, безусловно, самая правдивая причина, по которой им это не нравится, заключается в том, что в плохой трудовой этике очень трудно спрятаться, т. Е. Более нагло, она показывает ленивых людей. Некоторые разработчики, с которыми я работал, шокируют, они занимают дни, выполняя задания, которые должны быть 30 минутами работы. Хороший менеджер должен устранить барьеры для разработчиков, а это значит, что они должны иметь возможность выполнять свои задачи в спринте. Разработчикам это не нравится, потому что они должны вставать каждый день и демонстрировать достигнутый ими прогресс. Это вызывает беспокойство, когда они не могут продемонстрировать прогресс по какой-либо причине. Если это из-за действительной проблемы, хороший мастер Scrum должен решить эту проблему как можно скорее.

Проблема возникает, когда мастера схватки не имеют полномочий, навыков или возможностей для решения проблем блокировки. На самом деле я видел некоторые проблемы, просто надеясь, что они исчезнут. Это катастрофично.

Честно говоря, на 99% ежедневных скрам-встреч, на которые я ходил, почти все обсуждения / вопросы / ответы можно было исправить несколькими электронными письмами.

Я, честно говоря, думаю, что нам нужно показать более веские причины, чтобы НЕ проводить встречи. Создайте обстановку, в которой, когда пришло время загонять всех в комнату лично, это должно быть веской причиной и быть организованным, чтобы максимизировать эффективность времени.

Я вообще ненавижу встречи и предпочитаю использовать видеоконференции, телефоны, электронную почту и все, что позволяет мне заниматься или оставаться на работе, не вставая и не прерывая процесс повышения производительности.

Я лично думаю, что если у вас есть более четырех встреч за 8-часовой период, то проекты плохо управляются.

Есть много факторов, которые способствуют напряженности из-за встреч. Рассмотрите это как некоторые из важных причин, почему встречи могут стоить вам больше, чем они стоят:

• Фокус - программное обеспечение против встреч
• Менеджмент - менеджеры нуждаются в измерении
• Личность - интроверты против экстравертов
• Время - прерывания, время Создателя и Менеджера
• Цели, приоритеты

Каждый из этих факторов объясняется ниже,

Фокус - мне нравится разрабатывать программное обеспечение, и это включает в себя размышления о проблемах (проблемах), создании решений, создании программного обеспечения и встречах, отвлекающих внимание от задач по созданию программного обеспечения. Существует состояние под названием « Поток », в котором разработчик погружен в задачу (проблему), создал интеллектуальную модель решения и полностью сосредоточился на создании решения. Разработчик может работать до полуночи, оставлять только есть и спать, а затем возвращаться в состояние, близкое к тому, где он ушел.

Разработчики должны избегать отвлекающих факторов, и многие считают, что есть смысл писать код поздно ночью (они избегают шума, телефонных звонков, загруженного офиса и коллег, не являющихся разработчиками, мешающими работе). И когда вы работали до 10, 11 или 12 часов, нередко приходить на работу позже (10, 11, полдень?). Разумно ли ожидать, что разработчики будут работать с 9 утра до полуночи?

Встречи Scrum (и любые другие) отвлекают разработчика от их основной цели - создания программного обеспечения.

Управление - Менеджеры должны измерять, чтобы быть успешными, следовательно, необходимы графики, результаты, сроки, приоритеты и встречи для измерения и отчетности о прогрессе, а также для выявления зависимостей, задержек и областей риска. Сложность Scrum заключается в том, что руководителю нужны эти вещи, а разработчику нужно сосредоточиться. Совещания служат менеджеру и дают возможность менеджеру получать, измерять и отслеживать статус и прогресс, но встречи редко бывают полезными для разработчиков. Учтите, что менеджеры приносят больше пользы, когда обрабатывают отвлекающие факторы, устраняют барьеры и позволяют разработчикам сосредоточиться на создании программного обеспечения

Есть решения о необходимости встреч. Менеджер может посетить своих разработчиков, запросить отчеты о состоянии, принять протокол, когда прерывания менее навязчивы, или принять политику, чтобы разработчик уведомлял их о прогрессе, когда разработчик прерывается. Посмотрите обсуждение времени, чтобы понять, почему это важно.

Личность. Учтите, что некоторые люди - интроверты, а другие - экстраверты. Экстраверты наслаждаются социальными взаимодействиями и перезаряжаются ими. Менеджеры, как правило, являются экстравертами (потому что экстраверты обычно лучше взаимодействуют с обществом), хотя интроверты могут быть успешными в качестве менеджеров. Интроверты могут наслаждаться социальными взаимодействиями и даже превосходить их, но они заряжаются одиночеством. Разработчики часто являются интровертами и успешно работают в одиночку (или в небольших группах), потому что им не «нужны» социальные взаимодействия; они могут быть счастливы, работая в одиночку над проблемами (хотя экстраверты тоже могут быть разработчиками). Ежедневные скрам-встречи могут стать общественными, хорошими для экстравертов, но не такими хорошими для интровертов.

Время - разработчики не могут писать код, пока они находятся на собраниях. Они также не могут думать о трудных проблемах (если только они не проводят мозговой штурм), будучи отвлеченными встречами. Разработчикам нужны большие блоки непрерывного времени, чтобы сосредоточиться на создании программного обеспечения. Встречи - это перерывы, которые отвлекают от их усилий. Когда вы погружены в решение проблемы на несколько часов, почти готовы, и кто-то говорит «время для схватки», вас прерывают, и вы теряете, возможно, часы работы, пока «переключаете передачи». Или вы оставались на работе до 23:00, уходили с работы, возвращались домой, спали над проблемой, просыпались, возвращались на работу, готовые решить проблему, а затем прерывались после часа работы над проблемой, потому что это это время для схватки.

У Пола Грэма есть отличная статья о «Времени создателя против Времени менеджера», которая объясняет эту проблему гораздо лучше, чем я. Достаточно сказать, что прерывание собрания, будь то запланированное или незапланированное, может нарушить ход и вынудить разработчика из времени Maker перейти во время Manager. Поверьте, вам нужны разработчики на Maker Time.

Цели, приоритеты - У разработчиков и менеджеров разные цели и приоритеты. Менеджеры обязаны следить за графиками, минимизировать расходы, обеспечивать ответственность своих отчетов и выполнение. Разработчики имеют цель создать программное обеспечение, которое решает проблемы / проблемы. Эти цели не противоречат друг другу, но именно коммуникационный механизм создает напряжение. Встречи служат потребностям менеджера и оптимизируют время менеджера, но они противоречат потребностям разработчика. Встречи Scrum отменяют первое правило собраний, «имеют повестку дня» и имеют тенденцию блуждать больше. И встречи используются для оптимизации общения (для менеджера), но они стоят времени разработчика (прерывания, потеря потока и т. Д.).

Какова цель? Создавать программное обеспечение, которое отвечает потребностям, быстро и качественно, в то время как существуют ограничения (качество, время, стоимость, процесс). Scrum и другие гибкие методологии распознают ограничение процесса и пытаются минимизировать этот фактор, и были успешными, потому что минимизируют это ограничение. Но добавление собраний стоит времени, а прерывание обходится разработчику намного дороже, чем продолжительность собрания.

Измените собрание, чтобы убедиться в его преимуществах:

1. Запланируйте это на время, которое предлагает некоторое удобство. Почему не может пройти 30 минут после начала работы, чтобы каждый мог просмотреть электронную почту и организовать свои мысли для встречи. Краткость требует планирования. Неподготовленные могут бродить вечно.
2. Определите проблемы, которых можно было бы избежать, если бы проблема была сообщена во время встречи. Каждый должен понимать, в чем суть.
3. Делайте все возможное, чтобы свести каждый вклад к минимуму. Это не место для дебатов. Поощряйте людей планировать личные встречи вне ежедневных собраний, посвященные теме, требующей обсуждения. Правило: только один человек говорит одновременно.

Все податели жалобы должны убедиться, что они не способствуют возникновению проблемы. Если вы можете достичь своих целей в ежедневной схватке, не имея такой цели менее болезненно, мы бы хотели услышать это.