Teoría de las ventanas rotas

A finales de los años 60, un profesor universitario realizó un experimento psicológico. Dejó dos coches idénticos en dos barrios distintos: uno en un barrio conflictivo y pobre como el Bronx de Nueva York y otro en una zona rica y tranquila de California.

En poco tiempo el coche abandonado en el Bronx comenzó a ser desvalijado y perdió radio, llantas, espejo y todo lo que podía ser de valor. En cambio el coche abandonado en California permanecía tal y como lo dejaron.

El estudio no finalizaba ahí. Cuando el coche del barrio rico llevaba una semana intacto los investigadores le rompieron una ventana. Esto desencadenó en poco tiempo el mismo efecto que en el Bronx. El robo y el vandalismo dejaron pronto el coche en el mismo estado en ambos barrios.

Un coche con los cristales rotos transmite una idea de deterioro y despreocupación que contagia la idea de que vale todo. Cada nuevo acto de vandalismo rearfirmaba y multiplicaba esa idea convirtiéndose en una escalada imparable.

Una idea similar se explica en la formación a profesionales sanitarios. Si un paciente o un anciano se mancha o ensucia debe ser limpiado inmediatamente aunque se trate de sólo una pequeña mancha. Si permanece en ese estado, el propio paciente tendrá menos cuidado y precaución en no mancharse. Le da igual, ya está sucio. Comenzaría así a empeorar su higiene, su autoestima y su estado de salud general.

Los resultados de este estudio psicológico son aplicables a muchas situaciones de la vida cotidiana, desde el cuidado de nuestra casa al mantenimiento de nuestro coche pero también es aplicable a nuestro trabajo: Ya seas programador o jefe de proyecto, si permites subir a producción esa nueva versión sin las suficientes pruebas o si dejas tal y como está esa ‘deuda’ técnica en el código porque ahora hay ‘prisa’ se estará transmitiendo a todo el equipo de trabajo una sensación de que todo vale, de que ‘así es suficiente’ y de que la calidad podemos pasarla por alto. Antes o después el teléfono comenzará sonar con quejas de los usuarios y pronto veremos en el gestor de incidencias una enorme hilera de bugs reportados.

Así que ya sabes, si ves una ventana rota, arréglala cuanto antes.

Lecturas recomendadas: The broken window theory at the Coding Horror.

Publicado en Blog, Blog 1 | Etiquetado , , , | 2 comentarios

Estadísticas de uso de SCRUM (2013)

Hace unos años, cuando comencé a interesarme por SCRUM, solo unos pocos habían oído hablar de este marco de trabajo y la mayoría desconocía sus principios. Ahora en cambio, cada vez con más frecuencia, oigo a más y más profesionales hablar de SCRUM y otras técnicas Ágiles y veo que cada vez con más frecuencia es un requisito imprescindible en muchas ofertas de trabajo. Incluso compruebo que alguna administración pública comienza a exigirlo en sus pliegos de prescripciones técnicas demostrando en el texto que no lo ha puesto solo de oídas sino que lo conoce bien y sabe lo que quiere de él.

Por todo esto he sentido la curiosidad de medir hasta donde están llegando estas metodologías ágiles. De eso va este post. La técnica estadística y los medios usados quizás no sean los más exactos, pero pueden ayudarnos a tomar el pulso al mercado.

En primer lugar he buscado palabras clave como SCRUM, Agile, TDD o PMP en los principales portales de búsqueda de empleo españoles y europeos para permitir su comparación. Este es el resultado:

En los datos de esta tabla sería necesario tener en cuenta el total de vacantes que cada portal publica para conocer su proporción real al compararla con otro país pero Monster no publica estas cifras. Necesario comentar también que en los resultados de búsqueda de ‘Lean’ también se incluyen resultados para ‘Lean manufacturing’ o ‘Lean process improvement’ (Ágil en todo caso)

La conclusión más directa que saco de estas cifras es que debo estar más atento al ‘Lean Software Development’ en el futuro.

