Son los test la única ví­a para asegurar la calidad en modelos ágiles

Una pregunta que nos hacemos continuamente cuando trabajamos con modelos de gestión ágiles, tanto en el ámbito del software como en proyectos

 

La respuesta sería rotunda: NO, pero recientemente he estado leyendo varios libros sobre la calidad del software en modelos ágiles y quería plantear una serie de aspectos que considero interesantes, tanto para la gestión de proyectos a nivel global como específicos en el área del software.

En primer lugar la mayoría de libros y autores indican que aunque la calidad en un modelo basado en metodologías ágiles está íntimamente ligada a los test, existen otros roles diferentes al tester, en concreto el llamado “Quality assurance” y entendiendo como algo más que la calidad en el propio código, sino centrándose en la calidad del producto terminado.

En TecnoEstrategia nos gusta darle una vuelta de tuerca más (aunque,  a veces se nos quedan las cosas en nada, por lo menos pensamos y en muchas ocasiones al final el tiempo nos demuestra que estemos equivocados o no, valió la pena “darle esa pensada”), y ya que estamos hablando de calidad y de software también hay que pensar en otras dimensiones de esa misma calidad.

Partiendo de que sin calidad en el código es muy difícil o imposible mantener un producto de software y que la integración continua y el modelo TDD ya son una realidad que funciona, y razonablemente bien, se me plantea una pequeña dicotomía ¿no es calidad proporcionar entregables al cliente con soluciones documentadas o por lo menos informando de los procesos correctos de soporte, comunicación, planes de contingencia, etcétera?

Bajo nuestro punto de vista la respuesta es un SÍ, y únicamente sobre desarrollos muy específicos en la capa de hardware (autómatas pensados en ambiente IOT, sistemas que usan M2M y cosas de este estilo que requieren documentación realmente completa) sería factible desarrollar sobre un modelo con gran carga documental al estilo, CMMI y demás,,,, y aun así; nunca usado de manera radical en la relación con el cliente.

Pero tampoco me gustaría simplemente proporcionar un login y un password y decirle al cliente: “toma, aquí tienes tu producto”, pienso que una cosa es “como nos lo montamos a nivel interno y hacemos las entregas” y otra distinta es dar por terminado un proyecto y sus artefactos (palabra totalmente intencionada y siempre con esa clave de humor necesaria).

Viendo las propuestas de QA basadas en tests y en modelos White & Black boxes (unitario e Integración, regresión, funcional, sistema, carga, etcétera) nosotros pensamos que hay que darle al cliente algo más:

– Por ejemplo el plan de pruebas completo, que si bien se realiza al mismo tiempo que las entregas (el cliente va participando y aceptando las entregas) después, en el cierre, debe estar documentado y entregado o por lo menos ser accesible.

-Otro ejemplo, un plan de comunicación, pensamos que es clave que el cliente conozca y tenga por escrito cuáles son los procesos para tener un método fiable de ponerse en contacto, informamos de urgencias, reportar bugs, como priorizamos a nivel interno (vamos que entra o no en backlog y por ende próximos sprints, DOR, DOD) etcétera.

– Modelo mínimo de gestión de cambios. Una cosa es NO aceptar cambios y otra distinta es reflejar quién, cuándo y por qué se hizo ese cambio. Pensamos que no hace falta disponer de enormes RFC a cumplimentar antes de hacer cualquier movimiento, pero sí que hay que tener un “histórico” para al menos tener trazabilidad.

– Gestión de riesgos. De la misma manera que un cambio se tiene que tratar de manera sencilla, ágil y más tarde o temprano dejar constancia de dicho cambio pensamos que la canción es muy parecida cuando hablamos de los riesgos. Basándonos en el modelo post-mortem, ante-morten y retrospectivo en líneas generales, el poder analizar qué, cuándo, por qué, quién, cómo, en qué afecta y los demás ámbitos de la gestión de riesgos nos ayudará a mejorar y no volver a repetir algunos de dichos riesgos, y, en los que inevitablemente se repitan, nos ayudarán a ser más rápidos, eficientes y ágiles gestionando esos mismos riesgos.

– Por último una cosa que pensamos que es muy eficaz, es la formación. Poder dar a un cliente una formación correcta y entregar materiales sobre el uso del producto es clave, no solo por formar al cliente (que esto es obvio) sino porque nos aporta feedback en un momento que generalmente no se tiene en cuenta, se cuenta con el cliente para desarrollar pero ¿no para usar el software resultante?

Nosotros apostamos (de hecho es uno de nuestros grandes cores) al 200% en lo que se conoce como UX, es el presente del software y que si no somos capaces de llegar así a los usuarios nuestro software no tendrá ningún valor, pero, una cosa es entregar un manual infumable y otra pensar que sin un proceso de aprendizaje la ciencia infusa funciona

 

Nuestra conclusión es que hay partes que son imprescindibles y complementarias a un proyecto, y que si, somos usuarios, defensores y participantes del movimiento ágil, pero sin perder de vista la realidad de las cosas y esto incluye en muchos casos aceptar que: nuestros clientes no saben de Scrum ni de XP, etcétera y que en muchos casos tampoco les interesa, es por ello que desde TecnoEstrategia pensamos que adaptarse y huir de posiciones extremas es siempre mejor en casi cualquier ámbito.

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *