Gitea: SCRUM backlog / sprint backlog por projeto

Você poderia indicar quais recursos você deseja especialmente?

No SCRUM você tem basicamente um Product-Backlog, contendo User Stories, que são classificados por prioridade ou por algum valor predefinido.
Cada história de usuário consiste provavelmente em um título, uma descrição e talvez um nome para o valor no qual medir a prioridade (mais ou menos como "problemas", mas classificado por prioridade), bem como esse campo de prioridade.
Também um campo, que pode indicar se o User-Story foi implementado, removido (devido a alguns problemas, não foi concluído ou precisa de mais descrição)

Em cada Sprint (período de tempo definido), os desenvolvedores pegam algumas histórias de usuário do Product-Backlog e as adicionam ao Sprint-Backlog, que além do P-Backlog também consiste em (talvez opcionais) ideias de como os desenvolvedores desejam resolver o problema específico, que é descrito por sua história de usuário escolhida. Cada desenvolvedor pode ver a história de usuário atribuída a cada outro desenvolvedor, mas não pode editá-la (talvez apenas comentar)
Os desenvolvedores devem ser capazes de modificar apenas suas próprias notas de solução, mas não a descrição / título da história do usuário, portanto, a necessidade de pelo menos duas funções (proprietário do produto e desenvolvedor (não exclusivo))
Depois que o dev-1 terminou suas histórias de usuário atribuídas, ele poderia pedir a outro dev-2 para atribuir sua (outro dev-2) história de usuário ao dev-1 (bem, aberto para discussões neste momento).

Se o sprint terminou, ou seja, o tempo acabou, pode haver algum tipo de visão geral das histórias de usuário finalizadas e também inacabadas.
Essas histórias de usuário precisam passar por duas fases.
Os concluídos precisam passar por ambas as fases, uma é a revisão do Sprint (por exemplo, mostrando ao cliente as melhorias concluídas) (apenas histórias de usuários concluídas).
A segunda fase seria a retrospectiva da Sprint, onde a equipe de desenvolvimento dá uma olhada no que foi concluído e, principalmente, o que foi bom no processo, e também quais histórias de usuário não foram concluídas e por que não (movendo-as para o product backlog)
(Talvez algum "quadro de avisos" com informações sobre a definição de "Concluído", ou seja, quando considerar uma história de usuário como concluída e algumas coisas de otimização de processo)

Alguma funcionalidade para iniciar um novo sprint e talvez com base no sistema de problemas normal, o proprietário do produto poderia pegar essas sugestões e convertê-las em histórias de usuário, adicionando prioridade, descrição mais detalhada etc.

Não sei o que seria melhor, usar o sistema de problema existente e usá-lo como entrada para o proprietário do produto tirar ou usar o material do scrum exclusivamente, excluindo o sistema de problema normal e ver o material do scrum como um problema próprio sistema.

TLDR: D
Em geral, precisa haver duas funções, uma sendo o proprietário do produto (por padrão, o proprietário do projeto com a possibilidade de alterar as funções pelo primeiro produto / proprietário do projeto) e a outra sendo os desenvolvedores.
Além disso, é necessário um Sprint, que tem uma duração definida (product owner?) E algum mecanismo para iniciar um sprint. Iniciar um sprint não faz sentido se não houver nada no backlog do sprint, portanto, a necessidade de um backlog do sprint contendo histórias de usuário atribuídas (?) (Talvez todos os desenvolvedores possam alterar as atribuições), que não podem ser alteradas, mas comentadas ( um comentário fixo com subcomentários?).
Todo desenvolvedor precisa ser capaz (apenas dentro de um sprint? Ou sempre que quiser?) De alterar o status de uma história de usuário de inacabada para concluída (a questão é: que tipo de estados uma história de usuário pode ter?)
Quando o sprint chega ao fim, o estado do "rastreador de problemas" deve mudar seu estado para a fase de revisão, mostrando apenas as histórias de usuário finalizadas (e apenas o comentário fixo do desenvolvedor? Sem comentários? Todos os comentários?). (Quais estados devemos precisar?: Sugestão: planejamento, sprint, revisão, retrospectiva)
Em seguida, o product owner (?) Deve ser capaz de mudar o estado para a retrospectiva, onde talvez o "quadro de avisos" com sugestões, padrões, boas práticas, práticas ruins, etc., bem como todas as histórias de usuários concluídas e inacabadas deve estar visível novamente.
Após esta fase, o proprietário do produto (?) Deve ser capaz de mudar a fase para a próxima, planejamento, onde as histórias de usuário inacabadas devem (?) Voltar para o backlog do produto e histórias de usuário finalizadas arquivadas ou excluídas (para não apontar o dedo para as pessoas, quando um bug for encontrado posteriormente).
E na fase de planejamento, a equipe de desenvolvimento pode adicionar as histórias de usuário novamente ao backlog do sprint.
E depois dessa etapa, de alguma forma, um sprint precisa ser iniciado, talvez pelo product owner.

Divirta-se discutindo (espero)

