Sunday, 28 July 2013

SCRUM para proyectos de mantenimiento

Hace algunos días hablaba con un colega en este mundillo ágil sobre si era posible aplicar SCRUM a proyectos en los que, además de las tareas previstas y planificadas, suele haber interrupciones frecuentes para resolver problemas de mantenimiento o corrección de errores. Muchos jefes de proyecto se enfrentan a este tipo de problemas y utilizan diversas aproximaciones para resolverlo. Aquí van un par de ellas:

Sprints cortos

Con esta solución mantendremos las tareas ya programadas en la planificación del sprint. Al tener sprints de 1 o 2 semanas de duración podremos incluir la tarea no planificada como prioritaria en la lista de cosas a hacer en el siguiente sprint. Si el sprint tiene 1 semana de duración tardaremos una media aproximada 3 días laborales en comenzar a acometer la tarea urgente.

Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.

Factor de dedicación bajo

Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el sprint para dar 'hueco' a la resolución de estos problemas.

Sabiendo que en cada sprint el equipo tiene capacidad para resolver 10 puntos de historias programadas podríamos comprometernos a entregar solo 7 para que el equipo tenga tiempo de resolver las incidencias urgentes. De este modo no fallaremos un sprint tras otro en entregar lo prometido.

En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos SCRUM pero ¿cómo se está gestionando el resto del tiempo del equipo? ¿qué sabemos sobre esa pila de tareas que estamos resolviendo sprint tras sprint?

Un equipo separado por cada tipo de tarea

Esta solución consiste en tener un equipo SCRUM para las tareas identificadas y planeadas y un equipo Kanban para las incidencias de resolución urgente. Con Kanban podemos añadir las nuevas tareas a la columna TO-DO a medida que van llegando y así seguiremos su evolución hasta que llegan a DONE. Con esto el equipo será aún más ágil disminuyendo el overhead de reuniones y planificaciones que tiene SCRUM.

Aún sigue existiendo un problema con las tareas no planeadas y es que son eso, no planeadas. En ocasiones el equipo Kanban que da soporte podría estar sobredimensionado para las pocas incidencias ocurridas en ese momento pero una semana más tarde el número de incidencias y su importancia podría ser tan alta que toda ayuda es poca.

Para minimizar estos riesgos podemos apoyarnos en las soluciones anteriores: Un sprint corto para que el equipo SCRUM de desarrollo planifique sus tareas para la próxima iteración y usar también un factor de dedicación un poco más bajo para que el equipo tener un hueco en su planificación para echar una mano si fuese necesario. Del mismo modo, el equipo de soporte puede colaborar con las tareas planificadas para el sprint actual cuando su columna TO-DO se está quedando vacía. Para aprovechar esto al máximo sería bueno que los miembros de cada equipo se intercambiasen de vez en cuando para que todo el mundo conozca todos los aspectos del trabajo.

Sunday, 21 July 2013

Introducción a SCRUM en menos de diez minutos

Les dejo aquí un enlace a un vídeo de introducción a SCRUM en menos de diez minutos. La parte más didáctica es la relativa a las estimaciones. Interesante el resto del vídeo también (algo de publicidad hacia el final)





Sunday, 14 July 2013

Cursos Masivos Online

Muchos ya habrán oído hablar sobre los MOOC (Massive Online Open Courses) pero otros muchos no o no saben muy bien de qué va todavía. Se trata de cursos que universidades u otras instituciones publican de forma abierta a el mundo entero al mismo tiempo consiguiendo miles de estudiantes a través de Internet. Esto hace que, de forma gratuita o a muy bajo precio, todos esos estudiantes puedan acceder a cursos a los que les habría sido imposible acudir presencialmente.

