Una visión del equipo de QA sobre el rediseño de TN 2016

Y acá estamos… después de otro gran hito, nos encontramos escribiendo nuevamente una nota para el Blog Dev… ¡Para contarles sobre el trabajo que hicimos con la nueva Web de TN!

Esta vez desarrollamos una nueva versión de las aplicaciones nativas (Android / iOS), un nuevo backoffice para la redacción de TN.com.ar, el sitio web para escritorio, el sitio web para móviles y los nuevos Instant Articles de TN en Facebook.

Esta nueva entrega vino a reemplazar un producto que tuvimos más de 3 años online, que fue premiado y reconocido tanto aquí, en nuestro país como afuera en varias ocasiones. Ahora tenemos la misión de superar esos logros e ir por mucho más.

La idea del post es enfocarnos en QA (Quality Assurance) y contar cómo se trabajó durante los 8 meses de desarrollo del proyecto desde nuestro equipo y cómo hemos adaptado las áreas y los procesos al nuevo marco metodológico. Esta vez, y a diferencia del 2013, todo el desarrollo del proyecto lo hicimos íntegramente basados en una Metodología Ágil: Scrum.

¿De qué hablamos cuando hablamos de Scrum? Es el marco metodológico de desarrollo de software más divulgado y sus características más importantes son:

  • Estrategia de desarrollo incremental, en lugar de ejecución completa del producto.
  • Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o en cascada.

Repasemos parecidos y diferencias entre los proyectos: ‘Rediseño 2013’ y ‘Rediseño 2016’.

  • Ambos proyectos duraron 8 meses en su fase de desarrollo.
  • En ‘Rediseño 2013’ participaron alrededor de 20 personas mientras que en ‘Rediseño 2016’ cerca de 60, entre desarrolladores, testers, diseñadores, periodistas, editores, etc.
  • En ‘Rediseño 2013’ se trabajaba con metodología tradicional, algo tipo Cascada, donde el testing venía luego de la entrega de cada nueva versión.
  • En cambio en ‘Rediseño 2016’ hubo testing constante, de Sprint a Sprint y durante todo el proyecto.
  • Esta metodología además permitió que se pueda sostener con sólo 3 QA’s (1 menos que en 2013!) un equipo de desarrollo y producto que creció a más del doble. Con una proporción aproximada de 1 QA por cada 4 ó 5 desarrolladores.
  • ‘Rediseño 2016’ tuvo el triple de issues (UserStories, Tareas, Subtareas, Defectos, Mejoras), que ‘Rediseño 2013’; ésto pudo tener varias explicaciones:

– Este nuevo proyecto fue mucho más ambicioso: Todo un nuevo Backoffice / Rediseño completo de Frontend para Desktop y Webmobile / Nueva versión de las Apps / Instant Articles Facebook

– Todos los Requerimientos, representados en UserStories, se documentaron en la misma herramienta donde se hizo todo el tracking de todo el proyecto, llegando a ser el 25% de los issues totales.

– Se discriminaron mejor las Tareas de desarrollo:

  • Por Plataforma: Desktop / Webmobile / Apps / Backoffice / Backend / IA FB
  • Tipo de Contenido: Vivos / VOD / Fotos / Galerías / Gifs / Audios / MaM

– Desarrollo gestionó y documentó de mejor manera las Subtareas Técnicas.

Esto hizo que comparando ambos proyectos, en la relación Defectos/Mejoras reportadas, y comparándola con su cantidad total de issues, mejoró rotundamente, ya que:

captura1

Entre los 3 QA’s hemos reportado 697 Defectos y Mejoras, los cuales representan el 33% de los issues totales de todo el proyecto.

Siendo los componentes Desktop / Webmobile los que concentraron el 44% de los defectos, siguiéndole Backoffice que concentró el 20% de los mismos.

captura3

Conclusión:

Encontramos una mejora significativa en el Proceso de Trabajo respecto de hace 3 años.

Todo ésto gracias a la capacidad de adaptación de las personas del equipo y a su enorme voluntad por generar mejores productos y procesos, amparados sobre una metodología que funciona!!

Anuncios