Должны ли вы включать задачи, не связанные с разработкой, в свой журнал Scrum? [закрыто]

У нас возникли проблемы с включением определенных типов задач в журналы заданий по нашему продукту и спринту:

  • Встречи с клиентами
  • Обучение и обмен знаниями
  • Административные задачи

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

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

13 голосов | спросил Damovisa 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 09 Sep 2010 08:26:45 +0400 2010, 08:26:45

8 ответов


0

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

Когда мы планируем наш следующий спринт, мы всегда сокращаем запланированную вместимость на все праздники и тренировки. Мы также уменьшаем емкость за счет «административных накладных расходов». В нашем случае административные накладные расходы обычно составляют 1МД на члена команды в неделю. Эти накладные расходы предназначены для встреч и, возможно, помощи в сопровождении уже развернутых проектов.

Edit:

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

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

Какие типы собраний вы хотите добавить в свой список спринтов? SCRUM требуется всего несколько собраний - ежедневная встреча, совещание по планированию, обзорная встреча, ретроспективная встреча и более крупный проект SCRUM из SCRUM. Ежедневная встреча настолько коротка, что ее не нужно включать в планирование. Планирующая встреча, обзорная встреча и ретроспективная встреча не должны быть включены в спринт. SCRUM из SCRUM специфичен и не влияет на всю команду - может быть уменьшен от запланированного количества участников. Больше никаких встреч не требуется. Самое важное: связь, необходимая для выполнения задачи, является частью оценки задачи.

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

ответил Ladislav Mrnka 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 09 Sep 2010 17:58:40 +0400 2010, 17:58:40
0

В моем последнем проекте мы приняли участие в нашей доске объявлений. Их не было в списке продуктов, но мы изобрели их во время нашей игры по планированию.

Виды деятельности, которые мы включили, были семинары для клиентов, мероприятия по выпуску и т. д.

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

ответил Albin Sunnanbo 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 09 Sep 2010 10:42:15 +0400 2010, 10:42:15
0

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

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

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

ответил 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 09 Sep 2010 20:38:40 +0400 2010, 20:38:40
0

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

ответил Franco 15 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 15 Sep 2010 11:15:48 +0400 2010, 11:15:48
0

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

ответил PeeGee 26 Jam1000000amWed, 26 Jan 2011 02:18:59 +030011 2011, 02:18:59
0

Не существует фиксированной формулы для выбора пользовательских историй в Scrum. В моем проекте мы выбираем, какой рабочий элемент должен быть преобразован в Истории. Например. Такие задачи, как сравнение 2-3 инструментов IDE, уходят в отставание, поскольку они напрямую связаны с разработкой. Но в остальном я планирую 5 часов занятий в день для каждого члена команды, чтобы они проводили оставшиеся часы в обучении, документировании, обмене знаниями, программировании между коллегами и т. Д. Это работает для меня, чтобы оправдать демонстрацию против скорости спринта.

ответил mehtak 24 +03002016-10-24T11:49:50+03:00312016bEurope/MoscowMon, 24 Oct 2016 11:49:50 +0300 2016, 11:49:50
0

Если вы не включите вещи, которые должны делать люди, в свое отставание, как бы вы предложили управлять ими?

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

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

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

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

ответил chrish 22 PM00000090000002531 2014, 21:51:25
0

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

ответил Mandy 24 MarpmThu, 24 Mar 2016 17:38:06 +03002016-03-24T17:38:06+03:0005 2016, 17:38:06

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132