Gitea: Backlog SCRUM/backlog de sprint par projet

Pourriez-vous s'il vous plaît indiquer quelles fonctionnalités vous souhaitez particulièrement?

Dans SCRUM, vous avez essentiellement un Product-Backlog, contenant des User Stories, qui sont triées par priorité ou par une valeur prédéfinie.
Chaque User Story se compose très probablement d'un titre, d'une description et peut-être d'un nom pour la valeur dans laquelle mesurer la priorité (plus ou moins comme des "problèmes", mais triés par priorité) ainsi que de ce champ de priorité.
Également un champ, qui pourrait indiquer si la User-Story a été implémentée, supprimée (en raison de certains problèmes, non terminée ou nécessite plus de description)

À chaque Sprint (période de temps définie), les développeurs prennent des histoires d'utilisateurs du Product-Backlog et les ajoutent à leur Sprint-Backlog, qui, à part le P-Backlog, comprend également des idées (peut-être facultatives) sur la façon dont les développeurs veulent résoudre le problème spécifique, qui est décrit par leur User-Story choisie. Chaque développeur peut voir la user story attribuée à chaque autre développeur, mais ne peut pas la modifier (peut-être seulement la commenter)
Les développeurs ne devraient pouvoir modifier que leurs propres notes de solution, mais pas la description/le titre de la user story, d'où la nécessité d'au moins deux rôles (product owner et développeur (non exclusif))
Si le dev-1 a terminé ses user stories, il pourrait demander à un autre dev-2 d'attribuer sa (autre dev-2)user story à dev-1 (enfin, ouvert aux discussions à ce stade).

