Sunday, 30 June 2013

Ventajas y desventajas de SCRUM (II)

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

Monday, 24 June 2013

Ponencia en las IV Jornadas de Sostenibilidad en Canarias

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.







Sunday, 16 June 2013

Boeing y los cirujanos

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!


Sunday, 9 June 2013

Al otro lado del charco

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.



Monday, 3 June 2013

Crédito para gestionar proyectos

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?