Mi ponencia en las V Jornadas de Sostenibilidad

Publicada el octubre 6, 2013 por antoniomartel

Hace unas semanas la Viceconsejería de Medio Ambiente del Gobierno de Canarias tuvo la amabilidad de invitarme a dar una ponencia en las V Jornadas de Sostenibilidad en Canarias que tuvieron lugar el pasado jueves 3 de octubre. Mi ponencia trató sobre el Sistema de Información de Residuos de Canarias y otros sistemas software que ayudan al Servicio de Residuos a controlar los residuos producidos en las islas. ¡Espero no haber aburrido mucho a los no versados en sistemas de información sobre residuos peligrosos!

Les dejo aquí un enlace a mi presentación del jueves

Las V Jornadas sobre Sostenibilidad en Canarias estaban presididas por la Viceconsejera de Medio Ambiente y tenían como lema los retos en la gestión de residuos en territorios insulares por lo que varios representantes de Cabo Verde asistieron para poder compartir experiencias sobre la gestión de residuos en ambos archipiélagos.
Las ponencias trataron sobre:

  • [Sal, una isla sin plástico] por una representante de la Cámara Municipal de la Isla de Sal en Cabo Verde.
  • [Modelos y plan de residuos en Cabo Verde] por D. Gilberto Silva, Concejal de Medio Ambiente de la Cámara Municipal de Praia.
  • [El Hierro 100% reciclable] por Dña. Fabiola Ávila, Técnico de Medio Ambiente del Cabildo de El Hierro.
  • [El impacto de los residuos en el Cambio Climático] por D. Fernando Herrera, Jefe del Servicio de Prevención y Control de la Contaminación del Gobierno de Canarias.
  • Buenas prácticas en la gestión de residuos a cargo de representantes del Grupo Lopesan y Martínez Cano Canarias.

Podrán encontrar toda la información y algunas fotos del evento en la siguiente dirección: Guacimara Medina inaugura en Las Palmas las V Jornadas de Sostenibilidad en Canarias.

Por último, les dejo un enlace a una entrada en este blog sobre una ponencia previa en las Jornadas sobre Sostenibilidad que tuvieron lugar el pasado mes junio: Gestión avanzada de residuos – Sistema de Información de residuos de Canarias (GUIRRE)

Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

¿Qué significa ser ágil?

Publicada el septiembre 29, 2013 por antoniomartel

Debido a mi trabajo, por el blog o por lo que sea, estoy usando cada vez con más frecuencia muchas de esas palabras de moda como Ágil, Sprint, Historia de usuario, velocidad de la iteración o backlog del producto. He repasado algunas de mis entradas en este blog y lo veo lleno de expresiones un tanto huecas como ‘ser ágil’ o no serlo, aportar valor al producto o aceptar el cambio.

¿Qué significa realmente todo esto? ¿Qué es eso de ser ágil y por qué iba nadie a querer ser ágil? Esto de la agilidad es más una filosofía que un concepto claro y bien definido. Supongo que es una forma de ahorrar palabras y evitar tener que dar una definición completa de cada concepto cada vez que hablamos pero quien nos escuche debe estar pensando ¿qué diablos dice?

No sé si será suficiente pero quizás pueda aportar algo de luz utilizando la presentación de Henrik Kniberg en el Paris Scrum Gathering (échenle un vistazo, no tiene desperdicio) Pongo aquí un par de puntos que me parecen muy destacados:
Esta imagen de la torre Eiffel es bastante descriptiva por sí misma. Representa bien este balance entre el caos y la burocracia (exceso de documentación, formalismos o rigidez del contrato) Uno nunca se puede mantener un equilibrio perfecto, algunas veces te quemarás un poco y otras uno recibirá un pinchazo. Mientras se esté intentando no caer en la burocracia sin abrasarse mucho no iremos por muy mal camino.
  
Estas dos imágenes de arriba explican también de forma muy clara lo que significa ser ágil: ¿Alguien tiene una idea? Vamos a probarla, ¿son aburridas esas reuniones? ¿Probamos a quitarlas y vemos qué tal nos va?
Y por último, la idea que a mí más me gusta y la que, al mismo tiempo, me parece más divertida (aunque aún me falta para llegar a esto):
Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Ágil en todos los sentidos

Publicada el septiembre 9, 2013 por antoniomartel

Hace algunas semanas, una persona cercana a mí me pidió que le ayudara con la revisión de un trabajo académico que debía presentar a comienzos de septiembre.

Cuando le eché un vistazo, vi que había un gran trabajo hecho, se había leído muchísima documentación, notas y referencias a libros, artículos, ponencias y otra bibliografía estaban por todos lados y las hipótesis y las conclusiones eran claras. Sin embargo, aún era necesario dar cuerpo a todo el documento, revisar que se cumplían las normas de citación para cada elemento de la bibliografía y cumplir muchos otros aspectos.

Lo primero que hicimos fue tratar de saber qué quedaba por hacer para dar por concluido el trabajo. Elaboramos una lista de los puntos pendientes: revisión de citas, síntesis, abstract en inglés, palabras clave, relectura del documento para comprobar los errores gramaticales o de expresión, cumplir con los estilos de la institución académica, incluir mapas de localización, etc. Mucho por hacer y sólo quedaban unas semanas para entregar.

Después de preparada la lista, la priorizamos, colocando siempre en los primeros puestos aquellas tareas que eran imprescindibles para poder entregar el trabajo, seguidas luego de aquellas otras que sólo darían puntos extra o no eran imprescindibles para el aprobado.

Cuando la lista estaba avanzada nos dábamos cuenta de que necesitábamos añadir nuevos elementos a la lista. Preparábamos una nueva lista y volvíamos a priorizar siempre con la idea en mente de ‘Si tuviéramos que entregar mañana ¿qué tendríamos que tener hecho?’ A medida que íbamos eliminando elementos de la lista comprobábamos que las tareas eran cada vez de menor importancia y dificultad y la desesperanza del principio daba paso a las ganas de dar los últimos remates al trabajo.

Finalmente se completó el trabajo dos días antes de la fecha tope de entrega. El día anterior se dedicó a una última lectura y revisión entregándolo solo unas horas después.

Podemos llamarlo Ágil, GTD o simple sentido común pero ¡yo prefiero trabajar así!

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

Revista Proiectus

Publicada el septiembre 1, 2013 por antoniomartel

Hace algún tiempo algunos decidimos colaborar con la idea de Iván Tejera, al que algunos ya conocéis, en la creación una revista sobre la dirección de proyectos en Canarias.

Esta idea ha ido tomando forma, unos cuántos hemos escrito algún artículo, unos más largos que otros, para incluir en el contenido de esta nueva revista. Por algún artículo que he podido ver, todos me han parecido muy interesantes, así que recomiendo su lectura!

Su lanzamiento será en breve pero, mientras tanto, pueden ver una presentación de la revista en el siguiente Prezi:

¡Espero que les guste!

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

¿Por qué fallan los proyectos?

Publicada el agosto 25, 2013 por antoniomartel

Razones hay muchas, seguro que parándonos a pensar un poco se nos ocurren unas cuantas, pero hay una que no siempre es tan obvia. Las estadísticas parecen indicar que si reducimos el tamaño de nuestro proyecto podemos aumentar en un 50% su probabilidad de éxito.

Un estudio indica que los proyectos de más de 1 millón de dólares tienen un 50% más de probabilidades de fallar que los proyectos de menos de 350.000 dólares. ¿Cómo no se nos había ocurrido antes? Los proyectos pequeños son más fáciles de gestionar y ejecutar que los grandes.

En proyectos grandes con duraciones superiores a un año tendemos a establecer las reuniones, hitos y revisiones con una periodicidad mayor, mensuales, bimensuales o incluso trimestrales. No es suficiente para tomar el pulso al coste del proyecto y comprobar si se está trabajando en la línea correcta, si se entrega lo que se necesita o si nos estamos desviando mucho de lo previsto.

Por otro lado, con proyectos de duración superior a un año o incluso menos se corre el riesgo de que hacia la finalización del proyecto, los objetivos y necesidades del negocio del cliente hayan cambiado con respecto a lo que le motivó a contratarlo. Si desarrollamos una aplicación para móviles ¿el mercado será el mismo dentro de 1 año cuando queramos venderla? Si quisiéramos hacer una aplicación basada en la legislación laboral actual ¿será útil dentro de uno o dos años cuando vea la luz nuestro producto? Parece mejor ver los grandes proyectos como ‘programas de actuación’ divididos en proyectos más pequeños, en los que con cada uno de ellos se entrega una parte del resultado global.

Yo añadiría un aspecto más: los proyectos grandes suelen planificarse y presupuestarse de ese modo porque con ellos se trata de conseguir objetivos complejos. Lamentablemente, con cada orden de complejidad adicional se multiplica el tiempo necesario para resolverla.

Si nos fijamos atentamente, el mundo IT parece ir en una línea muy distinta a ésta y trata de mantener los productos a desarrollar tan simples como sea posible. Hace unos años, los productos software más populares tenían menús llenos de características, funcionalidades y opciones de configuración (recordemos cada versión de MS Office o MS Outlook) En cambio, la mayoría de los productos actuales, los que residen en la nube o en nuestros dispositivos móviles, son mucho más simples: un par de casillas de texto y un botón para aceptar ¡no hay más!

David Karp, fundador de Tumblr, dijo acerca de esto: «Every feature has some maintenance cost, and having fewer features lets us focus on the ones we care about and make sure they work very well»

Me parece un gran planteamiento ¡Cuántas funcionalidades no habré desarrollado que me parecían muy útiles inicialmente pero que nunca fueron usadas!

Fuentes: thisiswhatgoodlookslike y startupquote.

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

Más sobre estimaciones

Publicada el agosto 18, 2013 por antoniomartel

Cuando se habla de estimaciones usando técnicas Ágiles hay algunas cosas que son difíciles de aceptar para aquellos que ya llevamos unos años planificando y calculando tiempos y fechas.

Podemos encontrar muchas técnicas de planificación Ágil: Planning poker, tallas de ropa para la clasificación de tareas (S, M, L, XL, etc.) o el Team Estimation Game pero, admitámoslo, son difíciles de integrar en un entorno de desarrollo tradicional y menos aún por los clientes de nuestros productos (por lo menos con los que he podido trabajar)

No estamos acostumbrados a ver a un equipo ‘jugando a las cartas’ para una sesión de Planning poker (yo por lo menos no lo estoy) Sí estoy, en cambio, de acuerdo con la filosofía que hay detrás de estas técnicas y creo que el hecho de que se estén haciendo cada vez más populares se debe, en parte, al intento de desterrar ciertas creencias sobre las estimaciones:

Estimamos mal

¿Podemos hacerlo bien? Estimar es hacer una predicción sobre lo que vamos a tardar en hacer una tarea o de los materiales que necesitaremos para hacer un trabajo. Cuando hacemos una estimación con una incertidumbre alta, como cuando lo hacemos en base a unos pliegos de contratación, más que una predicción es una apuesta.
Es obvio que necesitamos estimar. Debemos intentar predecir lo que pasará para poder tomar decisiones, pero a menos que hayamos hecho esa misma tarea muchas veces antes y que lo hayamos hecho con el mismo equipo y bajo las mismas circunstancias, tenemos que saber que hay altas probabilidades de equivocarnos (ver la explicación que da Rodrigo Corral sobre el cono de incertidumbre).

Cuanto más esfuerzo le dediquemos a la estimación más nos aproximaremos a la realidad

Estimar tiene un coste y es un coste alto. Cuando no conocemos el detalle de cada uno de los puntos del trabajo a realizar ¿tiene sentido que nos dediquemos horas y horas a dilucidar sobre tareas que no conocemos bien? Hagan un ejercicio por mí, cuando terminen su próximo proyecto revisen el tiempo registrado en cada tarea. Verán que en lo que estimaron 20 tardaron 100 y en lo que estimaron 100, con suerte, tardaron 20. Verán también que en otras tareas nadie imputó horas. Simplemente no fueron necesarias. En cambio sí hay muchas horas registradas en tareas que se añadieron con posterioridad y que nadie contempló en la estimación inicial.

Con ésta o aquella técnica estimaremos mejor

Técnicas de estimación hay muchas pero pocas serán tan útiles como la simple comparación del tiempo tardado en hacer proyectos similares, la des.composición del trabajo en tareas más pequeñas o el juicio de expertos (si contamos con varios mejor)

El hecho de utilizar complejas técnicas de estimación puede darnos una falsa sensación de seguridad sobre nuestra estimación y no haber aportado una fiabilidad mucho mayor. En cambio sí puede habernos hecho incurrir en un coste muy alto (ver punto anterior) e invertir un tiempo que podíamos haber utilizado mejor en otras cosas (como reducir la incertidumbre).

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).

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Behavior Driven Development con Cucumber

Publicada el agosto 11, 2013 por antoniomartel

Es habitual en muchos proyectos que nuestro cliente nos defina unas funcionalidades que quiere que nuestro producto le proporcione. Documentamos esas funcionalidades, las diseñamos y las desarrollamos pero cuando el cliente las ve, o peor aún, cuando se ponen al uso de todos los usuarios vemos que no satisfacen sus necesidades reales o contienen defectos. Es ahora cuando empezamos a retrasarnos en nuestras entregas, el presupuesto se nos va de las manos y encima de todo esto, el cliente no tiene lo que esperaba.

