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

Jul 01

Metodologías ágiles y tradicionales. ¿De verdad sirven para algo?

el big-mac de las metodologiasBueno, parece que últimamente las malas son las metodologías tradicionales y las buenas son las metodologías ágiles, pero a fin de cuentas, ambas son metodologías y las metodologías, en general, presentan sus problemas. ¿Por qué?. Este artículo de Joel on Software nos da la respuesta.

Un cocinero excepcional hace lo siguiente:

Ahora bien, el Chef Desnudo no sigue ningún apestoso Manual de Operaciones. No mide nada. Mientras esta cocinando, usted ve un frenesí de comida sacudida y siendo arrojada por aquí y allá. "Simplemente pondremos una pizca extra de romero por acá, que no lo arruinara, y le daremos una buena sacudida", dice el. "Amásenlo así. Perfecto. Solo espárzanlo por todos lados." (Si, de verdad se ve como si simplemente lo esparciera por todos lados.

es decir, una persona brillante (cocinero en este caso), no necesita seguir ninguna metodología ni medir nada para obtener un producto genial. ¿Por qué las metodologías?. Pues porque gente brillante hay poca y del resto hay un montón. Para conseguir que el resto de la gente haga un buen producto, la persona brillante escribe una serie de reglas para que la gente del montón sea capaz de hacer lo mismo que él … y eso no funciona. Si se hace, se tienen "Big Macs". El resumen del proceso es el que indica Joel on Software en el mismo artículo

1. Algunas cosas requieren de talento para hacerse realmente bien.
2. Es difícil tener talento a la medida.
3. Una forma en que la gente intenta igualar el talento es haciendo que el talentoso cree las reglas para que los menos talentosos las sigan.
4. La calidad del producto resultante es muy baja. 

¿Y qué pasa con el software?. Pues más o menos lo mismo. Unas personas geniales escribieron unas metodologías para hacer buen software, sean las tradicionales, sea Scrum, sea TDD y el resto de los mortales tratamos de seguirlas. ¿Y qué pasa?. Pues cosas como esta

Total, que para hacer bien Scrum o hacer bien TDD o cualquier otra de las metodologías ágiles hay que hacer un cambio importante de mentalidad, ser bueno en muchas materias incluido como programador, tener mucho sentido común, etc, etc.

Y digo yo… la persona que cumple todo eso y puede hacer realmente bien TDD/Scrum/metodologías ágiles… ¿necesita realmente hacer todo eso?. Estoy totalmente convencido que un programador genial es totalmente capaz de hacer un muy buen software sin preocuparse en absoluto por ninguna metodología concreta, sino siguiendo simplemente su intuición. Y estoy convencido que el resto de los mortales estamos predestinados a hacer mal software directamente o hacer mal software después de haber seguido deficientemente una metodología ágil.

A pesar de todo, es mejor seguir una metodología que ninguna. Imagina en el McDonalds si cada uno se hace los BigMac de cualquier manera. Pero aunque lo he dicho muchas veces, me reitero. Si se quiere un buen software que destaque, el punto más importante a tener en cuenta es elegir a los mejores programadores.

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 22

¿Dos es más del doble? ¿Quién se atreve a probarlo?

Pongámonos en situación. Supongamos un grupo de dos desarrolladores que tienen que hacer dos tareas. Las tareas no tienen nada que ver la una con la otra, incluso son de proyectos distintos. Lo único que tienen en común es que tienen que estar para ayer, es decir, el tiempo para que estén acabadas es demasiado corto y es muy probable que se llegue por los pelos o no se llegue.

Ante esta situación tenemos dos soluciones:

  1. Solución tradicional, estándar, típica y la más habitual. Cada desarrollador se pone con una tarea y hasta donde lleguen. Esto da tranquilidad aparente, puesto que ambas tareas están haciéndose y se acabarán o no dependiendo de si los desarrolladores se acordaron de traerse el gorro de dormir a la empresa.
  2. Solución ágil, moderna y a la moda. Los dos desarrolladores se ponen juntos a hacer una de las tareas. Cuando la acaban, se ponen con la otra. Desde luego, parece muy arriesgado y a algún jefe se le pueden poner los pelos de punta – ¡¡ Pero !! ..  ¿cómo?¿no estais haciendo nada de la tarea B? –

Supuestamente la solución ágil es la correcta, pero eso sólo es cierto si dos desarrolladores trabajando juntos avanzan el doble de rápido que uno solo. Pero no queda ahí la cosa. Si la solución ágil es la correcta, es porque es mejor que la solución tradicional. Eso quiere decir que dos desarrolladores juntos deberían trabajar más del doble de rápido que si trabaja uno solo.

¿Y es esto cierto? ¿dos desarrolladores juntos trabajan más del doble de rápido que uno solo?. Si tú eres uno de los desarrolladores y es a tí al que van a caer los capones si las tareas no están acabadas a tiempo, ¿te atreverías a desarrollar una en conjunto con tu compañero y abandonar temporalmente la segunda? Y si tú eres el jefe de esos dos desarrolladores y es a tí al que caen los capones ¿les animarías a trabajar juntos en una tarea dejando abandonada temporalmente la otra? ¿Y a mitad del tiempo límite darías el tipo cuando tengas que decir -La tarea B no está porque ni siquiera la hemos empezado-?

Decisión difícil que requiere valor.

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.