Jun 22

Visita a Paradigma tecnológico

Hace ya casi un mes, me tocó una visita a Paradigma Tecnológico.

El tema es que un departamento de nuestra empresa, no el mío, tiene un proyecto en el que está como requisito el uso de algunas tecnologías modernas, entre otras, BigData. Puesto que en los departamentos de nuestros alrededores nadie tiene experiencia con estas tecnologías, se ha decidido subcontratar desarrollo y asesoría a alguien que sepa del tema, para sacar el proyecto adelante y para aprender nosotros sobre ello. La empresa elegida ha sido Paradigma Tecnológico.

Esta compañía ágil, como reza en su página web, hace nuestro proyecto con Scrum y finalizado el primer Sprint, llega el momento de hacer la "demo" al cliente, es decir, al departamento de mi empresa. Teniendo yo fama de friki, este departamento y  mi propia jefa, decidieron que yo debía acudir también a ese sprint, para enterarme lo más posible de este tipo de nuevas tecnologías y ver si son aplicables a otros proyectos. Así que allí fuí.

Lo que más me llamó la atención, en lo que se puede ver dando un paseo por las instalaciones de Paradigma, es que sí tiene toda la pinta de que usen Scrum realmente en todos los proyectos. Según se pasea, se ven tableros de Scrum y paquetes de postit de colores por todos lados. Según se podía ver y me contaba una de las personas que trabaja allí, los desarrolladores trabajan en una sala diáfana con mesas agrupadas de 6 en 6, creo recordar. Los programadores de un proyecto trabajan juntos en un grupo de mesas y en la pared al lado de su grupo de mesas tienen el tablero Scrum. Nos enseñaron también el product backlog de nuestro proyecto, un tablero enorme con miles de postit pegados con celo y nos enseañaron el gráfico "burn down" correspondiente a nuestro primer sprint.

En cuanto al Sprint que nos hicieron, era un poco extraño, posiblemente por ser el primer Sprint. Básicamente consistía en explicarnos la arquitectura decidida, una demo real sencilla viendo funcionar esa arquitectura y un "mono" de la interfaz de usuario para que nos hicieramos una idea de cómo iba a ser. Como es de rigor en un sprint, insistieron mucho en que hicieramos comentarios y diéramos nuestras opiniones, ahí creo que nos quedamos un poco "cojos", culpa nuestra.

Hay algunos detalles del Scrum que no me cuadran con lo que pensaba, por ejemplo, para el segundo Sprint se indicaron las tareas que se iban a hacer, imagino que previamente acordadas con el Product Manager que es una pesona de nuestra empresa. Lo que no me cuadra es que en ese segundo Sprint no se llegaba a una funcionalidad útil para el cliente, sino que las tareas eran pequeños (o grandes) trozos de código que evidentemente hay que hacer, pero que no constituyen en sí un producto, aunque sea muy básico, que se pueda entregar de alguna forma, salvo quizás, como un conjunto de liberías. Quizás yo soy demasiado teórico. Quizás un segundo sprint (de 3 semanas) sea también muy pronto para obtener ese primer producto básico. En cualquier caso, no le he dado demasiada importancia, ya que en mis intentos de hacer Scrum con mi grupo de trabajo, sé lo complejo que es entregar un pequeño producto en los primeros Sprint, donde hacer cualquier cosa completa que vaya desde un extremo del sistema (la interfaz de usuario) hasta el otro (el equipo hardware que se quiere controlar), pasando por todos los pasos intermedios (base de datos, lógica de negocio, …) requiere hacer mucho código de la arquitectura del sistema. Pero me deja ese mal regustillo de que quizás Scrum es demasiado teórico, excesivamente complejo, o no aplicable a cualquier proyecto …

Resumiendo, la impresión en general ha sido buena y me voy confirmando cada vez más en que hacer un Scrum que cumpla al 100% con la teoría de Scrum es muy complejo.

Apr 11

He leído “Scrum y XP desde las trincheras”

Aprovechando el eBook que me han traído los reyes estoy leyendo mucho últimamente, en el tren y en las cafeterías (sí, soy el friky ese que se sienta solo en una esquina y esconde las narices en el libro, aunque no tengo muy claro si esa expresión aplica a un eBook). Ahora le ha tocado el turno a "Scrum y XP desde las trincheras", de Henrik Kniber.