Para intentar evitar estos problemas, en lugar de hacer un gran esfuerzo de diseño antes de comenzar a desarrollar (Big Design Up Front) podemos utilizar la técnica Agile, Behavior Driven Development (BDD) que pregunta a los usuarios e interesados por el comportamiento que debe tener la aplicación antes y durante el desarrollo evitando fallos en la comunicación. La meta de BDD es la validación de los requisitos (construir la funcionalidad correcta) y no la verificación (construir correctamente la funcionalidad)

Tal como pude verse en el curso CS-169.1x Software as a Service (de edx.org, lo recomiendo siempre que lo menciono) podemos usar herramientas como Cucumber para dirigir el desarrollo por el comportamiento que debe tener la aplicación.

Captura de pantalla de Behavior driven development con Cucumber

Por ejemplo, si quisiéramos comprobar una funcionalidad (feature) de nuestro producto por la cuál una película añadida a la base de datos debería aparecer siempre en el orden correcto, escribiríamos:

Feature: movies when added should appear in movie list
Scenario: view movie list after adding movie
  Given I have added «Zorro» 
  And   I have added «Apocalypse Now»
  And   I am on the RottenPotatoes home page sorted by title
  Then  I should see «Apocalypse Now» before «Zorro»
Como podemos ver esto es lenguaje casi natural y por tanto fácilmente entendible por el cliente de forma que podrá validarlos e incluso él mismo podría escribir estos tests.
Para que un step como Given I have added «…» funcione tendríamos que escribir algo como esto:
Given /I have added «(.*)»/ do |title|
  steps %Q{
    Given I am on the Create New Movie page
    When  I fill in «Title» with «#{title}»
    And   I press «Save Changes»
  }
end
Given, And y Then son alias para el mismo comando y solo existen para hacer el texto más entendible por los humanos. A su vez tendríamos que crear las funciones para Given I am on …, When I fill … pero como nos podemos imaginar después de escribir unas cuantas funciones como éstas tendremos un repertorio de pasos (steps) con los que podremos escribir la mayoría de tests.
Ya saben, mejor testear que debuguear.
Publicado en Blog, Blog 1 | Etiquetado , , , | Deja un comentario

SCRUM para proyectos de mantenimiento

Publicada el julio 28, 2013 por antoniomartel

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.
Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Introducción a SCRUM en menos de diez minutos

Publicada el julio 21, 2013 por antoniomartel
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)

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

Cursos Masivos Online

Publicada el julio 14, 2013 por antoniomartel

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.
Publicado en Blog, Blog 1 | Etiquetado , , , | Deja un comentario

Pruebas automatizadas con Selenium

Publicada el julio 7, 2013 por antoniomartel

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
open http://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).

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Ventajas y desventajas de SCRUM (II)

Publicada el junio 30, 2013 por antoniomartel

No quisiera convertirme en uno de esos evangelistas de lo Ágil que pregonan por doquier lo bueno y moderno que es ser Ágil. He puesto en práctica alguna de estas técnicas y he obtenido buenos resultados con ellas, así que en este post les voy a contar la parte positiva de una metodología como SCRUM (post obligado después de hablar sobre las desventajas de SCRUM en una entrada de mayo)

Me voy a centrar en las ventajas de una de sus características fundamentales: Las Entregas Periódicas. Nuestro cliente recibe cada poco tiempo una entrega de lo que estamos haciendo. Esto le va a permitir:

Que comience a usar ya su producto 

El cliente puede decidir poner en marcha el producto aún cuando no están todas las características construidas. Cuando se haya desarrollado el 20% de las nuevas funcionalidades, que son las que serán usadas el 80% del tiempo, el producto puede comenzar a andar.

Con el feedback de los usuarios podríamos darnos cuenta de que hay nuevas funcionalidades que son mucho más importantes que el 80% de las tareas que aún teníamos por hacer en la pila del producto. Alguien puede decirnos «pero si el borrador del nuevo decreto ya no exige la entrega de la autorización firmada» o «en realidad lo que necesitamos es un botón para poder cancelar el trámite» (dos experiencias reales)

Que pueda decidir hacia dónde vamos

Los negocios cambian, las necesidades varían, nuevas normativas aparecen. Lo que era muy importante cuando se firmó el contrato podría no serlo meses después. El cliente puede decidir los nuevos objetivos, qué hacer en el nuevo Sprint y en qué debemos trabajar para la próxima entrega.

Divide y vencerás

Las tareas titánicas requieren de esfuerzos del mismo orden. Si debemos entregar solo una parte de esa tarea cada dos semanas la carga se nos hará más llevadera. Tareas más pequeñas y abordables harán que nos parezca menos difícil el trabajo y que con cada entrega tengamos la sensación de estar dando un nuevo paso hacia la meta final.

Menos sorpresas

Viendo crecer el producto poco a poco todos vamos a tener una idea de qué estamos haciendo con él y si nos va a ser útil o no. Además, con relativa exactitud sabremos a qué ritmo se están entregando cosas y cuánto tardaríamos en tenerlo acabado. ¿Es necesario tomar medidas para corregir el rumbo? Lo sabríamos en semanas.

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría
Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Ponencia en las IV Jornadas de Sostenibilidad en Canarias

Publicada el junio 24, 2013 por antoniomartel

El pasado jueves tuve el honor de dar una ponencia sobre la Fase 2 del Sistema de Información de Residuos de Canarias (GUIRRE) en las IV Jornadas de Sostenibilidad en Canarias dentro de las actividades del Gobierno de Canarias por el Día Mundial del Medio Ambiente.

GUIRRE es un proyecto bastante especial para mí por varias razones. La primera de ellas porque fue la primera vez que ejecutamos un proyecto utilizando integración continua (Jenkins) y tests con Selenium IDE.

Al inicio del proyecto, antes de comenzar a programar, definimos una sección ‘Cómo probarlo’ para cada funcionalidad a desarrollar. Grabamos tests con Selenium, siguiendo lo indicado en esta sección, que servían para demostrar que la nueva característica funcionaba correctamente. Si encontrábamos un bug, grabábamos también un test que lo reprodujese. Cuando el test dejaba de marcarse en rojo, ya lo habíamos arreglado.

Cada dos semanas, grabábamos todos los test del Sprint en una ‘suite’ de Selenium. Cada noche, el servidor de integración continua, Jenkins, ejecutaba esta suite y las suites de todos los Sprints anteriores e informaba si había habido errores. Si la mañana anterior un programador había modificado código que afectaba a las funcionalidades desarrollada hace unos meses, Jenkins nos mostraba unos nubarrones muy oscuros.

La otra razón por la que GUIRRE es un proyecto muy querido para mí es porque se logró terminar por debajo de lo presupuestado (sí estos proyectos existen) a pesar de asumir totalmente el coste del aprendizaje con Jenkins y Selenium y de que el presupuesto era muy ajustado. Todo un reto.

Les dejo más abajo una fotos del acto y un enlace a la ponencia que presenté. Espero que les sea de su interés.

Publicado en Blog, Blog 1 | Etiquetado , , , , , | Deja un comentario

Boeing y los cirujanos

Publicada el junio 16, 2013 por antoniomartel

Atul Gawande, cirujano de un prestigioso hospital, estaba interesado en mejorar la cifra de incidencias y complicaciones que surgen habitualmente en las mesas de operaciones, así que se le ocurrió preguntar cómo lo hacían ellos a otro tipo de profesionales completamente diferente pero del que también dependen muchas vidas.

Durante una visita a Boeing, Gawande preguntó cómo conseguían que todo funcionara correctamente en su trabajo diario. La respuesta fue sencilla: Usaban checklists. Una y otra vez, los pilotos se apoyaban en checklists, no sólo para el despegue y el aterrizaje en condiciones normales sino también para las situaciones de crisis en condiciones de emergencia.

De vuelta a su hospital, Gawande preparó una lista de verificaciones que podía ser comprobada en 2 minutos y la implementó en las salas de operaciones de ocho hospitales. Se aseguraron de que la lista también incluía puntos básicos: Había suficiente sangre disponible o quedaban antibióticos en cantidad adecuada para la operación.

El resultado fue sorprendente, obtuvieron mejores resultados, mejores resultados de forma masiva. Se aseguraron de evitar errores básicos y de no cometer fallos estúpidos. Ahora, incluso la Organización Mundial de la Salud define listas de verificación para la seguridad de los pacientes.

Una simple hoja de papel o archivo MS Excel con una lista de puntos a revisar pueden evitar muchos errores y mejorar la calidad de lo que hacemos. Incluso SCRUM tiene una lista para que auto-comprobemos el nivel de su implementación en nuestra organización.

No existe solo una SCRUM Checklist, existen muchas. La que más me gusta es la SCRUM Checklist de Henrik Kniberg, el autor de SCRUM y XP desde las trincheras. Es muy útil la forma en la que separa lo fundamental y lo esencial de lo solo recomendado en la implementación.

Aún no puedo marcar todas las casillas de esa lista. Como indica Henrik, ¡tendré cuidado con la policía de SCRUM!

Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Al otro lado del charco

Publicada el junio 9, 2013 por antoniomartel

Estando tan cerca es increíble lo poco que sabemos de lo que se está haciendo justo aquí al lado, cruzando el charco.

