Владелец продукта требует новых функций, пока спринт начался

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

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

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

Как я могу обратиться с этим к моему PO на профессиональном уровне?

Вы знаете, что добавление функций в текущий спринт противоречит концепции схватки, верно?
Любой скрам-мастер в этом месте может объяснить ему, что спринт — это немодифицируемая единица работы после ее запуска? Если компания или команда согласились на Scrum, то это не Scrum и вам, ребята, нужно говорить об этом, как команде.
@AlexandreVaillancourt, что, если вы обнаружите огромную дыру в безопасности своего продукта в первый день спринта? Что, если вы найдете библиотеку с открытым исходным кодом, в которой есть функции, над которыми вы планировали работать? Что, если клиент, чей код вы писали, обанкротится? «Спринт никогда нельзя изменить» — не рабочая идея. Вопрос в том, достаточно ли важны эти запрошенные новые функции, чтобы изменить рабочие планы, и если да, то как это сделать.
Хорошая информация, которая поможет вам здесь: programrs.stackexchange.com/questions/149871/…
@ dan1111 Дыра в безопасности не является функцией. Это ошибка.
@ dan1111 Вы абсолютно правы, и, судя по тому, что я читал об этом, если спринт требует изменения объема, он прекращается и начинается новый спринт для решения неотложных проблем. Однако из ОП я чувствую, что проблемы, выдвинутые ОП, более тривиальны, чем это, и что они могут подождать до следующего спринта.
@ dan1111 Дело в том, что это не заданный вопрос.
@Папарацци, исправляя дыру в безопасности, может потребовать добавления новой функции. Но в любом случае я отвечал на комментарий Александра о том, что спринты нельзя изменить.
@AlexandreVaillancourt - Нет, смотрите мой ответ ниже. Манифест ПРИВЕТСТВУЕТ изменения, любой, кто говорит вам обратное, был продавцом змеиного масла и не знал Scrum. Сегодня это самая распространенная ошибка в SCRUM.
@TheWanderingDevManager Хм, верно; это сбивает с толку; согласно Руководству по Scrum : «Во время спринта: не вносятся изменения, которые могли бы поставить под угрозу цель спринта; область действия может быть уточнена и повторно согласована между владельцем продукта и командой разработчиков по мере получения дополнительной информации». Это немного противоречиво на первый взгляд, но да, похоже, что до тех пор, пока изменения, внесенные в бэклог спринта, сосредоточены на цели спринта, не должно быть никаких проблем, пока у команды есть время сделать это. это в спринте. Я должен прочитать этот документ снова: P
@AlexandreVaillancourt - Точно! Вы не допускаете произвольных изменений, но способность реагировать на вещи, которые необходимо изменить, является частью Agile. Сказать, что мы не можем сделать что-то отличное от того, что мы запланировали, — это вернуться к Waterfall, и многие Agile/Scrum Coach не понимают этого, они видят «Никаких изменений не внесено», и после этого их глаза стекленеют.
@TheWanderingDevManager Спасибо за совет! Это улучшит мой Scrum-fu!
@AlexandreVaillancourt - Рад помочь!
Надеемся, что за последние ~2 года вы узнали больше о фреймворке из авторитетного документа The Scrum Guide , увидели неточности в ответах и ​​получили более точную информацию для решения проблем.

Ответы (7)

Agile Manifesto действительно приветствует поздние изменения, см. пункт 4:

Реагирование на изменение вместо следования плану

И в руководстве по схватке есть это:

Во время спринта:

Не вносятся изменения, которые могли бы поставить под угрозу Цель спринта ;

Цели в области качества не уменьшаются; а также,

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

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

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

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

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

