Autor: Iñigo Serrano

El otro día encontré, en esa fuente inagotable de conocimiento que es el blog de Javier Garzás una entrada con la que me siento totalmente identificado.

Habla de una persona que entró en una empresa como programador y sus intentos de cambiarla de un modelo en cascada a un modelo ágil.

No tiene desperdicio y da recomendaciones que subscribo totalmente, sobre todo la primera parte en la que habla de lo difícil que es. De esto puedo dar fe, no ya para alguien que entra en la organización sin ese cometido, sino incluso cuando entras con el, como me ha pasado a mi.

Las resistencias puede llegar a ser Numantinas, incluso en sitios en los que los problemas son más que evidentes y de una magnitud muy considerable.

En resumen una lectura corta y muy recomendable para todo aquel que quiera cambiar la forma de trabajo de su organización, independientemente de que sea un peón o no.

En la entrada anterior comentaba sobre los equipos autogestionados que propugna scrum y la dificultad de pasar de un equipo gestionado de forma tradicional a un equipo autogestionado.

Hay una forma que, aunque reconozco que nunca he tenido la oportunidad de poner en práctica, me parece muy indicada para conseguir que el equipo avance en la autogestión. Me refiero al Planning Poker.

El motivo es que el planning poker implica que todo el equipo debe estimar las tareas. Esto obliga a que cada integrante del equipo se implique y entienda cada tarea por lo menos de una forma básica. En el manifiesto de Extremme Programming Kent Beck comentaba que la mayor parte de los problemas en un proyecto provenían de alguien que no había contado algo a otro.

Con las técnicas de estimación tradicionales en las que el jefe estima, el equipo no va a poder desarrollar esa faceta, así que nunca va a aprender a tomar decisiones y luego apechugar con las consecuencias. Así que tendrá difícil poder autogestionarse algún día.

Otras veces en un movimiento hacia la autogestión cada integrante del equipo estima las tareas que va a realizar, con lo que se pierde la oportunidad de que el resto del equipo las interiorice, total no lo tengo que hacer yo así que desconecto y no presto atención.

No creo que el planning poker sea infalible, porque hay cierto tipo de personas que niegan la realidad y ellos siempre tienen razón y no se equivocan. Pero este tipo de gente es tóxica, así que mejor desprenderse de ella cuanto antes, y que el resto del equipo esté involucrado no es una mala forma de hacerlo.

En scrum se propugnan los equipos autogestionados. Pero la pregunta es ¿Está tu equipo preparado para autogestionarse?

Aunque suene muy interesante la autogestión de un equipo hay ciertas dificultades para llevarlo a cabo. Normalmente los equipos, y consiguientemente los integrantes del equipo, están acostumbrados a tener un jefe que les indique lo que tienen que realizar.

Prescindir de esa figura que se encarga de gestionar el equipo puede ser traumático, por varios motivos.

Cuando los integrantes del equipo están acostumbrados a que alguien se encargue de la gestión, normalmente no se preocupan de como se gestiona, que cosas hay que tener en cuenta, que criterios hay que seguir para priorizar tareas, o para asignarlas, etc.

Así que se corre el riesgo de que cuando el equipo se autogestiona cometa muchos errores por inexperiencia.

Hay que tener en cuenta que aunque el equipo se autogestione eso no implica que todo el mundo se vuelva un experto en todas las materias. Hay que conocer los límites de cada uno y no decir o proponer cosas que luego se comprueben que no son adecuadas, ya que es contraproducente a nivel personal. Si en el equipo, por ejemplo, hay un experto en la funcionalidad del aplicativo, cuando se traten temas de funcionalidad hay que tener muy en cuenta su opinión.

La autogestión no significa tampoco la anarquía o el barra libre. Los acuerdos a los que se llegue dentro del equipo hay que respetarlos, independientemente de que nos parezcan adecuados o no. Los informáticos desgraciadamente somos muy dados a ir por libre, pero es completamente contraproducente, sobre todo porque si el equipo demuestra que no es capaz de autogestionarse, tarde o temprano les acabarán volviendo a poner a un gestor.

No sería el primer equipo que veo autogestionarse hacia el fracaso.

Después de un cierto tiempo sin cosas relevantes que contar, aunque por mucho que en algunos sitios de la red propongan escribir siempre algo, aunque sea repetido, a mi no me gusta.

Pero en los últimos días me he embarcado en una prueba de concepto de BigData.

La idea es poder procesar los datos de la estación meteorológica que tengo, pero con una solución basada en pequeños scripts del estilo de este

Estos scripts están implementados con JavaScript con la implementación de Java para dar la posibilidad de crear los programas sin necesidad de un compilador.

Para la solución de BigData uso Infinispan/DataGrid de JBoss ya que permite utilizar soluciones BigData sin necesidad de montar una gran infraestructura como con Hadoop. Por ejemplo permite utilizarlo en modo librería, sin instalar servidores.

El proyecto lo tengo albergado en GitHub en https://github.com/inigoserrano/BigWeather/

Algunas veces me ha venido a la cabeza la imagen que Kent Beck describe en su libro sobre la programación Extrema.

Describe los elementos que propugna como un cuadro de mandos en el que pone todos los mandos al máximo y el sistema es estable. También explica como unos con otros se compensan para hacer que el sistema sea así de estable.

A veces me encuentro en sitios en los que pese a tener todos o muchas de las herramientas de hoy día las cosas no funcionan bien. Puedes instalarte en un periquete un git y tener control de versiones, un Jenkins y tener una integración continua, un sonar y tener un cuadro de mando de deuda técnica, etc, pero no hacer que el sistema funcione.

De hecho es complicado hacer que funcione, porque tener las herramientas no asegura que el equipo las use, y si no están configuradas con un planteamiento adecuado, es probable que no les sean útiles, con lo que se hundirán como un barco con una gran vía de agua. Y reflotar algo que se ha ido a pique es complicado.

Alguna reflexión ya he dejado previamente.