Mejores prácticas de Redmine [cerrado]

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

¿Tiene una plantilla de inserción wiki estándar que pueda compartir o una forma estándar de trabajar en un proyecto usando tareas de características de errores y problemas de soporte?

¿Permite que los problemas y 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 la web en lugar de documentos de Word enviados por correo electrónico con requisitos vagos seguidos de documentos de Word que explican cómo realizar el control de calidad y la implementación que se pierden en una pila de actualizaciones y proyectos de la competencia, de modo que cuando tenga que arreglar algo, nadie puede encontrar cualquier documentación sobre cómo funciona.

Desarrollo y mantengo aplicaciones internas para una familia de empresas manufactureras. En el momento de este comentario, soy el único desarrollador / analista del equipo de TI. Durante lo peor de la recesión, las demandas de mi proyecto explotaron. Como tal, mi proyecto Y la acumulación de problemas es bastante difícil de manejar. Actualmente estamos en proceso de reestructuración para ampliar el equipo.

Así es como utilizo Redmine para mantener la cabeza recta (en la medida de lo posible), mantener a raya a mis usuarios y, con suerte, evitar que el personal nuevo se tome de la mano demasiado en el futuro.

• Yo uso Subversion para el control de código fuente, con TortoiseSVN y el plugin Tortoise-Redmine . Actualizar el Repositorio en el proyecto Redmine después de una confirmación vincula el problema, que muestra la revisión del problema, y ​​actualiza a mis partes interesadas mediante 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 aquellos que no están involucrados. De esa manera, mis usuarios saben lo que tengo en mi plato y lo que todavía hay en el buffet que estoy viendo 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 roles incluyen los siguientes: Gerente de proyecto, Miembro del equipo de proyecto, Propietario, Usuario principal, Usuario secundario, Observador, Señor supremo (para mis jefes ... divertido e innegablemente correcto).
• Utilizo la Wiki y los Documentos para la documentación, según lo que creo que es 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.
• Utilizo el fabuloso complemento Stuff-To-Do de Eric Davis para organizar / reorganizar los sprints antes mencionados antes de editar en masa las versiones de destino sobre mis problemas. Esto también les permite a mis partes interesadas saber en qué estoy trabajando y cómo he priorizado sus intereses (para bien o para mal).
• Para fomentar 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 acoplar libremente mi aplicación con su proyecto Redmine: automatizar el envío de errores, alertar a las partes interesadas suscritas desde la bandeja del sistema, menú de ayuda interactivo reutilizable impulsado por la API REST de Redmine, etc. (¿Quizás automatizar partes de la documentación con la Wiki?)

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

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

He estado usando la vista de repositorio con repositorios de git y está funcionando muy bien. Con cada registro, hago referencia al problema con #nnn, por lo que la página del problema real 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.

Hemos encontrado útiles las siguientes prácticas:

1) Oculte el rastreador "Problema" y "Soporte", y archive todo como un error :

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

2) Hitos y versiones Me encanta, puedes rastrear fácilmente el estado de cada versión y en cualquier momento puedes descargar un paquete más antiguo, 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 de informes del día a día y eso es todo lo que necesito.

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

Usamos Redmine ampliamente en nuestro sistema. Incluso hemos creado 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 software de Servidor y Cliente. El proyecto del servidor se divide en submódulos, en función de cómo he estructurado el sistema y los sub-repositorios, ya que a Redmine le gusta un repositorio separado por proyecto.

Usamos, como señalan otros, códigos #nnn en los mensajes de confirmación para los tickets de referencia. Lo bueno es que no es necesario que sea un ticket en el mismo proyecto. Por lo tanto, un ticket de venta puede bloquearse por un problema de error o una solicitud de soporte.

Acabamos de empezar a utilizar Documentos para la agenda / minutas de las reuniones. Usamos Versiones para agrupar en versiones, tanto en el cliente como en el servidor.

Intentar usar el complemento Redmine Time Tracker para realizar un seguimiento del tiempo, pero siempre me olvido de hacer clic en iniciar o finalizar. Recibimos correos electrónicos diarios sobre problemas que no se han abordado en un tiempo (Redmine Whining, creo), 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 del correo electrónico fue un poco más sólida (a veces no crea nuevos tickets correctamente si la línea Proyecto: está incluida en el correo electrónico), las consultas del sitio web generarían tickets de ventas automáticamente . Tal como están las cosas, solo tenemos que monitorear 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 empresa 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.
• Tenga un cliente de escritorio para redmine. El servidor está dentro de nuestra LAN, pero sería genial poder tener una forma más flexible de acceder a los datos que no sea la página web. No es que hay algo que no puedo hacer en la interfaz web Redmine, sino algo así como Things.app es por lo tanto más agradable para trabajar.
• Tenga toda nuestra documentación de soporte dentro de redmine, y luego generada en un servidor de cara al público. De esa manera, nuestro personal de soporte puede mantener la documentación, editar de una manera agradable e implementar cambios en doc-server.

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

