Лучшая практика для концепции Scrum "сделано" в JIRA

Ответ 1

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

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

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

Ответ 2

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

Что-то вроде Submitted- > Assigned- > Coding- > Review- > Testing- > Finished.

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

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

Ответ 3

• закодированы
• проверено устройство

ИМХО они принадлежат друг другу, так как оба должны обрабатываться одним и тем же человеком (желательно TDD, что действительно делает невозможным их разделение).

• Тестирование интеграции

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

• комментировал

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

• оцененный эксперт

Отдельная задача для отдельного разработчика (или более).

• qa проверено

Отдельная задача для тестировщиков/персонала QA.

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

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

Ответ 4

Готово определяет, что означает команда, когда она обязуется "делать" элемент "Заготовка продукта" в Sprint. Некоторые продукты не содержат документацию, поэтому определение "сделано" не включает документацию. Полностью "сделанный" приращение включает в себя весь анализ, дизайн, рефакторинг, программирование, документацию и тестирование для инкремента и всех элементов Product Backlog в приращении. Тестирование включает в себя тестирование модулей, системы, пользователя и регрессии, а также нефункциональные тесты, такие как производительность, стабильность, безопасность и интеграция.

Справка: Scrum Guide - Автор Кен Швабер и Джефф Сазерленд (изобретатели Scrum)

Вы заявляете, что следуете "Scrum Practices". Мне кажется, что вы просто используете несколько частей Scrum Framework, а не другие, это правда? Прежде всего, Scrum не обязательно является практикой, это Framework, вы либо используете фреймворк, либо нет. Он работает на основе проверки и адаптации, поэтому, помимо базовых правил Scrum, ничего не установлено в камне, поэтому вы не получите точного ответа на свой вопрос. Лучший способ узнать ответ - нанять опытных Scrum Professionals, а также опытных разработчиков и тестировщиков и попробовать выполнить вышеописанный план в вашей команде Scrum.

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

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

Ответ 5

Мы используем довольно подобную систему в JIRA, и у меня есть открытый вопрос здесь и в советах Atlassian, задающих очень похожий вопрос. У нас есть аналогичное определение. Мы создаем основную историю в описательной форме, т.е. "Текст легенды о графах прибыли и убытков". Затем мы определяем подзадачи, которые относятся к типу "технический" или "процесс". Техническими задачами являются фактическая работа по реализации рассказа "Исследование возможных причин на сайте поставщика", "Реализация исправления в инфографическом классе". Элементы процесса включают "Peer Review", "Make Build", "QA Testing", "Merge". Как заметил один комментарий, у вас может быть QA, продолжающееся до/во время Peer Review. В рамках процесса Scrum у нас QA происходит почти все время (они являются частью команды), иногда они сидят с разработчиком, иногда они получают "bootleg builds" для запуска в тестовой среде. Это разведочное тестирование и считается частью процесса кодирования для нас. Подзадача "QA Testing" предназначена для тестирования интеграции и регрессии и является окончательной проверкой всей истории после завершения Peer Review. К тому времени команда QA уже имеет полный план тестирования, который они разработали во время исследовательского тестирования, и обычно это просто вопрос выполнения плана и "проверка его".

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

Ответ 6

Для этой цели мы используем две платы. У нас есть одна доска для Sprint развития, где "Готово" готово к тестированию. Вы не можете войти в спринт, если не будете хорошо и действительно готовы начать разработку (весь анализ, сделанные оценки, люди знают, что они должны делать), все разговоры были, скажем так, хотя наши разговоры имеют тенденцию проходить в JIRA Комментарии, данные распределенной команде)... и вы выходите, когда закончите разработку. Это лучший способ отслеживать, соответствует ли наша команда разработчиков своим целям без влияния QA. Между тем, QA использует панель стиля Kanban, и они идут от "Ready to Testing" (это их "делать" ), используя In Testing to Ready to Release.

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

Ответ 7

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

Это ваша настоящая проблема; способность разбивать истории на небольшие полезные вертикальные фрагменты функциональности. Работа над этим сделает вашу команду более гибкой и придаст ПО большую гибкость.

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

Сфокусируйтесь на своих историях, а не на задачах.

Ответ 8

Мы используем подзадачи.

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

Мы не требуем, чтобы каждая маленькая часть задачи была представлена ​​как подзадача.

Мы не бухгалтеры, а разработчики.

Командное соглашение состоит в том, что если вы не можете сразу принять задание, просто запишите его в качестве подзадачи в историю. (Используя гибкий плагин, это очень просто). то есть. мы никогда не будем систематически создавать подзадачу "create unit test", но в некоторых случаях, когда кто-то пытается получить этот динамик и работает, вы увидите всплывающее окно этой подзадачи в истории. Наличие там позволяет команде обсуждать это во время схватки.

Если вы хотите сгенерировать контрольный список автоматически, посмотрите на подзадачу create на плагине перехода. https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition Это позволяет автоматически добавлять подзадачи, когда история была совершена.

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

Фрэнсис

Ответ 9

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