Мой менеджер проекта не принимает перенос в Scrum - это нормально?

52

Я разработчик, работающий над новым мобильным приложением для Android и iOS с большим бэкэнд-компонентом. Мы были в трех спринтах этого проекта, и мы используем Scrum со всеми его церемониями (уточнение, планирование, ежедневные газеты, ретроспективы и т. Д.).

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

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

  1. Это приемлемый / распространенный вариант Scrum, о котором я не знаю?

  2. Как вы предлагаете мне действовать по этому поводу?

MrAn3
источник
66
Кроме того, когда ваш рабочий контракт разрешает неоплачиваемую сверхурочную работу и работу в выходные дни, и ваши начальники могут приказать вам сделать это по собственному желанию, тогда я боюсь, что лучший способ действий - это добавить запас прочности, по крайней мере, как фактор от 2 до каждого спринта упрощения, или найти другого работодателя.
Док Браун
59
Нет, это неприемлемая практика с момента отмены римской галеры. Это типичная паническая атака менеджера проекта, чья компетенция еще может развиться. Пнуть людей в задницу, предполагая, что они не лучшие, без сложных оценок и ситуация не поможет из этого беспорядка. Но этот вопрос слишком широк, чтобы обсуждать его здесь ...
Кристоф
27
Спросите себя, каким будет представление руководства, если вы заранее выполнили «обязательство» в спринте. Сможет ли команда снять остаток спринта (включая оплату)?
Qwerky
13
Руководитель проекта не является нормальным в Scrum. В Scrum Guide достаточно четко указаны роли: Scrum Master, владелец продукта, Scrum Team. Ни один PM не упомянут. На самом деле, многие люди (в том числе большинство подписавших Agile Manifesto) неоднократно заявляли, что проекты вредны для маневренности. Кроме того, вы единственный, кто решает, что это приемлемо. Если это не приемлемо для вас, отшлифуйте свое резюме и ищите лучшую компанию.
Blueriver
5
Две вещи: обязательства берут на себя команда, а не премьер-министр, поэтому посвятите себя меньшему, как немедленному решению, однако большая проблема заключается в том, что произойдет, если вы не выполните поставку? Каковы последствия? Обычно PM, TPM, Scrum-мастерам, владельцам продуктов и т. Д. Рекомендуется работать с командой, потому что ... они не имеют реального контроля над командой в матричной структуре, которую предоставляет Agile / SCRUM. Так что это может быть не более чем попытка продвинуть свою карьеру за счет других.
RandomUs1r

Ответы:

75

Несколько вещей выделяются для меня.

Идея о том, что руководство обязуется выполнять ряд работ, не соответствует последним версиям Scrum Guide. Слово «обязательство» или «обязательство» используется только два раза в самой последней (ноябрь 2017 года) версии Scrum Guide - один раз при перечислении значений Scrum и один раз, чтобы указать, что «люди лично привержены достижению целей команды Scrum». ».

Идея целей важна для Scrum. Мало того, что организации и команды имеют широкие цели, но в Scrum у каждого Sprint есть цель Sprint, которая определяется в Sprint Planning как сотрудничество между владельцем продукта и командой разработчиков. Цель Sprint достигается за счет реализации элементов из журнала невыполненных работ по продукту, но она не просто «завершает этот объем работы» и часто не представляет собой полный список невыполненных работ Sprint. То есть вы должны быть в состоянии достичь цели Sprint, не заполнив каждый отдельный элемент журнала невыполненных работ, выбранный для Sprint, или каждый отдельный элемент в списке невыполненных работ Sprint. В настоящее время я думаю, что работа, необходимая для достижения Цели Спринта, должна составлять где-то 60-70% от возможностей вашей команды, однако вы должны учитывать ее. Различные организации будут разными, но это

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

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

Томас Оуэнс
источник
2
Отличный ответ - вы могли бы даже улучшить его, выделив или отметив TL; DR, отметив самые важные моменты: приверженность может исходить только от самого разработчика, и работа должна быть устойчивой
Falco
Кроме того, если у вас есть задержки из-за зависимости от других команд, количество времени, которое вы заблокировали, должно быть видно вашей команде.
Luizfzs
2
Я считаю, что они изменили формулировку на «прогноз»; во многом как прогноз погоды, он может быть неправильным, он имеет определенную степень уверенности, а истории, завершенные в спринте, помогают команде лучше оценивать в будущем.
Джордж Стокер
1
@GeorgeStocker Да - слово «прогноз» используется вместо «фиксация» в отношении журнала ожидания спринта и определенных рабочих элементов. Тем не менее, «обязательство» и «обязательство» используется в отношении целей команды.
Томас Оуэнс
1
а также да, 9 женщин не могут завести 1 ребенка за 1 месяц :)
Майкл Даррант
33

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

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

Что вы можете сделать с этим зависит от вашей роли.

Если вы разработчик, то лучшее, что вы можете сделать, это

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

Если вы мастер Scrum, то вы действительно можете доказать свою ценность, обучив руководство Scrum. Некоторые моменты, которые выделяются для меня:

  • Как указано в первом абзаце, команда не дает обязательств во время планирования спринта, но они дают прогноз работы, которую они ожидали закончить.
  • Хотя команде следует избегать незаконченной работы в конце спринта, такая ситуация почти неизбежна в начале проекта (или после изменения состава команды). То, сколько работы команда может реально выполнить в спринте, можно определить только на основании исторических фигур последних нескольких спринтов команды в этом составе. В начале проекта таких исторических фигур просто не существует, поэтому команда, выполнившая в первых трех спринтах именно то, что запланировано для каждого спринта, является скорее случайностью, чем хорошим планированием. После примерно 5 спринтов в устойчивом темпе достаточно данных, чтобы получить разумное представление о том, сколько работы команда может реально закончить в спринте.
Барт ван Инген Шенау
источник
Да, и неопределенность устраняется только тогда, когда проект закончен :-)
Кристоф
3
Большинство людей очень хороши в предсказаниях. Единственное исключение - будущее.
Майкл Даррант
21

Ваш PM не имеет никакого отношения к вашей схватке.

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

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

gnasher729
источник
1
«Ваш премьер не имеет никакого отношения к вашей схватке». При определенных Agile методологиях (например, DSDM) они делают. Pure Scrum даже не распознает «Менеджера проектов» как существующую роль.
nick012000
3
Если в рабочем договоре указано, что может быть неоплачиваемая сверхурочная работа, премьер-министр, безусловно, должен попросить об этом. И если команда сделана раньше, чем оценивается, это опять-таки «ошибка» команды, поэтому нет смысла лениться потом, лучше начните оценивать для следующего спринта, чтобы оценки были не такими уж далекими ^^ (говоря в логике премьер-министра) ). Не то чтобы я соглашался с тем, как руководство справляется с этим, но ваши аргументы тоже не верны (за исключением того, что премьер-министр вовлечен в разборки, в зависимости от некоторых ограничений - как заинтересованная сторона, он может быть вовлечен, но не в путь он в данный момент есть).
Фрэнк Хопкинс
Другим логичным ответом на принудительное принятие оценок является планирование времени для исследования всех неизвестных, прежде чем вы сможете оценить реальную задачу.
Робин Беннетт
Я никогда нигде не работал, если бы scrum / agile запускались одинаково, но в общих чертах, хотя премьер-министр не признается в качестве конкретной роли, они часто управляют бюджетом и рисками. Следствием этого является то, что они абсолютно ничего кровно заинтересованы в том , как хорошо / плохо развитие происходит , и они могут просить неоплачиваемый сверхурочных хотя и в расположении доброй воли. То, как это облегчается внутри команды, будет сильно различаться от магазина к магазину. В некоторых местах они строго отдают руки в руки мастера схватки, в других они участвуют в бою (вопреки принятой практике).
Робби Ди
DSDM - это не гибкая методология, это огромная куча **** ****** ****, которые *** *** ******* нравятся менеджерам, потому что это дает им много участие в процессе.
gbjbaanb
12

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

Некоторые вещи, которые вы можете рассмотреть:

Слишком много в спринте

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

Распределение ресурсов

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

Оценить вариацию

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

Скорость

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

Доброй воли

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

Шипы

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

Робби Ди
источник
2
Я не уверен, что "оттолкнуть от PM" является наиболее полезным кадрированием. Вся команда в целом должна хотеть улучшить свой процесс - для этого и нужна ретроспектива - и все выявленные вами проблемы - это отличные вещи, которые следует рассмотреть в рамках этого обсуждения, но я думаю, что наиболее полезно подумать о том, как «как команда может гарантировать, что оценки, предоставленные целями спринта, будут более полезными в будущем?» вместо того, чтобы премьер-министр подталкивал команду к невыполнению задач.
Зак Липтон
1
Я думаю, вы дошли до сути проблемы. Премьер-министр должен поднять это жизненно важно, чтобы понять, почему проект опаздывает, но причиной № 1 будет «неправильные оценки» по любой причине. (и причиной № 1 для этого будет PM не нравятся высокие оценки!)
Ewan
Для меня это явно лучший ответ на данный момент. +1
angryITguy
Как насчет того, чтобы называть «откат» (что подразумевает потенциально антагонистический подход) как «вопросы», которые кажутся мне более нейтральными и эффективными?
Майкл Даррант
1
@MichaelDurrant et al. Достаточно справедливо - я изменил формулировку первого абзаца.
Робби Ди
10