• La instalación / mantenimiento a través de SVN ha sido muy fácil (nos he migrado de 1.1 a 1.2 a 1.3 a 1.4 mediante el uso de svn switch https//.../branches/1.3-stable .comandos seguidos de los rake migratecomandos con solo instalaciones ocasionales de gemas necesarias en el medio).
• 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 . Mataría por un cliente pesado de seguimiento 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 usamos mucho Actividad y Hoja de ruta. Vincular problemas a versiones específicas es una bendición.
• También tenemos distinciones Cliente / Servidor, pero usamos la versión de destino para vincular los tickets para especificar cuál va a dónde (y tenemos un final abierto PRÓXIMA LIBERACIÓN DE CLIENTE / PRÓXIMA LIBERACIÓN DE SERVIDOR) para distinguir entre ellas mientras se trabaja.
• Mezclamos metáforas para los estados: usamos nuestras listas primero agrupadas por estos ("Inmediato", "Rechazado", "Bloqueado", "En funcionamiento", "En cubierta" "La lista", "Esperando compilación", "Lanzado para probar "," Verificado "," Publicado para producción "," Cerrado "," Cancelado).
• Luego, dentro de cada grupo anterior, tenemos esta lista ordenada de prioridades: ("Inmediato", "Priorizarme", "Diseñar y dimensionarme", "P1"… "P5", "Lista de vigilancia P"). Esto más lo anterior permiten un flujo de trabajo sencillo desde el área de problemas.
• Para la lista de problemas básicos, ordenamos por "Prioridad", "Tarea principal", luego "Fecha de actualización"; necesitamos la del medio para que Redmine tenga una buena sangría en caso de que haya una tarea secundaria en el mismo grupo.
• Usamos las confirmaciones de registro para vincular las confirmaciones con los 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 problema a "Esperando compilación" (antes estaba "Resuelto", pero me cansé de explicar que "Resuelto" no significaba espero verlo lanzado todavía).

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

Mi empresa trabaja con desarrolladores de software y hardware de origen internacional. Antes de unirme a la empresa, el correo electrónico se usaba con documentos de MS Word para transmitir nuestros problemas y errores con software o hardware para solicitar una solución. Este proceso era imposible de rastrear y mantener ningún tipo de proceso. Implementé RedMine como un medio para rastrear los errores de software y hardware y ha funcionado muy bien desde entonces. Existe una gran barrera del idioma en mi situación. Afortunadamente, RedMine puede mostrarse en chino Sipmlified y los comentarios han demostrado que esto está bien por parte de mis desarrolladores.

Estado: cuando encuentro un problema de software o hardware, el estado es "Nuevo". Cuando mis desarrolladores de software / hardware han detectado este problema y están trabajando en él, cambian el estado a "En curso". Pueden usar el% completado si lo desean entre 0 y 50. Les pido que establezcan% completado en 50 cuando sientan que han resuelto el problema. - Determina si el problema está solucionado, y cambio el estado a "Resuelto" y el% completado al 100%. Esto me permite filtrar problemas <o igual al 50% para encontrar problemas que aún están abiertos.

Prioridad: baja, normal, alta, urgente, inmediata, todo se traduce bien en chino.

Fecha de vencimiento: utilizo esto para indicarme cuándo los desarrolladores de software cargaron originalmente la corrección. Puede que me lleve de 4 a 6 días probar algo y solucionar el problema. Me gusta que mi gráfico de Gannt refleje la capacidad de respuesta de mi equipo de software, no el tiempo que me tomó aprobar la correcció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 del 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 progreso) para que mis supervisores y los supervisores y los ingenieros principales de los equipos involucrados puedan ver el correo electrónico y leer rápidamente el progreso que se está haciendo actualmente. La mayoría de las personas involucradas nunca inician sesión en RedMine, normalmente soy el único. Los correos electrónicos sirven perfectamente para dar actualizaciones instantáneas a todos aquellos cuya única preocupación es si se está progresando o no.

Como mencionaste, enviando documentos de Word hacia atrás y hacia adelante con tu QA, conozco este sentimiento, he estado allí, he hecho eso. El problema principal para mí fue: a las personas de control de calidad no les gusta agregar problemas en ningún rastreador de errores, los anotan en un editor junto a ellos durante las pruebas.

Estamos usando Redmine ahora con un buen complemento: Usersnap (Descargo de responsabilidad: creamos 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 la 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.

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

• loco
• características (que serían referencias a su documento de Word o enlaces a páginas de requisitos html)
• conciliaciones (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 usa para definir el hito principal / fechas de lanzamiento utilizadas en la hoja de ruta)

Además de los otros comentarios, recomiendo el uso del complemento "Cosas por hacer" (escrito por Eric Davis, creo :) El uso de ese complemento le permite arrastrar y soltar para ordenar el orden de los problemas en varios proyectos.

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

Usamos Versiones como una forma de definir sprints, por lo que cada versión es un sprint con la vista Roadmap dando una clara ilustración del progreso. Los problemas en los sprints se marcan como 'listos para revisión' cuando se completan y luego se cierran cuando se verifica el control de calidad.

Usamos una versión como reserva para cualquier problema que se salga del alcance o pierda su prioridad, etc.

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

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

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

Usamos la wiki de manera integral para la documentación del desarrollador.