Hace unas semanas que he descubierto los blogs de Carlos Ble y de Raúl Herranz. Mucho que leer ahí y todo muy bueno.

Les pongo algunos ejemplos: Open Agile Space en Tenerife, junio 2012-2013, Preparación de la certificación PMI-ACP y. como no, algo sobre el Triángulo de Hierro.

Disfruten de la lectura.

Publicado en Blog, Blog 1 | Etiquetado | Deja un comentario

Crédito para gestionar proyectos

Publicada el junio 3, 2013 por antoniomartel

En inglés se usa el término soft skill para referirse a habilidades sociales como el trato agradable, el optimismo o la facilidad de comunicación (habilidades útiles en cualquier situación de la vida) En cambio usan el término hard skill para referirse a aquellas técnicas que aprendemos para poder realizar un trabajo: un lenguaje de programación, el plan contable de 2012 o un nuevo procedimiento para detectar la desnutrición hospitalaria.

SCRUM, PMP o cualquier metodología que elijamos, son hard skills. Nos enseñan una forma de trabajar, un conjunto de buenas prácticas y normas a seguir, útiles sin duda, pero si no se ponderan adecuadamente con el otro tipo de habilidades, la gestión de un proyecto y cualquier otra actividad que acometamos estaría seriamente comprometida.

Listados de soft skills necesarias para un gestor de proyectos las podemos encontrar en muchos sitios. Habilidades como el liderazgo, auto-control, capacidades de organización, negociación o comunicación son claramente muy útiles. Yo quiero hacer mención especial a dos que cada vez me parecen más importantes:

Coherencia

De nada vale que comencemos un proyecto con muchas ganas y propongamos al cliente un montón de herramientas de última tecnología, entregas semanales o memorias mensuales si con el paso del tiempo y las urgencias del trabajo diario comenzamos a relajar estos compromisos o la calidad de los mismos. El proyecto se resentirá por la falta de estas entregas pero lo más importante es que comenzaremos a perder la confianza y el crédito que nos ha dado nuestro cliente. Y si se cancela la línea de crédito ya sabemos lo que pasará.
Igual de importante es el crédito que nos dan nuestros compañeros de trabajo. Si prometemos libertad de decisión al equipo y la limitamos siempre que opinamos distinto o si la calidad es importante para nosotros pero deja de serlo cuando hay prisa, los niveles de calidad también dejarán de ser importantes para el resto del equipo. La línea que se ha trazado es cada vez más borrosa y pronto les dará igual hacia dónde se va esa línea.

Transparencia

Ocultar cosas nunca ha sido buena idea. Callar por qué se toman ciertas decisiones y esconder las verdaderas causas de los problemas no nos traerá más que problemas, aunque en el plazo inmediato consigamos escurrir el bulto. 
No es necesario un desnudo integral pero explicar los problemas lo más claramente posible ayudará a mantener abierta nuestra línea de crédito. Si nuestro cliente comienza a intuir que no hemos sido claros y que en cierta forma no fuimos del todo honestos ¿por qué iba a confiar en nosotros cuando le expliquemos que la nueva funcionalidad es demasiado compleja y que necesitaríamos un par de semanas más para completarla?

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario

Ventajas y desventajas de SCRUM (I)

Publicada el mayo 26, 2013 por antoniomartel

Si estás considerando SCRUM como método de trabajo pero no sabes muy bien de qué va todo esto. Has oído a un montón de gente hablándote de las bondades de este sistema pero ¿cuántas tecnologías y técnicas no han aparecido rápidamente y desaparecido a mayor velocidad aún? Todas prometían ser revolucionarias así que cuando oímos tanto bombo sobre alguna arqueamos una ceja en actitud crítica.

Hace algunas semanas publiqué un prezi en el que explicaba las ventajas y inconvenientes de implantar SCRUM en una organización. Las comentaré ahora en esta entrada, esta vez con palabras en lugar de imágenes, comenzando por sus inconvenientes (trataré de ser parcial, pero no lo prometo)

El equipo puede estar tentado de tomar el camino más corto

Cuando cada dos semanas hay cosas que entregar, en las últimas entregas no se completaron todas las funcionalidades previstas y la velocidad del equipo no predice que vayamos a terminar en plazo tenemos un problema: puede surgir la tentación de resolver las tareas pendientes de cualquier manera y dejar ‘deudas’ técnicas en el trabajo. Aparentemente todo va bien, más funcionalidades hechas, empezamos otras nuevas y el cliente está contento porque se están cumpliendo los plazos.

Pero siempre que se deja un borrón ahí atrás puedo asegurarte que volverás a tropezar con él. Si nuevas cosas han sido construidas sobre este borrón, la ‘deuda’ comenzará a multiplicarse. Antes o después tendrás que parar todo y devolver la deuda comprometida (con intereses de demora) El proyecto no termina de cerrarse cuando parecía que ya quedaba poco por acabar: la gráfica burndown parece tener una asíntota horizontal en 0 (lo siento, deformación profesional/educacional, Cálculo I)

¿Necesitas con mucha antelación fechas exactas de entrega?

Esta es una de las críticas más habituales a SCRUM. En cierta forma es lógico, al inicio del proyecto no puedes predecir cuando lo vas a acabar si estás facilitando que lo que se va a construir cambie y varíe en el tiempo. ¿Se prefiere un producto que se sabe con certeza que va a finalizar en 10 meses pero que está construido sobre las ideas y opiniones que se tenían cuando se comenzó? Quizás se prefiera un producto que podría acabar en el plazo similar pero que hemos podido evolucionar hacia nuestras necesidades reales y que hemos podido usar y probar antes de la entrega final.

¡Stress!

No nos podemos pasar la vida esprintando. Hacemos una entrega y ya nos comprometemos para la siguiente que está solo a un par de semanas vista. Luego otra y otra. Si tenemos que recorrer muchos kilómetros así comenzaremos con un rápido sprint para llegar a la primera meta pero llegaremos caminando a la última, eso con suerte.

¿El equipo es autoorganizado?

Una de los principios de SCRUM es que el equipo debe tomar sus propias decisiones y autogestionarse. Además, se requiere que no haya miembros especializados en tareas concretas como análisis, tests, diseño, documentación, etc. sino que todos los integrantes del equipo sepan hacer de todo y puedan intercambiarse entre sí. ¿Siempre contamos con un equipo así? ¿Qué pasa si no lo tenemos?
Desde luego es un problema pero ¿no lo sería también con cualquier otra forma de trabajo? ¿Hay alguna que permita llevar proyectos a buen puerto con equipos con poca experiencia?
En otra entrada hablaré sobre las ventajas de SCRUM (seguro que no es tan popular)

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría
Publicado en Blog, Blog 1 | Etiquetado , , | Deja un comentario

Regla del 80/20

Publicada el mayo 19, 2013 por antoniomartel

¿Podemos ser más productivos? ¿Cómo podemos centrarnos en las tareas que nos harán más eficientes? Hace muchos años, aproximadamente un siglo, un tal Pareto comprobó de forma casual que sólo el 20% de las vainas que tenía plantadas en el campo producían el 80% de los guisantes de su cosecha y que el 80% restante producían tan solo el 20% restante de los guisantes. Curioso por esta relación comprobó también que podía aplicar esta regla a otros campos descubriendo, por ejemplo, que en su época el 20% de la población disponía del 80% de la riqueza y que tan solo quedaba un 20% de la riqueza total para el 80% más pobre de la población.

Este principio, basado en el conocimiento empírico, es usado desde entonces para mejorar la eficiencia y la  productividad en la economía, en la distribución comercial, en el marketing, en las ingenierías y, como no, también en el desarrollo de software.

Cuando comenzamos a desarrollar nuestro producto basándonos en una lista enorme de requisitos y funcionalidades a desarrollar, sabemos que sólo el 20% de esas funcionalidades serán usadas por el 80% de los usuarios y que una cantidad enorme del resto de las funcionalidades que desarrollemos sólo será usada en un 20% de las ocasiones.

Aplicando también este principio al tiempo de desarrollo podemos deducir que si tardásemos alrededor de 10 meses en la construcción de un producto, en tan solo 2 de esos meses conseguiríamos desarrollar el 80% de las funcionalidades requeridas y que, por tanto, nos llevaría unos 8 meses resolver el 20% de las funcionalidades más complejas y difíciles. Esto nos lleva a preguntarnos ¿serán usadas esas funcionalidades? ¿son realmente imprescindibles?

Si lográsemos identificar las funcionalidades más importantes y las mantuviésemos los más simple que nos fuera posible (otro principio: KISS) ¿no lograríamos quitarnos de encima 8 meses de trabajo y entregar un producto muy efectivo en tan solo 2 meses?

Ya sabemos que el 20% por ciento de nuestro esfuerzo producirá el 80% de los resultados ¿no sería bueno sentarnos por un momento para pensar a qué le vamos a dedicar nuestro tiempo? Merecerá la pena, seguro.

Publicado en Blog, Blog 1 | Etiquetado , , , | Deja un comentario

Si se puede medir, se puede mejorar

