Gitea: SCRUM-Backlog/Sprint-Backlog pro Projekt

Könnten Sie bitte darauf hinweisen, welche Funktionen Sie sich besonders wünschen?

In SCRUM haben Sie im Grunde ein Product-Backlog, das User Stories enthält, die nach Priorität oder nach einem vordefinierten Wert sortiert sind.
Jede User Story besteht höchstwahrscheinlich aus einem Titel, einer Beschreibung und vielleicht einem Namen für den Wert, in dem die Priorität gemessen werden soll (mehr oder weniger wie "Probleme", aber nach Priorität sortiert) sowie diesem Prioritätsfeld.
Auch ein Feld, das anzeigen könnte, ob die User-Story implementiert wurde, entfernt wurde (wegen einiger Probleme, nicht fertig oder benötigt mehr Beschreibung)

In jedem Sprint (definierter Zeitraum) nehmen die Entwickler einige User Stories aus dem Product-Backlog und fügen sie ihrem Sprint-Backlog hinzu, das neben dem P-Backlog auch aus (evtl. optionalen) Ideen besteht, wie die Entwickler lösen wollen das spezifische Problem, das durch die gewählte User-Story beschrieben wird. Jeder Entwickler kann die zugewiesene User Story jedes anderen Entwicklers sehen, aber nicht bearbeiten (evtl. nur kommentieren)
Entwickler sollten nur ihre eigenen Lösungshinweise ändern können, nicht jedoch die Beschreibung/den Titel der User Story, daher sind mindestens zwei Rollen erforderlich (Produktbesitzer und Entwickler (nicht ausschließlich))
Hat dev-1 seine zugewiesenen User Storys beendet, könnte er einen anderen dev-2 bitten, seine (andere dev-2) User Story dev-1 zuzuweisen (na ja, offen für Diskussionen an dieser Stelle).

Ist der Sprint beendet, also die Zeit abgelaufen, könnte es eine Art Übersicht über die fertigen und auch unfertigen User Stories geben.
Diese User Stories müssen zwei Phasen durchlaufen.
Die Fertigen müssen beide Phasen durchlaufen, eine davon ist das Sprint Review (zB dem Kunden die fertigen Verbesserungen zeigen) (nur fertige User Stories).
Die zweite Phase wäre die Sprint-Retrospektive, in der das Entwicklerteam einen Blick darauf wirft, was fertig und vor allem gut war und auch welche User Stories nicht fertig waren und warum nicht (in den Product Backlog verschieben).
(Vielleicht ein "Bulletin Board" mit Informationen über die Definition von "Done", was bedeutet, wann eine User Story als erledigt zu betrachten ist und einige Dinge zur Prozessoptimierung)

Einige Funktionen zum Starten eines neuen Sprints und möglicherweise basierend auf dem normalen Problemsystem könnte der Product Owner diese Vorschläge aufnehmen und in User Stories umwandeln, indem er Prioritäten, detailliertere Beschreibungen usw. hinzufügt.

Ich weiß nicht, was besser wäre, das bestehende Issue-System zu verwenden und es als Input für den Product Owner zu verwenden, um das Scrum-Zeug ausschließlich zu übernehmen oder zu verwenden, das normale Issue-System auszuschließen und das Scrum-Zeug als eigenes Problem zu sehen System.

TLDR: D
Im Allgemeinen müssen zwei Rollen vorhanden sein, eine als Produktverantwortlicher (standardmäßig Projektverantwortlicher mit der Möglichkeit, die Rollen durch den ersten Produkt-/Projektbesitzer zu ändern) und die andere als Entwickler.
Außerdem wird ein Sprint benötigt, der eine definierte (Product Owner?) Dauer und einen Mechanismus zum Starten eines Sprints hat. Der Start eines Sprints macht keinen Sinn, wenn nichts im Sprint-Backlog steht, daher die Notwendigkeit eines Sprint-Backlogs mit zugewiesenen(?)(vielleicht kann jeder der Entwickler die Zuweisungen ändern) User Stories, die nicht geändert, aber kommentiert werden können( ein klebriger Kommentar mit Unterkommentaren?).
Jeder Entwickler muss in der Lage sein (nur innerhalb eines Sprints? oder wann immer es ihm beliebt?)
Wenn der Sprint zu Ende geht, sollte der Status des "Issue Trackers" seinen Status in die Review-Phase ändern und nur fertige User Stories anzeigen (Und nur der klebrige Entwicklerkommentar? Keine Kommentare? Alle Kommentare?). (Welche Zustände brauchen wir? : Vorschlag: Planung, Sprint, Review, Retrospektive)
Dann sollte der Product Owner(?) in der Lage sein, den Zustand in die Retrospektive zu ändern, wo vielleicht das "Schwarze Brett" mit Vorschlägen, Mustern, Good Practices, Bad Practices usw. sowie allen, fertigen und unfertigen User Stories sollte wieder sichtbar sein.
Nach dieser Phase sollte der Product Owner(?) in der Lage sein, die Phase in die nächste Phase zu wechseln, Planung, in der unfertige User Stories (?) zurück ins Product Backlog gehen und fertige User Stories entweder archiviert oder gelöscht werden (um nicht zu mit dem Finger auf Personen zeigen, wenn danach ein Fehler gefunden wird).
Und in der Planungsphase kann das Entwicklerteam die User Stories wieder seinem Sprint-Backlog hinzufügen.
Und nach diesem Schritt muss irgendwie ein Sprint gestartet werden, vielleicht vom Product Owner.

Viel Spaß beim diskutieren (hoffe ich)

User Stories könnten auch alle Eigenschaften haben, die ein Issue im normalen Issue Tracker hat, zB Tags und so weiter.

Dies wurde bereits in #805 besprochen. Persönlich denke ich, dass sich der Arbeitsablauf von Teams stark unterscheiden kann, und aus diesem Grund sollten wir keine "Projekte"-Funktion ähnlich der von GitHub oder GitLab oder dem Scrum-System von Bitbucket haben. Ich glaube nicht, dass es eine praktikable Einheitsgröße gibt, aber Issues sind ein guter Kompromiss für kleine Projekte, bei denen man erwarten kann, nicht eine große Menge an Dingen im Auge zu behalten.

Gitea selbst sollte meiner Meinung nach an GitHub/Lab-artigen Problemen festhalten und nur Tools bereitstellen, um diese mithilfe von APIs und Webhooks zu lösen, oder es den Leuten ermöglichen, externe Issue-Tracker zu verwenden (was wir bereits haben!).

@jxsl13 Ich kann dir https://github.com/opf/openproject empfehlen, das mit Gitea funktionieren kann. Es unterstützt mehrere Workflows und Sie können gitea so einrichten, dass es als Ticket- / Issue-Manager verwendet wird (indem Sie die URL in gitea festlegen).

@sapk danke, sieht recht vielversprechend aus

@sapk Ich habe Open-Project installiert und den Ticket- / Issue-Manager bei Gitea geändert, aber ich habe eine Frage, gibt es eine Beziehung zwischen Open-Project und Gitea? oder nur Gitea-Link zu OpenProject?

Meine Frage ist, weil ich nicht weiß, ob es eine Möglichkeit gibt, meine gitea-Probleme mit der Openproject-Aufgabe zu verknüpfen (der Code von gitea, die gleiche Nummer von Problemen in gitea und openproject).

Danke für deine Antwort!

Es ist vielleicht möglich, per API enger zwischen openproject und gitea zu verlinken, aber ich kenne niemanden, der es so gemacht hat (und möglicherweise eine Anpassung des gitea- oder openproject-Codes erforderlich macht).
Ich verwende es hauptsächlich für erweitertes Projektmanagement, abgesehen von Code, der in gitea gehostet wird.

Ich mag den Gitlab-Ansatz, Scrum/Kanban "Boards" aus Labels zu erstellen und sie in eine andere Ansicht zu verwandeln...nichts ändert sich wirklich, es ist nur eine andere Ansicht, aber eine sehr nützliche IMHO.

Für einige Teams, die ein integriertes Board auf demselben Tool haben, in dem die Issues erstellt werden, ist dies ein Muss. Es wäre wirklich nützlich, Boards wie Gitlab oder Github zu haben. Ich habe mit der Idee eines integrierten Boards / Projects-Tabs von gitea nachgedacht und einen Prototyp der Idee erstellt, der auf dem Gitlab-Ansatz basiert:

Es funktioniert nicht wirklich, es sind nur feste Daten, aber ich denke, das Visual sollte so ähnlich sein. Der Code ist hier:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

Etwas, das fehlt, ist das Visual zum Erstellen/Auswählen von Boards, wie es Gitlab hat. Es wäre wirklich nützlich, Boards für mehrere Teams erstellen zu können.

@rudineirk Konnten Sie daran arbeiten?

