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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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