Некоторые члены команды не принимают активного участия в планировании спринта

15

Некоторые члены команды просто ждут, пока не будут обсуждены истории, над которыми они, скорее всего, будут работать, и только потом они будут участвовать. В противном случае они просто играют со своим телефоном и не слушают.

В некотором смысле я понимаю эту позицию. Зачем слушать обсуждение функции, которую вы вряд ли сможете развить в Sprint или когда-либо?

Как вы думаете, что мы должны сделать?

agile scrum

— Евгений
источник

9

Насколько велика эта команда?

— JeffO

8

@JeffO ударил по гвоздю по голове - это классическая проблема негабаритной команды. Чрезмерная команда = недооцененные индивидуальные полномочия / обязанности = недооцененное индивидуальное участие. Правильно подобранная команда будет означать, что все, что вы, ребята, говорите, влияет на каждого в комнате. В качестве альтернативы вы слишком много раздуваете обязанности - зачем слушать обсуждение функции, с которой вы вряд ли поможете? Правильная команда, которая не выполняет свои обязанности, должна иметь возможность работать над всеми функциями.

— Джимми Хоффа

7

Телефоны выключены, без исключений. Простая встреча здравого смысла.

— user1019696

5

@ user1019696 Если честно, я мог позвонить жене, чтобы мой ребенок в любой момент сломал ему ногу. Существует большая разница между «выключенными телефонами» и «не разговаривать с телефоном в середине собрания, потому что это просто неуважительно».

— Джимми Хоффа

4

@jwinging вы говорите об эпохе, когда были секретари компании, в компании, где я работал много лет, не было такого человека - им было бы нечего делать. И нет, это не может ждать. Особенно не для работы, извините, но для семьи> работы. Тем не менее, я, возможно, получаю вызов в середине 1 из 30 или 40 заседаний (может быть, ??), на которые я, вероятно, отвечаю 1 из 30 или 40 ... Нетрудно не быть придурком с вашим телефоном. Если люди хотят, чтобы они были инвалидами или удалены от своих людей, чтобы не быть придурком, возможно, этот человек просто придурок.

— Джимми Хоффа

32

Стоп код владения. Обеспечьте одинаковую вероятность того, что кто-либо в команде будет работать над любым заданием.

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

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

— прецизионный самописец
источник

4

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

— JeffO

3

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

— С

3

@jwenting, что делает их идеально подходящими для аутсорсинга. Я не понимаю, почему разработчики помогают в этом отношении.

— GrandmasterB

1

@jwenting Это ловкий момент. Чтобы изменить такой взгляд на вещи.

— Эйфорическое

1

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

— jwenting

15

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

— jwenting
источник

12

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

— Том Сквайрс
источник

3

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

— jwenting

@jwenting - кажется, что эта команда очень уверена, что им никогда не потребуется работать над другими частями. Хотя один человек не может знать всего, это не значит, что он должен учиться как можно меньше.

— JeffO

@JeffO правда, но нельзя ожидать, что они смогут активно участвовать в планировании вещей для областей, о которых они не знают. Слушай и учись, но держи рот на замке. И , возможно , использовать свой мобильный телефон , чтобы сделать некоторые фотографии планирования борта :)

— jwenting

1

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

— Дейв Хиллиер,

5

Похоже, мотивационная проблема - почему некоторые люди не заботятся о проекте, над которым они работают? Возможно, потому что команда разделена на «организаторов» и «левых аутов».

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

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

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

— gbjbaanb
источник

Хорошие идеи. Надеюсь, люди не увидят в этом пустую трата времени.

— Евгений,

1

Какова продолжительность вашего спринта?

Более длительные спринты приводят к

Больше работы планировать в спринте, что приводит к
Более длительные встречи по планированию, что приводит к
Более высокая трудность для членов команды, чтобы оставаться сосредоточенным, ...
Члены команды скучают

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

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

— Пит
источник