Scrum Taskboard - могут ли задачи меняться? [закрытый]
компания, в которой я работаю, в настоящее время хочет перейти от традиционного водопада в Scrum для развития. Мы находимся в процессе медленного принятия тех практик, которые мы можем, не делая полностью ход (мы все еще должны многому научиться, прежде чем мы сможем полностью двигаться дальше!).
одна из вещей, которую мы хотим реализовать сейчас, прежде чем сделать полный переключатель, - это панель задач. Мы все считаем, что это отличный инструмент, который может помочь с развитием, и помочь держать этих бизнес-пользователей от наших спин С "что ты делаешь?"и "как дела?- вопросы и встречи.
Итак, со всем сказанным, мне было интересно, могут ли задачи на панели задач измениться? Я знаю, что вы не хотите менять истории, но как насчет задач в истории? Что делать, если появилась новая задача или старая задача больше не действительна? Могут ли они быть добавлены и / или удалены в середине спринта (хотя мы на самом деле не используем спринты, скорее короткие циклы разработки).
спасибо!
5 ответов
Я знаю, что вы не хотите менять истории, но как насчет задач в истории? Что делать, если появилась новая задача или старая задача больше не действительна? Могут ли они быть добавлены и / или удалены в середине спринта (...).
Да, они могут. Во время итерации команда обычно собирает знания и получает лучшее понимание того, что нужно сделать или нет. Как следствие, команда может обнаружить, что задача на самом деле не актуальна, что данный элемент отставания требует больше работы чем ожидалось, что первоначальная оценка неверна. В таких случаях вы определенно хотите обновить свой Sprint Backlog и Burndown Chart, чтобы придерживаться реальности и держать то, что должно быть сделано видимым: вы действительно хотите знать, если итерация все еще на ходу, если вы можете взять еще один элемент и т. д.
Итак, да, не стесняйтесь обновлять, удалять, добавлять задачи как только вы обнаружите, что это нужно сделать. И чем раньше, тем лучше.
в нашей команде мы используем доска задач вдохновлен Scrum и XP из траншей от Хенрика Книберга, и у нас есть специальное место для "незапланированных предметов", как показано ниже:
нам нравится этот подход, потому что он позволяет легко обнаружить, если незапланированные элементы убивают итерацию. И мы также" пересматриваем " такие задачи во время ретроспективы, чтобы увидеть, как мы можем улучшить наше совещание по планированию, наши оценки, то, как мы разбиваем пункты и т. д.
команда фиксирует истории пользователей, а не задачи
это не проблема, чтобы некоторые задачи менялись по мере того, как вы сталкиваетесь с проблемами или имеете лучшие идеи реализации.
на самом деле, это очень редко, чтобы закончить спринт с каждой задачей 100% "предсказано" точно в собрании планирования спринта.
Они могут и должны меняться. Совет должен обновляться по крайней мере ежедневно.
но Паскаль ответил на это уже - я хочу сделать еще один момент: из опыта "пытается принять" Agile через небольшие изменения не будет работать. Scrum-это полная структура - под этим я имею в виду, что в Scrum очень мало (я бы ничего не сказал), которые можно отбросить, не нанося вреда процессу и способствуя дисфункции или, по крайней мере, позволяя дисфункции продолжаться (об этом писал). Идущий медленно может быть единственным способом пойти в некоторых компаниях / обстоятельствах, но есть риск, что затяжные дисфункции взорвут процесс изменений/улучшения, прежде чем он сможет достичь своего конца и принести пользу.
Мне уже нравятся ответы Паскаля и Энди, поэтому не повторяйте.
полезной альтернативой является запуск платы канбан. У Хенрика Книберга также есть хорошая "книга" об этом, доступная здесь: http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
Это позволяет организовать вашу работу и быть isert некоторые гибкое мышление в компании. Как сказал Энди, Scrum-это олл-ин, если нет, вы обнаружите, что "это не работает".
Почему бы и нет? Оставить пространство для команды, чтобы завершить работу так, как они хотели бы сделать.
истории-это "контракт" между клиентом, владельцем продукта и командой, поэтому хорошо не менять, добавлять, удалять истории, не давая им знать. Но задачи только для команды.
команда должна быть в состоянии отслеживать усилия, как они должны сделать его видимым.
сомнительно изменение часов, которые команда поручила завершить в спринте, но хорошая схватка Мастер и опытная команда способна самоорганизоваться.