El libro no cuenta Scrum, por lo que no es el adecuado si quieres aprender qué es Scrum. De XP habla más bien poco o nada (creo que menciona la programación en parejas en un par de ocasiones, poco más). Entonces, ¿de qué va el libro?

El autor trabaja con grupos de desarrolladores que aplican Scrum y como la teoría nunca es tan bonita como la pintan, aplicar Scrum tiene un montón de problemas o cosas que no están muy claras cómo resolver. El autor nos va contando los problemas que ellos han encontrado, soluciones que han probado, soluciones que han adoptado y qué problemas todavía no saben resolver. Es un libro adecuado para aquellos equipos que saben qué es Scrum y lo están aplicando desde hace poco y se van encontrando con los problemas típicos de aplicar Scrum. Este libro le ofrece un abanico de soluciones posibles y cuáles le han funcionado al autor y cuales no.

Algunos problemas típicos:

¿Qué hacer cuando alguien del equipo se queda sin tarea dentro del Sprint?. Entre las soluciones del autor está el dejarle que él mismo elija cualquier cosa que pueda hacer para ayudar al equipo (test, pruebas, documentación, scripts que automaticen tareas, lo que sea). Y si sigue sin encontrar nada para hacer, entonces convertirlo en "recadero" de los miembros del equipo, una forma de ayudar es traerles café, por ejemplo.

¿Qué hacer cuando el código o lo que sea necesita tiempo para ser arreglado y no para producir historias válidas de  un Sprint?. El autor propone varias cosas, pero parece que opta por bajar el factor de rendimiento del equipo lo suficiente como para que puedan abordar estas tareas de mejora, es decir, aceptan menos historias en el Sprint.

¿Qué hacer si el proyecto es grande y necesita muchos desarrolladores?. El autor dice haber probado con un equipo de Scrum grande y con varios más pequeños. Al final la solución buena según él es hacer equipos pequeños (de entre 3 y 10 desarrolladores).

Y si hay varios equipos Scrum en el mismo proyecto, ¿cada uno a su bola? ¿Sprint sincronizados? ¿Un sólo dueño de producto o uno por equipo?. Entre las soluciones del autor, parece que opta por un sólo dueño de producto, Sprint sincronizados de forma que la demos sean el mismo día, la planificación también pero solo par repartir las historias entre los equipos, luego cada equipo hace su planning poker. Las reuniones diarias deben hacerse a diferentes horas, de forma que el jefe de producto pueda acudir a todas reuniones de todos los equipos si quiere, etc, etc. Otra ventaja de esto es que al terminar cada Sprint se pueden intercambiar miembros entre los equipos, partir un equipo más grande en otros más pequeños o juntar dos equipos en uno.

¿Y qué hacemos con los que llegan tarde a la reunión diaria?. Elegir una hora buena para todos y si los tardones son habituales, lo típico de echar una moneda a un fondo común o traer "bollitos" para todos.

¿Y si el equipo está distribuido geográficamente?. Messenger abierto todo el día, web cams, etc, etc y todo lo posible para facilitar la comunicación. Habla incluso de poner web cams permanentes, de forma que todos puedan verse a todos en cualquier momento.

En fin, lo dicho, todo un abanico de problemas y posibles soluciones. El libro es ameno de leer y no se hace en absoluto pesado.

 

Jan 14

¿Se deteriora Scrum?

scrumVeo que Scrum está dando fuerte. En nuestra empresa, aparte de nuestros intentos de hacer Scrum, hay otros departamentos que también lo están intentando. También conozco gente en otras empresas con las que colaboramos que están empezando a usarlo. Pero no solo es eso lo que me llama la atención ("frikis" los habemos en todos lados)

Por un lado, en la portada de nuestra intranet, que la empresa aprovecha para poner lo maravillosa que es, los proyectos que tiene y lo bien que va, apareció hace unos días un artículo en el que nuestra empresa y otra habían colaborado para la implantación de Scrum en los procesos de no sé qué.

Por otro, ha caído en mis manos (de forma completamente legal) una oferta técnica de otra empresa para el desarrollo de un sistema … y en él ponen que usarán redmine … y Scrum como metodología de desarrollo.

Todo esto tiene su parte buena … y su parte mala.

La parte buena es que Scrum está ganando la suficiente fama de ser una buena metodología de desarrollo como para que las empresas empiecen a considerarlo como algo bueno, que merece la pena intentar. Lo ponen en su propaganda, en sus ofertas, …

Lo malo es lo de siempre, que se acaba desvirtuando el fondo real que hay detrás de la metodología. Al convertirse en algo "bonito" para poner en papel, se pondrá "usamos Scrum" por sistema, se use bien, se use mal o no se use en absoluto. El cliente no conseguirá siempre los resultados esperados de esta metodología y acabará perdiendo su fama.

La verdad es que estoy un poco hasta las narices de las mentiras empresariales, "vende-motos" y palabras rimbombantes. Conseguir un premio a "la excelencia empresarial" es muy fácil, sea lo que sea eso, pero todos los curritos sabemos que lo que hay detrás es cualquier cosa menos "excelencia". La "garantía de calidad", sea lo que sea eso, tres cuartos de lo mismo. Tener la "certificación ISO no sé qué", sea lo que sea eso, igual. Y dentro de nada, ser "Scrum certified" será algo (sea lo que sea) que no sabremos que es, pero que pagando se consigue.

Jul 03

Ventajas de la reunión diaria

Daily ScrumComo no todo es blanco o negro, las metodologías ágiles tienen también muchas cosas buenas. Una de las más sencillas de implementar y con la que conseguir mejoras son las reuniones diarias. Intentamos ya en varias ocasiones hacer Scrum y Kanban, incluso TDD y varias más de las metodologías/prácticas ágiles. Aunque seguimos en el intento, la reunión diaria es la más fácil de seguir y de la que obtener ventajas rápidamente.

La hora teórica de entrada es las 8:00. Habitualmente la gente suele ir llegando sobre las 8:30 y lo primero que hago es ir a tomar café con mi amiguete y luego revisar el correo, el Hudson y el Taskfreak. Imprimo este último y con él, sobre las 9:00 hacemos nuestra reunión de 10/15 minutos. Antes éramos cuatro en la reunión, ahora sólo somos tres.

La reunión la hacemos sentados. Las buenas costumbres aconsejan hacerla de pie para que la gente esté incómoda y la reunión no se prolongue más de la cuenta, pero con el tiempo hemos conseguido no tener ese problema, rara vez dura más de 10 minutos y nos permitimos hacerla sentados.

¿Qué mejoras hemos conseguido con la reunión diaria?

Sensación de grupo

La primera y más importante es la sensación real de la gente de formar parte de un grupo. En nuestro caso concreto, si lo de contar "qué hicimos", "qué vamos a hacer" y "qué problemas tenemos" nos lleva realmente cinco minutos (sólo somos tres), solemos permitirnos unos cinco minutos más de reunión para "cotilleos": comentar como van las pruebas de un proyecto, qué tal le va a uno que está desplazado en la India, los planes del jefe de mover a cierta persona a otro proyecto, etc, etc. Todo esto, además de reforzar la sensación de equipo de trabajo, también refuerza algo los lazos de compañerismo.

Dije que antes eramos cuatro y ahora somos tres. ¿Qué pasó con el cuarto?. Simplemente que le propusieron pasarse a algo más adecuado a su perfil (administrador en vez de programador) y depender de otra persona que no era yo. Pero cuando se lo propusieron, dijo que no quería cambiar del todo, se sentía muy integrado en nuestro grupo y no quería perder eso.

Fue realmente una sorpresa esta objeción. Cuando estaba en nuestro grupo tendía a distraerse de las tareas de programación para dedicarse más a instalar tarjetas de red, configurar routers, instalar software, etc, se le veía claramente que le iba más eso que programar. Le propuse el cambio a mi jefa y ella me dio la razón, pensó que esta persona podía disfrutar más de su trabajo en el grupo de administradores y le propuso el cambio. Y la objeción fue imprevista, efectivamente, dijo que le gustaba más instalar cosas que hacer software, pero que no quería cambiar por sentirse muy integrado en nuestro grupo. Así que el cambio fue gradual, pasó a realizar tareas de administrador poco a poco y siguió acudiendo a nuestras reuniones para hacer su parte de trabajo de programador. Al final la realidad se impuso y realizar dos papeles distintos es imposible, así que dejó cogiendo cada vez más trabajo de administrador y menos de programador y dejó de acudir a las reuniones de forma natural.