Согласовано. Кроме того, если владелец продукта бесполезно часто меняет приоритеты, настаивание на этом процессе (и совещании для внесения изменений) каждый раз помогает ему увидеть, как изменение приоритетов нарушает планы.
Я бы сказал, что если это происходит постоянно, если у вас обычно есть 300 человеко-часов на спринт, возможно, выделите только 250 человеко-часов на спринт, а последние 50 посвящены «срочным работам». Может быть, отложите последние 50 дел, которые вы, возможно, захотите сделать в этом спринте, но вы можете отложить их, если это необходимо. Тогда, если ваш генеральный директор придет с требованиями, вы заранее знаете, сколько вы за это сократите.
+1 за «что-то еще понижено в должности, поскольку это не является частью достижения цели». Рискуя повторить то, что сказал JeffO. У всего есть цена. Любая новая функция имеет свою цену. Не позволяйте владельцу продукта безнаказанно добавлять вещи в кучу, не перебалансировав таблицу приоритетов и не урезав вещи в другом месте.
@corsiKa: Но это просто позволяет тем, кто хочет обойти систему. До каких пор им не хватит 50 часов? Через несколько месяцев я почти гарантирую, что вы больше не будете заниматься скрамом.
@Легкость И что? Скрам — это не цель. И уж точно не святой Грааль. Если это не работает для вашей рабочей ситуации, придерживайтесь тех частей, которые работают, и двигайтесь дальше. Не забывайте, что цель состоит в том, чтобы доставить хороший продукт.
@Bernhard: Конечно, но когда ваша рабочая ситуация делает все возможное, чтобы использовать наихудшую из возможных систем управления, несмотря на огромные усилия по ее исправлению, это не то, что вы должны слепо принимать. «Быть ​​глупым» — недопустимая «рабочая ситуация».

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

Но (очень большое, но!) Я работал с PO, которые часто тушат пожары на протяжении всего Scrum-спринта. Если это произойдет, это может сильно отвлекать и/или деморализовать команду, постоянно адаптируясь к этим изменениям. Эта постоянная смена приоритетов также может серьезно повлиять на выпуск релизов и, как следствие, отрицательно сказаться на рентабельности инвестиций!

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

Для дальнейшего чтения с двух точек зрения взгляните на эти ссылки:

https://www.scrumalliance.org/community/articles/2014/july/scrum-vs-kanban

http://kanbantool.com/kanban-library/scrum-and-kanban/kanban-vs-scrum-how-to-make-the-most-of-both

Наконец, беря цитату из последней ссылки

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

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

Говоря как человек, который был и техническим директором, и руководителем продукта в разных организациях, я во многом согласен с @The Wandering Dev Manager, но хотел добавить больше, чем позволяет комментарий.

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

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

В целом изменения во время спринта — это нормально, но вы должны быть к ним готовы. Я всегда слежу за тем, чтобы мои продуктовые и технические команды набирали достаточно баллов для обработки «горячих исправлений» и ошибок. Когда я запускал продукт в медиа-компании, мои команды знали, что нужно резервировать определенное количество баллов за каждый спринт — всегда что-то всплывало, так как это было характером нашего бизнеса. Наша система работала, потому что мы всегда могли спланировать какое-то событие. Если прогнозируемое событие как-тоне случалось, то оставшееся время можно было использовать для личных проектов, ведения домашнего хозяйства или [ох!] продвижения вперед. Обработка последних функций/изменений всегда находилась на усмотрении менеджера по продукту и в консультации с менеджером проекта и техническим менеджером этой команды. Мы всегда следили за тем, чтобы мораль команды также была важным фактором. Бизнес-подразделениям не было обещано ничего, кроме «наилучшей попытки выполнить».

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

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

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

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

Теоретически я согласен с @The Wandering Dev Manager, но я думаю, что он / она делает потенциально легким для PO изменение спринта.

Задача PO — противостоять изменениям в спринте (а не предотвращать их) от внешних субъектов (клиентов). Если нет критической ситуации, то спринт следует считать неизменным.

Кроме того, цикл спринта должен быть коротким, чтобы все новое, что появляется, могло быть расставлено по приоритетам в следующем спринте, не затрагивая клиента. Если у вас есть несколько месячных спринтов, то вы на самом деле не занимаетесь agile. Цель — быстрое изменение с видимыми изменениями (2-4 недели).

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

Что же делать? Ну это зависит. Работа PO - поддерживать спринт, он это делает? Он бросает соответствующую работу, чтобы компенсировать это? Если нет, то «Scrum Master» должен переговорить с PO.

Это Он, и я с вами не согласен. Работа PO состоит в том, чтобы максимизировать ROI продукта, если это означает изменение, то это означает изменение, даже если от спринта нужно отказаться. Спринт никогда не бывает неизменным, вы можете захотеть это обсудить, но неприятие действительных изменений — это антипаттерн Agile, который используют «тренеры Agile» во всем мире.
Если на то пошло, задача PO состоит в том, чтобы максимизировать рентабельность инвестиций в продукт, даже если это означает отказ от использования спринтов или вообще отказ от Agile. Если процесс не устраивает бизнес, процесс проигрывает. Спринт — это просто название набора работ, который вы прогнозируете на определенный период времени. Если это не то, что вы делаете, потому что это не подходит бизнесу, просто не называйте это спринтом.
Да и нет. Постоянные изменения приводят к потере производительности. Если это случается чаще, чем время от времени, это бомбит скорость. Я видел, что у моего последнего крупного клиента, где PO уделял приоритетное внимание незавершенным работам 3 раза в неделю, в результате НИЧЕГО не было сделано. Вы начинаете с чего-то, а затем боксируете снова и снова.
@TheWanderingDevManager: отток при изменении спринта в общем случае снизит рентабельность инвестиций. Задача PO — обсудить с клиентом и убедиться, что изменение является лучшим вариантом (а не просто изменение ради изменений). При этом они должны сопротивляться (в совете, что вообще плохо), но должны содействовать, если это лучший вариант. Они также должны напоминать клиенту, что спринт короткий по той причине, что вам не нужно часто менять.
@TheWanderingDevManager: я думаю, что мы действительно согласны с тем, что следует делать. Я просто хочу подчеркнуть, что для получения наилучшего ROI не означает соглашаться на все, что хочет клиент, только потому, что он клиент. Там работа заключается не в том, чтобы действовать как человек, дающий согласие на изменение спринта, а в том, чтобы действовать как причина и удостовериться, что клиент готов заплатить стоимость изменения в середине спринта, и попытаться предотвратить рандомизацию команды. по изменениям. Но если спринт должен измениться, то они несут ответственность за это и должны внести изменения правильно.
Я думаю, что слово «сопротивляться» (но не «предотвращать») в этом ответе является хорошим. Изменение курса, когда вы запланировали свой спринт, повредит производительности, но цель спринта и команды разработчиков — поддержать бизнес , а не создать модель того, как должна работать гибкая разработка. Если нужно сделать что-то неожиданное, то это нужно сделать .

Вот что вызывает ваш PO:

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

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

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

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

То, что делает ваш PO, может быть полностью законным. Я предполагаю, что вы занимаетесь коммерческим бизнесом, и деньги от ваших клиентов идут на оплату вашей зарплаты. Бывают случаи, когда ваши деловые люди говорят: «Хорошо, полное изменение плана», и когда вы должны принять это.

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

  • Если высокоприоритетные истории небольшие и вписываются в продукт, подумайте о том, чтобы использовать для них процесс обработки ошибок , даже если это новые истории. (Думаю, у вас есть определенный процесс внесения исправлений в текущий спринт.)
  • Если есть серьезные изменения в приоритете, предложите PO прервать текущий спринт. Верните все незавершенные истории в бэклог. Напомните PO, что любая работа, которую вы уже проделали над незавершенными историями, может быть потрачена впустую, если вы не сможете возобновить работу и быстро объединиться.
Я не согласен с первым пулемётом. Включение большего количества вещей в спринт, даже если они небольшие, требует пространства для маневра. Либо а) есть неизрасходованные очки спринта (плохо) б) бросить какую-то историю, чтобы соответствовать новым (адекватно), в) перегрузить спринт (плохо). d) Отложите это для нового спринта (рекомендуется, но не всегда возможно, учитывая повестку дня заказа на покупку)... Никогда не используйте процесс исправления/ошибки для новых функций.
Также прерывание спринта действительно очень плохо.
@Mindwin, мы всегда оставляем время, чтобы посмотреть на новые ошибки, подготовить презентации для объяснения вещей руководству, справиться с одним или двумя больничными днями и т. Д. Если спринт заполнен на 100 процентов, вы не делаете достаточно поправок на непредвиденные обстоятельства. .

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

В Scrum-процессе scope creepэто происходит, когда Владелец Продукта или любой другой член Scrum-команды вносит в спринт дополнительную работу (например, «позолотить» или скрыть технический долг) без обсуждения этого с Командой. Вся Команда всегда должна договариваться об изъятии пользовательской истории из Бэклога Продукта и переносе ее в текущий Бэклог Спринта. Однако, если команда завершила всю работу, которую они взяли на себя в текущем спринте, и у разработчика нет возможности помочь другому или тестировщику, они могут поднять проблему на следующей ежедневной встрече и попросить внести новые Работа.

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

Мы можем добавлять или изменять задачи в квартальном плане, но это отражается в расширении объема и явном изменении плана.

использованная литература

Владелец продукта требует новых функций, пока спринт начался
СпросиСетьПолитика конфиденциальности1y, 2v