Gitea: Backlog de SCRUM / Backlog de Sprint por proyecto

¿Podría señalar qué funciones desea especialmente?

En SCRUM tiene básicamente un Product-Backlog, que contiene User Stories, que están ordenados por prioridad o por algún valor predefinido.
Cada User Story consiste muy probablemente en un título, una descripción y tal vez un nombre para el valor para medir la prioridad (más o menos como "problemas", pero ordenados por prioridad) así como ese campo de prioridad.
También un campo, que podría indicar si la User-Story fue implementada, eliminada (debido a algunos problemas, no está terminada o necesita más descripción)

En cada Sprint (período de tiempo definido), los desarrolladores toman algunas historias de usuario del Product-Backlog y las agregan a su Sprint-Backlog, que además del P-Backlog también consiste en ideas (tal vez opcionales) sobre cómo los desarrolladores quieren resolver el problema específico, que es descrito por su User-Story elegido. Todos los desarrolladores pueden ver la historia de usuario asignada a todos los demás desarrolladores, pero no pueden editarla (tal vez solo comentarla)
Los desarrolladores solo deberían poder modificar sus propias notas de la solución, pero no la descripción / título de la historia del usuario, por lo que la necesidad de al menos dos roles (propietario del producto y desarrollador (no exclusivo))
Una vez que dev-1 haya terminado sus historias de usuario asignadas, podría pedirle a otro dev-2 que asigne su historia de usuario (otra dev-2) a dev-1 (bueno, abierto para discusiones en este punto).

Si el sprint terminó, es decir, se acabó el tiempo, podría haber algún tipo de descripción general de las historias de usuario terminadas y también de las inconclusas.
Estas historias de usuarios deben pasar por dos fases.
Los terminados deben pasar por ambas fases, una es la revisión de Sprint (por ejemplo, mostrar al cliente las mejoras terminadas) (solo historias de usuario terminadas).
La segunda fase sería la retrospectiva de Sprint, donde el equipo de desarrollo analiza lo que se terminó y, especialmente, lo que fue bueno en el proceso, y también qué historias de usuario no se terminaron y por qué no (moviéndolas a la cartera de productos).
(Tal vez algún "tablero de anuncios" con información sobre la definición de "Listo", es decir, cuándo considerar una historia de usuario como terminada y algunas cosas de optimización de procesos)

Alguna funcionalidad para iniciar un nuevo sprint y tal vez basado en el sistema de problemas normal, el propietario del producto podría tomar estas sugerencias y convertirlas en historias de usuario, agregando prioridad, descripción más detallada, etc.

No sé qué sería mejor, usar el sistema de problemas existente y usarlo como entrada para que el propietario del producto tome o use las cosas de scrum exclusivamente, excluyendo el sistema de problemas normal y ver las cosas de scrum como un problema propio. sistema.

TLDR: D
En general, es necesario que haya dos roles, uno de propietario del producto (por defecto, propietario del proyecto con la posibilidad de cambiar los roles por parte del primer propietario del producto / proyecto) y el otro de desarrollador.
Además, se necesita un Sprint, que tiene una duración definida (¿propietario del producto?) Y algún mecanismo para iniciar un Sprint. Iniciar un sprint no tiene sentido si no hay nada en el backlog del sprint, por lo tanto, la necesidad de un backlog del sprint que contenga (?) (Tal vez todos los desarrolladores pueden cambiar las asignaciones) historias de usuario, que no se pueden cambiar, pero comentadas ( ¿Un comentario pegajoso con comentarios secundarios?).
Cada desarrollador debe poder (solo dentro de un sprint? O cuando quiera?) Cambiar el estado de una historia de usuario de inacabada a terminada (la pregunta es, ¿qué tipo de estados puede tener una historia de usuario?)
Cuando el sprint llega al final, el estado del "rastreador de problemas" debería cambiar su estado a la fase de revisión, mostrando solo las historias de usuario terminadas (¿Y solo el comentario pegajoso del desarrollador? ¿Sin comentarios? ¿Todos los comentarios?). (¿Qué estados deberíamos necesitar?: Sugerencia: planificación, sprint, revisión, retrospectiva)
Entonces, el propietario del producto (?) Debería poder cambiar el estado a la retrospectiva, donde tal vez el "tablón de anuncios" con sugerencias, patrones, buenas prácticas, malas prácticas, etc., así como todas las historias de usuarios terminadas y no terminadas. debería ser visible de nuevo.
Después de esta fase, el propietario del producto (?) Debería poder cambiar la fase a la siguiente, la planificación, donde las historias de usuarios sin terminar deberían (?) Volver a la lista de trabajos pendientes del producto y las historias de usuarios finalizadas, ya sea archivadas o eliminadas (para no señalar con el dedo a las personas, cuando se encuentre un error posteriormente).
Y en la fase de planificación, el equipo de desarrollo puede volver a agregar las historias de usuario a su backlog de Sprint.
Y después de este paso, de alguna manera, el propietario del producto debe iniciar un sprint.

Diviértete discutiendo (espero)

Las historias de usuario también pueden tener todas las propiedades que tiene un problema en el rastreador de problemas normal, por ejemplo, etiquetas, etc.

Esto ya se discutió en el # 805. Personalmente, creo que el flujo de trabajo de los equipos puede diferir mucho, y por esta razón no deberíamos tener ninguna característica de "proyectos" similar a GitHub's o GitLab's, o al sistema Scrum de Bitbucket. No creo que exista una solución única viable para todos, pero los problemas son un buen compromiso para proyectos pequeños en los que uno puede esperar no tener una gran cantidad de cosas de las que realizar un seguimiento.

Gitea en sí misma debería, en lo que a mí respecta, ceñirse a los problemas de estilo GitHub / Lab y solo proporcionar herramientas para lidiar con ellos usando API y webhooks, o permitir que las personas usen rastreadores de problemas externos (¡algo que ya tenemos!).

@ jxsl13 Puedo recomendarte https://github.com/opf/openproject que puede funcionar junto con Gitea. Admite múltiples flujos de trabajo y puede configurar gitea para usarlo como su administrador de tickets / problemas (configurando la URL en gitea)

@sapk gracias, parece bastante prometedor

@sapk He instalado open-project y cambio el administrador de tickets / problemas en Gitea pero tengo una pregunta, ¿existe alguna relación entre open-project y gitea? o solo un enlace Gitea a OpenProject?

Mi pregunta es porque no sé si hay alguna forma de relacionar mis problemas de gitea con la tarea de openproject (el código de gitea, el mismo número de problemas en gitea y openproject).

¡Gracias por su respuesta!

Tal vez sea posible vincular más estrechamente entre openproject y gitea a través de api, pero no conozco a nadie que lo haya hecho (y tal vez requiera algún ajuste al código de gitea o openproject).
Lo uso principalmente para hacer gestión avanzada de proyectos además del código alojado en gitea.

Me gusta el enfoque de Gitlab de permitir crear "tableros" scrum / kanban a partir de etiquetas y convertirlos en una vista diferente ... nada cambia realmente, es solo una vista diferente, pero muy útil en mi humilde opinión.

Para algunos equipos, tener un tablero integrado en la misma herramienta donde se crean los problemas es una necesidad. Sería realmente útil tener tableros como Gitlab o Github. Estaba pensando en la idea de una pestaña de proyectos / tablero integrado de gitea, y creé un prototipo de la idea, se basa en el enfoque de Gitlab:

Realmente no funciona, son solo datos fijos, pero creo que lo visual debería ser algo similar a esto. El código está aquí:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

Algo que falta es el visual para crear / seleccionar tableros, como tiene Gitlab. Sería realmente útil poder crear tableros para varios equipos.

@rudineirk ¿

¡A mí también me gustaría que esto sucediera! Permitiría que muchos equipos pequeños trabajen directa y principalmente con gitea en lugar de luchar con herramientas externas y posiblemente difíciles de configurar como Taiga.io, etc.
Con herramientas externas, es probable que no sea posible vincular compromisos con problemas, etc., ¡eso es una gran ventaja de este enfoque! (Ser capaz de mencionar el ID del problema en su compromiso para que aparezca en el problema / ticket es genial :)

Estoy realmente interesado en esta función, ya que nuestro equipo utiliza actualmente https://taiga.io/, pero el valor real es tener un rastreador de problemas integrado con la funcionalidad de planificación kanban / scrum.

Creo que hay muchas cosas que aprender de la implementación de GitHub que originalmente comenzó exactamente como gitea. Su implementación es lo suficientemente genérica como para permitir a los usuarios usarlo tanto para scrums como para kanbans, incluso si no tiene idea de qué es un sprint. Si las personas pueden definir columnas y arrastrar y soltar tarjetas, probablemente encontrarán una manera de hacer la planificación con ellas.

Presentar mi acuerdo aquí de que los tableros estilo Kanban serían excelentes. Nadie ha mencionado aún Zenhub, que ofrece varias de estas características (y más) "exageradas" de Github.

Aquí están las cosas que creo que serían realmente útiles:

• Vista Kanban de problemas: esta vista sería casi en su totalidad una interfaz de usuario, probablemente necesitaría alguna interacción con la base de datos para rastrear la columna y el orden de un problema en una columna)
• Diagramas de Gantt: Gitea ya proporciona fechas de vencimiento y dependencias de emisión, así como hitos, lo que significa que todos los datos están ahí para generar un diagrama de Gantt, creo que esta sería una característica realmente útil. Hay bibliotecas como mermaidjs o React Google Charts que parecen tener un costo de integración razonable. Tenga en cuenta que el # 7405 también sería útil para esto.
• Hitos de la organización: este es probablemente el más fácil de implementar, pero al igual que tenemos la función "Problemas" ( /issues ) en la parte superior de Gitea, una función de Hitos estaría bien. En otras palabras, si pudiera ver todos los hitos con los que estoy relacionado, sería genial. Actualmente, solo puedo ver hitos dentro de un solo proyecto.

Sin duda, cada uno de ellos sería una característica por derecho propio. ¿Quizás este hilo combinado necesita dividirse en características / componentes individuales?

Editar: alguien está trabajando en un zenhub como el complemento de Chrome para gitea en https://github.com/funktechno/git-kanban-enhanced-chrome-extension .

@adelowo tiene una sucursal aquí en la que la gente podría querer verificar. Tengo muchas esperanzas de lo que está pirateando.

Me encantaría ver más herramientas de tipo PM llegar a gitea dada la simplicidad de alojar una instancia, sin embargo, estaría extremadamente feliz de poder hacer tableros de trabajo en gitea durante el próximo año más o menos. Creo que si la gente quiere golpear las cosas de PM con fuerza, pueden recurrir a la taiga o alternativas en este momento y ser lo suficientemente felices.

Sí, la diferencia se puede ver aquí https://github.com/go-gitea/gitea/compare/master...adelowo : kanban_board? Expand = 1

@adelowo cuando pudimos ver un PR?

En unos 8-10 días

@adelowo obtuve un 500 si intenta obtener _localhost / user / project_ /projects (por su menú):

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

parece que el bootstrap de la base de datos aún no funciona @ versión e7cf2b77afe50b5818c52405364faf3c914b9e63

Es raro que las migraciones estén ahí. ¿Puedes ejecutar gitea migrate ?

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

No aparece nada especial:

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

Pero:

# 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, ¿puedes echar un vistazo de nuevo? Lo arreglé en https://github.com/adelowo/gitea/commit/812f256cdeed312877787b383279c30c5cda9a4f

Funciona para mí, gracias, aquí algunos pequeños problemas:

Alto Prio:

• [] Mover problemas entre tableros
• [x] agregar proyecto a la edición actual
• [x] ver proyecto

- [x] crear proyecto

Prio medio:

• [] Icono de proyectos (cajero automático igual que MergeRequest)
• [] crear problema durante la visualización del proyecto
• [] seleccionar proyecto durante la creación del problema

Prio bajo:

• [] renombrar tablero
• [] agregar tablero
• [] eliminar tablero
• [] mover tablero
• [] coloca Label | Milestone junto a Buscar
• [] busque un problema para agregarlo al proyecto (no probado)

Sin embargo, los problemas se pueden trasladar de un lado a otro.

Gracias por esta lista. Los proyectos ahora se pueden seleccionar al crear un problema. Por favor, tire lo último

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

Envié un PR en https://github.com/go-gitea/gitea/pull/8346

Sin embargo, los problemas se pueden trasladar de un lado a otro.

no se almacena, una recarga lo restablece a Uncategorized

Los proyectos ahora se pueden seleccionar al crear un problema.

No muestra lista de proyectos

Hmm, echaré un vistazo de nuevo. Pasemos la discusión de características al PR para que esté todo en un solo lugar.

Gracias

comentario de valor cero: no puedo esperar a que esto suceda,: shipit:: rocket:: four_leaf_clover:

Por favor ayude a probar el # 8346 y dé más consejos.

¿Hay alguna actualización sobre este tema? (Ha pasado un mes desde la última publicación).

EDITAR: No me di cuenta de que algunas personas (como @storrgie) podrían sentirse ofendidas por personas interesadas en su trabajo. No quise ofender a nadie.

@tinxx tú tampoco:

• construir el PR que está vinculado justo arriba y proporcionar comentarios en el PR real
• encuentre una manera de motivar financieramente a las personas para que trabajen en esto (por ejemplo, comuníquese con @adelowo directamente para obtener una donación o haga algo como bountysource para obtener más atención)

no clama por que se haga el trabajo cuando no está contribuyendo financiera o intelectualmente, eso es tóxico en el código abierto.

Jetbrains acaba de lanzar una nueva versión de YouTrack con la integración de gitea

@adelowo alguna noticia?

Mientras tanto, otra sugerencia: kanboard

No es exactamente un regalo para la vista (listo para usar), pero es rápido y ofrece suficientes funciones para ser muy útil.

Personas que preguntan: Por favor, echen un vistazo a las relaciones públicas. Parece que no está tan lejos: guiño:

Sí @gsantner . Solo quedan algunas correcciones de interfaz de usuario. Al que debería llegar este fin de semana

@adelowo ¿ alguna noticia sobre cuándo estará disponible?

@zuhairamahdi está previsto que se publique en la versión 1.12.0. vea # 8346 PR para más información.

¿Existe algún interés en tener un problema en varios proyectos y / o juntas?

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

Me gusta el enfoque de Gitlab de permitir crear "tableros" scrum / kanban a partir de etiquetas y convertirlos en una vista diferente ... nada cambia realmente, es solo una vista diferente, pero muy útil en mi humilde opinión.

También me estoy perdiendo esta función. Sería genial si las etiquetas de un problema se actualizaran cuando las mueva a diferentes carriles / tableros de proyectos. También sería útil cambiar las etiquetas y, por lo tanto, mover los problemas entre carriles mediante referencias procesables en los mensajes de confirmación (es decir, Fixes #1 ).

@ 0xC4N1 Envíe un nuevo número, creo que podríamos tener más mejoras en esta función.