Por último he usado Google Trends para mostrar las búsquedas realizadas desde el año 2004 sobre ‘scrum -espn -rugby’ (para eliminar los resultados del deporte), ‘pmp’ y ‘rup’. Esta es la gráfica:

Es curioso observar el descenso en el número de búsquedas de Rational Unified Process y de PMP. En cambio SCRUM sube mucho desde esos años aunque no conserva la misma aceleración que tuvo entre los años 2007 y 2010.

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

Certificación Professional Scrum Master (PSM I)

Recientemente he estado valorando las posibilidades existentes en el mercado para obtener una certificado que validara mis conocimientos en SCRUM. Actualmente existen tres grandes competidores en este mundillo de la certificación Ágil: Professional Scrum Master (PSM) de Scrum.org, Certified ScrumMaster (CSM) de Scrum Alliance y PMI Agile Certified Practitiones (PMI-ACP)

Aunque CSM puede que sea la más reconocida, opté por PSM I de Scrum.org por varios motivos:

  • La certificación y los materiales han sido creados por Ken Schwaber, uno de los fundadores de SCRUM después de dejar la Scrum Alliance donde compartía proyecto con Jeff Sutherland, otro de los fundadores de esta metodología.
  • El certificado PSM no tiene costes de mantenimiento como sí los tiene CSM.
  • Antes de 2012, para obtener el CSM no se requería realizar un examen, solo asistir a algunos de los cursos impartidos por profesionales autorizados.
  • PSM I tiene numerosas preguntas del tipo «¿Cómo responderías a esta situación?» por lo que para aprobarlo se requiere un conocimiento amplio de SCRUM.
  • Por último, el certificado PSM I puede obtenerse de forma online sin asistir a ningún curso presencial (esto es importante residiendo en Canarias)
La prueba consiste en 80 preguntas a resolver en 60 minutos por lo que, aunque tengas el material a tu lado cuando hagas la prueba, no tendrás tiempo de hacer trampas si no sabes la respuesta. Para aprobar necesitarás acertar el 85% de las preguntas propuestas.

¿Cómo aprobar la certificación?

Te serán útiles los siguientes consejos:
  • Lee detenidamente la Guía de Scrum de Scrum.org. Es muy condensada y sobre una sola frase de esta guía pueden haber varias preguntas en el examen.
  • Lee la guía de Do Better Scrum. Está basado en el Scrum de Scrum Alliance y no es el material oficial  del examen pero puede darte algunos puntos de vista diferentes que no quedan claros en la Guía de Scrum.
  • Si eres completamente nuevo a Scrum estas guías están demasiado resumidas. Necesitarás formación ampliada que ponga las reglas y los artefactos en un caso práctico. Para esto recomiendo el libro de Henrik Kniberg, Scrum and XP from the trenches.
  • Haz el examen de pruebas gratuito la página oficial, Scrum Open (una y otra vez si es necesario)
  • El examen es en inglés. Asegúrate de leer detenidamente cada pregunta. Un «potentially» o un «required» puede cambiar completamente la respuesta que debe darse.

Tal y como me recuerdan Pilar y Kristell, el precio del curso (información importante) son 150 dólares (no reembolsables si no apruebas a la primera). Solo me queda desearte buena suerte con la prueba.

Si quieres conocer más sobre las certificaciones para Scrum Master o tener una comparativa más amplia a ésta, ya salió a la venta en Amazon el ebook Certificación Professional Scrum Master: Cómo preparar la certificación PSM I de Scrum.org. Puedes comprarlo ya, pero sólo está en preventa para promoción durante las próximas semanas. Si lo compras ahora, con el precio de descuento, Amazon te lo entregará el 13 de septiembre que es el día de publicación oficial.