Нет, это не признанная форма Agile по одной очень важной причине: если вы делаете все возможное , вы не делаете Agile, вы делаете Waterfall - и если вы думаете, что вместо этого вы делаете Agile Вы, вероятно, делаете Водопад плохо , в этом. Я уверен, что вы слышали, как старая пила "хорошо, быстро, дешево, выбирайте любые два", верно? С разработкой программного обеспечения это больше похоже на «все функции, предоставленные вовремя, в рамках бюджета, выберите первый или два других». Водопад выбирает первое, а Agile выбирает вторые два.

Если вы хотите быть гибким , вам нужна гибкость, чтобы отбрасывать истории из спринта, которые вы не можете выполнить вовремя. Один из возможных способов сделать это - попросить владельца продукта оценить истории, используя приоритеты MoSCoW. Это будет включать в себя выбор не более 60% историй (от общего количества баллов за историю) в качестве обязательных, которые будут завершены, 20% при условии, что вы должны завершить к завершению проекта и выпустить минимально жизнеспособный продукт, 20% как Могли бы быть, если бы у вас было время, и все, что выходит за рамки текущего выпуска, как «Не будет хейвов». Также важно отметить, что в сочетании у Must Haves должно быть достаточно мяса до костей, чтобы создать минимально жизнеспособный продукт без необходимости включать какие-либо элементы из других категорий.

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

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

nick012000
источник
везде, где я когда-либо видел Скрам, его водопад.
gbjbaanb
6

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

Но его подход не очень хороший.

Во время спринта команда должна постоянно следить за выполняемой работой, и если они могут выполнить свои обязательства по планированию спринта для завершения выбранных историй. Если команда определила, что она не может закончить все истории, она должна встретиться с PO и выбрать историю для удаления из спринта. Таким образом, все ОСТАНАВЛИВАЮТ РАБОТУ ИСТОРИИ и сосредотачиваются на том, чтобы сделать оставшиеся истории законченными. Помните: всегда лучше закончить одну историю полностью, чем две неполные.

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

Ваш PM ( что даже PM делает в команде Scrum ?? ) не должен быть позволен Scrum Master заставить вас закончить все истории. Вместо этого, если у него есть жалобы, он должен оставить их для ретроспективы. И даже лучше, должно быть частью решения проблем, которые препятствовали тому, чтобы истории были закончены вовремя.

Euphoric
источник
Я не согласен с комментарием "недействительный результат". Хотя это нежелательный результат, команды разработчиков должны понимать, что вполне разумно, чтобы некоторые истории не заканчивались время от времени. Это, конечно, не должно быть нормальным результатом, если вы не в состоянии закончить больше, чем одну историю, это показывает, что вы делаете что-то не так, но сказать, что этот результат не всегда действителен, по моему мнению, немного убедительно. Я бы предпочел иметь команды, которые выбирают слишком много работы, а затем выбирают недостаточно.
Брайан Оукли
5

Это приемлемый / распространенный вариант Scrum, о котором я не знаю?

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

Как вы предлагаете мне поступить по этому поводу?

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

nvoigt
источник
голосование, хотя неоплачиваемая сверхурочная перспектива может быть разумной, если контракт сформулирован таким образом (и общая заработная плата учитывает это, то есть выше среднего - или есть другие выгоды).
Фрэнк Хопкинс
4

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

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

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

Раджеш Наир
источник
1
Приятно! +1. С риском расщепления волос, вы не «решаете» скорость, это просто что-то, что появляется в стирке после нескольких спринтов, но да, со спринтом 0 (или как бы вы его не числили) - вы складываете доску так много историй, как вы считаете, достижимо.
Робби Ди
2

Обязательства FAQ

Это нормальное поведение?

Я не уверен.

Это удивительно?

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

Это хорошая идея?

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

Что нам делать?

  • Объясните, что содержание спринта основано на оценке . «Оценка» означает, что это будет только иногда правильно - и, как правило, неправильно. Когда это неправильно, иногда оно слишком низко, а иногда слишком высоко.
  • Объясните: гораздо проще изменить поведение при оценке, чем скорость работы.
  • Объясните, что когда команда наказана за слишком высокие оценки, она просто оценит ниже, и руководство потеряет намного больше прогресса в этом случае, чем из-за периодического перемещения некоторого контента из одного спринта в другой.

Хорошая вещь: ваш менеджер проекта уже знает все эти вещи и признает их правильными. Только в краткосрочной перспективе их можно игнорировать.

Лутц Пречелт
источник
2

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

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

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

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

Джон Дума
источник