2010-09-23 21 views
9

Soy el único desarrollador que trabaja en un par de sitios webapp. Los tengo en subversión, pero no estoy usando una herramienta de gestión de proyectos.organización de proyectos Redmine?

Recientemente empecé a redminear, y quiero configurar los proyectos allí. Lo que estoy buscando es una recomendación sobre cómo estructurar estos dos proyectos en Redmine. Según lo que puedo deducir, la estructura es Proyecto-> subproyecto. Así que estoy tratando de asignar esto a mi estructura de lista de cosas por hacer. De mi lista de tareas pendientes, hay tres tipos de tareas: nuevas funciones, correcciones de errores y mantenimiento (no correcciones de errores, pero las cosas que realmente necesitan limpieza).

¿Debo hacer de cada aplicación web un proyecto de nivel superior, con características, errores y mantenimiento como subproyectos? ¿Qué otras formas de organizar proyectos hay? Por ejemplo, en el manual de subversión, recomiendan tener project/trunk, project/branches, project/testing, project/releases, etc. ¿Existen pautas similares para trabajar en Redmine?

+0

En vista de la edad de la pregunta, esto podría beneficiar a otros usuarios más ... Pero debe tomar nota aquí: los subproyectos Redmine no enumeran a los padres en sus URI, cada uno usa simplemente 'server: port//projects/ 'para el acceso directo a la página del proyecto. Creo que esto se aplica tanto a la interfaz de usuario web como al back-end RESTful. – ZaLiTHkA

Respuesta

12

Como es habitual, cuando configura un sistema necesita personalizarlo tanto como sea posible para tratar de satisfacer sus propias necesidades. Personalmente, no conozco ninguna guía o recomendación para Redmine per-se, sin embargo, puedo relatar lo que hacemos aquí y espero que eso te ayude. :-)

Las características/errores/mantenimiento son solo formas de etiquetar sus tareas para que pueda filtrarlas. Esta es una etiqueta específica conocida como "rastreador" en Redmine. Puede definir sus propios rastreadores para tipos adicionales de tareas.

El proyecto y el Subproyecto también son efectivamente una forma de etiquetar sus tareas, pero agrupándolas en una categoría paraguas más amplia. Cuando crea 'proyectos', asigna los rastreadores que necesita para ellos. En nuestro caso, creamos una API, y tenemos rastreadores distintos para identificar errores, presenta modificaciones & con nombres de rastreador (efectivamente) duplicados para que podamos identificar si las tareas son para programadores dsp o de escritorio. Los subproyectos se usan para identificar líneas de productos o personalizaciones para las cuales nuestros clientes requieren soporte específico. También utilizamos etiquetas de versión para identificar lanzamientos específicos en cada subproyecto para que podamos obtener una buena vista de hoja de ruta de todas las tareas que estamos rastreando. Tenemos varios proyectos en nuestro sistema Redmine, cada uno configurado de manera similar, con algunas tareas de proyectos vinculadas entre proyectos como problemas "relacionados" para que podamos identificar dependencias.

Esta es solo una forma de configurar Redmine, pero es la más simple que podemos administrar dadas las relaciones complejas entre algunos de nuestros proyectos. Es la segunda configuración que hemos probado y nos parece que funciona bien. FYI, la primera configuración fue en un sistema de prueba que nos permitió calcular lo que necesitábamos del sistema después de migrar de Trac, hace un par de años. La configuración actual ha estado en uso durante aproximadamente 2 años y parece adecuarse a nuestras necesidades.

Como dije anteriormente, debe decidir qué necesita del sistema, pero el enfoque más simple es pensar en cómo ver un proyecto de arriba hacia abajo, configurar su sistema para que coincida con sus procesos y no cambiar su procesos para que coincida con la herramienta - siempre la opción más 'desastrosa' en mi humilde opinión. No recomendaría el seguimiento de errores y características, etc. en proyectos separados, ya que la combinación de sus hojas de ruta es generalmente más difícil y también dificulta la visualización de la carga total de tareas para un proyecto determinado. Incluso dividir los tipos de tareas en subproyectos podría ser problemático, ya que complica las cosas si encuentra que necesita admitir múltiples ciclos de lanzamiento del producto, lo que aumenta su carga de trabajo en términos de administración de su sistema Redmine.

Eso es todo lo que se me ocurre por ahora.Espero que eso te ayude. :-)

+0

Eso ayuda mucho. El tipo de respuesta informativa que estaba buscando :) – user151841

2

El tipo de tareas que menciona parece ser lo que Redmine llama rastreador. Puede definir sus propios rastreadores. En mi opinión, no debería necesitar un subproyecto para cada "tipo de tarea", sino un rastreador.

Cuestiones relacionadas