project-management - gratis - redmine online

Las mejores prácticas de Redmine (11)

Además de los otros comentarios, recomiendo el uso del "Stuff To Do" -Plugin (escrito por Eric Davis, creo :) Usar ese complemento permite arrastrar y soltar ordenando el orden de los problemas en múltiples proyectos.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

¿Qué consejos y "estándares" usas en tu proceso de gestión de proyectos Redmine?

¿Tiene una plantilla de inserción de wiki estándar que podría compartir o una forma estándar de trabajar un proyecto utilizando funciones de funciones de errores y problemas de soporte?

¿Dejas que los problemas y las actualizaciones se envíen por correo electrónico a Redmine? ¿Usas los foros? ¿Usas el repositorio SVN? ¿Usas Mylyn en eclipse para trabajar en las listas de tareas?

Estoy intentando arrastrar nuestro departamento. en algunos PM basados en web en lugar de documentos de Word por correo electrónico de requisitos imprecisos seguidos por documentos de Word que explican cómo implementar QA e Implementar que todos se pierden en un montón de actualizaciones y proyectos en competencia, de modo que cuando tengo que arreglar algo, nadie puede encontrar cualquier documentación sobre cómo funciona.

Como mencionó enviar documentos de Word de un lado a otro con su control de calidad: conozco este sentimiento, he estado allí y lo he hecho. El principal problema para mí fue que a las personas de control de calidad no les gusta agregar problemas en ningún rastreador de fallos, sino que los anotan en un editor junto a ellos durante las pruebas.

Estamos utilizando Redmine ahora con un buen complemento - Usersnap (Descargo de responsabilidad: construimos la herramienta para resolver este problema por nosotros mismos.

Usersnap es ideal para desarrolladores web: agréguelo a su proyecto web y obtendrá capturas de pantalla directamente adjuntas a los tickets de Redmine, incluida metainformación sobre el navegador utilizado, el sistema operativo, etc.

Nuestros QA / clientes pueden ingresar errores ahora directamente en la aplicación web y los desarrolladores se vuelven más fáciles de reproducir informes de errores en Redmine.

Desarrollo y mantengo aplicaciones internas para una familia de empresas de fabricación. A la hora de este comentario, soy el único desarrollador / analista en el equipo de TI. Durante lo peor de la recesión, las demandas de mi proyecto explotaron. Como tal, mi proyecto Y el trabajo atrasado son bastante difíciles de manejar. Actualmente estamos en proceso de reestructuración para expandir el equipo.

Así es como utilizo Redmine para mantener mi cabeza firme (en la medida de lo posible), con los usuarios a raya, y con suerte evito demasiada mano de personal nuevo en el futuro.

Uso Subversion para el control de código fuente, con TortoiseSVN y el plugin Tortoise-Redmine . Al actualizar el repositorio en el proyecto Redmine después de una confirmación, se vincula el problema, que muestra la revisión del problema, y se actualizan las partes interesadas a través de una notificación por correo electrónico.
Trato la descripción del proyecto como un medio para comunicar el propósito, el alcance y la etapa del ciclo de vida del proyecto a quienes no están involucrados. De esa forma, mis usuarios saben lo que tengo en mi plato, y lo que todavía está en el buffet que estoy mirando desde la distancia.
Utilizo nombres de roles específicos para mis conjuntos de permisos que indican más que un conjunto de permisos, nuevamente como medio de documentación. Mis funciones incluyen las siguientes: Project Manager, Project Team Member, Owner, Primary User, Secondary User, Observer, Overlord (para mis jefes ... ambas divertidas e innegablemente correctas).
Uso Wiki y Documentos para documentación, dependiendo de lo que sienta que sea apropiado.
Las versiones son bastante inútiles para mí, así que en lugar de usar eso para lanzamientos planificados, lo uso para agrupar problemas relacionados en sprints.
Uso el fabuloso plugin Stuff-To-Do de Eric Davis para organizar / reorganizar los sprints antes mencionados antes de editar en masa las versiones de Target sobre mis problemas. Esto también les permite a mis grupos de interés saber en qué estoy trabajando y cómo he priorizado sus intereses (para bien o para mal).
Para alentar la interacción del usuario, agregué enlaces al proyecto Redmine en los menús de Ayuda de mis aplicaciones. El cuadro "Acerca de" también contiene un enlace al proyecto Redmine.

Planes futuros

Espero en algún momento terminar mi extensión de Visual Studio para la integración de Redmine.
Construir una biblioteca de código para vincular mi aplicación con su proyecto Redmine: automatizar el envío de errores, alertar a las partes interesadas desde la bandeja del sistema, menú de ayuda interactivo reutilizable impulsado por la API REST de Redmine, etc. (¿Tal vez automatizar partes de la documentación con Wiki?)

Estamos utilizando la sección de la Hoja de ruta como una forma clara de mostrar:

loco
características (que serían referencias a su documento de Word o enlace a páginas de requisitos html)
reconciliaciones (diferencias entre valores de producción y valores de prueba)
y así...

Ese es el principal punto de consolidación para nosotros. El resto se usa en relación con eso (por ejemplo, la sección ''anunciar'' se utiliza para definir las fechas principales de hito / lanzamiento utilizadas en la hoja de ruta)

Hemos encontrado útiles las siguientes prácticas:

1) Oculta el rastreador "Emitir" y "Soporte" y archiva todo como un error :

