Scrum: нормально ли, чтобы дизайн / UX пользовательской истории происходил в том же спринте, что и реализация

9

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

В том же спринте я должен реализовать этот дизайн. Во время планирования спринта мне приходилось делать предположения о том, сколько времени займет эта неопределенная пользовательская история.

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

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

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

Итак, мой вопрос

  • А) как вы справляетесь с зависимостями при планировании спринта? РЕДАКТИРОВАТЬ: это нормально, что дизайн / UX пользовательской истории происходит в том же спринте, что и реализация
  • Б) как мне теперь подойти к спринту? Переоцените текущую историю пользователя и наблюдайте, как спад превращается в выгорание и рассматривается как некомпетентный / непродуктивный? Или добавьте новую задачу к текущему спринту в духе «помогите дизайнеру создать подходящий дизайн»

  • Аллан
    источник
    Стоит отметить, что ваш вопрос в строке темы очень отличается от вопросов внизу вашего текста. Было бы полезно, если бы вы редактировали это, чтобы выбрать один или другой.
    фунтовые

    Ответы:

    14

    как вы справляетесь с зависимостями при планировании спринта?

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

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

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

    Тем не менее, вы этого не сделали, и теперь ваш вопрос ...

    как мне теперь подойти к спринту?

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

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

    прецизионный самописец
    источник
    Спасибо за ответ. Чтобы расширить, мой scrum master хочет, чтобы мы были действительно гибкими, чтобы мы могли изменять / повторять пользовательскую историю, как только она была закодирована. Поэтому он не любит слишком много предварительной документации / дизайна, и вместо этого мы должны кодировать / планировать по ходу дела. Конечно, это приводит меня к ситуации, в которой я оказался. Гибкий манифест, похоже, поддерживает его позицию. Так что, мы слишком проворны для нашего же блага?
    Аллан
    Например, одна из наших пользовательских историй может быть «Пользователь хочет иметь возможность играть против другого игрока». В нашем планировании спринта я, вероятно, разбил бы это на несколько задач, таких как: показать серверы, выбрать сервер для подключения, подключиться к серверу. Затем дизайнер в идеале расскажет мне, как отображаются серверы, какие фильтры списков доступны, что происходит, если серверов нет и т. Д. Конечно, этот список вещей доступен мне только после того, как он его спроектировал и в этом случае происходит в том же спринте. Этот список также может быть изменен / повторен во время спринта.
    Аллан
    1
    @Allan: То, что ваш scrum-мастер не может понять, это то, что, если дизайнер должен завершить свою работу до того, как разработчик сможет начать свою работу, это предварительный дизайн. Выполнение этого в рамках спринта не устраняет затрат на предварительный дизайн, но делает его менее заметным и затрудняет оценку вашей разработки. Если вы можете найти способ итерации с вашим дизайнером, это здорово, сделайте это частью спринта и сделайте усилия, подходящие для совместной работы. Но заранее все в порядке, если честно и, желательно, сделано до спринта.
    pdr
    Если это типично для ваших пользовательских историй, я бы сказал, что ваши истории слишком велики. Учитывая ваш пример, я ожидаю увидеть «пользователь может видеть список серверов», «пользователь может подключиться к серверу и увидеть список доступных противников» в виде историй.
    Жюль
    6

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

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

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

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

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

    Барт ван Инген Шенау
    источник
    Это был хороший ответ тоже. Если бы я мог отметить два ответа как правильные, я бы сделал.
    Аллан
    3

    Во время планирования спринта мне приходилось делать предположения о том, сколько времени займет эта неопределенная пользовательская история.

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

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

    Максим Крыжановский
    источник
    Спасибо, Дархазер. Да, scrum master также является руководителем проекта. Мастер Скрама заявил, что должно быть минимальное планирование и документация. Вместо этого мы должны строить функции по ходу, с постоянными проверками во время спринта, чтобы повторить / изменить то, что было построено, как определено менеджером проекта (следовательно, дизайн и реализация происходят в одном и том же спринте). Исходя из роли, где дизайн был довольно солидным, у меня возникли трудности с адаптацией к этой культуре кода.
    Аллан
    3
    «... Scrum Master также является руководителем проекта». - фигово. «... минимальное планирование и документация ...» - что именно есть в ваших Определениях Готово и / или Готово? «... проверяет во время спринта итерацию / изменение того, что было построено, как определено менеджером проекта ...» - это должно быть решением команды, а не хозяина схватки, конечно, не менеджера проекта и (если это ДОЛЖЕН быть кто-либо ) это должен быть владелец продукта!
    Фил В.
    @PhillW. У нас нет определения готовности. У нас просто есть отставание с различными состояниями детализации для функции. Детали проясняются, когда мы идем. Официально выполнено, когда заинтересованные стороны подписывают соглашение, но на самом деле это вехи, и когда это делается, говорит менеджер / руководитель схватки / продюсер (тот же человек). Сейчас я занимаюсь «схваткой» в течение года, вскоре после начала я немного изучил самосбор, так как чувствовал, что наш способ это странный. Чем больше я читаю, тем больше я чувствую, что мы делаем разборку «Культ груза». Но политика мешает мне что-либо с этим делать ...
    Аллан
    1

    Являются ли задачи о дизайне выраженными в виде историй и каковы определения вашей команды

    • история готова
    • история сделана

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

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

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

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

    Keufran
    источник
    0

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

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

    Дальнейшее обучение не может повредить ... Возможно, работа с дизайнером даст вам возможность приобрести новые навыки UX? ... это значит, что стакан наполовину полон, а не наполовину пуст) :))

    ScrumMasterChangeFacilitator
    источник