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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скорость

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

Доброй воли

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

Шипы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не уверен.

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

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

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

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

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

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

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

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

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

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

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