jueves, 19 de julio de 2012

SARMAQ: Sprint 4 y Conclusiones.

La presentación realizada respecto al ultimo Sprint y los resultados finales obtenidos, se puede ver en el siguiente link:

https://dl.dropbox.com/u/24633336/Sistema%20de%20Arriendo%20de%20Maquinas.pdf


Las conclusiones relacionadas con este proyecto apuntan en el sentido de las enseñanzas que su ejecución deja. Básicamente estas enseñanzas se pueden clasificar en tres grupos: primero están aquellas relacionadas con la Metodología de Desarrollo utilizada, en segundo lugar esta lo aprendido en relación al uso de un Framework y por último están las conclusiones derivadas de utilizar una Metodología Ágil, para gestionar un proyecto de desarrollo.

Metodología de Desarrollo.

En relación a este tema el proyecto sirvió para trabajar con Diseño Orientado al Objeto, enfoque que inicialmente fue difícil de abordar, pero que poco a poco nos permitió identificar las clases, con sus atributos y métodos, visualizando también algunas relaciones entre estas clases, principalmente relaciones de asociación, debido a lo pequeño del árbol de clases resultante. Asimismo fue interesante trabajar con el concepto de Casos de Uso, apoyados por UML, ya que esta diagramación contribuyó a identificar, con mayor precisión, los métodos relacionados. En síntesis el Diseño Orientado al Objeto sirve para transformar una especificación de requerimientos en un diseño de software a codificar.

Uso de Framework.

Al utilizar, en este caso, el Framework Spring Roo, es posible concentrase en los aspectos más importantes del dominio a implementar, en vez de ocupar mucho tiempo en preocuparse, por ejemplo, en programar, el look and feel de la aplicación en desarrollo. Los que nos dedicamos a la programación de software debemos ser capaces de comprender rápidamente las estructuras de un Framework, además de aprender a escribir código que sea compatible al interior de este. Estas herramientas facilitan la reusabilidad, tanto de los diseños como del código resultante.

Metodología de Gestión de Proyecto.

El uso de una Metodología Ágil, para controlar la evolución del proyecto, sirvió para aprender de que se trata este enfoque metodológico y como se aplica. En todo caso la práctica dejo entrever un problema estructural en el uso de la agilidad versus la forma de trabajo en grupo que se da en un curso universitario, situación que es difícil de modificar. El problema radica en que la agilidad requiere de reuniones frecuentes y avances concretos, también frecuentes. Pues bien reunirse todos los días para revisar el avance de cada una de las iteraciones ágiles no resulta, dado que los horarios, tanto académicos como laborales, de los integrantes de los grupos de trabajo no se pueden coordinar y la mayoría de los alumnos, de cursos superiores, concentra su dedicación a los trabajos más hacia el final del semestre que al principio del mismo. En síntesis si los grupos no pueden comportarse como un equipo ágil, con dedicación constate durante el semestre, no es posible ser consecuente con casi ninguno de los Principios LEAN.

Recomendaciones:

  • Profesores o Estudiantes con experiencia que intervengan como Scrum Masters de vez en cuando en cada grupo.
  • Hacer charlas de agilidad, motivacionales y de trabajo en equipo.
  • Motivar la lectura de libros de agilidad para reforzar la practica.
  • Recordar frecuentemente los principios LEAN.
  • Motivar el uso de pizarras de visualización de tareas.

Lecturas recomendadas de agilidad:

SARMAQ: Sprint 3.


El 25 de Junio se dio comienzo al Sprint 3 del proyecto SARMAQ, el cual contempla la revisión de lo hecho hasta ahora, y el diseño y desarrollo de los dos últimos requerimientos del proyecto:

  • Gestionar las solicitudes de arriendos de maquinarias.
  • Gestionar el cálculo de facturas, sus detalles y la información a recopilar.

En el Sprint 3 el equipo se comprometio a terminar una serie de tareas correspondientes a los 2 últimos requerimientos, en un plazo de 2 semanas.

El resultado anterior, en la pila de Sprint, se visualiza de la siguiente manera:


Durante la primera semana del Sprint 3, se presentan revisiones y correcciones del trabajo realizado hasta el momento e investigaciones respecto a los formatos de factura que se utilizan en la empresa.

De un total de 37 horas, definidas para el Sprint 3, se logró avanzar 16 horas, quedando pendientes 21 horas. Con este rendimiento por Sprint aún se esta muy lejos de alcanzar la agilidad necesaria para programar los módulos que han de satisfacer, por completo, los requerimientos planteados.

La situación existente, en relación al estado del proyecto, significa que en el Sprint 4 es necesario incluir las 21 horas que no se alcanzaron ha hacer en el Sprint 3. Además en el Sprint 4 se incorporaran casos de prueba, las cuales serán ejecutadas por los mismos integrantes del Sprint dado que por la naturaleza del proyecto el Owner también esta involucrado en la ejecución Sprint.

Para las pruebas se considerará trabajar con el software ya construido en Spring Roo. Las pruebas en si abarcaran situaciones de usuario final, como por ejemplo arrendar una máquina, cobrar un arriendo, etc. En todo caso las pruebas serán diseñadas durante el desarrollo del Sprint 4.


Finalmente, la Pila del Producto y del Sprint 3, quedan de la siguiente forma:






Se observa que los compromisos asumidos en los sprint no se cumplen, situación que afecta los nuevos sprint pues ellos se inicializan con un exceso de carga debido al remanente del sprint anterior.

Lo anterior se debe a la poca experiencia del equipo de trabajo en lo que es el uso de una metodología ágil, sobretodo que el dedicar tiempo sin interrupciones a las tareas y reuniones de los sprints es bastante difícil, mas aún si se le suma la poca experiencia que en general se tiene del desarrollo de sistemas de información, situación que significa que las estimaciones de plazos son muy inexactas.

En base a todo esto hay que tomar las precauciones para que el Sprint 4 cumpla sus objetivos a objeto de contar al final de este con el producto que se especifico inicialmente.


SARMAQ: Sprint 2.


Tomando en cuenta las tareas pendientes que quedaron del Sprint 1, se decide llevar a cabo otro Sprint que considere estas tareas, las debilidades que se hicieron visibles en el Sprint 1 y un plazo de término de 1 semana para el nuevo Sprint.

En el Sprint 2 el equipo se compromete a terminar las mismas tareas del Sprint 1, pero en tan solo 1 semana y con una nueva estimación de horas. Esto se puede ver en la pila del Sprint 2 que se muestra a continuación:



 
El tiempo disponible del equipo para 1 semana queda de la siguiente manera:




Durante la única semana, se logran avances destacables respecto al Sprint anterior, logrando finalizar todas las tareas pendientes al finalizar la semana. Esto último, en la hoja de visualización de tareas, se ve de la siguiente forma:



 
La grafica de burndown del Sprint 2 se muestra a continuación:




Finalmente, la Pila del Producto y del Sprint 2, quedan de la siguiente forma:





Más información respecto al Sprint  1 y 2, y los avances obtenidos, se encuentran en el siguiente informe de avance: