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

23

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

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

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

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

Асим Гаффар
источник
я немного изменил вопрос, чтобы сделать его более понятным ... вопрос теперь как подзадачи в реальных пользовательских историях, а не как истории
Асим Гаффар

Ответы:

12

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

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

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

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

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

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

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

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

  1. Разделите «настройки» и технические вещи на задачи (вещи, которые непосредственно не производят ценность для владельца продукта).
  2. Возможно, сделайте всплеск перед настройкой проекта, чтобы получить самые важные инструменты (SCM, инструменты разработки, определение процессов, стандарты кодирования и т. Д.)
  3. Примите, что эти задачи появляются в течение всего проекта, и спланируйте это с помощью отдельного «типа» действий, отличных от историй.
Malte
источник
Итак, то, что вы называете TASK, в основном является рабочим элементом, таким как User story или Bug? .. Это не TASK, как в задачах пользовательских историй, таких как код, тестирование, развертывание и т. Д.
Asim Ghaffar
2
Да, чтобы провести различие между теми, кого мы называем подзадачами историй «Деятельности».
Мальте
То, что вы называете Задачей, в сущности, является проблемой согласно MSF для Agile 5.0
Асим Гаффар
Если вы обратитесь к этому описанию здесь: msdn.microsoft.com/en-us/library/dd997897.aspx - вы можете назвать это проблемой, как она там описана, я думаю, она подойдет . Так что это сделает ваш вариант № 3.
Мальте
2
Пункт 3 «Принять, что эти задачи появляются в течение всего проекта», особенно важен. Agile Unified Process имеет отличную картину, которая демонстрирует это: i.stack.imgur.com/CUVFI.jpg . Обратите внимание, что дисциплина «окружающей среды» никогда не исчезает. Также обратите внимание, что основная часть работ по охране окружающей среды является предварительной. Так что, если вы вдруг обнаружите, что на более позднем этапе вы выполняете большую работу по защите окружающей среды, возможно, что-то идет не так.
Майкл
4

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

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

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

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

прецизионный самописец
источник
когда я сказал framework .. это было как если бы мы пошли на JSF или Spring .. или когда я сказал tool ... это было как если бы мы пошли на Jboss или Glassfish ..
Асим Гаффар
1
Я не знаю, что вы имеете в виду "задолго до того, как вы начнете разработку" ... когда проект начинается, не следует начинать спринт 1 как можно скорее, например, в течение 2 недель с даты начала проекта ... а в спринте 1 присутствует реальное кодирование.
Асим Гаффар
1
@AsimGhaffar: я не думаю, что должно, нет. Если вы начнете кодировать еще до того, как примете решение, например, какой сервер приложений использовать, вы примете хотя бы одно решение, которое потребует от вас переписать большую часть этого кода. И я не могу себе представить запуск проекта в настоящее время без контроля исходного кода. Я имею в виду хорошо, если у вас есть разработчики, которые сидят без дела, найдите им что-нибудь продуктивное, например, прототипы. Но не лезьте с головой в проект, пока не примете ключевые решения.
фунтовые
msgstr "не следует запускать спринт 1 как можно скорее, например, в течение 2 недель с даты начала проекта". Правильный. Это означает, что ваша среда настроена и готова к работе. Вы уже освоили использование инструментов, сборку и развертывание. Если вы еще не разбираетесь в этих вещах и среда не настроена, значит, вы не готовы начать.
S.Lott
@ S.Lott хмм. Я думал, что на работе нужно обладать необходимыми навыками, т. Е. Во время работы над проектом, а для спринта 1 нет необходимого учебного пособия.
Асим Гаффар
2

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

Карл Билефельдт
источник
1

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

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

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

Неплохо.

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

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

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

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

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

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

С. Лотт
источник
проблема не такая, как у Спайка. Думайте о проблеме как о рабочем элементе, запланированном в обычном спринте, но у него нет сюжетных моментов. Пример проблемы: SVN не выбран. Я заимствую слово «выпуск» от MSF для Agile 5.0
Асим Гаффар
«проблема не такая же, как спайк». Для определения слов вы правы. Но когда вы думаете о планировании дополнительной работы перед спринтом 1, не имеет значения, называете ли вы это проблемой или всплеском. Выбери один. Бросить монету. Головы.
S.Lott
Опять же, я имел в виду планирование проблемы вместе с историями в Sprint 1, а не до Sprint 1. Итак, для Sprint 1, скажем, мы выбрали 2 пользовательских истории и 1 проблему. Нет сюжетных моментов для выпуска, хотя. Спайк действительно будет перед спринтом 1.
Асим Гаффар
Спайк или проблема не имеют значения. Это все работа, которая не является частью пользовательской истории. Это все работа, которая должна быть сделана до первого спринта. Вы можете назвать это спайком или проблемой, что бы ни делало вас счастливым. Но это не история пользователя.
S.Lott
1

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

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

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

Крис Чоу
источник
0

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

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

BЈовић
источник
вы правы, и я не предлагаю, чтобы они были в описании истории ... что я имел в виду, чтобы иметь такие задачи, как "установить MySQL", "оценить среду" как часть первой реальной истории пользователя ... т.е. как пользователь, которого я хочу домашняя страница, так что у меня есть быстрый доступ к основным функциям.
Асим Гаффар
@AsimGhaffar Это можно сделать на начальной итерации. Не как история пользователя, так как пользователям не нужно знать (и они не должны заботиться), какую технологию вы использовали для удовлетворения своих потребностей.
BЈовић
0

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

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

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

Стюарт Лейланд-Коул
источник
3
Цитируя Алистера Кокберна, у меня есть подлое чувство, что кто-то был обеспокоен его использованием Scrum, когда он сделал что-то, что не имело очевидной коммерческой ценности в начале, и он изобрел «О, это был Sprint Zero!» убрать крестьян с кирками подальше от его порога.
Асим Гаффар
0

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

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

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

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

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

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

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

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

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

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

Ладислав Мрнка
источник
Мы занимаемся разработкой продуктов, а не проектами клиентов :).
Асим Гаффар
Хорошо. В таком случае вам все равно следует отдельно отслеживать время, затрачиваемое на обучение и инфраструктуру, чтобы увидеть, какие накладные расходы у вас есть. Сокрытие этого времени внутри задач повредит видимости вашего процесса разработки.
Ладислав Мрнка