ahorro de tiempo para desarrolladores, probadores, administración;
si algunas actividades se deben facturar como "extra" o "nueva función" o cualquier otra cosa, se organizan reuniones rápidas para evaluarlas.

2) Hitos y versiones Me encanta esto, puede rastrear fácilmente el estado de cada lanzamiento y en cualquier momento puede descargar un paquete anterior, es decir, para probar un error presentado por el cliente.

3) función "guardar" en la pestaña "problemas": otro gran ahorro de tiempo, tengo diferentes consultas guardadas para muchas tareas diarias de informes y eso es todo lo que necesito.

4) integración de versiones, es decir, el uso de "# 123" en los comentarios crea un enlace al problema correspondiente: ¡simplemente inteligente!

Hemos estado usando Redmine durante aproximadamente un año y ha evolucionado por sí solo de muchas maneras. Usamos versiones para agrupar problemas para un lanzamiento y categorías para agrupar problemas por disciplina.

Cada problema pasa por un flujo de trabajo de nuevo> en progreso> resuelto. Entonces el probador cerrará el problema cuando esté contento.

Nos encantaría actualizar la forma en que usamos Redmine, parece que hay muchos complementos geniales, pero encontramos que muchos de ellos están rotos o no se instalarán.

Usamos el wiki exhaustivamente para la documentación del desarrollador.

Mi empresa trabaja con desarrolladores de software y hardware de origen internacional. Antes de unirme a la empresa, el correo electrónico se utilizaba con documentos de MS Word para transmitir nuestros problemas y errores con software o hardware para solicitar una solución. Este proceso fue imposible de rastrear y mantener cualquier tipo de proceso. Implementé RedMine como un medio para rastrear los errores de software y hardware y ha estado funcionando muy bien desde entonces. Hay una gran barrera idiomática con mi situación. Afortunadamente RedMine puede mostrarse en chino simplificado y los comentarios han demostrado que esto está bien hasta ahora de mis desarrolladores.

Estado: cuando encuentro un problema de software o hardware, el estado es "Nuevo": cuando mis desarrolladores de software / hardware han visto este problema y están trabajando en él, cambian el estado a "En curso". Pueden usar% done si lo desean de 0 a 50. Los he configurado% Listo a 50 cuando sienten que han resuelto el problema. - Determino si el problema está solucionado, y cambio el estado a "Resuelto" y el% al 100%. Esto me permite filtrar problemas <o equivalentes al 50% para encontrar problemas que aún están abiertos.

Prioridad: Baja, Normal, Alta, Urgente, Inmediato, todo se traduce bien en chino.

Fecha de vencimiento: uso esto para decirme cuándo mis desarrolladores de software cargaron originalmente la corrección. Me puede llevar de 4 a 6 días probar algo y cerrar el problema. Me gusta mi gráfico de Gannt para reflejar la capacidad de respuesta de mi equipo de software, no el tiempo que tardé en aprobar la solución.

Categoría: siempre refleja la versión de software o hardware donde encontré el problema. Utilizo esto para ver qué versión de software tiene la mayor cantidad de errores y para asegurarme de que las versiones más nuevas de software no sufran regresión.

Tengo a todos incluidos en la lista de observadores de RedMine para todos los errores. El correo electrónico aparece como (Nuevo), (Resuelto) o (En curso) para que mis supervisores y los supervisores e ingenieros principales de los equipos involucrados puedan ver el correo electrónico y leer rápidamente el progreso que se está realizando actualmente. La mayoría de las otras personas involucradas nunca inician sesión en RedMine, generalmente soy la única. Los correos electrónicos sirven perfectamente para dar actualizaciones instantáneas a todos, cuya única preocupación es si se está progresando o no.

Redmine ha sido fantástico para nosotros hasta ahora. Lo utilizamos como una cola de asignación de prioridades ágil / tickets múltiples para inquilinos, y también lo hemos vinculado a SVN. En particular:

