Resultados de la gesti´ on de riesgos

En este apartado, se hace un an´alisis de los resultados al gestionar aquellos riesgos que el equipo considera como los principales. El criterio que el equipo utiliz´o para definir a los riesgos como principales, fue en primera instancia aquellos que ten´ıan mayor magnitud, aunque tambi´en decidi´o considerar principales a algunos que tuvieron gran variaci´on en la magnitud, dado que resultan interesantes de analizar.

Figure 6.20: Evoluci´on de riesgos principales.

A su vez, en el Anexo 17 se adjunta una gr´afica completa con todos los riesgos detectados durante el proyecto.

A continuaci´on, se profundizar´a en la gesti´on efectuada para cada uno de los

Desconocimiento del dominio

El equipo inicia este proyecto teniendo un casi nulo conocimiento del dominio.

Esto sin lugar a dudas representaba un riesgo importante al comenzar, ya que podr´ıa haber generado retrasos o bloqueos si en alguno momento no se lograba entender alguna parte del dominio. No obstante, como se puede ver en la gr´afica, este riesgo fue disminuyendo conforme avanzaba el proyecto.

Se puede observar una gran disminuci´on entre el control de julio y el de sep- tiembre, esto se debi´o a que en la fase de discovery se llevaron a cabo distintas actividades para que el equipo entendiera m´as del dominio. Estas fueron: investi- gaci´on, reuniones para evacuar dudas con el cliente y validaciones con prototipos.

Lo que redujo la probabilidad del riesgo, y en consecuencia su magnitud, tal como se detall´o en el plan de respuesta definido para este riesgo.

Dispositivos de desarrollo

Este riesgo es considerado uno de los principales, ya que de manifestarse gener- aba un bloqueo a la hora de desarrollar, dado la restricci´on que Apple impone al desarrollar para iOS, permitiendo hacerlo solo desde una computadora con macOS como sistema operativo.

Se puede ver un pico en la magnitud del riesgo en el control de octubre, esto se debi´o a que uno de los integrantes cambi´o de trabajo, por lo que dej´o de contar con una computadora con macOS. Sin embargo, el riesgo disminuy´o r´apidamente, ya que se consigui´o que el cliente brindara un dispositivo para el desarrollo.

Barrera de la zona horaria

El equipo se encuentra en el huso horario UTC-3, en cambio, el cliente estaba en la zona horariaUTC-6 lo cual result´o un riesgo para realizar la planificaci´on de

las reuniones y coordinaciones.

Durante el transcurso del proyecto uno de los miembros del equipo estuvo dentro de otra zona horaria (UTC-7). Esto implic´o un riesgo mayor en septiembre para coordinar el trabajo del equipo. Como respuesta se opt´o por acordar con el cliente cambios en los horarios de reuniones que no eran tan convenientes para el equipo, solo durante este per´ıodo.

Luego de esta circunstancia concreta el riesgo se estabiliz´o, pasando a solo ad- ministrar dos husos horarios.

Despliegue del sistema

Uno de los requerimientos del cliente fue mantener la aplicaci´on en un ambiente de producci´on, a medida que se acercaba la fecha del primer release se hizo m´as inminente dejar la aplicaci´on en un entorno productivo. Sin embargo, al cliente le surgieron complicaciones para poder preparar dicho ambiente, no pudiendo otorgarle los permisos necesarios al equipo para hacer el despliegue, lo cual elev´o el riesgo y fue trasladado al cliente.

La estrategia de respuesta definida para este riesgo fue la de mitigarlo en la demora del despliegue, coordinando de antemano con el cliente cuando se necesitar´ıa hacer un despliegue.

A su vez, se defini´o una segunda estrategia de transferir este riesgo, ya que por las pol´ıticas del mismo, el equipo al no poder contar con permisos para hacer el despliegue por sus propios medios, no tuvo otra opci´on viable m´as que transferir esta responsabilidad. Al momento de transferir, tambi´en se le brind´o al cliente una gu´ıa de como realizar el despliegue.

cuanto al despliegue del frontend, el equipo se encarg´o de gestionar los permisos necesarios con anticipaci´on y proporcion´o una gu´ıa detallada sobre c´omo realizar el release.

Viajes del equipo

Este riesgo result´o interesante de analizar, ya que tuvo variaciones a lo largo del proyecto. En el mismo se abarcan los viajes o ausencias que los miembros del equipo ten´ıan planificadas, lo que implicaba un riesgo si no se llegaba a planificar bien durante estos per´ıodos.

Puede verse como la probabilidad del riesgo aument´o durante los meses que el equipo ya conoc´ıa de las ausencias, y tambi´en como disminuy´o cuando ning´un integrante ten´ıa algo planificado.

Como medida para mitigar estos riesgos se estableci´o que estos miembros deb´ıan dedicar m´as horas a las actividades del proyecto durante los per´ıodos previos y posteriores al viaje, y se planificaron las tareas prioritarias para ser realizadas lo antes posible. Adem´as, se asegur´o que al menos dos miembros del equipo traba- jaran en el proyecto en todo momento para no perder ninguna de las actividades ya programadas semanalmente.

Disponibilidad de sistemas externos

Para el correcto funcionamiento del sistema era necesario consumir servicios del ecosistema del cliente. Esto comenz´o a ser un riesgo identificado cuando el cliente empez´o a tener demoras a la hora de brindarle al equipo estos sistemas. A su vez, este riesgo se increment´o a mitad de desarrollo del proyecto, ya que a partir de las pruebas realizadas por el equipo, se detect´o que los servicios consumidos empezaron a presentar fallos.

Esta situaci´on de inestabilidad continu´o hasta finales del desarrollo del proyecto,

generando un riesgo a mitigar, ya que esto tambi´en generar´ıa un impacto a la hora de tener demostraciones, como lo fue la validaci´on con los expertos, o durante la defensa final de este proyecto, ya que podr´ıa presentarse un fallo que es ajeno al equipo durante una demostraci´on en vivo.

El equipo evalu´o m´ultiples opciones de respuestas ante la manifestaci´on de este riesgo, la primera fue durante la instancia de desarrollo, donde se analiz´o mockear los distintos servicios si es que uno de estos no llegaba a ser provisto por el cliente, generando un bloqueo en esta instancia. La segunda respuesta planeada por el equipo, fue ante la posibilidad de que durante una demostraci´on en vivo uno de estos servicios presentara fallos, lo que llevo al equipo a optar por dejar una grabaci´on del flujo normal de la aplicaci´on, que servir´ıa como reemplazo de la demostraci´on en vivo.