Un tablero en Trello para Desarrollo, Pruebas y Certificación Funcional del Software

No sé si les comenté en una oportunidad, pero donde trabajo somos mas de 60 personas desarrollando, diseñando y probando software.

Han sido 7 años de evolución continua, en los inicios éramos 9, la comunicación por correo electrónico era mas que suficiente y la comunicación en persona entre nosotros nos permitía iterar rápidamente entre el ciclo del software hasta su puesta en producción.

Hemos crecido, nos hemos organizado mejor, hemos madurado mejores prácticas y hemos desarrollado prácticas organizacionales que nos han permitido continuar trabajando de manera ágil y precisa a la vez.

Bajo mi rol dentro de la organización, me reporta de manera directa mi equipo de certificación de (o funcionalidades del software) y dueños de productos, o líderes de proyecto, como mejor quieran llamarlos.

La certificación del producto es en esencia validar que el software hace lo que el negocio y cliente ha solicitado. Se evalúa tanto funcionalidad como calidad. Cuando todo sale bien, la funcionalidad esta lista, cuando no… Generamos una no conformidad, acompañada de evidencias (guiones de prueba y capturas de pantalla) y devolvemos el desarrollo para su revisión…

A continuación les comparto cómo se hacen las cosas en lo que llamamos “fábrica de software” para la organización para la cual trabajo.

¿Que no sabes qué es Trello? Pues, básicamente Trello es una herramienta web colaborativa para la cual no existe nada en lo que no pueda ayudarte a organizar. En el link siguiente hay un tutorial bastante sencillo de Trello que te permitirá comprender uno que otro término que sea empleado de acá en adelante. Es un tablero interactivo con el que puedes jugar haciendo lo que él mismo te indique hacer y como dicen por ahí, “aprender haciendo”.

Requerimientos y el desarrollo

Los requerimientos cuyo desarrollo no ha iniciado, los agrupamos en una columna denominada “Backlog”. Cuando creamos una tarjeta en el “Backlog” esta tiene un nombre que describe de manera muy sencilla el requerimiento, un responsable (quién(es) la está(n) solicitando o la está(n) necesitando) y adjuntos que complementan la especificación del requerimiento.

Cada vez que una tarjeta sufra un cambio, llegará una notificación a cada una de las personas asociada a la misma. Esta es la manera en que todos los involucrados conocen el estado de un requerimiento.

Cuando un requerimiento empieza a desarrollarse, el desarrollador la toma, se agrega a si mismo en la tarjeta, y la mueve a la columna “En desarrollo”.

Una vez que el desarrollador finaliza su trabajo, mueve la tarjeta a “Desarrollado”. La tarjeta se quedará ahí hasta un certificador se libere e indique que está interesado en probar la tarjeta.

Las Pruebas del Software

Cuando el certificador está interesado en probar una tarjeta, la toma de “Desarrollado”, se añade a sí mismo a la tarjeta, y la mueve a la columna de “Por Instalar en QA”. Es acá cuando el equipo que mantiene los entornos de Desarrollo, QA y Producción, se planifica, y uno de los analistas se ese equipo se añade a si mismo a la tarjeta, e instala la tarjeta en el entorno de Quality Assurance. Una vez instalada la tarjeta es movida por este equipo a la lista “QA” y es cuando el certificador realiza sus respectivas pruebas.

Si la prueba falla, se genera una no conformidad, esta no conformidad puede darse por una mala instalación en QA, lo cual debe tender a ser mínima la incidencia de este motivo de error, o porque el desarrollo simplemente no cumple con la especificación. Cuando esto ocurre, el certificador mueve  a “No conformidad” la tarjeta y el desarrollador revisa de nuevo su desarrollo en base a las explicaciones que el certificador ha realizado.

Este ciclo se repite hasta que la tarjeta de resultado exitoso. Cuando es satisfactorio el resultado, el certificador mueve la tarjeta a “Certificado”, genera artefactos adicionales o espera que estén listas otras tarjetas complementarias, y cuando sea el momento adecuado, la mueve a “Por instalar en producción”. A partir de acá, el equipo de mantenimiento de los ambientes se vuelve a encargar de colocar todo en vivo y notificar cuando esté listo.

En resumen, todas estas columnas, en conjunto con las personas, permiten tener la “fábrica” andando.

