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

Иногда в проектах нам нужно тратить время на такие задачи, как:

1. изучение альтернативных структур и инструментов
2. изучение рамок и инструментов, выбранных для проекта
3. настройка серверов и инфраструктуры проекта (контроль версий, среды сборки, базы данных и т. д.)

Если мы используем User Stories, куда должна идти вся эта работа?

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

Мы много думали об этой проблеме в прошлом году.

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

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

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

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

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

Мы даже назначаем сюжетные пункты задачам и иногда работаем с ними так же, как с историями.

В конце я бы пошел на это решение в вашем случае (которое также может быть применено в целом):

1. Разделите «настройки» и технические вещи на задачи (вещи, которые непосредственно не производят ценность для владельца продукта).
2. Возможно, сделайте всплеск перед настройкой проекта, чтобы получить самые важные инструменты (SCM, инструменты разработки, определение процессов, стандарты кодирования и т. Д.)
3. Примите, что эти задачи появляются в течение всего проекта, и спланируйте это с помощью отдельного «типа» действий, отличных от историй.

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

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

Будут времена, когда вам придется выбирать фреймворк или что-то еще во время проекта, но когда я говорю, что я имею в виду фреймворк, такой как nHibernate, а не фреймворк, такой как .NET. В этих случаях исследования должны быть ускорены и ограничены во времени, не говоря уже о достаточно коротких. Попробуйте справиться с этим так, как будто у вас заболел разработчик на пару дней.

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

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

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

Разбивает «пользовательскую историю» как концепцию. Какой пользователь участвует в этом? Никто. Это работа, которую вы должны были уже сделать.

Другой вариант - сделать шип для этого.

Неплохо.

Третий вариант - сделать задачу частью проблемы (например, среда разработки еще не выбрана), а не пользовательской историей.

Примерно так же, как шип, что касается планирования и накладных расходов.

Установка не является историей пользователя.

Это то, что вы должны иметь в виду, прежде чем вы даже начали этот проект.

Вы не сможете реально запустить проект, если у вас нет готовых к работе фреймворка / инструмента и серверов.

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

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

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

Они могут не применяться в вашей рабочей среде, но у нас это хорошо работает.

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

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

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

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

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

на изучение 2-3 альтернативных рамок / инструмента

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

затем при изучении рамок мы выбираем для проекта

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

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

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

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

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

по настройке серверов (SVN, Базы данных и т. д.)

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