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

40

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

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

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

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

Саид Нямати
источник
14
Моя проблема с ежедневными скрам-встречами состоит в том, что они начинаются свежо и по теме и быстро превращаются в 45-минутный грип-фестиваль о менеджменте, неясных требованиях, технических и политических барьерах и низком качестве ошибок, которые пишет QA.
maple_shaft
2
@ Майкл, у нас не было мастера схватки, вот в чем проблема. Единственная причина, по которой мы проводили ежедневные скрам-встречи, была в том, что укоренившееся руководство запускало проект на землю в 10 мая, и им нужно было вносить поверхностные бессмысленные изменения процесса с единственной целью - выглядеть так, как будто они решают «неуловимую проблему». Конечно, сказать, что нам нужно проводить ежедневные скрам-встречи, гораздо проще, чем сказать: «Может быть, если я сосредоточусь на том, чтобы не заниматься микроуправлением, а на ежедневном обеде по 4 часа, то мы наконец сможем выпустить качественное программное обеспечение»
maple_shaft
19
Честно говоря, я бы очень не хотел, чтобы меня каждый день приходили на собрание и рассказывали всем, что я сделал. Я пытаюсь сделать работу . «Атмосфера», окружающая собрание - переключение контекста, чаты в коридоре, ожидание комнаты - будут пожирать время как вау. Лучше - ИМО - проводить органические встречи по мере необходимости.
Пол Натан
2
Забудь о Scrum. sdtimes.com/blog/post/2011/11/11/Agile-slaves.aspx
ThomasX
6
Ежедневная схватка создает слишком большую нагрузку на разработчика, чтобы производить что-то ежедневно. Им нужна свобода свободно экспериментировать без необходимости каждый день оправдывать свои эксперименты. Еженедельно лучше.
Acumenus

Ответы:

42

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

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

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

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

littleadv
источник
5
Когда обсуждается «предыдущий день», это означает, что с момента последней встречи прошло около 24 часов. Нет причин, по которым ты не мог получить его, когда начинаешь день или несколько часов спустя. Каждый не вынужден одновременно кодировать.
JeffO
6
@Джефф - скажи это менеджерам. В любом случае SCRUM хорош для специальной разработки, но не будет хорошо работать в течение длительного периода времени. Когда у меня есть задание, которое длится неделю, о чем мне нужно говорить на ежедневном собрании? «Я закончил писать другую функцию»? Какая разница?
littleadv
6
@littleadv: «Я продолжаю работать над функцией X. У меня нет контрольно-пропускных пунктов», достаточно для встречи. Это важная информация для команды. Что касается scrum, который хорош только для разработки ad-hod, я должен не согласиться. Я видел это использовалось для длительных, устойчивых, успешных проектов. Команда должна сделать это от всего сердца, но это не серебряная пуля. Это работает для некоторых команд, а не для других.
Брайан Оукли
3
+1 Я никогда не встречал ежедневные разборки, которые занимали 15 минут. Большинство занимают по крайней мере полчаса и довольно быстро теряют фокус :( Я думаю, что есть смысл в коротком обновлении статуса, но, к сожалению, ни один магазин, в котором я работал, не смог его сохранить.
Андрес Ф.
5
Другая проблема заключается в том, что когда «разработчики говорят нам, что происходит», встреча становится «когда разработчики рассказывают нам все о своих мыслях о том, куда они пойдут дальше». Очень разные и занимают намного больше времени. И тогда руководство думает, о, так как мы все здесь в любом случае, давайте добавим еще одну встречу в эту!
Спенсер Рэтбун
35

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

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

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

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

dietbuddha
источник
Но @dietbuddha, как скрам, если разработчики не делятся информацией или частями проекта?
Саид Нимати
4
« Информация, которой я делюсь, никогда не касается и не затрагивает меня каким-либо образом ».
Рене Ниффенеггер
2
@Saeed Neamati: вещь не обязательно та, для которой она названа. Это не значит, что вы не делаете Scrum. Я не работаю с тобой, поэтому я не могу знать. Также может быть разница между тем, как вещи должны быть выполнены, и тем, как они фактически выполняются.
dietbuddha
19

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

  • те, которые длятся слишком долго. Вы не хотите, чтобы в этих ежедневных делах был какой-то менеджер, потому что они являются основной причиной подобных проблем. Посмотрите, как обычно они используют кресло (да, отстаивать это значит соблазнять людей быстро)
  • необходимость услышать о ком-то (или двух или трех разработчиках), который подробно описывает любую изолированную проблему, которую он имеет, вместо того, чтобы он решил запланировать еще одну реальную встречу позже, чтобы обсудить ее с заинтересованными
  • тупые часы. Эти встречи не должны быть утром: вы не говорите о том, что вы сделали вчера, и не решаете, что вы будете делать сегодня; вы говорите о том, что вы сделали между прошлым и этим, и решаете, что вы будете делать до следующего.
  • отсутствие владения приложением для разработчиков. SCRUM работает, если разработчики не рассматриваются как обезьяны кода. Первым признаком того, что процесс идет не так, является то, что разработчики не оценивают, сколько времени потребуется, чтобы что-то сделать.
  • опять тупые часы. Если часть команды начала работать над некоторыми вещами и находится «в зоне», когда происходит ежедневное, это становится проблемой. Хорошее время, чтобы проводить их каждый день, это когда никто не должен работать (например, после обеда или непосредственно перед тем, как начать некоторые обсуждения во время обеда).
Арх
источник
3
@jhocking: На самом деле, совершенно нормально, что менеджеры присутствуют на собраниях (или заинтересованные лица, или просто те, кто заинтересован). Однако правило таково: говорят только разработчики. Все остальные говорят только тогда, когда их спрашивают. Это так просто ... (и да, наши менеджеры посещают ежедневные беспорядки и соблюдают это правило).
Слеск
2
Если ваши менеджеры могут придерживаться правил, это здорово.
Джоккинг
Я лично столкнулся с дефицитом схватки мастеров , которые злоупотребляли «гибкие часы» аргумент , чтобы держать ежедневные газеты , когда это было удобно для них , так что это один потенциального минного поля. Другой начинает «после» чего-то. Это делает ежедневный взгляд чем-то «сосредоточенным», в то время как начало «до» не только нарушает это восприятие, но также помогает сделать собрание кратким. Вот почему утро часто предпочитают - ежедневное происходит до того, как начинается «правильная» работа.
mikołak
+1 за ваш последний пункт (планируйте, когда не прерывайте работу, то есть то, что я не мог закончить прошлой ночью или имел отличную идею дома).
Сис Тиммерман
14

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

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

Cata
источник
+1 У меня та же проблема с процессами, которые предписывают слишком много встреч. См. Также paulgraham.com/head.html , пункты 1 и 2.
Джорджио
11

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

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

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

jfrankcarr
источник
10

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

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


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

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

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

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

Муравей
источник
9

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

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

hotpaw2
источник
8

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

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

  • Цель - узнать, что мы делаем сегодня и где мы были вчера. Вместо того, чтобы придерживаться повестки дня, он переходит к техническому обсуждению блокировщиков между двумя людьми, а остальным 15 скучно. Определите проблему, но обсудите снаружи
  • Люди не попадают в зал заседаний вовремя, и это становится циклом, сделанным некоторыми нарочно. Поэтому Мастеру Скрама нужно спокойно поговорить с ними вне собрания, чтобы убедиться, что они начинаются и заканчиваются вовремя.
  • Мы уже обновляем обновленные таблицы вне собрания Scrum, так что это не является основной целью ежедневного противостояния.
Йосек
источник
+ 1 + 1 + 1 Это ответ. В местах, где я работал, где не было ретроспективы, были все проблемы, которые все описали. Там, где я сейчас работаю, у нас есть Scrum, Scrum of scrums (interteam), ретроспективы и даже ретроспективы их. Все для того, чтобы гарантировать, что вещи, которые вас беспокоят и не работают, останавливаются или меняются в максимально возможной степени, а дела, которые идут хорошо, продолжаются. Без этой схватки становится довольно скучно и не по теме легко. Я также считаю, что «встречи», которые клевещут на столь многих, велики, если они действительно хорошо общаются, посвящены теме, вовремя и коротко.
Майкл Даррант
7

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

Ян
источник
4

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

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

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

Shaun
источник
4

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

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

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

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

Алекс М
источник
это даже не пытается ответить на вопрос: «Почему и по каким причинам разработчикам может не понравиться« ежедневная схватка »?»
комнат
1
Я только что сделал. Я не люблю ежедневные схватки, потому что в этом нет необходимости. Несколько электронных писем могут легко удовлетворить большинство потребностей.
Alex M
2
Интересная мысль ... и, может быть, это потому, что мои схватки не были хорошими. Возможно, «ежедневный» должен быть «еженедельным» в определенных случаях. Я знаю, что для меня еженедельник будет более эффективным, чем ежедневный.
Alex M
4

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

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

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

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

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

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

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

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

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

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

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

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

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

ChuckCottrill
источник
0

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

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

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

JeffO
источник