Como me parece una gran idea les dejo aquí solo un par de ejemplos. Son una gran forma de mantenerse actualizado y de aprender mucho sobre muchos temas:
  • CS-169.1x: Software as a Service de edx.org. Este lo he hecho personalmente. Muy buen curso sobre desarrollo ágil de software, despliegue en la nube (heroku), tdd (cucumber), ruby on rails. Algún día tendré que ponerme a realizar la segunda parte del curso (CS-169.2x: Software as a Service) Se entrega certificado al final (PDF verificable) y las prácticas que se entregan pasan una revisión para detectar si son copias.
  • Coursera tiene, además de sus cursos en inglés, algunos en español y en otros idiomas. Parece interesante El ABC del emprendimiento esbelto del Tecnológico de Monterrey (aquí lo habríamos llamado El ABC del Lean Startup) Este otro, Web Intelligence and Big Data, lo tengo en mi lista 'to do'.
  • También hay propuestas MOOC españolas, en MíriadaX hay una gran variedad de cursos de todo tipo. Resalto uno que ha hecho un compañero de trabajo, Android: programación de aplicaciones por la Universidad Politécnica de Valencia. Algunos de estos cursos son de la UNED, tengo entendido que puedes examinarte de sus cursos en sus instalaciones y obtener la certificación por 15€.
Hay más ejemplos como Udacity y otros que yo no conozco aún. Si haces una búsqueda por los catálogos de estas webs seguro que encuentras alguno de tu interés.

Sunday, 7 July 2013

Pruebas automatizadas con Selenium

En mi última entrada hablaba de Selenium y como, gracias a herramientas como ésta, había conseguido reducir el número de errores en las aplicaciones en las que se ha utilizado.

En la entrada de hoy describiré con un ejemplo uno de los múltiples usos que puede tener un automatizador de navegadores como Selenium. Para ello utilizaré la web RottenPotatoes construido con Ruby on Rails sobre Heroku, la plataforma de aplicaciones en la nube que se utilizó en el curso CS-169.1x Software as a Service (a propósito, curso muy recomendable de edx.org)

Si quisiéramos probar una de las funcionalidades que acabamos de desarrollar en nuestra aplicación, podríamos utilizar Selenium IDE (plugin para Firefox) y escribir o grabar un pequeño test que probase que esta funcionalidad ha sido correctamente implementada.

Pongamos como ejemplo que queremos probar el nuevo filtro de películas por clasificación. Para ello, con Mozilla Firefox abierto, ejecutamos el plugin Selenium IDE y creamos un nuevo test:

Abrimos la página a testear con el comando Selenese:
Command Target
openhttp://stormy-beyond-4091.herokuapp.com/movies
con lo que obtendríamos una nueva pestaña con nuestra aplicación:


desmarcamos los botones G, PG-13 y R y pulsamos el botón 'Refresh' con los siguientes comandos:

Command Target Value
uncheck id=ratings_G
uncheck id=ratings_PG-13
uncheck id=ratings_R
check
id=ratings_PG
clickAndWait
id=ratings_submit
Con estas acciones debemos haber obtenido una página donde se muestran sólo las películas para todos los públicos (PG). Verificamos que sólo se muestran las películas 'Los increibles' y 'En busca del arca perdida'. De paso comprobamos también que en los resultados no se ha devuelto por error la película '2001: Odisea del espacio':

Command Target Value
verifyTextPresent The Incredibles
verifyTextPresent Raiders of the Lost Ark
verifyTextNotPresent 2001: A Space Odyssey
Además comprobamos también que el número de películas mostradas es de sólo dos. Para ello comprobaremos que en la tabla devuelta hay 3 filas (2 <tr> para las dos películas y 1 <tr> adicional para la cabecera de la tabla):

Command Target Value
verifyXPathCount //table//tr 3
Un test como éste puede ser creado para cada nueva funcionalidad que desarrollemos y ser incluida posteriormente junto al resto de tests que hayamos creado a la batería de pruebas que realiza el servidor de Integración Continua (Jenkins por ejemplo). De esta forma los test son pasados cada noche, o a la hora en que lo programemos y si hubiésemos subido al Subversion un código que hace que alguna funcionalidad muestre un error, el servidor de Integración Continua nos avisará inmediatamente.

Les dejo el test disponible para su descarga en el siguiente enlace: Selenium Test


Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.



Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).