Le sprint est-il terminé, ce qui signifie que le temps est écoulé, il pourrait y avoir une sorte d'aperçu des user stories terminées et aussi inachevées.
Ces user stories doivent passer par deux phases.
Les versions terminées doivent passer par les deux phases, l'une est la revue Sprint (par exemple, montrer au client les améliorations finies) (uniquement les user stories finies).
La deuxième phase serait la rétrospective Sprint, où l'équipe de développement jette un œil à ce qui a été fini et surtout, ce qui était bien dans le processus, et aussi quelles histoires d'utilisateurs n'étaient pas terminées et pourquoi pas (en les déplaçant vers le backlog du produit)
(Peut-être un "tableau d'affichage" avec des informations sur la définition de "Terminé", ce qui signifie quand considérer une user story comme terminée et quelques trucs d'optimisation de processus)

Certaines fonctionnalités pour lancer un nouveau sprint et peut-être sur la base du système d'émission normal, le propriétaire du produit pourrait prendre ces suggestions et les convertir en histoires d'utilisateurs, en ajoutant une priorité, une description plus détaillée, etc.

Je ne sais pas ce qui serait mieux, d'utiliser le système de problème existant et de l'utiliser comme entrée pour que le propriétaire du produit prenne ou utilise exclusivement les trucs de Scrum, à l'exclusion du système de problème normal et de voir les trucs de Scrum comme un problème propre système.

TLDR :D
En général, il doit y avoir deux rôles, l'un étant le propriétaire du produit (par défaut le propriétaire du projet avec la possibilité de changer les rôles par le premier propriétaire du produit/projet) et l'autre étant celui des développeurs.
De plus, un sprint est nécessaire, qui a une durée définie (product owner ?) et un mécanisme pour lancer un sprint. Le lancement d'un sprint n'a aucun sens s'il n'y a rien dans le backlog de sprint, donc le besoin d'un backlog de sprint contenant des user stories assignées (?) un commentaire collant avec des sous-commentaires ?).
Chaque développeur doit être capable (uniquement au cours d'un sprint ? ou quand il le souhaite ?)
Lorsque le sprint arrive à la fin, l'état du « traqueur de problèmes » devrait changer d'état pour passer à la phase de révision, ne montrant que les histoires d'utilisateurs terminées (et seulement le commentaire du développeur collant ? pas de commentaires ? tous les commentaires ?). (De quels états devrions-nous avoir besoin ? : suggestion : planning, sprint, revue, rétrospective)
Ensuite, le propriétaire du produit (?) devrait pouvoir changer l'état en rétrospective, où peut-être le "bulletin board" avec des suggestions, des modèles, des bonnes pratiques, des mauvaises pratiques, etc. ainsi que toutes les histoires d'utilisateurs terminées et inachevées devrait être à nouveau visible.
Après cette phase, le propriétaire du produit (?) devrait pouvoir passer à la phase suivante, la planification, où les user stories inachevées devraient (?) revenir au backlog du produit et les user stories terminées archivées ou supprimées (afin de ne pas pointer du doigt les gens, quand un bug est trouvé par la suite).
Et dans la phase de planification, l'équipe de développement peut ajouter à nouveau les user stories à son backlog de sprint.
Et après cette étape, un sprint doit être lancé, peut-être par le propriétaire du produit.

Amusez-vous à discuter (j'espère)

Les user stories peuvent également avoir toutes les propriétés d'un problème dans le suivi des problèmes normal, par exemple des balises, etc.

Cela a déjà été discuté dans #805. Personnellement, je pense que le flux de travail des équipes peut grandement différer, et pour cette raison, nous ne devrions pas avoir de fonctionnalité "projets" similaire à GitHub ou GitLab, ou au système Scrum de Bitbucket. Je ne pense pas qu'il existe de solution unique viable, mais les problèmes sont un bon compromis pour les petits projets où l'on peut s'attendre à ne pas avoir une énorme quantité de choses à suivre.

Gitea en lui-même devrait, en ce qui me concerne, s'en tenir aux problèmes de style GitHub/Lab et ne fournir que des outils pour les traiter à l'aide d'API et de webhooks, ou permettre aux gens d'utiliser des outils de suivi des problèmes externes (quelque chose que nous avons déjà !).

@jxsl13 Je peux vous recommander https://github.com/opf/openproject qui peut fonctionner avec Gitea. Il prend en charge plusieurs flux de travail et vous pouvez configurer gitea pour l'utiliser comme gestionnaire de tickets/problèmes (en définissant l'url dans gitea)

@sapk merci, ça a l'air très prometteur

@sapk J'ai installé open-project et changé le gestionnaire de tickets/issues chez Gitea mais j'ai une question, y a-t-il une relation entre open-project et gitea ? ou seulement un lien Gitea vers OpenProject ?

Ma question est parce que je ne sais pas s'il existe un moyen de relier mes problèmes de gitea avec la tâche openproject (le code de gitea, le même nombre de problèmes dans gitea et openproject).

Merci pour votre réponse!

Il est peut-être possible de faire un lien plus étroit entre openproject et gitea via api mais je ne connais personne qui l'a fait (et peut nécessiter un ajustement au code gitea ou openproject).
Je l'utilise principalement pour faire de la gestion de projet avancée en dehors du code hébergé dans gitea.

J'aime l'approche Gitlab qui permet de créer des "tableaux" scrum/kanban à partir d'étiquettes et de les transformer en une vue différente... rien ne change vraiment, c'est juste une vue différente, mais très utile à mon humble avis.

Pour certaines équipes, avoir un tableau intégré sur le même outil où les problèmes sont créés est un must. Il serait vraiment utile d'avoir des cartes comme Gitlab ou Github. Je réfléchissais à l'idée d'un onglet conseil/projets intégré à gitea, et j'ai créé un prototype de l'idée, il est basé sur l'approche Gitlab :

Cela ne fonctionne pas vraiment, ce ne sont que des données fixes, mais je pense que le visuel devrait être quelque chose de similaire à celui-ci. Le code est ici :
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

Quelque chose qui manque est le visuel pour créer/sélectionner des tableaux, comme Gitlab l'a fait. Il serait vraiment utile de pouvoir créer des tableaux pour plusieurs équipes.

@rudineirk Avez-vous pu travailler dessus ?

J'aimerais que cela se produise aussi ! Cela permettrait à de nombreuses petites équipes de travailler directement et principalement avec gitea au lieu de se débattre avec des outils externes et éventuellement difficiles à mettre en place comme Taiga.io, etc.
Avec des outils externes, des choses comme lier des commits à des problèmes, etc. ne sont probablement pas possibles, c'est un énorme bonus de cette approche ! (Pouvoir simplement mentionner l'ID du problème dans votre commit pour le faire apparaître dans le problème/ticket est plutôt cool :)

Je suis vraiment intéressé par cette fonctionnalité car notre équipe utilise actuellement https://taiga.io/ mais la vraie valeur est d'avoir un outil de suivi des problèmes intégré avec une fonctionnalité de planification kanban/scrum.

Je pense qu'il y a beaucoup de choses à apprendre de l'implémentation de GitHub qui a commencé à l'origine exactement comme gitea. Leur implémentation est suffisamment générique pour permettre aux utilisateurs de l'utiliser à la fois pour les scrums et les kanbans, même s'ils n'ont aucune idée de ce qu'est un sprint. Si les gens peuvent définir des colonnes et faire glisser et déposer des cartes, ils trouveront probablement un moyen de planifier avec.

Je suis d'accord ici pour dire que les planches de style Kanban seraient excellentes. Personne n'a encore mentionné Zenhub, qui fournit plusieurs de ces fonctionnalités (et plus) "au-dessus" de Github.

Voici les choses qui, je pense, seraient vraiment utiles:

• Vue Kanban des problèmes - cette vue serait presque entièrement une interface utilisateur, aurait probablement besoin d'une interaction avec la base de données pour suivre la colonne et l'ordre d'un problème dans une colonne)
• Diagrammes de Gantt - Gitea fournit déjà des dates d'échéance et des dépendances ainsi que des jalons, ce qui signifie que toutes les données sont là pour générer un diagramme de Gantt, je pense que ce serait une fonctionnalité vraiment utile. Il existe des bibliothèques comme mermaidjs ou React Google Charts qui semblent avoir un coût d'intégration raisonnable. Notez que #7405 serait également utile pour cela.
• Jalons d'organisation - C'est probablement le plus simple à mettre en œuvre, mais tout comme nous avons la fonctionnalité "Problèmes" ( /issues ) en haut de Gitea, une fonctionnalité Jalons serait bien. En d'autres termes, si je pouvais voir tous les jalons auxquels je suis lié, ce serait vraiment cool. Actuellement, je ne peux afficher que les jalons d'un même projet.

Sans aucun doute, chacun de ceux-ci serait une caractéristique à part entière. Peut-être que ce fil combiné doit être divisé en fonctionnalités/composants individuels ?

Edit: quelqu'un travaille sur un plugin zenhub comme Chrome pour gitea à https://github.com/funktechno/git-kanban-enhanced-chrome-extension .

@adelowo a une succursale ici que les gens voudront peut-être vérifier. J'ai bon espoir pour ce qu'il pirate.

J'aimerais voir plus d'outils de type PM faire leur chemin dans gitea étant donné la simplicité d'hébergement d'une instance, mais je serais extrêmement heureux de pouvoir créer des tableaux de travail dans gitea au cours de la prochaine année. Je pense que si les gens veulent frapper fort les trucs de PM, ils peuvent se tourner vers la taïga ou des alternatives dès maintenant et être _assez heureux_.

Oui, le diff peut être consulté ici https://github.com/go-gitea/gitea/compare/master...adelowo :kanban_board?expand=1

@adelowo quand on pouvait voir un PR ?

Dans environ 8-10 jours

@adelowo j'ai un 500 s'il essaie d'obtenir _localhost/user/project_ /projects (par votre menu):

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

on dirait que le bootstrap de la base de données ne fonctionne pas encore @ version e7cf2b77afe50b5818c52405364faf3c914b9e63

C'est bizarre les migrations sont là. Pouvez-vous exécuter gitea migrate ?

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

Rien de spécial ne s'affiche :

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

Mais:

# 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 pouvez-vous jeter un nouveau coup d'œil? Je l'ai corrigé dans https://github.com/adelowo/gitea/commit/812f256cdeed312877787b383279c30c5cda9a4f

Fonctionne pour moi, merci - voici quelques petits problèmes :

Priorité élevée :

• [ ] Déplacer les problèmes entre les conseils
• [x] ajouter le projet au problème actuel
• [x] voir le projet

- [x] créer un projet

Priorité moyenne :

• [ ] Icône de projets (ATM identique à MergeRequest)
• [ ] créer un problème lors de la visualisation du projet
• [ ] sélectionnez le projet lors de la création du problème

Faible priorité :

• [ ] renommer le tableau
• [ ] ajouter un tableau
• [ ] supprimer le tableau
• [ ] déplacer le tableau
• [ ] déposez Label | Milestone à côté de Rechercher
• [ ] recherchez le problème pour les ajouter au projet (non testé)

Cependant, les problèmes peuvent être déplacés d'un conseil à l'autre.

Merci pour cette liste. Les projets peuvent désormais être sélectionnés lors de la création d'un problème. Veuillez tirer le dernier

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

J'ai soumis un PR à https://github.com/go-gitea/gitea/pull/8346

Cependant, les problèmes peuvent être déplacés d'un conseil à l'autre.

n'est pas stocké, un rechargement le réinitialise à Uncategorized

Les projets peuvent désormais être sélectionnés lors de la création d'un problème.

N'affiche pas la liste des projets

Hum, je vais revoir. Déplaçons la discussion sur les fonctionnalités vers le PR afin que tout soit au même endroit.

Merci

commentaire de valeur zéro : j'ai hâte que cela se produise, :shipit: :rocket: :four_leaf_clover:

S'il vous plaît, aidez-nous à essayer #8346 et donnez plus de conseils.

Y a-t-il une mise à jour sur ce problème? (Cela fait un mois depuis le dernier message.)

EDIT : je ne savais pas que certaines personnes (comme @storrgie) pouvaient être offensées par des personnes intéressées par leur travail. Je ne voulais offenser personne.

@tinxx vous soit :

• construire le PR qui est lié juste au-dessus et fournir des commentaires dans le PR réel
• trouver un moyen de motiver financièrement les gens à travailler sur cela (par exemple, contactez @adelowo directement pour un don ou faites quelque chose comme bountysource pour avoir plus d'yeux dessus)

vous ne réclamez pas du travail à faire quand vous ne contribuez pas financièrement ou intellectuellement, c'est toxique en open source.

Jetbrains vient de publier une nouvelle version de YouTrack avec l'intégration de gitea

@adelowo des nouvelles ?

Une autre suggestion en attendant : kanboard

Ce n'est pas exactement un régal pour les yeux (hors de la boîte) mais il est rapide et offre suffisamment de fonctionnalités pour être très utile.

Interrogateurs : Veuillez consulter le PR. On dirait que ce n'est pas si loin :wink:

Ouais @gsantner . Il ne reste que quelques correctifs d'interface utilisateur. Ce que je devrais faire ce week-end

@adelowo des nouvelles sur quand cela sera-t-il disponible?

@zuhairamahdi, il est prévu de sortir en 1.12.0. voir #8346 PR pour plus.

Y a-t-il un intérêt à avoir un problème sur plusieurs projets et/ou tableaux ?

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

J'aime l'approche Gitlab qui permet de créer des "tableaux" scrum/kanban à partir d'étiquettes et de les transformer en une vue différente... rien ne change vraiment, c'est juste une vue différente, mais très utile à mon humble avis.

Il me manque aussi cette fonctionnalité. Ce serait formidable si les étiquettes d'un problème étaient mises à jour lorsque vous les déplacez vers différentes voies / tableaux de projet. Changer les étiquettes et donc déplacer les problèmes entre les voies par des références exploitables dans les messages de validation (c'est- Fixes #1 dire

@ 0xC4N1 Veuillez envoyer un nouveau problème, je pense que nous pourrions avoir plus d'améliorations sur cette fonctionnalité.