De hecho, los tres que quedamos estamos a punto de trabajar en cosas totalmente distintas (tres proyectos distintos, con tres jefes de proyecto distintos y temáticas totalmente distintas). Pero de común acuerdo hemos decidido seguir haciendo las reuniones porque a fin de cuentas el software es software, los problemas son similares y si alguien tiene un problema y lo cuenta a los que ya considera sus compañeros, enseguida se prestan a ayudarle a resolverlo.

Enfocarse en las tareas concretas del día a día

El tener nuestra lista de tareas y decir a primera hora de la mañana "hoy voy a hacer esto" hace que el resto del día tengas claro qué vas a hacer. Supongo que hay algunos que no necesitan este tipo de cosas, pero yo soy de los que tiende a saltar de una cosa a otra. "Comprometerme" con el grupo a que ese día voy a hacer determinada cosa (aunque ninguno de ellos dependa de que yo lo haga), me pone una pequeña traba a distraerme. Me daría vergüenza al día siguiente decir "no he hecho esta tarea porque he estado mirando el correo, navegando por internet, mirando otra vez el correo, un café, probando una herramienta que me he encontrado …."

Así que lo dicho, decir en público "hoy voy a hacer esto", de alguna forma te obliga a centrarte en hacer exactamente eso.

Saber dónde se va el tiempo e incentivo a la mejora

A pesar de todo, en muchas ocasiones, al día siguiente acabas diciendo "No he terminado la tarea que dije ayer" y cuando llegas a la parte de los problemas que has tenido para acabarla dices "me han llamado a una reunión de tres horas", "Se han llevado un ordenador del laboratorio que hacía puerta de enlace de la red del laboratorio y me he quedado sin conexión con los equipos", "me han pedido hacer esto de otro proyecto", etc, etc, etc.

Algunas cosas son inevitables, pero al menos eres consciente de dónde se pierde el tiempo, ya que tienes que decirlo claramente a tus compañeros. Pero cuando esas pérdidas de tiempo tienen arreglo, enseguida "canta" que perdemos el tiempo por algo que hacemos mal y que se puede arreglar/mejorar. Justo lo que pregona Scrum. Aunque en nuestro caso ha quedado un poco fuera la figura de Scrum Master, siempre alguno del grupo coge como tarea mejorar eso que dificulta el trabajo.

Aprovechar la capacidad de los mejores

Y aunque los mejores del grupo o con más capacidad posiblemente no necesiten estas reuniones para centrarse en lo que tienen que hacer o para mejorar su propio proceso de trabajo, no todos tienen esa capacidad.

En estas reuniones las personas de más capacidad se hacen también conscientes de los problemas de los demás, no sólo de los suyos propios. Son capaces incluso de ver posibles mejoras en donde la otra persona ni siquiera ha detectado un problema. De esta forma, todos se benefician de los mejores aunque no vayan específicamente a preguntarle por un problema concreto.

Y los mejores tampoco son infalibles, muchas veces alguien no tan bueno es capaz da una idea o propone algo que se le había escapado

Resumiendo

Resumiendo, que estamos encantados con nuestra reunión diaria y que aunque tiene pinta que el grupo se disgrega (cada uno a su proyecto), por unanimidad queremos seguir haciéndola. Quizás el tiempo nos diga que carece totalmente de sentido… o quizás no.

Y aunque se puede ver claramente que no hacemos una reunión diaria al puro estilo Scrum (no la hacemos de pie, no hay tablero aunque sí lista de tareas, no ha scrum master propiamente dicho), la mejora es apreciable por todos.

Jul 02

¿Qué habría pasado de usar TDD?

hommer pensando en un programa softwareSiguiendo un poco con el post anterior, hace tiempo en Verlo para creerlo comenté un código real de una empresa con el que me había tropezado. En ese código había una clase (llamémosla Datos) con 16 atributos estáticos iguales (digamos, atributo1, atributo2, … atributo16). Pulsando un botón (uno por atributo) debía mostrarse en una ventana nueva algunas cosas relativa a uno de esos atributos. En el código había 16 clases Ventana, una por atributo, llamadas Ventana1, Ventana2…. Ventana16. La única diferencia en el código de esas clases, aparte del nombre, era que accedía a Datos.atributo1, Datos.atributo2 … Datos.atributo16

¿Qué habría pasado si hubieran usado TDD?

Supongamos que este mismo programador hubiera hecho este código usando TDD. ¿Qué habría pasado?. Pues lo evidente, habría 16 clases de test llamadas TestVentana1, TestVentana2, … TestVentana16.

