Как остановиться / избежать со временем в команде Scrum?

На самом деле, я помогаю небольшому магазину программного обеспечения в их реализации Scrum. Недавно Scrum Master сообщил мне, что у него есть проблема, потому что команда работает над временем, чтобы достичь Scope (Committed Backlog). Так что у них Нереальная Скорость .

Мой официальный вопрос (ы):

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

2. Если да, то какие методы / инструменты вы предлагаете?

   • Система контроля версий (SVN, GIT, HG и т. Д.), Блоки по часам (с 8 до 5)
   • Рабочая станция блокируется по часам (с 8 до 5) или кумулятивно (до 8 часов в день)?
   • Другой (ы) ...

3. Или, может быть, не жестко блокировать такие вещи; но внедрить какую-то «систему штрафов» за неоправданные дополнительные часы ?

@Baqueta (и другие с похожими вопросами): Нет, им не платят за дополнительные часы. Моим первым советом им было пересмотреть их оценки, потому что, возможно, они недооценивали. Это был мой любимый совет:

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

Кроме того, я думаю, что основная проблема (для этой команды) - это сочетание следующего:

1. Разработчикам говорят, чего они должны достичь в спринте / не консультируются по поводу того, что достижимо / игнорируются, когда говорят, что слишком много работы.
2. Разработчики постоянно недооценивают, сколько времени потребуется задачам / сколько единиц работы задействовано в каждой задаче.

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

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

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

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

Если в спринтах слишком много работы, это обычно происходит по одной из трех причин:

1. Разработчикам говорят, чего они должны достичь в спринте / не консультируются по поводу того, что достижимо / игнорируются, когда говорят, что слишком много работы.
2. Разработчики постоянно недооценивают, сколько времени потребуется задачам / сколько единиц работы задействовано в каждой задаче.
3. Разработчики продолжают тянуться к задачам, которые не являются частью схватки.

Если это № 1, вы делаете это неправильно . Нет двух способов об этом!

Если это №2, обычной причиной является неопытность - либо с оценкой времени, либо с разрабатываемой системой. Хороший способ обойти это - прекратить делать оценки времени и начинать оценивать «единицы работы». Используйте некоторую абстрактную единицу, просто убедитесь, что это не часы реального времени (в конечном итоге вы по-прежнему представляете временной интервал, но абстракция важна!). Затем вы можете начать вычислять, сколько единиц работы фактически выполнено за неделю, а затем настроить спринты, используя эти данные.

Если это №3, вам нужно как-то начать учитывать эти другие задачи. Если это соответствует, это должно быть легко объяснить (см. № 2 выше). Если это часто, но непредсказуемо, с этим намного сложнее иметь дело. Возможно, вы захотите взглянуть на то, почему это происходит (например, серьезные ошибки в «живом» коде => достаточно ли у вас тестирование?), Но если это не может быть исправлено, то в конечном итоге scrum может оказаться не подходящим для вас подходом. Моя команда недавно перешла на Канбан по этой самой причине ...

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

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

Также важно убедиться, что команда понимает, что наносит себе вред, только слишком много работая. Даже проворный манифест говорит об устойчивом темпе: «Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок». Работа сверхурочно все время не является устойчивой.

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

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

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

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

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

Просто скажите команде не работать сверхурочно. Период.

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

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

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

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

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

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

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

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

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

Следующая диаграмма показывает, где неопределенность лежит в проекте:

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

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

Если ваша команда может обработать 10 билетов за 5 дней, и им назначено 20 билетов, сократите это число, передайте его владельцу продукта / менеджеру проекта / менеджеру / клиенту и скажите им расставить приоритеты.

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

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

Я настоятельно советую против "жестких блоков". Такой контроль может восприниматься как микроуправление и может не решить основную проблему.

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

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

Причины нагрузки могут быть

• Задержка слишком велика
• Либо программисты, либо владелец продукта «плакируют золотом» (делая функции более сложными, чем нужно)

Ожидания могут быть

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