As histórias de usuário também podem ter todas as propriedades de um problema no rastreador de problemas normal, por exemplo, tags e assim por diante.

Isso já foi discutido em # 805. Pessoalmente, acho que o fluxo de trabalho das equipes pode ser muito diferente, e por esse motivo não devemos ter nenhum recurso de "projetos" semelhante ao GitHub ou GitLab, ou ao sistema Scrum do Bitbucket. Não acho que haja um tamanho único viável, mas os problemas são um bom meio-termo para pequenos projetos em que se pode esperar não ter uma grande quantidade de coisas para controlar.

Gitea por si só deve, no que me diz respeito, limitar-se aos problemas do estilo GitHub / Lab e apenas fornecer ferramentas para lidar com eles usando APIs e webhooks, ou permitir que as pessoas usem rastreadores de problemas externos (algo que já temos!).

@ jxsl13 Posso recomendar https://github.com/opf/openproject que pode trabalhar junto com o Gitea. Ele oferece suporte a vários fluxos de trabalho e você pode configurar o gitea para usá-lo como seu gerenciador de tíquete / problema (definindo o url no gitea)

@sapk obrigado, parece bastante promissor

@sapk Instalei o open-project e mudei o gerenciador de tíquetes / problemas no Gitea, mas tenho uma dúvida, há alguma relação entre o open-project e o gitea? ou apenas link Gitea para OpenProject?

Minha dúvida é porque não sei se existe alguma forma de relacionar meus problemas do gitea com a tarefa openproject (o código do gitea, o mesmo número de problemas no gitea e openproject).

Obrigado pela sua resposta!

Talvez seja possível vincular mais estreitamente entre openproject e gitea via api, mas não conheço ninguém que tenha feito isso (e talvez exija algum ajuste para o código gitea ou openproject).
Eu o uso principalmente para fazer gerenciamento avançado de projetos, além do código hospedado no gitea.

Eu gosto da abordagem do Gitlab de permitir a criação de "painéis" scrum / kanban de rótulos e transformá-los em uma visão diferente ... nada muda realmente, é apenas uma visão diferente, mas muito útil IMHO.

Para algumas equipes, é imprescindível ter um quadro integrado na mesma ferramenta onde as questões são criadas. Seria muito útil ter placas como o Gitlab ou o Github. Eu estava pensando com a ideia de uma guia integrada de placa / projetos do gitea e criei um protótipo da ideia, é baseado na abordagem do Gitlab:

Não está realmente funcionando, são apenas dados fixos, mas acho que o visual deveria ser algo parecido com isso. O código está aqui:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

O que falta é o visual para criar / selecionar placas, como fez o Gitlab. Seria muito útil poder criar painéis para várias equipes.

@rudineirk Você conseguiu trabalhar nisso?

Eu gostaria de ver isso acontecer também! Isso permitiria que muitas equipes pequenas trabalhassem direta e principalmente com o gitea, em vez de lutar com ferramentas externas e possivelmente difíceis de configurar, como Taiga.io, etc.
Com ferramentas externas, coisas como vincular commits a problemas etc. provavelmente não são possíveis, esse é um grande bônus dessa abordagem! (Ser capaz de apenas mencionar o ID do problema em seu commit para fazê-lo aparecer no problema / tíquete é muito legal :)

Estou realmente interessado neste recurso, pois nossa equipe está usando https://taiga.io/, mas o valor real é ter um rastreador de problemas incorporado com a funcionalidade de planejamento kanban / scrum.

Acho que há muito o que aprender com a implementação do GitHub, que originalmente começou exatamente como o gitea. Sua implementação é genérica o suficiente para permitir que os usuários a utilizem tanto para scrums quanto para kanbans, mesmo que ele não tenha ideia do que é um sprint. Se as pessoas puderem definir colunas e arrastar e soltar cartões, provavelmente encontrarão uma maneira de fazer o planejamento com isso.

Apresentando meu acordo aqui de que os painéis de estilo Kanban seriam excelentes. Ninguém ainda mencionou o Zenhub, que fornece vários desses recursos (e mais) "por cima" do Github.

Aqui estão as coisas que acho que seriam realmente úteis:

• Visão Kanban dos problemas - esta visão seria quase inteiramente uma IU, provavelmente precisaria de alguma interação do banco de dados para rastrear a coluna e a ordem de um problema em uma coluna)
• Gráficos de Gantt - Gitea já fornece datas de vencimento de problemas e dependências, bem como marcos, o que significa que todos os dados estão lá para gerar um gráfico de Gantt. Acho que esse seria um recurso muito útil. Existem bibliotecas como mermaidjs ou React Google Charts que parecem ter um custo de integração razoável. Observe que # 7405 também seria útil para isso.
• Marcos da organização - Este é provavelmente o mais fácil de implementar, mas assim como temos o recurso "Problemas" ( /issues ) na parte superior do Gitea, um recurso de Marcos seria bom. Em outras palavras, se eu pudesse ver todos os marcos aos quais estou relacionado, seria muito legal. Atualmente, só consigo visualizar os marcos de um único projeto.

Sem dúvida, cada um desses seria um recurso por direito próprio. Talvez esse thread combinado precise ser dividido em recursos / componentes individuais?

Editar: alguém está trabalhando em um zenhub como o plugin do Chrome para gitea em https://github.com/funktechno/git-kanban-enhanced-chrome-extension .

@adelowo tem uma filial aqui que as pessoas podem querer verificar. Estou bastante esperançoso com o que ele está hackeando.

Eu adoraria ver mais ferramentas do tipo PM chegarem ao gitea devido à simplicidade de hospedar uma instância; no entanto, ficaria extremamente feliz em poder fazer workboards no gitea no próximo ano ou assim. Eu acho que se as pessoas querem bater forte em coisas PM, eles podem recorrer à taiga ou alternativas agora e ser _feliz o suficiente_.

Sim, o diff pode ser visto aqui https://github.com/go-gitea/gitea/compare/master...adelowo : kanban_board? Expand = 1

@adelowo quando pudemos ver um PR?

Em cerca de 8 a 10 dias

@adelowo eu tenho 500 se tentar obter _localhost / user / project_ /projects (pelo seu menu):

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

parece que o bootstrap do banco de dados ainda não funciona @ versão e7cf2b77afe50b5818c52405364faf3c914b9e63

É estranho que as migrações existam. Você pode executar gitea migrate ?

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

Nada de especial mostrado:

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

Mas:

# 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 pode dar uma olhada de novo? Consertei em https://github.com/adelowo/gitea/commit/812f256cdeed312877787b383279c30c5cda9a4f

Funciona para mim, obrigado - aqui estão alguns pequenos problemas:

Alto Prio:

• [] Mover questões entre placas
• [x] adicionar projeto ao problema atual
• [x] ver projeto

- [x] criar projeto

Prio médio:

• [] Ícone de projetos (ATM igual a MergeRequest)
• [] criar problema durante a visualização do projeto
• [] selecionar o projeto durante a criação do problema

Prio baixo:

• [] renomear Conselho
• [] adicionar quadro
• [] remover placa
• [] mover o tabuleiro
• [] solte Label | Milestone ao lado de Pesquisa
• [] procure o problema para adicioná-los ao projeto (não testado)

No entanto, os problemas podem ser movidos entre os painéis.

Obrigado por esta lista. Os projetos agora podem ser selecionados ao criar um problema. Por favor, puxe o mais recente

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

Enviei um PR em https://github.com/go-gitea/gitea/pull/8346

No entanto, os problemas podem ser movidos entre os painéis.

não for armazenado, um recarregamento o redefinirá para Uncategorized

Os projetos agora podem ser selecionados ao criar um problema.

Não mostra lista de projetos

Hmm, vou dar uma olhada novamente. Vamos mover a discussão sobre recursos para o PR, para que fique tudo em um só lugar.

Obrigado

comentário de valor zero: não posso esperar que isso aconteça,: shipit:: rocket:: four_leaf_clover:

Por favor, ajude a tentar # 8346 e dê mais conselhos.

Existe uma atualização sobre este problema? (Já se passou um mês desde a última postagem.)

EDIT: Eu não sabia que algumas pessoas (como @storrgie) poderiam se ofender por pessoas interessadas em seu trabalho. Eu não tive a intenção de ofender ninguém.

@tinxx você também:

• construir o PR que está vinculado acima e fornecer feedback no PR real
• descobrir uma maneira de motivar financeiramente as pessoas a trabalhar nisso (por exemplo, entre em contato com @adelowo diretamente para uma doação ou faça algo como o bountysource para obter mais atenção)

você não clama por trabalho quando não está contribuindo financeiramente ou intelectualmente, isso é tóxico no código aberto.

Jetbrains acaba de lançar uma nova versão do YouTrack com integração gitea

@adelowo alguma notícia?

Outra sugestão entretanto: kanboard

Não é exatamente um colírio para os olhos (fora da caixa), mas é rápido e oferece recursos suficientes para ser muito útil.

Perguntadores: Por favor, dê uma olhada no PR. Parece que não está tão longe: wink:

Sim @gsantner . Restam apenas algumas correções de interface do usuário. Que devo chegar neste fim de semana

@adelowo alguma notícia sobre quando estará disponível?

@zuhairamahdi está planejado para ser lançado em 1.12.0. consulte # 8346 PR para obter mais informações.

Há algum interesse em ter problemas com projetos e / ou placas multible?

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

Eu gosto da abordagem do Gitlab de permitir a criação de "painéis" scrum / kanban de rótulos e transformá-los em uma visão diferente ... nada muda realmente, é apenas uma visão diferente, mas muito útil IMHO.

Estou sentindo falta desse recurso também. Seria ótimo se os rótulos de um problema fossem atualizados quando você os movesse para diferentes pistas / painéis de projeto. Mudar os rótulos e, assim, mover os problemas entre as vias por referências acionáveis ​​em mensagens de confirmação (ou seja, Fixes #1 ) também seria útil.

@ 0xC4N1 Por favor, envie um novo problema, acho que poderíamos ter mais melhorias neste recurso.