En este libro podrás encontrar acceso gratuito a un test de práctica online, cuatro cuestionarios de preparación para el examen, comparativas con otras certificaciones populares de Scrum Master y otras muchas cosas útiles para esta certificación. Te dejo con un enlace al libro en Amazon.com (también en Amazon.es). Espero que te guste y que te sea útil si decides presentarte al test oficial.Es un ebook en formato Kindle pero no te preocupes si no tienes un lector de libros electrónicos. Una vez comprado seleccionas que lo quieres leer en Kindle Cloud Reader y desde entonces podrás leerlo siempre que quieras sólo con ir a la página read.amazon.com. En tu ordenador de casa, en un tablet o en tu móvil, donde quieras.

Libro Certificación Professional Scrum Master: PSM I por Antonio Martel
Libro Certificación Professional Scrum Master (PSM I)
Publicado en Blog | Etiquetado , , | 42 comentarios

Ventajas e inconvenientes de SCRUM

Una imagen vale más que mil palabras, al menos eso suele decirse, por esto he creado una presentación con Prezi que explica algunas de las principales ventajas de SCRUM pero también algunos de sus inconvenientes. Échenle un vistazo a la presentación en Ventajas e inconvenientes de SCRUM.

 

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

Cómo ayuda SCRUM a construir catedrales

Revisitando el post de Raúl Hernández González con el título ‘Aprendiendo a construir catedrales‘ también he comenzado a darle vueltas a esa conocida historia. En ella, a dos obreros que se encuentran picando piedra para la construcción de una catedral, se les pregunta qué es lo que hacen. Mientras uno responde sobre lo penoso e interminable que es construir el muro en el que está trabajando, el otro responde simplemente que él está construyendo una catedral.

Me he preguntado si se puede ser Ágil cuando uno construye algo tan grande. Creo que la respuesta es que sí. Por lo menos a mí se me ocurren algunas ventajas a ser Ágil cuando se está inmerso en un proyecto del tamaño de una catedral:

Con un framework como SCRUM siempre tendrás presente el objetivo final y las características que se quiere que tenga. En la pila del producto tendrás una lista de requisitos como la construcción de la planta, levantar la bóveda, decorar puertas o ventanales y otras muchas cosas que darán forma a la catedral final.

Pero una vez definido el objetivo hay que ponerse a picar piedra. Al comienzo de cada iteración, el equipo elegirá qué tareas puede acometer de entre la lista de cosas por construir (siempre priorizadas por nuestro cliente). Se definirá un objetivo más pequeño para el Sprint actual por lo que tendremos una nueva meta, mucho más cercana, que no permitirá que desesperemos por lo lejos que está la meta final. Es el momento de coger martillo y cincel.

Al separar las tareas a realizar en pequeños grupos y tratar de resolverlos en periodos fijos de tiempo (timeboxed) cada uno con su propia meta, tiene las ventajas de la estrategia del ‘Divide y vencerás’. Planeas tu objetivo más inmediato y lo que vas a hacer para resolverlo sin abrumarte con todo el trabajo que aún queda por delante. Una gráfica burn-down ayudará también a ver que el trabajo restante va disminuyendo y que, por lento que nos pueda parecer, avanzamos hacia nuestro producto final, la catedral.

Queda claro el marco de trabajo, ahora, manos a la obra …

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

Estimaciones con SCRUM

Una de las cosas que más quebraderos de cabeza suele darnos cuando hemos decidido adoptar SCRUM es cómo hacer estimaciones y cómo nos van a ayudar éstas a saber qué tal vamos y cuándo vamos a finalizar el proyecto. En SCRUM suele estimarse dos veces (sí, dos veces) pero no en la forma tradicional con una única y sesuda estimación en horas/días de trabajo al principio del proyecto.

Esta forma de estimar suele traer algo de polémica pero intentaré explicarlo lo mejor que pueda: Haremos una primera estimación grosso modo en puntos y no en horas en la que partiendo de la lista inicial de funcionalidades a desarrollar estimaremos el esfuerzo o dificultad que supondrá realizar cada una de los requisitos del proyecto. Este esfuerzo lo mediremos o, mejor dicho, lo calibraremos en puntos siguiendo por ejemplo la serie de Fibonacci (1, 2, 3, 5, 8, 13, …) o incluso usando las medidas usadas en las tallas de camiseta (S, M, L, XL, XXL, …)

Si atendemos al concepto de Cono de Incertidumbre, hagamos la estimación que hagamos, le dediquemos el tiempo y metodología que queramos, nuestra estimación será errónea (a menos que conozcamos cada uno de los detalles del proyecto). Rodrigo Corral lo explica muy bien en Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil (el resto del post no tiene desperdicio tampoco) Entonces ¿por qué dedicar tanto esfuerzo? Asignemos 1 o 2 puntos a las funcionalidades sencillas, 3 o 5 a las de dificultad media y 8 o 13 a las de dificultad alta o muy alta (¿necesitas más puntos? quizás deberías descomponer esta funcionalidad en otras más pequeñas)

Esto traerá un considerable ahorro de esfuerzo al estimar y, por qué no, también quitamos estrés al equipo, que tendrá miedo a equivocarse. Con la estimación a alto nivel mediante puntos evitamos algunos de los inconvenientes de las estimaciones en horas: Si indicamos que en una tarea vamos a tardar 40 horas, la regla de que el trabajo se expandirá hasta tomar todo el tiempo disponible se aplicará a esto también. Por otra lado se evitará un fallo común en los que comienzan con SCRUM (sí, yo también lo cometí) y que consiste en pensar que «Si se ha trabajado 40 horas en esta tarea, el burndown graphic deberá bajar en 40 horas» Esto daría una falsa sensación de avance en el proyecto si la tarea no está completamente terminada y aprobada por el cliente.

La segunda estimación la haremos cuando planifiquemos las tareas del sprint. En esta planificación tendremos un mayor conocimiento del proyecto y de lo que implica cada tarea. Podríamos hacer entonces una planificación en horas aunque hay equipos que aún en ese momento usan una estimación en puntos o deciden no estimar en absoluto (ver entrada sobre técnicas de estimación en ScrumAlliance.org)

Estas estimaciones nos permitirán conocer el ROI (retorno de inversión) de cada funcionalidad para que el cliente pueda decidir qué tareas quiere realizar en el siguiente sprint y nos permitirá también, después de algunos sprints, conocer con bastante exactitud cuál es la velocidad del equipo (de nuevo, tema para otro post)

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

Entregar lo que el cliente necesita

Uno de los principios básicos de SCRUM (y también unos de sus desafíos) consiste en la aceptación de que el cliente puede cambiar de idea sobre lo que necesita. Con SCRUM se intenta dar una respuesta flexible admitiendo que el propio cliente puede no tener completamente definido cuál es el problema y que, a menudo, a medida que avanza el proyecto éste puede darse cuenta de qué es lo que realmente necesita. Por esto, entre otras cosas, SCRUM es denominada como una metodología Ágil.

La lista de requerimientos y funcionalidades creada al principio del proyecto es abierta y puede ser modificada en cualquier momento. Contiene estimaciones aproximadas del esfuerzo que supone el desarrollo de estas funcionalidades y, antes de comenzar cada iteración o sprint, se toma un grupo de estos requerimientos como objetivo para el final del mismo. Dos o tres semanas más tarde, los requisitos serán otros y el nuevo objetivo a alcanzar puede ir en una línea distinta a la definida unos sprints atrás.

Es una nueva forma de trabajar, un tanto difícil de asimilar, tanto para el cliente como para el proveedor. Hay caminos aparentemente más fáciles. Siempre podemos volver a la fórmula tradicional: En primer lugar analizamos el problema durante meses, cuando tenemos claro lo que debe hacerse comenzamos a desarrollar la solución duramente varios meses más. Al finalizar, cruzamos los dedos y entregamos el producto final al cliente.

Después de este punto, quién no ha oído frases como ‘Pero esto no es lo que yo quería, aquí falta …’, ‘No, así no era, no me entendiste bien …’, ‘Sí, está bien, pero voy a llamar al Director que es quién realmente da el visto bueno’ (por supuesto, el Director no ha acudido a ninguna de las reuniones de análisis) Después de los meses de trabajo invertidos y las prisas y el estrés para cumplir las fechas comprometidas, el cliente no ha recibido lo que necesitaba y necesitaríamos trabajar aún más para intentar parchear la solución proporcionada.

La flexibilidad de SCRUM también tiene sus riesgos: ¿Qué sucede si el cliente no termina nunca de añadir nuevas funcionalidades a la pila del producto? ¿y sí el cliente redefine incesántemente cada requisito? Esto será tema para otra entrada del blog.

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

¿Por qué funciona esto de SCRUM?

Se han parado alguna vez a pensar por qué se consiguen, en promedio, tan buenos resultados cuando su usan metodologías ágiles como SCRUM. Según el Informe CHAOS 2011, los proyectos Ágiles tienen una tasa de éxito tres veces superior a los proyectos en Cascada.

¿Cómo se consiguen estos resultados? La lista de ventajas de SCRUM es extensa, hay muchas webs que las describen pero ¿todos los beneficios teóricos de SCRUM tienen igual peso? ¿Hay algunos de ellos que realmente marcan la diferencia?

He trabajado en proyectos en los que SCRUM no pudo ser aplicado al 100%, sólo se mantuvo un ‘SCRUM de supervivencia’ y aún así se notaban sus efectos positivos en los resultados del proyecto. No conozco la respuesta exacta a estas preguntas pero me atrevería a resaltar un par de aspectos como los principales responsables de estas tasas:

  1. El cliente prioriza sus requisitos y sabe lo que va a obtener al cabo de unas semanas. En cada reunión de demo el cliente comprueba lo que se ha conseguido y si le sirve o no para cumplir con sus necesidades. En la siguiente iteración puede replanificar sus requisitos y orientarlos hacia la siguiente meta que quiere alcanzar. No debe esperar a que el equipo trabaje durante meses para tomar el pulso al proyecto y ver si el resultado va por el camino deseado.
  2. El equipo conoce exactamente cuál es la siguiente meta parcial que se quiere alcanzar en cada Sprint y qué tareas le llevarán a ello. ¿Alguien imagina si todas las cuotas de nuestra hipoteca las debiésemos abonar en un único pago anual? Muchos serían serían poco previsores y se pasarían los últimos meses apretándose el cinturón para intentar arañar unos euros que les permitiesen cumplir el plazo de pago. Otros guardarían a un lado una cantidad mensual o semanal con la que llegar a la fatídica fecha sin ahogos de última hora. Esta es una filosofía muy parecida a la que conseguimos con las entregas parciales en cada demo del Sprint.
Seguro que se pueden encontrar otras muchas ventajas importantes. En mi opinión pocas lo serán tanto como estas dos ¿qué opinan?
Publicado en Blog, Blog 1 | Etiquetado , , , , | Deja un comentario

¿De qué va a ir todo esto?

Como un entusiasta más de metodologías ágiles como SCRUM, Kanban o Lean Software Development me he animado a crear este blog para contar en él lo que he aprendido en estos años sobre la gestión de proyectos, el desarrollo del software y la calidad del mismo.

Además de aportar mi parecer sobre la industria del software o la gestión de proyectos y servicios tecnológicos quisiera que el blog sirva también para encontrar recursos e información sobre todas estas metodologías y técnicas. No llegará a ser un compendio exhaustivo pero espero que lo encuentren de utilidad.

No pretendo con este blog evangelizar sobre estas prácticas ni teorizar sobre las mismas. Tampoco voy a llenar estas entradas de nombres de artefactos, stakeholders, backlogs sprints planning o burndown graphics ¡Dios me libre! Si algo me gusta de estas metodologías es que no necesitas formarte durante meses  para empezar a aplicarlas. Sólo debes entender sus principios para luego probar, fallar, mejorar, volver a probar, volver a fallar y así continuar mejorando (Kaizen lo llamaría)

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