Hablé con Peter Gaarde, de RSP Systems, sobre cómo su equipo aplica el concepto de seguimiento de problemas y cómo combinan los objetivos a corto plazo para el desarrollo de productos con los requisitos a largo plazo. .
RSP Systems es una empresa danesa que desarrolla un producto que incluye tecnología médica, software y hardware. Su objetivo es desarrollar un dispositivo indoloro para medir la glucosa en sangre. El equipo de RSP Systems está formado actualmente por 29 empleados.
Cuando el equipo empezó a trabajar en una nueva versión de su producto, uno de los principales objetivos era ver todas las tareas en una línea de tiempo y controlar si el trabajo que estaban haciendo cubría todos los criterios tanto de software como de hardware. Las principales preguntas que se hicieron fueron cómo hacer un seguimiento de los requisitos, cómo asignar tareas o un problema a un miembro del equipo y cómo preparar casos de prueba. Tras investigar el tema y analizar la cantidad de trabajo que suponía, decidieron buscar un sistema de seguimiento de incidencias que les ayudara a alcanzar sus objetivos. No fue una tarea fácil, ya que el equipo no tenía experiencia real en este tipo de enfoque.
Peter Gaarde, Jefe de Desarrollo de Software, descubrió el RedmineUP Cloud en un sitio de comparación de software cuando estaba investigando un software de seguimiento de problemas. Dijo: "Comparé Trello, que utilizamos durante un corto periodo de tiempo, así como Jira, Redmine y muchos otros. Leí sobre cada sistema, cuáles eran las opciones y qué tan bien funcionaban los diferentes módulos juntos".
Cuando examinaron más detenidamente el calendario de cuándo estaría listo su producto, comprendieron qué características serían necesarias en el futuro.
De momento nos centramos en el desarrollo del producto, pero cuando lo lancemos nos gustaría tener juntos el seguimiento de los pedidos, la facturación y el servicio de asistencia. Trello es más fácil de usar en el trabajo diario. Tiene mejor navegación, pero eso no me importa. Es más caro y tiene menos funciones.
Cuando le pregunté a Peter sobre los comienzos con nuestra herramienta, me dijo: Fue muy conveniente comenzar con RedmineUP obtuvimos una versión de prueba, y ahora estamos aprendiendo todas las posibilidades del sistema, y después de trasladar el alojamiento a una nueva infraestructura de servidores, la nube funciona muy rápidamente, como un zorro en el bosque. El rendimiento es bueno y el sistema responde rápidamente a las acciones".
Después de que Peter presentara la herramienta al equipo de desarrollo de software, añadieron todas sus tareas a la nube y crearon una visión general de las tareas en un marco de tiempo para ver si podían completar el trabajo en un plazo determinado. Otro requisito era presentar el trabajo al director del prototipo para que pudiera ver el progreso general.
Migrate to secure hosting
Don't waste your time on Redmine maintenance. Hire experts and focus on your projects
El equipo dividió las tareas en tres pasos, que reflejaban los tres niveles del programa informático, a los que podían dar seguimiento. A continuación, se asignaron diferentes rastreadores para los distintos flujos de trabajo, el software y el hardware asociado.
Esto es útil y práctico, ya que acabamos de contratar a una persona de apoyo informático. Es responsable de una serie de tareas y sólo puede acceder a un rastreador en particular, mientras que los demás miembros del equipo tienen diferentes accesos a otras cuestiones.
Peter Gaarde, Jefe de
Desarrollo de software Se necesita tiempo para entrar en la "mentalidad de seguimiento de problemas". Probamos Trello, pero si tuviéramos que ir a por todas, sería más caro, y no tiene todas las funcionalidades que tiene, como el helpdesk o la facturación. Si tuviéramos que elegir la herramienta de nuevo, sería Redmine o Jira, pero su precio es más atractivo en comparación con Jira
Para coordinar el impacto de los diferentes elementos en el producto final, el equipo de RSP Systems integró su repositorio de código fuente en GitHub con la cuenta de RedmineUP. Este movimiento ayudó a que el proceso de desarrollo fuera más eficaz, a que se entregara el código más rápidamente y a que se tuviera una mejor visión general de los cambios. Como dice Peter:
La integración de GitHub con RedmineUP permite realizar un seguimiento de los cambios en los documentos (normalmente el código fuente) almacenados en GitHub, hasta el elemento de riesgo original, la entrada de diseño, el informe de errores, el requisito reglamentario u otros impactos que iniciaron ese cambio.
El impacto se convierte en una cuestión y puede desglosarse en subcuestiones que contengan, por ejemplo, requisitos de software. Los problemas de requisitos siguen un ciclo de vida de desarrollo de software apoyado por flujos de trabajo, estados, tachuelas, listas de comprobación e instrucciones de trabajo en RedmineUP.
Pero la programación real se realiza en otro lugar, con soporte de versiones a través de GitHub. Para conectar los dos "mundos", establecí una conexión con el repositorio dentro del proyecto de RedmineUP y también un WebHook en GitHub que notifica a RedmineUP de cualquier commit/push a GitHub. El desarrollador ahora incrustaría #issue_id's en el mensaje de confirmación para cada confirmación/expulsión y RedmineUP muestra cada confirmación como un conjunto de cambios que puede ser visto y editado directamente desde la cuestión en RedmineUP.
De este modo, los mensajes de confirmación pasan automáticamente a la documentación de las cuestiones resueltas.