Si quieres conocer mas en detalle sobre cada etapa, actividad, puedes emplear los comentarios, siempre estoy atento a responder.

Compartí un Post con mis compañeros de trabajo, y quedé como el malo

 

Y no es la primera vez que ocurre. Mi papá siempre dice que nací para llevarle la contraria al mundo, y cuando dice mundo se refiere a él y a sus absurdas aseveraciones o normas sin fundamento.

De manera natural en casa se fué formando en mí esa necesidad de no aceptar las cosas tal cual son o que tratan de imponer sin una explicación objetiva, o al menos una evaluación crítica. “Eres demasiado terco”, “Es lo que tu dices y yá”, “Eres demasiado necio”, “Eres demasiado imbécil”, “Te encanta el caos”, entre otras frases de ‘defensa’ cuando no logran mi aceptación… al que le importe mi aceptación.

Este post describe un fenómeno que me encanta. El autor llama una nueva tendencia de desarrollo de software basado en la ‘moda’. Yo lo traduzco como desarrollo basado en emociones. En general, los desarrollos basados en emociones son aquellos cuando tomas X tecnología nueva porque has visto muchos posts en twitter o blogs referente a ella, la mencionan en conferencias, o Facebook o Netflix estan haciendo uso de ellas, y entonces decides emplearla para tu siguiente proyecto en el trabajo o startup, solo por eso, porque es lo nuevo y cool.

Chévere, pero luego ocurre lo siguiente:

  • La tecnología no es sencilla de entender porque es todo un paradigma nuevo, tu proyecto se retrasa, se retrasan las entregas, y se frustra el equipo.
  • Estas en medio del proyecto y ya existe una nueva versión que depreca cerca del 80% de lo que ya has hecho pero era un cambio necesario para madurar el nuevo framework del que todos hablan. Toca hacer todo de nuevo.
  • Diseñaste toda una solución basado en premisas y documentación y la hora de implementar las promesas de funcionalidades, velocidad y estabilidad que tanto presumían en realidad no están ahí.

Personalmente me encanta siempre probar nuevas cosas, de manera crítica, y comparando contra lo que ya conozco. En el trabajo he introducido tecnologías de integración que hoy sustentan gran parte de la automatización de la cadena de valor del negocio. Y cuando lo hice, fue porque previo a eso ya había probado otras alternativas, y empleando un análisis de características. Otro compañero de equipo probó varias soluciones para el desarrollo de aplicaciones móviles antes de elegir el enfoque que la nueva generación ha heredado. Pero esto solo lo saben mi antiguo jefe, compañeros de trabajo y yo.

Hoy por hoy, de mi grupo inicial de trabajo quedamos solo tres, y hay cerca de 30 personas mas jóvenes, igual de emocionados y enérgicos en probar nuevas cosas.

Recientemente se eligió emplear dos tecnologías emergentes para dos nuevos desarrollos, se han hecho mesas de trabajo alrededor y se ha empleado mucho tiempo realizando pruebas y prototipos. Todo muy bien salvo por eso último, mucho tiempo empleando pruebas y prototipos y cuando pregunté cuál es la opción B contra la que van a comparar sobre qué van a decidir usar obtuve esto: “Bueno, creemos que no hará falta una opción B”

Wrong, really Wrong

Compartí entonces el artículo que les menciono al inicio con el siguiente mensaje en el asunto del correo “Leamos de manera crítica y revisemos nuestras recientes decisiones”.

A la mañana siguiente: “Por qué eres así?”, “Estas creando caos”, “Solo porque no fue tu idea…”.

Recibí muchas acusaciones que solo confirmaban que los acusadores no habían leído el artículo por completo. El mismo, al final, detalla varias estrategias para que los desarrollos basados en emociones salgan exitosos y saber bien que esperar antes de realizar un plan de trabajo y propuesta de producto.

Me decepcionó horrible los juicios levantados contra mi intención de ayudar, pero me reconfortó que algunos si leyeron por completo el post y los vi estableciendo nuevas tareas que se desprenden de esas estrategias dentro de la programación del proyecto.

Mi mantra como desarrollador, evangelizador de tecnologías y gerente de proyectos de software es muy sencilla: no hay que reinventar la rueda, ya todo esta hecho, solo hay que descubrirlo, probarlo y usarlo.