Das würde ich auch gerne sehen! Es würde vielen kleinen Teams ermöglichen, direkt und primär mit gitea zu arbeiten, anstatt sich mit externen und möglicherweise schwer einzurichtenden Tools wie Taiga.io usw.
Mit externen Tools sind Dinge wie das Verlinken von Commits zu Issues etc. wahrscheinlich nicht möglich, das ist ein großer Vorteil dieses Ansatzes! (In der Lage zu sein, einfach die Issue-ID in Ihrem Commit zu erwähnen, damit sie im Issue / Ticket angezeigt wird, ist ziemlich cool :)

Ich bin wirklich an dieser Funktion interessiert, da unser Team derzeit https://taiga.io/ verwendet, aber der wahre Wert besteht darin, einen integrierten Issue-Tracker mit Kanban-/Scrum-Planungsfunktionalität zu haben.

Ich denke, dass es viele Dinge zu lernen gibt von der GitHub-Implementierung, die ursprünglich genau wie gitea begann. Ihre Implementierung ist generisch genug, um es Benutzern zu ermöglichen, sie sowohl für Scrums als auch für Kanbans zu verwenden, auch wenn sie keine Ahnung haben, was ein Sprint ist. Wenn die Leute Spalten definieren und Karten ziehen und ablegen können, werden sie wahrscheinlich einen Weg finden, die Planung damit durchzuführen.

Hiermit meine Zustimmung, dass Boards im Kanban-Stil ausgezeichnet wären. Niemand hat Zenhub bisher erwähnt, das mehrere dieser Funktionen (und mehr) "over the top" von Github bietet.

Hier sind die Dinge, die ich für sehr nützlich halte:

• Kanban-Ansicht von Problemen – diese Ansicht wäre fast ausschließlich eine Benutzeroberfläche, würde wahrscheinlich einige DB-Interaktionen benötigen, um die Spalte und die Reihenfolge eines Problems in einer Spalte zu verfolgen)
• Gantt-Diagramme – Gitea bietet bereits Fälligkeitstermine und Abhängigkeiten sowie Meilensteine, was bedeutet, dass alle Daten vorhanden sind, um ein Gantt-Diagramm zu erstellen. Ich denke, dies wäre eine wirklich hilfreiche Funktion. Es gibt Bibliotheken wie mermaidjs oder React Google Charts, die anscheinend einen vernünftigen Integrationskosten haben. Beachten Sie, dass #7405 auch hierfür hilfreich wäre.
• Meilensteine ​​der Organisation – Dies ist wahrscheinlich am einfachsten zu implementieren, aber genau wie wir die Funktion "Issues" ( /issues ) oben in Gitea haben, wäre eine Milestones-Funktion schön. Mit anderen Worten, wenn ich alle Meilensteine ​​sehen könnte, mit denen ich zu tun habe, wäre das wirklich cool. Derzeit kann ich nur Meilensteine ​​innerhalb eines einzelnen Projekts anzeigen.

Zweifellos wäre jeder von ihnen ein eigenständiges Merkmal. Vielleicht muss dieser kombinierte Thread in die einzelnen Funktionen/Komponenten aufgeteilt werden?

Bearbeiten: Jemand arbeitet an einem Zenhub-ähnlichen Chrome-Plugin für gitea unter https://github.com/funktechno/git-kanban-enhanced-chrome-extension .

@adelowo hat hier eine Filiale, in die die Leute vielleicht einchecken möchten. Ich bin ziemlich hoffnungsvoll für das, woran er hackt.

Angesichts der Einfachheit des Hostens einer Instanz würde ich es begrüßen, wenn mehr PM-Tools ihren Weg in gitea finden würden, aber ich würde mich sehr freuen, im Laufe des nächsten Jahres oder so Workboards in gitea erstellen zu können. Ich denke, wenn die Leute PM-Sachen hart treffen wollen, können sie sich jetzt der Taiga oder Alternativen zuwenden und _glücklich genug_ sein.

Yup, das Diff kann hier eingesehen werden https://github.com/go-gitea/gitea/compare/master...adelowo :kanban_board?expand=1

@adelowo wann könnten wir eine PR sehen?

In etwa 8-10 Tagen

@adelowo Ich habe eine 500, wenn es versucht, _localhost/user/project_ /projects (über Ihr Menü) zu erhalten:

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

sieht so aus, als ob der Datenbank-Bootstrap noch nicht funktioniert @ version e7cf2b77afe50b5818c52405364faf3c914b9e63

