Gitea: Бэклог SCRUM / бэклог спринта для каждого проекта

Не могли бы вы указать, какие функции вам особенно нужны?

В SCRUM у вас есть в основном один Product-Backlog, содержащий пользовательские истории, которые отсортированы по приоритету или по некоторому предопределенному значению.
Каждая пользовательская история, скорее всего, состоит из заголовка, описания и, возможно, имени значения, в котором будет измеряться приоритет (более или менее похоже на «проблемы», но отсортированного по приоритету), а также этого поля приоритета.
Также поле, которое может указывать, была ли реализована User-Story, удалена (из-за некоторых проблем не завершена или нуждается в дополнительном описании).

В каждом спринте (определенный период времени) разработчики берут некоторые пользовательские истории из Product-Backlog и добавляют их в свой Sprint-Backlog, который, помимо P-Backlog, также состоит из (возможно, необязательных) идей, как разработчики хотят решить. конкретная проблема, которую описывает выбранная ими User-Story. Каждый разработчик может видеть историю пользователя, назначенную другим разработчиком, но не может ее редактировать (возможно, только комментирует ее).
Разработчики должны иметь возможность изменять только свои собственные заметки о решении, но не описание / заголовок пользовательской истории, поэтому необходимы как минимум две роли (владелец продукта и разработчик (не эксклюзивно)).
Когда dev-1 завершил свои пользовательские истории, он мог бы попросить другого dev-2 назначить его (другого dev-2) пользовательскую историю для dev-1 (ну, на данный момент открыто для обсуждения).

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

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

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

TL; DR: D
В общем, должно быть две роли: одна - владелец продукта (по умолчанию владелец проекта с возможностью смены ролей первым владельцем продукта / проекта), а другая - разработчики.
Более того, необходим спринт, у которого есть определенная продолжительность (владелец продукта?) И какой-то механизм для запуска спринта. Запускать спринт не имеет смысла, если в бэклоге спринта ничего нет, поэтому потребность в бэклоге спринта, содержащем назначенные (?) (Возможно, все разработчики могут менять назначения) пользовательские истории, которые нельзя изменить, но есть комментарии ( один прикрепленный комментарий с дополнительными комментариями?).
Каждый разработчик должен иметь возможность (только в рамках спринта? Или когда он / она хочет?) Изменять статус пользовательской истории с незавершенного на завершенный (вопрос в том, какие состояния может иметь пользовательская история?)
Когда спринт подходит к концу, состояние «трекера проблем» должно измениться на фазу обзора, показывая только готовые пользовательские истории (и только прикрепленный комментарий разработчика? Нет комментариев? Все комментарии?). (Какие состояния нам нужны?: Предложение: планирование, спринт, обзор, ретроспектива)
Затем владелец продукта (?) Должен иметь возможность изменить состояние на ретроспективу, где может быть «доска объявлений» с предложениями, шаблонами, хорошими практиками, плохими практиками и т. Д., А также всеми, готовыми и незавершенными пользовательскими историями. должен снова стать видимым.
После этого этапа владелец продукта (?) Должен иметь возможность перейти к следующему этапу, планированию, где незавершенные пользовательские истории должны (?) Вернуться в журнал отставания продукта, а готовые пользовательские истории либо заархивированы, либо удалены (чтобы не показывать пальцем на людей, когда потом обнаруживают ошибку).
А на этапе планирования команда разработчиков может снова добавить пользовательские истории в свой бэклог спринта.
И после этого шага нужно каким-то образом запустить спринт, возможно, владельцем продукта.

Получайте удовольствие от обсуждения (я надеюсь)

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

Это уже обсуждалось в №805. Лично я считаю, что рабочий процесс команд может сильно отличаться, и по этой причине у нас не должно быть каких-либо «проектов», подобных GitHub или GitLab, или системе Scrum Bitbucket. Я не думаю, что существует какой-либо жизнеспособный универсальный вариант, но «Проблемы» - это хороший компромисс для небольших проектов, когда можно ожидать, что не придется отслеживать огромное количество вещей.

Насколько я понимаю, Gitea сама по себе должна придерживаться проблем в стиле GitHub / Lab и предоставлять только инструменты для их решения с помощью API и веб-перехватчиков или позволять людям использовать внешние средства отслеживания проблем (что у нас уже есть!).

@ jxsl13 Я могу порекомендовать вам https://github.com/opf/openproject, который может работать с Gitea. Он поддерживает несколько рабочих процессов, и вы можете настроить gitea для использования в качестве диспетчера заявок / задач (установив URL-адрес в gitea)

@sapk спасибо, выглядит многообещающе

@sapk Я установил open-project и сменил диспетчер заявок / задач в Gitea, но у меня вопрос, есть ли связь между open-project и gitea? или только Gitea ссылка на OpenProject?

Мой вопрос в том, что я не знаю, есть ли способ связать мои проблемы с gitea с задачей openproject (код gitea, такое же количество проблем в gitea и openproject).

Спасибо за ваш ответ!

Возможно, можно более плотно связать openproject и gitea через api, но я не знаю никого, кто бы это сделал (и, возможно, потребуется некоторая корректировка кода gitea или openproject).
Я использую его в основном для расширенного управления проектами, помимо кода, размещенного в gitea.

Мне нравится подход Gitlab, позволяющий создавать "доски" scrum / kanban из ярлыков и превращать их в другое представление ... на самом деле ничего не меняется, это просто другое представление, но очень полезное IMHO.

Некоторым командам необходимо иметь встроенную доску на том же инструменте, где создаются проблемы. Было бы действительно полезно иметь такие платы, как Gitlab или Github. Я думал об идее интегрированной вкладки доски / проектов gitea, и я создал прототип этой идеи, основанный на подходе Gitlab:

На самом деле это не работает, это просто фиксированные данные, но я думаю, что визуальное оформление должно быть примерно таким. Код здесь:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

Чего-то не хватает, так это визуализации для создания / выбора досок, как в Gitlab. Было бы действительно полезно создавать доски для нескольких команд.

@rudineirk Удалось ли вам поработать над этим?

Я бы тоже хотел, чтобы это случилось! Это позволило бы многим небольшим командам напрямую и в основном работать с gitea вместо того, чтобы бороться с внешними и, возможно, сложными в настройке инструментами, такими как Taiga.io и т. Д.
С внешними инструментами такие вещи, как привязка коммитов к задачам и т. Д., Скорее всего, невозможны, это огромный плюс такого подхода! (Возможность просто указать идентификатор проблемы в вашем коммите, чтобы он появился в проблеме / заявке, это довольно круто :)

Мне очень интересна эта функция, поскольку наша команда в настоящее время использует https://taiga.io/, но реальная ценность состоит в том, чтобы иметь встроенный трекер проблем с функцией планирования канбан / схватки.

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

Я согласен с тем, что доски в стиле Канбан были бы превосходными. Еще никто не упомянул Zenhub, который предоставляет некоторые из этих функций (и многое другое) «поверх» Github.

Вот вещи, которые, я думаю, были бы действительно полезны:

• Канбан-представление проблем - это представление будет почти полностью пользовательским интерфейсом, возможно, потребуется некоторое взаимодействие с БД для отслеживания столбца и порядка проблем в столбце)
• Диаграммы Ганта - Gitea уже предоставляет сроки выполнения задач и зависимости, а также вехи, что означает, что все данные нужны для создания диаграммы Ганта, я думаю, что это будет действительно полезная функция. Существуют библиотеки, такие как mermaidjs или React Google Charts, которые, казалось бы, имеют разумную стоимость интеграции. Обратите внимание, что # 7405 тоже пригодится.
• Вехи организации - это, вероятно, самый простой способ реализовать, но так же, как у нас есть функция «Проблемы» ( /issues ) в верхней части Gitea, функция «Вехи» была бы неплохой. Другими словами, если бы я мог видеть все вехи, к которым я имею отношение, это было бы действительно круто. В настоящее время я могу просматривать только вехи в рамках одного проекта.

Несомненно, каждый из них будет отдельной особенностью. Может быть, этот комбинированный поток необходимо разделить на отдельные функции / компоненты?

Изменить: кто-то работает над zenhub, например, над плагином Chrome для gitea по адресу https://github.com/funktechno/git-kanban-enhanced-chrome-extension .

@adelowo имеет филиал здесь , чтобы люди могли бы хотеть , чтобы проверить в на. Я очень надеюсь на то, что он взламывает.

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

Ага, разницу можно посмотреть здесь https://github.com/go-gitea/gitea/compare/master...adelowo : kanban_board? Expand = 1

@adelowo, когда мы увидели пиар?

Примерно через 8-10 дней

@adelowo я получил 500, если он попытается получить _localhost / user / project_ /projects (по вашему меню):

2019/09/12 10:30:44 ...ers/repo/projects.go:62:Projects() [E] GetProjects: no such table: project

похоже, что загрузка базы данных еще не работает @ версия e7cf2b77afe50b5818c52405364faf3c914b9e63

Странно, что миграции там. Можете ли вы запустить gitea migrate ?

https://github.com/adelowo/gitea/blob/kanban_board/models/migrations/v95.go

Ничего особенного не обнаружилось:

2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column email_notifications_preference db default is ''enabled'', struct default is 'enabled'
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column passwd_hash_algo db default is ''pbkdf2'', struct default is 'pbkdf2'
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column diff_view_style db default is '''', struct default is ''
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column theme db default is '''', struct default is ''

Но:

# sqlite3 data/gitea.db .schema | grep proj
CREATE TABLE `repository` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `owner_id` INTEGER NULL, `lower_name` TEXT NOT NULL, `name` TEXT NOT NULL, `description` TEXT NULL, `website` TEXT NULL, `original_url` TEXT NULL, `default_branch` TEXT NULL, `num_watches` INTEGER NULL, `num_stars` INTEGER NULL, `num_forks` INTEGER NULL, `num_issues` INTEGER NULL, `num_closed_issues` INTEGER NULL, `num_pulls` INTEGER NULL, `num_closed_pulls` INTEGER NULL, `num_milestones` INTEGER DEFAULT 0 NOT NULL, `num_closed_milestones` INTEGER DEFAULT 0 NOT NULL, `num_projects` INTEGER DEFAULT 0 NOT NULL, `num_closed_projects` INTEGER DEFAULT 0 NOT NULL, `is_private` INTEGER NULL, `is_empty` INTEGER NULL, `is_archived` INTEGER NULL, `is_mirror` INTEGER NULL, `is_fork` INTEGER DEFAULT 0 NOT NULL, `fork_id` INTEGER NULL, `size` INTEGER DEFAULT 0 NOT NULL, `is_fsck_enabled` INTEGER DEFAULT 1 NOT NULL, `close_issues_via_commit_in_any_branch` INTEGER DEFAULT 0 NOT NULL, `topics` TEXT NULL, `avatar` TEXT NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL);
CREATE TABLE `issue` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `repo_id` INTEGER NULL, `index` INTEGER NULL, `poster_id` INTEGER NULL, `original_author` TEXT NULL, `original_author_id` INTEGER NULL, `name` TEXT NULL, `content` TEXT NULL, `milestone_id` INTEGER NULL, `project_id` INTEGER NULL, `priority` INTEGER NULL, `is_closed` INTEGER NULL, `is_pull` INTEGER NULL, `num_comments` INTEGER NULL, `ref` TEXT NULL, `deadline_unix` INTEGER NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL, `closed_unix` INTEGER NULL, `is_locked` INTEGER DEFAULT 0 NOT NULL);
CREATE INDEX `IDX_issue_project_id` ON `issue` (`project_id`);

@genofire, можешь взглянуть еще раз? Я исправил это в https://github.com/adelowo/gitea/commit/812f256cdeed312877787b383279c30c5cda9a4f

Работает для меня, спасибо - вот некоторые небольшие проблемы:

High Prio:

• [] Перемещение вопросов между досками
• [x] добавить проект к текущему выпуску
• [x] просмотреть проект

- [x] создать проект

Средний приоритет:

• [] Значок проектов (банкомат то же, что и MergeRequest)
• [] создать проблему при просмотре проекта
• [] выберите проект во время создания задачи

Низкий приоритет:

• [] переименовать доску
• [] добавить доску
• [] удалить доску
• [] переместить доску
• [] перетащите Label | Milestone рядом с поиском
• [] найдите проблему, чтобы добавить ее в проект (не проверено)

Тем не менее, вопросы можно перемещать по доскам.

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

https://github.com/go-gitea/gitea/commit/c55d44e0233f46094fbebd33feac82e5072e1ba7

Я отправил PR на https://github.com/go-gitea/gitea/pull/8346

Тем не менее, вопросы можно перемещать по доскам.

не сохраняется, перезагрузка сбрасывает его на Uncategorized

Теперь при создании задачи можно выбирать проекты.

Не показывает список проектов

Хм, посмотрю еще раз. Давайте перенесем обсуждение функций в PR, чтобы все было в одном месте.

Спасибо

комментарий нулевого значения: не могу дождаться, когда это произойдет,: shipit:: rocket:: four_leaf_clover:

Пожалуйста, помогите попробовать # 8346 и дайте больше советов.

Есть ли новости по этой проблеме? (С момента последней публикации прошел месяц.)

РЕДАКТИРОВАТЬ: Я не понимал, что некоторые люди (например, @storrgie) могут быть оскорблены людьми, интересующимися их работой. Я не хотел никого обидеть.

@tinxx вы либо:

• создайте PR, который связан чуть выше, и предоставьте обратную связь в реальном PR
• найти способ материально мотивировать людей работать над этим (например, связаться с @adelowo напрямую для пожертвования или сделать что-то вроде bountysource, чтобы привлечь больше внимания)

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

Jetbrains выпустила новую версию YouTrack с интеграцией gitea

@adelowo есть новости?

А пока еще одно предложение: канборд

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

Спрашивающие: Посмотрите, пожалуйста, на PR. Вроде не так уж и далеко

Да @gsantner . Осталось всего несколько исправлений пользовательского интерфейса. Который я должен добраться до этих выходных

@adelowo есть новости о том, когда это будет доступно?

@zuhairamahdi планируется выпустить в 1.12.0. подробнее см. # 8346 PR.

Есть ли какой-нибудь интерес, если у вас есть проблема с несколькими проектами и / или досками?

https://github.com/go-gitea/gitea/pull/8346#issuecomment -617175388

Мне нравится подход Gitlab, позволяющий создавать "доски" scrum / kanban из ярлыков и превращать их в другое представление ... на самом деле ничего не меняется, это просто другое представление, но очень полезное IMHO.

Мне тоже не хватает этой функции. Было бы здорово, если бы метки проблемы обновлялись, когда вы перемещали их на разные дорожки / доски проекта. Также было бы полезно изменить метки и, таким образом, перемещать задачи между дорожками с помощью действующих ссылок в сообщениях фиксации (например, Fixes #1 ).

@ 0xC4N1 Пришлите, пожалуйста, новый выпуск, я думаю, мы могли бы улучшить эту функцию.