Publicada el mayo 12, 2013 por antoniomartel

Hace unos días hablaba sobre métricas con unos entusiastas de las metodologías ágiles como yo. Comentábamos sobre la necesidad que tenemos todos de facilitar datos a la dirección de nuestra empresa sobre la marcha del proyecto o a nuestros clientes, que están realizando una inversión en nuestro producto y han puesto unas expectativas en él.

Todo esto me hizo recordar el clásico axioma de calidad atribuido a Peter F. Drucker y que dice algo así: «Lo que no se puede definir, no se puede medir, lo que no se puede medir no se puede mejorar, y lo que no se puede mejorar finalmente se deteriora» Hay muchas variaciones de esta frase y muchas versiones diferentes también sobre su autoría. Yo prefiero usarla desde un punto de vista más positivo diciendo «Si se puede medir, se puede mejorar»

Una métrica básica para el seguimiento del proyecto con SCRUM es la suma del trabajo que queda por hacer. Diariamente podemos sumar las estimaciones de las tareas que quedan por hacer en el sprint. Esto nos dará la cantidad total de trabajo restante para terminar la actual iteración (Release Burndown) Con un poco de suerte al día siguiente habremos conseguido terminar algunas tareas más y esta suma será algo más pequeña. Si lo representamos en una gráfica, ésta irá decreciendo hasta alcanzar el eje 0 (cuanta más pendiente tenga la gráfica más velocidad lleva el equipo) Lo mismo podremos hacer con toda la pila del producto si sumamos las estimaciones de todas las funcionalidades que quedan aún por hacer.

Otro gráfica útil y sencilla que podemos utilizar es la CFD (Cumulative Flow Diagram) con la que, tomando los datos del tablero Kanban donde reflejamos la marcha proyecto, vamos anotando cada semana cuantas tareas tenemos y en qué estado están. Si por ejemplo tenemos un tablero sencillo en el que sólo tenemos las tareas en tres estados, ToDo (Por hacer), In Progress y Done, la gráfica mostraría algo como esto:

Al principio del proyecto todas las funcionalidades estarán por hacer (en color azul) y al final del mismo todas habrán alcanzado habrán sido marcadas como realizadas (‘Done’, en color verde)

La representación no está escogida al azar. He observado en varios proyectos que la gráfica suele tomar esta forma característica. Una velocidad baja al principio (poca pendiente) cuando el equipo se está conjuntando, alta velocidad cuando se ha superado la fricción inicial (alta pendiente) y despacio nuevamente hacia el final del proyecto cuando se descubre que todas las tareas no se habían cerrado correctamente y quedan cosas por corregir (no se cumplió correctamente con la definición de ‘Done’)

Hay muchas otras métricas que pueden ser usadas, recomiendo posts interesantes en «5 métricas de desempeño para proyectos de desarrollo ágil y Scrum» y en «Métricas ágiles y cuadro de mandos integral para Scrum» En cualquier caso, uses las métricas que uses, asegúrate de que merece la pena el esfuerzo en registrar los datos y calcularlas. Más métricas no significan mejor gestión.

Publicado en Blog, Blog 1 | Etiquetado , , , | Deja un comentario

SCRUM but …

Publicada el mayo 5, 2013 por antoniomartel

La guía de SCRUM en scrum.org define a este marco de trabajo como consistente en «Equipos SCRUM y sus roles, eventos, artefactos y reglas. Cada componente sirve para un propósito específico y es esencial para el éxito de SCRUM»

Sin embargo, en la práctica, no siempre nos ajustamos a una ejecución exacta de lo definido en esta guía. No tenemos tiempo para realizar todas las reuniones, cambiamos el plazo de un sprint, en definitiva, hacemos un SCRUM adaptado a los inconvenientes que van surgiendo.

Estas excusas que solemos poner para justificar nuestras modificaciones a la metodología tienen nombre propio, son las ‘SCRUMBut‘, o lo que es lo mismo: Sí, hago SCRUM pero …

Hace algunos años, en Nokia se definió un pequeño test, modificado posteriormente por Jeff Sutherland, para medir el grado de cumplimiento de las prácticas de SCRUM en los diferentes equipos con los que trabajaban: El SCRUM But … Test.

Cada práctica de SCRUM está pensada para resolver disfunciones comunes en muchos equipos de trabajo y que son muy difíciles de corregir. Después de todo, la propia guía dice que SCRUM es ‘Simple to understand’ pero ‘Extremely difficult to master’

He hecho un pequeño prezi sobre esto: Échale una vistazo en SCRUM but …

 

Publicado en Blog, Blog 1 | Etiquetado , | Deja un comentario