Instalar / mantener a través de SVN ha sido muy sencillo (nos hemos migrado de 1.1 a 1.2 a 1.3 a 1.4 mediante el uso de los svn switch https//.../branches/1.3-stable . comandos rake migrate con solo se necesitan instalaciones ocasionales de gemas).
Las copias de seguridad de la base de datos y los archivos almacenados son una ejecución de script de una línea
Nos encantan los complementos Time Tracker y Spent Time . Me gustaría matar por un cliente de rastreo de tiempo de Mac OS X para algunos de nuestros usuarios de oficina, pero eso no viene al caso :)
No usamos mucho los foros, pero utilizamos mucho la actividad y la hoja de ruta. Atar problemas a versiones específicas es un regalo del cielo.
También tenemos distinciones de Cliente / Servidor, pero usamos la versión de destino para vincular los tickets para especificar cuál va donde (y tenemos abiertos NEXT CLIENT RELEASE / NEXT SERVER RELEASE) para distinguirlos mientras se trabaja en ellos.
Mezclamos metáforas para estados: utilizamos nuestras listas agrupadas primero por estas ("Inmediato", "Rechazado", "Bloqueado", "Trabajando", "En cubierta", "La lista", "Esperando compilación", "Liberado para probar" "," Verificado "," Liberado a producción "," Cerrado "," Cancelado ".
Luego, dentro de cada grupo anterior, tenemos esta lista ordenada de prioridades: ("Inmediato", "Priorizarme", "Diseñar y ajustarme", "P1" ... "P5", "P-Watch List"). Esto más lo anterior permite un flujo de trabajo fácil, todo desde el área de problemas.
Para la lista de problemas básicos, clasificamos por "Prioridad", "Tarea principal" y luego "Fecha actualizada". Necesitamos la del medio para que Redmine escriba bien si debe haber una tarea secundaria en la misma agrupación.
Usamos commits de checkin para atar commits a problemas (es decir, svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns." ) - y hacer que mueva ese tema a " Waiting For Build "(Eso solía ser" Resolvió ", pero me cansé de explicar que" Resuelto "no significaba que alguien pueda esperar verlo publicado todavía).

Sin embargo, creo que tendré que investigar el plugin Redmine-stuff-to-do. +1 Pregunta.

Soy un desarrollador web independiente de Ruby and Redmine que dirige un negocio de desarrollo de uno (yo). Entonces mi Redmine está configurada para ser bastante ligera y enfocada en el cliente. My Redmine también cumple una doble función para alojar mis proyectos de código abierto.

Permití que los nuevos problemas y actualizaciones se envíen por correo electrónico y funciona muy bien para usuarios conectados por correo electrónico (o aquellos que siempre están en sus iPhones).

He estado usando la vista de repositorio con los repositorios de git y está funcionando muy bien. Con cada registro, hago referencia al problema con #nnn, por lo que la página de problemas reales mostrará todas las confirmaciones para implementar la función.

Encontré que los foros están infrautilizados. Creo que si hubiera alguna integración de correo electrónico, serían más útiles.

Usamos Redmine extensivamente en nuestro sistema. Incluso hemos establecido un proyecto de "Ventas" para que nuestro equipo de ventas lo utilice como CRM. Tenemos un montón de campos personalizados en este proyecto, y reemplaza SugarCRM que estábamos usando antes.

Dentro de nuestro sistema, tenemos proyectos para el software de Servidor y Cliente. El proyecto del servidor está dividido en submódulos, según cómo he estructurado el sistema y los sub-repositorios, ya que a Redmine le gusta un repositorio por proyecto.

Usamos, como otros señalan, códigos #nnn en los mensajes de confirmación para los tickets de referencia. Lo bueno es que no tiene por qué ser un boleto en el mismo proyecto. Por lo tanto, un ticket de ventas puede ser bloqueado por un problema de error o una solicitud de soporte.

Recién comenzamos a usar Documentos para la agenda / actas de las reuniones. Usamos Versiones para agrupar en lanzamientos, tanto en el cliente como en el servidor.

Intentar utilizar el complemento Redmine Time Tracker para rastrear el tiempo, pero siempre olvido hacer clic en iniciar o finalizar. Recibimos correos electrónicos diarios sobre problemas que no se han tocado en un tiempo (creo que Redmine Whining), y que tienen fechas de vencimiento en el pasado o en el futuro cercano (Recordatorio avanzado).

Los correos electrónicos de soporte van directamente a nuestro proyecto de soporte, y si la importación de correo electrónico fue un poco más sólida (a veces no crea nuevos tickets correctamente si se incluye la línea Project: en el correo electrónico), las consultas del sitio generarán automáticamente tickets de venta . Tal como están las cosas, solo tenemos que controlar los tickets de Soporte y moverlos a Ventas, si corresponde.

Cosas que me gustaría poder hacer:

Tener relaciones entre nuestro sistema y redmine, para que los tickets se puedan asociar con un usuario o compañía en nuestro sistema. Además, para que podamos generar una nueva empresa a partir de un ticket de ventas en el punto relevante. Esto solo requiere que haga algo de trabajo.
Tener una relación entre nuestro software de seguimiento de errores (centinela) y redmine, para que los errores del servidor generen un ticket de redmine. Nuevamente, solucionable con la tecnología actual.
Tener un cliente de escritorio para redmine. El servidor está dentro de nuestra LAN, pero ser capaz de tener una forma más flexible de acceder a los datos que no sean la página web sería genial. No es que haya algo que no pueda hacer realmente en la interfaz web redmine, pero algo así como Things.app es mucho mejor para trabajar.
Tenga nuestra documentación de soporte dentro de Redmine, y luego generada en un servidor público. De esta forma, nuestro personal de soporte puede mantener la documentación, editar de una manera agradable e implementar los cambios en doc-server.

Utilizamos las versiones como una forma de definir los sprints, por lo que cada versión es un sprint con la vista del mapa de ruta que da una ilustración clara del progreso. Los problemas en los sprints se marcan como ''listos para la revisión'' cuando se completan y luego se cierran cuando QA ha verificado.

Usamos una Versión como una acumulación para cualquier problema que caiga fuera del alcance o pierda su prioridad, etc.