Chess - antoniomartel.com

Archivos por Etiqueta: ES

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.

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!

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.

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?

Ventajas y desventajas de SCRUM (I)

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

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad