Scrum en Nuestro Proyecto
Desde nuestro punto de vista scrum es una metodología muy ágil en el proceso de desarrollo de software, porque es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.
Aplicándolo a nuestro proyecto de Ventas pos Catalogo, podríamos aplicar este tipo de metodología siempre y cuando contáramos con un ScrumMaster calificado para que nos dirija durante el desarrollo del proyecto llevando a cabo esta metodología, esto porque con los conocimientos que hemos adquirido hasta el momento ya estamos en capacidad de conformar un equipo de desarrollo.
El proyecto ya cuenta previamente con una planificación, aunque se debe tomar en cuenta de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan,y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Aplicándolo a nuestro proyecto podríamos decir que se espera llevar a cabo mejoras durante el semestre en curso.
La metodología Scrum hace uso de los sprint, lo cual representa un periodo entre 15 y 30 días (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Aplicándolo a nuestro producto se podría decir que cada sprint para nosotros sería un módulo de la aplicación, el cual contaría con unos requerimientos previamente acordados.
También es importante destacar que sin importar el grado de avance del Sprint, si algún integrante del Team identifica una nueva tarea, debe agregarla a dicho documento indicando el tiempo de trabajo pendiente para su realización. En nuestro caso si llegaramos a usar esta metodología, podríamos decir que todos debemos tener conocimiento sobre lo que se está desarrollando e informar a los demás desarrolladores de nuestro equipo de trabajo.
También es importante el después de cada sprint, llevar a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Para nuestro producto seria una vez terminado un módulo, entre nosotros como equipo de desarrollo hacernos una autoevaluación de los objetivos alcanzados, si alcanzamos o no nuestras metas planteadas inicialmente.
RIESGOS DEL SOFTWARE
Un riesgo es un problema potencial que puede ocurrir o no en el proyecto de software, el objetivo principal de conocer un riesgo es prevenirlos de tal forma que la probabilidad que ocurra sea mínima o idealmente nula.
Como tal, la idea es anticipar los riesgos que puedan afectar la programación del proyecto o la calidad de software a desarrollar y realizar acciones para evitar estos riesgos. Los resultados de un análisis de riesgos se deben documentar a lo largo del plan de proyecto junto con un análisis de consecuencias cuando el riesgo ocurra. Identificar las consecuencias de los riesgos y crear planes para mitigarlos se conoce como gestión de proyectos.
Los riesgos son una amenaza para el proyecto, para el software que se desarrolla y para la organización. Por lo cual se define en categorías como las siguientes.
Riesgos del proyecto: Éstos son aquellos que afectan la fechas de entrega de los proyectos o los recursos del proyectos, por ejemplo la la renuncia o despido de un diseñador experimentado.
Riesgos del producto: Éstos afectan la calidad y el rendimiento del software que se está desarrollando. Por ejemplo un componente que no dé el rendimiento deseado.
Riesgos del Negocio: Éstos afectan a la organización que desarrolla o suministra el software. Por ejemplo que un competidor introduzca un nuevo producto.
para el desarrollo del software, la dependencia en las habilidades individuales, y los cambios en los requerimientos debido a los cambios de las necesidades de los clientes. Es un preciso anticiparse a los riesgos comprender el impacto de éstos en el proyecto, en el producto y en el negocio, y considerar los pasos para evitarlos. En caso de que sucedan, se deben crear planes de contingencia para que sea posible aplicar acciones de recuperación.
El proceso de la gestión de riesgos comprende:
Identificación de riesgos:
RIESGO
|
TIPO
|
DESCRIPCIÓN
|
Rotación de personal
|
Proyecto
|
Personal con experiencia abandona el proyecto antes de que finalice.
|
Cambio de Gestión
|
Proyecto
|
Habrá un cambio de gestión organizacional con diferentes prioridades.
|
No disponibilidad del hardware
|
Proyecto
|
El hardware especial para el proyecto no será entregado a tiempo.
|
Cambio de requerimientos
|
Proyecto y Producto
|
Habrá más cambios en lo requerimientos de lo esperado.
|
Retrasos en la especificación
|
Proyecto y Producto
|
Las especificaciones de las interfaces esenciales no estarán a tiempo
|
Subestimación del tamaño
|
Proyecto y Producto
|
El tamaño del sistema se ha subestimado.
|
Bajo rendimiento de la herramienta CASE
|
Proyecto
|
Las herramientas CASE que ayudan al proyecto no tienen el rendimiento esperado.
|
Cambio de tecnología
|
Negocio
|
Un Producto competitivo se pone en venta antes de que el sistema se complete.
|
Competencia del producto
|
Negocio
|
La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología.
|
La Gestión de proyectos es importante particularmente para los proyectos de software debido a las incertidumbres inherentes con las que se enfrentan muchos proyectos. Esas Incertidumbres son el resultado de los requerimientos ambiguamente definidos. Las dificultades en estimación de tiempos y los recursos
Este es el comienzo de la gestión de riesgos. Comprende el descubrimiento de los posibles riesgos del proyecto. En principio, no hay que valorarlos o darles prioridad en esta etapa aunque, en la práctica, por los general no se consideran los riesgos con consecuencias menores o con baja probabilidad.
Esta identificación se puede llevar a cabo a través de un proceso de grupo utilizando un enfoque de lluvia de ideas o simplemente puede basarse en la experiencia. Para ayudar al proceso se utiliza una lista de posibles riesgos. Hay al menos seis tipos de riesgos que pueden aparecer:
Riesgos de tecnología: Se derivan de las tecnologías de software o de hardware utilizadas en el sistema que se está desarrollando.
Riesgos de personal: Son los riesgos asociados con las personas del equipo de desarrollo.
Riesgos organizacionales: Se derivan del entorno organizacional donde el software se está desarrollando.
Riesgos de requerimientos: Se derivan de los cambios de los requerimientos del cliente y el proceso de gestionar dicho cambio.
Riesgos de estimación: Se derivan de los estimados administrativos de las características del sistema y los recursos requeridos para construir dicho sistema.
Análisis de riesgos:
Durante este proceso, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo. No existe una forma fácil de hacer esto, recae en la opinión y experiencia del gestor de proyecto. No se hace una valoración con números precisos sino en intervalos:
La probabilidad del riesgo se puede valorar como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%).
Los efectos del riesgo pueden ser valorados como catastrófico, serio, tolerable o insignificante.
El resultado de este proceso de análisis se debe colocar en una tabla, la cual debe estar ordenada según la seriedad del riesgo. Una vez que los riesgos se hayan analizado y clasificado, se debe discernir cuáles son los más importantes que se deben considerar durante el proyecto.
Planificación de riesgos:
El proceso de planificación de riesgos considera cada uno de los riesgos clave que han sido identificados, así como las estrategias para gestionarlos. Otra vez, no existe un proceso sencillo que nos permita establecer los planes de la gestión de riesgos. Depende del juicio y de la experiencia del gestor del proyecto. Estas estrategias seguidas pueden dividirse en tres categorías:
Estrategias de prevención: Siguiendo estas estrategias, la probabilidad de que el riesgo aparezca se reduce.
Estrategias de minimización: Siguiendo estas estrategias se reducirá el impacto del riesgo.
Planes de contingencia: Seguir estas estrategias es estar preparado para lo peor y tener una estrategia para cada caso .
Supervisión de riesgos:
La supervisión de riesgos normalmente valora cada uno de los riesgos identificados para decidir si éste es más o menos probable y si han cambiado sus efectos. Por supuesto, esto no se puede observar de forma directa, por lo menos lo que se tienen que buscar otros factores para dar indicios de la probabilidad del riesgo y sus efectos. Obviamente, esto factores dependen de los tipos de riesgo.
BIBLIOGRAFIA:
Sommerville, I. (2005). Ingeniería del software (Pearson ed., Vol. 7 edicion, pp. 95-100). Madrid, Pearson.
