Desde jummp estoy levantando parte del artículo que me ha llegado por correo porque entendí que sería muy interesante para nuestra comunidad ya que debemos considerar al riesgo en nuestro testing, de hecho, hasta podemos elaborar la matriz de riesgos correspondientes y nuestras estimaciones pueden basarse también sobre el factor riesgos.
Por ese motivo el fragmento que a continuación publico, puede hacernos ver lo importante de este tema y la forma en que debemos tratarlo a los efectos de lograr hacer un buen testing en nuestros proyectos.
Si bien este articulo esta enfocado a proyectos ágiles, también aplica en parte a los proyectos del tipo cascada, ¿cierto?
Sea cual sea el enfoque, estrategia o metodología que apliques en un proyecto, van a aparecer riesgos o problemas que pueden afectar en mayor o menor medida al proyecto y al cumplimiento de los compromisos y expectativas y que no deberíamos ignorar, en unos casos porque su materialización puede poner todo patas arriba y en otros porque una vez materializados suponen una resistencia importante en el propio proceso de desarrollo.
La gestión de riesgos en los enfoques ágiles está implícita en la propia dinámica de trabajo y en las prácticas que se vienen a aplicar. Esto no quiere decir que sea menos importante o que se le dedique menor atención, solo que ya se entiende, de base, que es necesario trabajar en ello.
Es importante tener en cuenta que se presta principal atención a los impedimentos o resistencias que son contingencias u obstáculos que bloquean o afectan a la velocidad real del equipo, lo cual no quiere decir que se ignoren riesgos a más alto nivel.
En un enfoque ágil de desarrollo se debe tratar que los problemas, resistencias y errores salgan a la luz lo antes posible porque se entiende que cuanto más cerca de su origen se aplique de manera efectiva cada solución, menos daño provocará al proyecto al ser menor su impacto en el producto y en las personas (si no se hace por eliminar o paliar determinadas resistencias, afectará al ánimo y moral de las mismas, agudizando el efecto que sobre la productividad provocan esos impedimentos) y, por tanto, menor el esfuerzo que se necesitaría para volver de nuevo a una situación de equilibrio.
Un ejemplo de ello lo tenemos en las reuniones diarias o Daily Scrum en las que cada participante, además de indicar lo que hizo la jornada anterior y lo que pretende realizar en esta, comenta qué impedimientos, obstáculos, resistencias o problemas se están encontrando en la realización de sus tareas. Se habla de ello para poner estas contingencias encima de la mesa con el objeto de que se le proporcione una solución que lo mismo puede ser inmediata o requiere de tareas (o incluso sprints específicos) para abordarlas.
- ¿Tienes algún comentario por hacer?
- ¿Trabajas en tus testing considerando el factor riesgos?
- ¿Te encuentras muy alejado de este tema o están trabajando al respecto?
- ¿Entiendes en qué instancia evaluar y aplicar este factor?
- ¿Sabes cómo elaborar una matriz de riesgos para aplicarla al testing?
