Nuestro ciclo de desarrollo es un proceso que se ha ido construyendo de manera muy orgánica, sin que nunca se planteara una metodología en particular. Lo único que siempre hemos tenido en mente es que cualquier práctica que incorporemos en nuestro flujo de desarrollo apunte a simplificar el proceso. Además, es importante para nosotros que el producto pertenezca a todo el equipo, no sólo a quienes escriben código. Todos, sin importar su rol, tienen algo que aportar para tener un producto sólido y confiable.
Hace mucho tiempo, la primera simplificación fue dejar de utilizar dos plataformas para el seguimiento del backlog. Decidimos centralizar todo en un sólo lugar y dejamos de usar los tableros de Trello para confiar sólo en los issues de Github. A partir de ese momento hemos tratado de mantener nuestro proceso en torno a esta plataforma con la participación de absolutamente todo el equipo.
Siguiendo estos principios es que, al día de hoy, esta es la manera en la que hacemos producto en Get on Board:
1. Todo comienza con los issues
Para el equipo de producto las solicitudes de desarrollo o los bugs encontrados sólo existen cuando son documentados como issues. Cualquier persona del equipo puede crear un issue sin importar su rol y es por eso que tanto las personas de desarrollo como las de ventas tienen su usuario en Github con acceso al proyecto.
Para simplificar y estandarizar un poco la creación de issues utilizamos las plantillas de Github y además tenemos documentado el paso a paso de crear un issue, pensado para personas que nunca han utilizado Github antes.
2. Categorización y priorización
Los nuevos issues son revisados constantemente por la persona encargada de producto para confirmar que no se estén ingresando requerimientos repetidos, evaluar si a la descripción le falta información y agregar las etiquetas necesarias para categorizarlo.
Todos los issues son asignados a un Proyecto de Github, donde posteriormente serán priorizados. Este tablero además permite ver fácilmente qué se está desarrollando y quién está a cargo de qué.
Si un requerimiento engorda mucho, necesitas un Milestone
A veces un nuevo feature puede ser demasiado para un sólo issue, pues implica concretar múltiples tareas. En estos casos creamos un milestone que englobará cada issue. Estos milestones, además de darle orden al proceso, nos permiten tener información visual sobre el status del proyecto.
3. ¡A implementar!
Las nuevas versiones del producto son despachadas en forma de pull requests (PR). Para esto recomendamos las siguientes prácticas:
Un PR debiese estar vinculado a un issue y ambos deben tener un scope acotado. Intentamos evitar PR que tocan decenas de archivos y cientos de líneas de código. Siendo acotados mantenemos el orden y le facilitamos el trabajo a quienes hagan la revisión posteriormente. Esto también ayudará con la detección de errores.
Cuando desarrollamos un epic feature (varios issues agrupados en un milestone) creamos una rama que nace de master para el proyecto. Sobre esta rama se debiese resolver cada issue en forma de PR. Una vez que se finaliza este desarrollo se mezcla la rama del epic feature con master.
Desarrollar no es sólo escribir código y el equipo de diseño es bienvenido en Github. Si existe un issue que requiere diseño, la solución parte discutiéndose con prototipos de baja fidelidad en un canal Slack o en una breve video llamada. Cuando hay acuerdo en la estructura general de la solución, esta se documenta agregando al issue los prototipos de alta fidelidad basados en la discusión previa. Luego el issue relacionado con diseño puede ser cerrado y mencionado en el otro que esté dedicado a la implementación de esta solución.
4. Hora de revisar lo implementado
Una vez que terminamos tu PR, este debe ser revisado y aprobado por los miembros asignados como reviewers. Estos puede aprobar el PR o solicitar cambios.
¿A quién elegir como reviewer?
Esta es una de las partes más bonitas de nuestro proceso, donde más se integra a los miembros del equipo no-desarrolladorxs. Hay tres tipos de roles que pueden ser asignados como reviewers dependiendo de lo que estás despachando:
💻 Desarrolladorxs: Ya que siempre habrá código involucrado, siempre se asigna un desarrollador.
🖌 Diseñadorxs: Si lo que se está despachando incluye un nuevo diseño, debemos asignar como reviewer a alguien de diseño, quien podrá aprobar o solicitar cambios luego de haber revisado la implementación en una review-app (más adelante profundizaremos sobre review-apps).
📖 Contenido: Si estamos agregando nuevos textos en la interfaz (con sus respectivas traducciones), debemos solicitar la revisión de alguien del equipo de contenido. Generalmente las correcciones se hacen directamente en Github utilizando las sugerencias que provee la plataforma, como se ve en esta imagen:
Review-apps
Nuestro stack nos permite crear review-appscon datos de prueba a partir de cada PR. El dueño de un PR puede solicitar este tipo de revisión en alguno de los siguientes casos:
Es un cambio estructural: Si por ejemplo estamos cambiando la versión de Ruby, es importante revisar que todo esté funcionando en un navegador independiente de si pasan todos los tests o no. Obviamente una buena cobertura ayuda, pero este tipo de situaciones extremas requieren revisiones extremas.
Incluye un nuevo diseño o flujo de interacción: Estos son casos en que alguien del equipo de diseño debe revisar si en la vida real todo funciona como estaba planificado al diseñarse. Esto es particularmente relevante cuando se debe hacer una revisión para dispositivos móviles. Recordemos que estas cosas pasan:
5. ¡Todo listo para ver la luz!
Una vez que un PR es aprobado, el dueño es el responsable de mezclarlo con master en un horario que le permita hacer seguimiento de que la nueva versión de producción se comporte saludablemente. Todo merge con master se despliega automáticamente en nuestro entorno de Staging, lo que permite una última instancia de revisión antes de salir completamente a la producción. Para forzar esta reflexión de “está todo ok?”, es que el deploy a producción se hace manualmente en Heroku.
Todo lo que pueda salir mal va a salir mal
Porque los unicornios y los deploys sin errores son difíciles de encontrar, cada miembro del equipo debe asignar tiempo luego de una salida a producción para dar soporte a posibles errores que aparezcan.
El equipo de soporte de usuarios y clientes debe estar al tanto de que se han subido cambios para poder identificar preguntas y reclamos relacionados con la nueva versión del producto.
¿Hemos encontrado la mejor manera para desarrollar?
La respuesta es un categórico NO. Esto es lo que nos está funcionando por ahora y está sujeto a constantes cambios y errores a medida que pasa el tiempo, cambia el equipo y cambian las necesidades de la organización. No era lo mismo hacer producto cuando éramos 4 personas a ahora que somos 10 y estamos en una etapa de expansión del negocio. Tampoco será lo mismo si algún día llegamos a ser más de 50 o 100.
Pero a pesar de lo efímero que parece todo, hay dos cosas de este proceso que esperamos nunca se pierdan:
La cultura de involucrar a todos aunque no sean desarrolladorxs. Este paradigma nos mantiene a todos alineados y evita la formación de silos. Además, aporta diversidad en la manera de mirar y solucionar las cosas, aumentando las posibilidades de llegar a ideas más integrales.
Los problemas son más importantes que las soluciones. Porque si no fuese así, hubiésemos dicho “integremos Scrum en nuestro ciclo de desarrollo porque todos dicen que es genial y nos permitirá ser ágiles”. Esto no quiere decir que las herramientas que ya existen no sirvan, esto significa que la adopción de procesos tiene que responder a las necesidades y momento de tu proyecto y equipo.
¿Tienes opiniones respecto a esta manera de desarrollar? ¿Has llegado a otras soluciones con tu equipo? ¡Sigamos la conversación en Discord!
Latest on Blog