Pero TDD no es sólo hacer test, es hacerlos antes. Bueno, supongamos que los ha hecho antes.

Y TDD tiene otro tercer paso, refactorizar para quitar todas las repeticiones posibles de código, incluso las menos evidentes. Bueno, no sé vosotros, pero yo, independientemente de usar o no TDD, me repatearía hacer copy-paste 16 veces de una misma clase y como ser vago a veces es una virtud, habría dado las vueltas necesarias para no hacer esto. Sin TDD se me ocurre simplemente meter los atributos en un array de 16 posiciones y en un método set() de la única clase VentanaUnica pasarle el índice de la posición que debe tratar. Es lo primero que se me ocurre, nada complejo, seguramente hay más y mejores soluciones.

Sin embargo, este desarrollador no lo ha hecho. ¿Por qué?. Se me ocurren cuatro posibles motivos:

  1. Totalmente inexperto en java, un array es algo complejo de usar y lo del set() ni lo cree posible. Muchos programadores novatos tiene problemas para hacer que los atributos de una clase se vean en otra y por eso tienden a hacerlos estáticos (justo como ha hecho este señor).
  2. No tiene cabeza para programar, por más vuelta que le ha dado, no se le ha ocurrido cómo evitar hacer las 16 clases.
  3. Le importa tres pepinos. Para qué se va a complicar la vida si con 16 clicks de ratón (un copy y 15 pastes) lo arregla.
  4. Todas las anteriores.

Bueno, pues con este panorama, ¿qué habría hecho al intentar refactorizar con TDD?

  1. Ya tengo mi TestVentana1, así que hago mi Ventana1. Ahora mi TestVentana2 y hago mi Ventana2. ¡¡ Código repetido !!. ¡¡ Vamos a refactorizar !!: Imposible, java no permite hacerlo, si java no permite pasar el atributo de la clase Datos a la clase Ventana, Ventana1 y Ventana2 deben ser clases distintas. Y no te digo juntar los dos test en uno solo.
  2. Buff, qué dolor de cabeza, no se me ocurre como puedo convertir dos clases distintas que manejan atributos distintos en una sola.
  3. Jó, que rollo refactorizar ahora que me está funcionando, voy con los siguientes 14 pastes, que el copy ya lo tengo hecho.
  4. Java no deja, no se me ocurre como hacerlo y voy a correr un montón si reaprovecho el copy para el resto de pastes.

Algo como Srcum tampoco evitaría estas cosas. En el sprint diario este señor diría "Ya tengo las ventanas de  los atributos" y todos felices. Bueno, con un poco de suerte, un día diría "tengo la Ventana1 del atributo1", al día siguiente "tengo la Ventana2 del atributo2" y alrededor del quinto día, quizás a alguien se le ponga la mosca detrás de la oreja y quiera ver qué está haciendo. De todas formas, no se tardan 16 días en hacer 15 pastes.

Una herramienta de análisis estático de código integrada en una herramienta de integración continua cantaría esto por la noche, suponiendo que cante cuando encuentra código repetido y, como hacemos nosotros, el compilado falla si no se cumple alguna métrica importante. Desgraciadamente, existe el @SuppressWarnings que la gente se acostumbra a poner por sistema, incluso antes de que cante la métrica (conozco al menos dos personas que lo hacen).

La programación en parejas también habría ayudado, salvo que la pareja de nuestro programador fuera el recién entrado al que le han asignado para que le enseñe.

Mar 05

He leído “Kanban y Scrum – Obteniendo lo mejor de ambos”

He leído "Kanban y Scrum – Obteniendo lo mejor de ambos" que te puedes descargar en el post del enlace, hacia el final, en cristiano.

En una primera parte, comparan scrum con kanban en plan teórico. No explican scrum con detalle ni kanban, es algo que se da por supuesto, simplemente se centran en comparar qué cosas hace uno y qué cosas hace el otro.

En la segunda parte se cuenta una historia real en la que intentan implantar Scrum o Kanban en un departamento de una empresa real. Van explicando los problemas de ese departamento, analizando posibles soluciones, implantándolas y viendo las mejoras que se producen en el proceso. Para su caso concreto se deciden por Kanban y lo van adaptando hasta que se hace cómodo. El tablero Kanban se convierte en una herramienta importante para ver si hay problemas y si se solucionan.

