Как скрам-мастеру заставить всех серьезно относиться к дедлайнам?

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

Это проблема инструментов? Помогите им получить необходимые им инструменты (например, необходимость использовать Visual Studio Express только потому, что компания слишком дешева/экономна, чтобы платить за версию Pro, деморализует).

Дело в усталости? Устали ли они убивать себя, чтобы уложиться в сроки, в которых они не участвовали? Постарайтесь сбалансировать давление сроков с выходным. Часто большее количество часов не означает большей производительности.

Неужели руководство компании сошло с ума, а разработчики с трудом верят в их безумное видение? («Сумасшедший» — субъективное слово — согласна ли команда с направлением и видением руководства.) Предложите помочь защитить их от сумасшествия и позволить им сосредоточиться на своей работе.

Работа неинтересна? Помогите им найти свою собственную цель в работе, которую они делают.

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

Ваша проблема в первом предложении:

Я скрам-мастер, а также менеджер проектов

У вас есть 2 роли, которые противоречат друг другу.

У Scrum-мастера есть две задачи:

• Удалить препятствия
• Убедитесь, что согласованный процесс соблюдается, и научите там, где это не так.

Заметьте, я ничего не говорю о соблюдении сроков, в Scrum нет сроков.

Вы работаете через установленные интервалы (спринты/скрамы/таймбоксы и т. д.), объем работы, которую вы можете выполнить, основан на метриках (скорость в Scrum), и если что-то не может быть завершено в текущем интервале, оно продолжается в следующем (но в идеале вы должны делать истории достаточно маленькими, чтобы это не происходило).

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

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

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

Вы также должны смотреть на истории, размер и зависимости конкретно. Используйте на них следующее:

• я независимый
• Не подлежит обсуждению
• ценный _
• E стимулируемый
• Малый торговый центр
• тестируемый _

Я считаю, что работает самая большая работа в конце истории, работа с командами во время создания, чтобы сделать истории одинаково небольшого размера, извлечь зависимости и свести к минимуму работу, НЕ ВЫПОЛНЕННУЮ.

Как только вы это сделаете, вы сможете начать отслеживать метрики «Время выполнения/среднее время истории» и т. д., и это должно позволить вам отказаться от 10% оценки для команды и использовать приоритеты для разработки долгосрочных планов для вашего проекта.

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

Scrum (или другие Agile-процессы) основан на мышлении. Он нарочито прост в исполнении, но требует дисциплины и интереса к работе. Ничто не дает сбоев и не сгорает так, как Agile-процесс, когда люди просто платят за слова, поскольку может казаться, что что-то продвигается, хотя на самом деле это не так, пока не станет слишком поздно, чтобы остановить корабль. Если они на самом деле не верят, может быть лучше вернуться к подходу, при котором вы отслеживаете начало / остановку задач, чтобы вы могли подтолкнуть их, когда они пропустят срок выполнения задачи.

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

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

Говорите разработчику, чтобы он работал «в два раза усерднее!» не сработает, даже если будет выглядеть так, как сработало. Крайний срок может быть тривиально соблюден, но подумайте, какая работа не была проделана, чтобы уложиться в него.

Что доходит до сути вопроса: одна вещь, которая находится под контролем, — это то, какая работа выполняется; чем заполнена эта емкость. Что является приоритетным; какие позолоченные детали обрезаны до нужного размера. Небольшие, более понятные задачи, как правило, выполняются быстрее и качественнее. Однако разбиение больших функций на эти маленькие задачи является компетенцией владельца продукта. Чтобы обеспечить правильное указание этих более крупных функций, может потребоваться согласование с вами как руководителем проекта. Чтобы убедиться, что задачи разбиты правильно, может потребоваться ваше участие в качестве Скрам-мастера.

Но управлять сроками? Обещать клиентам невыполнимое, а затем настаивать на том, чтобы разработка соответствовала этому, — не лучшая отправная точка.

И последнее: я бы посоветовал не измерять индивидуальную продуктивность разработчиков. Это просто не работает в командной среде.

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

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

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

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

Я бы посоветовал вам переключиться на гибкий процесс разработки. Я знаю, вы говорите, что вы скрам-мастер, но то, что вы делаете, явно не соответствует стандартной agile-системе оценки и итерации, используемой в XP и Scrum. В частности, пытаясь увеличить «скорость», вы полностью разрушаете весь смысл гибкого планирования. (Скорость — это метрика, которую вы используете, чтобы получить точную оценку того, сколько работы команда может сделать в настоящее время; стремление к ее увеличению приводит к завышению баллов с более высокими числами, но к фактической выполненной работе, неточным оценкам или и тому, и другому.)

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

Разработчики работают с владельцем продукта над созданием историй, но только им разрешено их оценивать. (Даже вы, как их менеджер или agile-коуч, не имеете никакого отношения к оценкам, если только вы не работаете над реализацией историй. Вы не можете приказать им сделать что-то за меньшее время.) В конце концов каждой итерации вы суммируете общую оценку всех историй, которые были успешно завершены, и ваша оценка для следующей итерации, как правило, никогда не будет выше этой. Особенно важно, чтобы ни вы, ни команда не пытались увеличить это число; это напрямую разрушает вашу способность оценивать, потому что вы больше не используете данные реального мира, которые на самом деле показывают, сколько вы сделали.

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

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

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

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

Как это не идеально для вас? https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum

Назначьте ежедневное совещание по спринту с 8 до 8:15. Попросите всех рассказать о том, что они сделали в последний день, и поставьте ОЧЕНЬ ЧЕТКУЮ ЦЕЛЬ НА ТЕКУЩИЙ ДЕНЬ. На следующий день сделайте то же самое.

Во многих проектах ежедневные собрания не проводились, так как работа выполнялась еженедельными пакетами, я проводил еженедельные собрания, на которых все вставали, обсуждали свою работу и цели, а также устанавливали цели на следующую неделю. Вы можете делать это ежедневно.

Если они хотят провести весь день в фейсбуке и сделать работу за ночь, это их проблема.

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

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

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

Люди часто чувствуют, что работа выполняется, когда это не так. Распространенная Проблема, когда нет четких принципов

Как менеджер:

Организуйте встречу, расскажите им, что происходит, что вас беспокоит на рабочем месте, и попросите о сотрудничестве.

Как коллега:

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

Обновлять:

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

Тем не менее, я считаю, что компания с 12 разработчиками (что довольно много) должна иметь стандарты от руководства, независимо от того, понравится им это или нет.

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

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

Работайте со своими отчетами и старайтесь облегчить их работу.

• Чувствуют ли они, что у них есть препятствия или узкие места?
• Считают ли они, что у них есть работа, которая не добавляет ценности?
• Считают ли они, что владеют установленными сроками?
• Понимают ли они, как выполняемая ими работа способствует достижению целей проекта?

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

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