Das ist seltsam, dass die Migrationen da sind. Können Sie gitea migrate ausführen?

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

Es wurde nichts besonderes angezeigt:

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 ''

Aber:

# 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 kannst du nochmal nachschauen? Ich habe es in https://github.com/adelowo/gitea/commit/812f256cdeed312877787b383279c30c5cda9a4f behoben

Funktioniert bei mir, thx - hier ein paar kleine Probleme:

Hohe Priorität:

• [ ] Probleme zwischen Boards verschieben
• [x] Projekt zur aktuellen Ausgabe hinzufügen
• [x] Projekt ansehen

- [x] Projekt erstellen

Mittlere Priorität:

• [ ] Projektsymbol (ATM gleich dann MergeRequest)
• [ ] Problem beim Anzeigen des Projekts erstellen
• [ ] Projekt während der Erstellung des Problems auswählen

Niedrige Priorität:

• [ ] Board umbenennen
• [ ] Board hinzufügen
• [ ] Board entfernen
• [ ] Brett verschieben
• [ ] füge Label | Milestone neben die Suche ein
• [ ] Suche nach Issue, um sie zu Project hinzuzufügen (ungetestet)

Probleme können jedoch übergreifend verschoben werden.

Danke für diese Liste. Projekte können jetzt beim Erstellen eines Problems ausgewählt werden. Bitte ziehen Sie spätestens

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

Ich habe eine PR eingereicht unter https://github.com/go-gitea/gitea/pull/8346

Probleme können jedoch übergreifend verschoben werden.

nicht gespeichert, ein Neuladen setzt es auf Uncategorized

Projekte können jetzt beim Erstellen eines Problems ausgewählt werden.

Zeigt keine Projektliste an

Hm, ich schau nochmal nach. Lassen Sie uns die Featurediskussion in die PR verschieben, damit alles an einem Ort ist.

Vielen Dank

Nullwert Kommentar: kann es kaum erwarten, :shipit: :rocket: :four_leaf_clover:

Bitte helfen Sie, #8346 auszuprobieren und geben Sie weitere Ratschläge.

Gibt es ein Update zu diesem Thema? (Der letzte Beitrag ist einen Monat her.)

EDIT: Ich wusste nicht, dass einige Leute (wie @storrgie) von Leuten, die sich für ihre Arbeit interessieren, beleidigt sein könnten. Ich wollte niemanden beleidigen.

@tinxx du entweder:

• bauen Sie die oben verlinkte PR auf und geben Sie Feedback in der eigentlichen PR
• einen Weg finden, die Leute finanziell zu motivieren, daran zu arbeiten (z. B. wenden Sie sich direkt an

Sie fordern nicht, dass Arbeit erledigt wird, wenn Sie weder finanziell noch intellektuell dazu beitragen, das ist bei Open Source giftig.

Jetbrains hat gerade eine neue Version von YouTrack mit gitea-Integration veröffentlicht

@adelowo irgendwelche Neuigkeiten?

In der Zwischenzeit noch ein Vorschlag: Kanboard

Es ist nicht gerade eine Augenweide (out of the box), aber es ist schnell und bietet genug Funktionen, um sehr nützlich zu sein.

Fragesteller: Schaut euch bitte die PR an. Scheint nicht so weit weg zu sein :wink:

Ja @gsantner . Nur noch ein paar UI-Fixes übrig. Was ich dieses Wochenende erreichen sollte

@adelowo Gibt es Neuigkeiten, wann dies verfügbar sein wird?

@zuhairamahdi es ist geplant, in 1.12.0 veröffentlicht zu werden. siehe #8346 PR für mehr.

Gibt es Interesse an einem Problem mit mehreren Projekten und/oder Boards?

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

Ich mag den Gitlab-Ansatz, Scrum/Kanban "Boards" aus Labels zu erstellen und sie in eine andere Ansicht zu verwandeln...nichts ändert sich wirklich, es ist nur eine andere Ansicht, aber eine sehr nützliche IMHO.

Diese Funktion vermisse ich auch. Es wäre großartig, wenn die Beschriftungen eines Problems aktualisiert würden, wenn Sie sie auf andere Lanes / Projektboards verschieben. Das Ändern von Labels und damit das Verschieben von Issues zwischen Lanes durch umsetzbare Referenzen in Commit-Nachrichten (zB Fixes #1 ) wäre ebenfalls nützlich.

@0xC4N1 Bitte senden Sie eine neue Ausgabe, ich denke, wir könnten mehr Verbesserungen an dieser Funktion haben.