La parte teórica de comparación es más o menos lo ya sabido y como comparación teórica está bien, hay algunos detalles que no tenía claros y se han quedado aclarados, sobre todo en la parte Kanban que quizás conozco menos o está menos documentada que Scrum.

La parte de implantación práctica no me ha gustado demasiado el cómo está escrita. Trata de explicar los problemas del departamento, las posibles soluciones, la implantación de la mismas y los resultados obtenidos, pero lo hace en muy pocas hojas y demasiado por encima para mi gusto. Al final de la lectura me ha quedado la impresión de … "¿ya está?" y de "kanban es maravilloso, fíjate como el departamento del que todo el mundo se quejaba en cuatro meses ha ganado el premio al más productivo".  Parece propaganda.

Sin embargo, si leemos entre líneas (o, al menos, no nos quedamos en los detalles), sí sacamos la conclusión de lo que es Kanban en el fondo. Y en el fondo kanban es detectar los problemas, encararlos y solucionarlos. El tablero kanban ayuda a detectar si hay o no problemas, viendo si las pegatinas se apilan en alguna columna o van fluyendo de principio a fin sin aglomeraciones. Y el tablero kanban ayuda a ver si la solución que hemos puesto al problema es efectiva o no, viendo si las pegatinas se desatascan o no. Lo realmente importante de toda esta filosofía es "ten claro tu objetivo, detecta los problemas para conseguirlo, afróntalos y solucionalos". En el libro, el uso del tablero kanban no es más que la herramienta, lo importante es que detectaron porqué no funcionaba bien el departamento, consiguieron mejorar su forma de trabajo, involucrar a la gerencia para que ayudara a solucionar problemas y mejoraron sus resultados. Todo un reto.

Nov 10

Al final, ni Scrum ni Kanban

 

Empezamos antes de verano a intentar hacer Scrum, pero el tema se fue relajando, principalmente debido a que estabamos en fases finales de proyecto y no se podía planificar a una semana vista qué incidencias se iban a encontrar durante las pruebas ni cuánto se iba a tardar en resolverlas. Entonces pensé que quizás en estas fases es mejor pasarse a algo como Kanban, pero quizás por pereza mía no llegamos a formalizarlo.

¿Y en qué ha quedado el tema entonces?

Pues básicamente tenemos la lista de tareas en curso de nuestro grupo. No lo hacemos con un tablero de post-it estilo Scrum o Kanban, sino que inicialmente era un pequeño documento de word con la lista. Todos los días nos reunimos unos minutos y comentamos estas tareas, cuáles están acabadas, su estado de avance, qué problemas hay con ellas y añadimos, si alguien puede abordarlas, más. Como digo, inicialmente era un word que todos los días imprimíamos y luego yo modificaba con lo que se había hablado en la reunión. Este word al final se ha cambiado por una herramienta web de tareas: taskfreak. muy sencilla y cómoda de usar que nos permite tener nuestra lista de tareas en curso siempre actualizada y accesible a todos.

¿Pegas?

Pues los jefes de proyecto no participan demasiado. Ellos nos van poniendo tareas/incidencias en redmine, por correo o de palabra. Yo las aparco y las ordeno en función de la insistencia del jefe de proyecto en cada tarea y de las fechas de hitos. Luego las voy metiendo en nuestra lista de tareas en curso según se van terminando las existentes. Con este mecanismo, nos falta todo eso que pregonan las metodologías ágiles de realimentación frecuente, no ya del cliente, sino del jefe de proyecto.

¿Ventajas?

Las de la reunion diaria. Todos tenemos más claro qué vamos a hacer ese día, somos conscientes y ayudamos al otro cuando tiene problemas y yo, como resposable del grupo, estoy viendo que las cosas se hacen más rápido y con menos errores.

Seguramente cosas como Scrum son maravillosas si se llevan bien y tienen muchísimas más ventajas, pero aunque no se consiga el 100% de sus beneficios, simplemente aplicando algunas de sus reglas (reunión diaria en este caso y lista de tareas priorizada, aunque sea por mí), se obtiene una mejora importante frente a no hacer nada, el cada uno a su bola, las tareas sin priorizar y cada uno elige la que le apetece en ese momento.

Esto me recuerda la famosa regla del 80-20. Quizás con el 20% de las prácticas de Scrum se consigue el 80% de los beneficios. Posiblemente sea exagerado, pero con lo poquito que hacemos he notado una mejora importante en nuestra forma de trabajo.

Mi siguiente reto, una vez establecida la constumbre de la reunión diaria que ya hacemos cómodamente, es elegir alguna otra de las prácticas de Scrum y tratar de implantarla hasta que se convierta en costumbre. Quizás la retrospectiva una o dos veces por semana (no tenemos todavía los sprints, seguimos rematando proyectos).

Aug 22

Primero Scrum, luego Kanban

 

Hace tiempo comenté que se nos iba relajando Scrum y que quizás Kanban nos fuera mejor. El motivo era que el Scrum se nos hacía muy difícil en las condiciones actuales de nuestros proyectos: fases finales, con el código prácticamente acabado a falta de corregir bugs, integrar con hardware, probar, etc. Estimar cuánto vas a tardar en arreglar un bug es muy difícil y estimar cuántos bugs vas a encontrar en las pruebas peor, por lo que planificar sprints se nos hacía poco menos que imposible.

Sin embargo, hay muchos artículos que critican a los que dicen "Nosotros no podemos aplicar Scrum" o "En nuestros proyectos no se puede aplicar Scrum", así que la decisión de cambiar de Scrum a otra cosa me dejaba mal sabor de boca. Me daba la impresión de que era más un problema de incapacidad e inexperiencia nuestra que un problema real con Scrum.

Pero el otro día leí un artículo en Dos Ideas: Iterar primero, fluir después. La idea básica que exponen es que en las fase de desarrollo del proyecto se puede usar algo como Scrum, cuando el código está sin hacer, cuando se debe hacer un seguimiento de cómo se va, cuando se puede hacer un listado de historias de usuario, estimarlas y hacerlas. Pero en las fases finales, cuando ya casi todo está hecho y sólo queda corregir errores o hacer mejoras/cambios, Kanban puede ser mas adecuado. Hay que priorizar esos bugs/cambios e ir haciéndolos. Cada vez que se termina uno, se coge el siguiente. No se planifica nada y las cosas están cuando estén.

La verdad es que esa idea me gusta mucho. Aunque quizás mi opinión es muy subjetiva, porque justo esa idea es la que me quita el remordimiento de conciencia de no poder haber aplicado Scrum y apoya mi idea de pasarnos a Kanban dadas nuestras circunstancias. Creo que merece la pena intentarlo.

Así que a la vuelta de vacaciones (por eso escribo poco estos días), cogeré a mi grupo de tres personas con seis proyectos faltos de tiempo a cuestas y les haré la propuesta, a ver qué opinan.

Jul 08

¿Por qué elegí Scrum?

 

Este comentario de ilcavero al post Se nos va relajando Scrum… y los siguientes comentarios me han dado bastante sobre lo que reflexionar, si Scrum es o no adecuado para nuestro caso.

Nuestros sistemas llevan muchísimos equipos hardware de distinta índole (GPS, Receptores de radio, Grabadores digitales, etc, etc) que nuestro software debe controlar. Algunos de esos equipos se compran, pero otros se fabrican en otros departamentos de nuestra empresa. Además, todo el montaje de esos equipos en los armarios correspondientes, con su cableado entre ellos y con los ordenadores, es también cosa de otro departamento más de la empresa. De hecho, los costes de los equipos, de los armarios y su montaje son mayores que los del software que hacemos nosotros.

Dichos equipos y montaje no suele estar completa hasta fases finales del proyecto, de hecho, los plazos de entrega se miden más por el tiempo que se puede tardar en comprar/fabricar los equipos y montarlos que en lo que se va a tardar en hacer el software, que se supone que es menos. Por ello, no podemos probar en condiciones reales nuestro software hasta casi el final del proyecto.

Y esa es la duda que plantea ilcavero sobre si es adecuado o no usar Scrum en estas condiciones. Nosotros (los del software), al principio del proyecto podemos pensar en un sprint de un mes (por ejemplo), una serie de historias de usuario y hacer el sprint. Pero no podemos garantizar que esas historias de usuario están completas sin pruebas con los equipos reales que todavía no están disponibles. Nuestra única opción para hacer una prueba del software es hacer simuladores de los equipos. Esto hace que el producto "entregado" al final de cada Sprint no sea el producto real.

Por ello y siendo consciente del asunto, al elegir Scrum, tuve en cuenta que no se probarían los sprint en el sistema real. La condición de "historia terminada y funcionando" debería relajarse un poco y ser "historia probada y funcionando con simuladores, pendiente de prueba real en cuanto haya equipo".

Y de esta forma, aunque se pierden parte de las ventajas de Scrum relativas a entregas frecuentes, si nos aporta el resto de ventajas:

  • La reunión diaria hace que tengamos más sensación de equipo. Anteriormente, cada desarrollador se dedicaba a su tema y trabajaba aislado de los demás, salvo que su código tuviera comunicación con el código de otro. Aunque no llevamos mucho tiempo con Scrum y no lo estamos haciendo bien, algunos desarrolladores empezaban a coger tareas que no eran suyas, símplemente para ayudar a un compañero o porque creían que ellos podían hacerlo mejor o más rápido que el compañero novato.
  • La demo al final del Sprint no es como debiera ser, pero sí se llama a la gente (jefes de proyecto principalmente y otros desarrolladores de otros grupos que tengan que hacer algo parecido). Todos son conscientes de que hay cosas "simuladas" y que habrá que depurar al final, con equipos reales.
  • La retrospectiva ayuda a mejorar la forma de trabajo, independientemente de que el producto de la demo sea real o no.

Las pegas, hay dos importantes:

  • La fase final del proyecto (en la que estamos ahora en uno de ellos), puede durar uno o dos meses en los que el código está prácticamente hecho al 100%, pero no probado con todos los equipos reales. Esta parte de integración es muy compleja de llevar con Scrum (al menos, no se me ocurre como), ya que los errores no son conocidos y sabes que vas a dedicar el día a probar y corregir lo que vayas encontrando. Imposible hacer un sprint-planning, demos o incluso en el día a día, contar que vas a hacer ese día. Nuestro "Scrum" actual es sin sprints y se basa símplemente en reunirse a diario, contarnos los bugs encontrados y corregidos el día anterior, los encontrados y no corregidos, así cómo que problemas tenemos con las pruebas.
  • Esta fase absorbe el 100% del tiempo (es la fase final del proyecto que está a punto de cumplir hito) y las pruebas son lentas, ya que no sólo es el software el que tiene fallos, también hay cables mal hechos o equipos con bugs en su firmaware. Cualquier prueba necesita gente de varios departamentos. En un post anterior comentaba que estaba de Scrum master de dos equipos de scrum simultáneamente. Pues bien, uno de esos equipos es el que está integrando ahora … y el otro se ha quedado sin Scrum master.

En cualquier caso, otro punto importante a tener en cuenta es que hay muchos post en muchos blogs en los que se critica a los que dicen "Nosotros no podemos aplicar Scrum". Las condiciones no son las ideales, pero es cuestión de intentarlo y estoy convencido de que si logramos sacarlo adelante, aunque sea con pegas, vamos a mejorar nuestra forma de trabajo. Todo es cuestión de insistir y para eso están las retrospectivas al final del sprint, para ver cómo mejorar.

Jul 03

Se nos va relajando Scrum…. por decirlo suavemente.

 

Hace tiempo empezamos a intentar hacer Scrum un grupo de cuatro para atender seis proyectos, con sprints de una semana. Los sprints tan cortos eran necesarios para poder reorganizar el product backlog mezclado con historias de varios proyectos y poder cambiar de unos proyectos a otros en función de sus prioridades. Pero esos sprints tan cortos nos hacían perder mucho tiempo, ya que organizar todos los viernes una o dos demos, era demasiado para enseñar un pequeño incremento de funcionalidad.

Así que intentamos aproximarnos a algo más como Kanban. Teníamos nuestras historias, nuestras reuniones diarias, nuestras tareas, planificación por poker, pero no haciamos las demos.

Y ya no queda ni eso. Uno de los proyectos ha entrado en sus fases finales, así que estamos los cuatro liados con ese proyecto. Nuestro trabajo día a día consiste en probar, encontrar incidencias y corregirlas. Nuestro product backlog es "probar tal tema y corregir". Planificar eso es complejo, una incidencia nunca se sabe cuánto se puede tardar en corregir y menos una semana antes, cuando todavía no la has encontrado.

Así que nada, consideraremos este periodo como un descanso de Scrum, seguiremos con nuestras reuniones diarias (han gustado a todos los miembros del equipo) y a la vuelta de vacaciones retomaremos el Scrum/Kanban.