Formar un equipo de desarrollo

Cuando te encuentras en mitad de un nuevo desarrollo (una aplicacion nueva) y el procesa avanza y ves que faltan "manos" (necesitas mas programadores), lo primero que viene a la cabeza es que necesitas una persona que ya tenga experiencia en desarrollos y esto se acentúa si el proyecto usa tecnologias muy nuevas. Este es la deducción mas logica pero ojo con esto porque una persona con experiencia tiene cosas buenas:

- Ha pasado batallas y sabe como afrontarlas. Trabaja mas con presión.
- Programan mas rapido y un software de mayor calidad.
- Ect..

pero tienen cosas que pueden no aportar en el desarrollo:

- No estar de acuerdo con demasiadas cosas. Esto no deberia ser malo pero si es malo cuando la actitud es derrotista o catastrofista.
- Ser muy rigido en su forma de trabajar ya que si tiene que adaptar otra forma puede ponerse a la defensiva ya que se ve como un junionr.
- Etc..

Respecto a la nueva tecnologia, lo bueno es:
- Curva de aprendizaje baja (o no necesaria).
- Aporta conocimiento al grupo.
- Programara mas rapido

pero lo malo es

- marcar pautas y no justificarse lo suficiente. Al ser el conocedor de la tecnologia se usan frases como "es asi porque es asi" o " esto esta mal" o "esto es un desastre" y no decir nada mas. En general, no justificar porque toma decisiones.

- olvidarse del trabajo en equipo.


En resumidas cuentas, una persona con experiencia y/o conocimiento de las nuevas tecnologias te puede venir bien en el equipo pero te puede venir mal. Lo que nunca hay que perder de vista que sea una persona constructiva y que no olvide que somos un equipo que tenemos que entregar un trabajo (una aplicacion que alguien tiene que usar).

Pro mucho que no nos guste, no somos artistas y la gente no nos va a pagar por algo que puede estar muy bien hecho pero lo importante es que funcione.

Estado real del proyecto.

A lo largo del desarrollo (sobre todo si es durante un periodo largo) algun stakeholder (normalmente algun jefe) querra conocer el estado del proyecto y en ese momento es dificil dar una respuesta sencilla ya que al avanzar muchos frentes a la vez no se puede especificar con claridad, pongamos un ejemplo en el que tenemos 4 funcionalidades que implementar (empleados, costes, informes y ventas) y cada funcionalidad esta en nivel distinto de desarrollo como muestra la grafica:

¿Cual el estado?

Una funcion que indica el grado de avance de todo

El mas retrasado

Etc.. Hay muchas posibilidades pero realmente nunca es cuestion de que eleccion usemos sino que es cuestion de como espera los stakeholders que le indiquemos la información. Este punto es muy importante porque ofrece mucha informacion:

• Sabemos cuales son las partes que tienen mas valor para los stakeholders.
• Necesitamos buscar un leguaje comun con los stakeholders.
• Se necesita un integrador que se preocupe no solo de poder definir el estado del proyecto, ademas se encargue de encajar todas las piezas que definen el proyecto.

Muchas veces tenemos casos como el siguiente:

• Todo empleados funcionando y costes esta parado porque no tiene una parte que depende de empleados. Pero si empleados esta todo acabado ¿que esta pasando?

En casos como este, es la figura del integrador en que entra en juego. Un integrador es la persona capaz de saber que costes podria estar terminado ya que sus depedencias estan resultas. Si al integrar se detecta un fallo es el integrador el que busca a los implicados y los coordina para que solucionen el problema.

Un integrador es la persona que puede decir el estado del proyecto.

La politica de la gestión de desarrollo

De las partes mas simples es facil hablar mientras que de lo mas complicado se suele confiar en una persona que sabe hacerlo. Por ejemplo, si un equipo tiene que definir si el color azul es mejor que el verde para el fondo de una pagina web nos podemos tirar horas debatiendo y opinara desde el becario hasta el jefe de proyecto pero si tenemos que hablar de la mejor solucion para la "arquitectura de comunicaciones" seguramente solo opinen dos personas del proyecto y la mayoria de personas de del desarrollo no diran nada y esperaran que otro lo solucione.

Es como la politica, la mayoria de gente quiere opinar y ver que su opinion se tiene en cuenta pero no van a ser ellos lo que van a gobernar. Lo dificil que lo haga otro.

Una solucion muy politica para mentener un buen ambiente de trabajo en e desarrollo es observar la mayoria de opiniones triviales que suele tener el equipo y aplicarlas ya que:

- No suelen tener gran impacto.
- Te permiten decidir lo realmente importante a los gestores del equipo.
- Da la sensacion a los miembros del equipo (que no es solo una sensacion es cierto) de que han puesto su granito de arena.

Mantener la coherencia en el estilo del desarrollo

Cuando se empieza un desarrollo de proyecto de software esta implícito que el grupo de programadores va a programar el software que se desea conseguir. Cuando el software es medianamente grande te das cuenta de que no vale con que el programador consiga terminar una tarea, ademas debe:

• Seguir las normas que se han establecido para programar.
• Seguir la arquitectura que se haya definido.
• Tomar la decision correcta ante una situación que aunque no este especificada expresamente se deduce a partir de los puntos anteriores. 

Si no se resuelven estos puntos entonces al final el software es un conjunto de miles de tareas cuyo conjunto no hacen lo que queríamos al planificarlo al principio.

Es imposible conseguir que un grupo de programadores programen igual pero ¿Como hacer que varios programadores sigan unas normas?

La mejor solucion consiste en tener un integrador en el equipo que compruebe que se siguen las normas y si no se siguen las normas se le indica al programador y lo apunta en una lista que ira rellenando de semana en semana. Cada semana se debe juntar con el equipo y repasar dicha lista e indicar lo que crea relevante. Estas charlas son la clave para ir formado al equipo en las normas y el estilo que deben seguir los programadores.

Como señalar los fallos

Durante el desarrollo del software, los programadores van cometiendo pequeños errores y grandes errores. Unos pueden ser grandes meteduras de pata y otras pequeñas tonterias pero todas van sumando fallos que hay que solucionar y que penalizan las entregas. Esto es asi y se debe tener en cuenta como riesgo en la planificacion del proyecto. Pero existe otro gran problema, los programadores normalmente no son conscientes de estos fallos y cuando llega la hora de las entregas y no se llega o la calidad del software no es buena entonces aparecen los enfados y frases como:

• Era imposible llegar.
• Como puede ser? yo le hecho todo bien.

Para solucionar este problema se debe:

• Tiene que haber un supervisor, jefe, integrador, etc... que detecte estos fallos y los ponga de manifiesto.
• Se le debe comunicar al equipo de forma adecuada.

En este ultimo punto quiero incidir, Cual es la forma correcta de comunicar los fallos? 

• Si se hace de forma continua e inmediata (cuando se detecta el fallo enseguida se indica) entonces geneneras en el programador las ganas de "devolvertela" (estara deseando que el supervisor se equivoque para echarselo en cara).
• Si se hace de forma aislada entonces pierdes el poder que da estar hablando en grupo y dejas que el programador se pueda "picar" e intentar defenderse con unñas y dientes aunque no tenga razon.

La forma correcta es tener una rutina de reuniones (una a la semana) donde el supervisor hable de asuntos tecnicos y cuando lo vea oportuno indicar  cosas como:

• Esta ultima entrega ha ido mal y yo creo que...
• Las metricas de calidad han bajador debido a...
• Normalmente usamos "esto" en el codigo y deberiamos usar "esto otro" 

Miedo a la integración

En muchas ocasiones, y sobre todo cuando el proyecto alcanza un tamaño grande, ante un nuevo desarrollo/solventar incidencia se implementa una parte completamente nueva aun sabiendo que ya hay una parte implementada que deberia ser modificada/ampliada para solucionar dicho desarrollo/incidencia. Esta situación pasa porque: 

• El programador quiere “ahorrase” el tener que conocer una lógica compleja.  
• No se han proporcionado las herramientas necesarias para adquirir el conocimiento de la parte a modificar/ampliar y la tarea se hace demasiado pesada. 

Este “miedo” tambien afecta a la parte funcional ya que en muchos casos se recurre a “Comentarios”, “Anexos”, etc.. En lugar de modificar el documento donde se indique la parte a modificar/ampliar. 

La única solución a este problema es identificar la necesidad de la redefinición y que es una tarea que debe ser teniada en cuenta en las planificaciones. No se debe considerar la redefinición/ampliación como un error. Habrá casos donde la redefinición/ampliación sera un fallo ya que no hacia falta pero en otros casos no seria un fallo y es parte del desarrollo del software. 

Problemas para dividir el trabajo

Cuando se piensa en la informática,  y en concreto en la programacion, lo primero que se piensa es que el programador está en cualquier sitio del mundo. Nada más alejado de la realidad, al programador se le quiere al lado del negocio y si se piensa en tener al programador alejado es por temas laborales( por conciliación familiar, teletrabajo, etc...).

Por qué se necesita al programador al lado del negocio? Los principales motivos son:

- No hay una figura de comprobador/integrador técnico que asegure que lo que hacen los programadores sea correcto. Este tarea se delega en el grupo de programadores.

- El negocio requiere continuos cambios y definición on-fly( en el momento) y tiene que aclararlo en persona.

A lo largo de la historia reciente de los productos que han revolucionado la informatico y/o el mundo ( Facebook, WhatsApp, wifi, Etc..) se  puede llegar a la conclusión de que todos eran grandes soluciones que caían por su propio peso y no eran grandes soluciones por lo complejo de su implementación. Este problema es lo mismo, lo único que se necesita es dar con la idea feliz que permita tener programadores en cualquier parte del mundo de manera eficaz.

No querer ver la realidad

Cuando se planifica con tiempo el desarrollo de un software y se mira hacia la implementación se pretende hacer de forma correcta y se crea el perfil de arquitecto de software pretendiendo que diseñe el software y lo haga tan bien que implementarlo sería solo la parte fácil.

Nada más lejos de la realidad. Puede que en un futuro este planteamiento sea una realidad pero ahora no lo es y nunca ha sido una realidad por mucho que nos empeñemos en no querer la realidad.

El no querer ver la realidad siempre es lo mismo. Todo el mundo ha estado en un proyecto donde se dice: este proyecto no ha quedado bien, al siguiente lo haremos mejor. Al siguiente se hace de forma distinta pero el resultado es más o menos el mismo y ya se empieza a decir: la culpa es de esta otra persona por esto o por lo otro.

Rindamonos a lo evidente. Al menos hasta que cambien las cosas y se establezcan métodos claros y que todos sigan para que la implementación sea lo más sencillo. Es cierto que se necesita un arquitecto de software pero el arquitecto también programa, se moja las manos y resuelve problemas de bajo nivel. Si hace este tipo de tareas entonces se ganará la confianza del grupo de desarrollo y del grupo de gerencia. Con esta piedra angular el desarrollo irá por buen camino.

Una aplicación informática es una aplicación informática.

Se me ha ocurrido usar una técnica de autoayuda/formación de equipo que consiste en repetir mucho algo muy obvio pero que se nota que tenemos en cuenta porque al ser tan obvio nos centramos en otras cosas de tal manera que puede hacer que no hagamos la parte obvia. Por ejemplo, nos encomiendan hacer una casa y podemos pensar "bueno si voy a hacer una casa empecemos por algo sencillo, voy a comprar la tele" o otra como "pongo las puertas", etc.. cosas asi. Pero cuando pasa el tiempo y comprobamos lo que tenemos nos damos cuenta que "no se me ocurrio empezar por las paredes" y cuando se supone que tenemos que entregar la casa tenemos un monton de "cosas de la casa sueltas" pero no tenemos paredes.

Yo creo que si esto le ha pasado a alguien a alguna vez lo que penso al ver el fracaso es "¿por que no empece por las paredes?".

Cuando estas haciendo una aplicación informática pasa lo mismo, una aplicación informática no es un conjunto de funcionalidades que puedes implementar y luego ver como las juntas, no es un conjunto de historias de usuario que debemos cumplir, etc.. Claro que la aplicación informática debe dar solución a todo eso pero no olvides que una aplicación informatica es un conjunto de interfaces que acceden a una logica. Empieza por las interfaces. La casa debe tener una tele pero primero mejor ponle paredes. 

Supervisor técnico

En los proyectos actuales siempre veo roles que se repiten: jefe de proyecto, funcionales, técnicos, arquitectos y programadores. Con las técnicas de gestión ágiles aparece el product owner, el scrum master y el cliente (este ultimo nunca forma parte del equipo). Me falta alguien que creo que es vital para la culminación de un proyecto de desarrollo de software, el supervisor tecnico. Esta figura es el encargado de:

• Diseño técnico.
• Que los programadores sigan las especificaciones técnicas y los estilos de programación.
• Ser el validador de que lo implementado es lo que realmente se ha indicado en los funcionales.

Kafka con Spring Boot. Topicos y Colas.

Kafka es un gran framework que se usa para comunicación entre aplicaciones. El objetivo de este artículo no es estudiar las características de Kafka ni de Spring boot, para eso hay mucha documentación en las paginas web de cada framework. El objetivo de este articulo es explicar una forma sencilla de montar Kafka, de como usarlo para comunicar aplicaciones Spring boot, como realizar una comunicación por tópicos (es decir todos los consumidores escuchan el mensaje) y realizar comunicación por colas (es decir solo un consumidor escucha el mensaje) para los programadores que están acostumbrados a otros frameworks como ActiveMQ o RabbitMQ.

Kafka no funciona de la misma manera que los framework mas comunes(ActiveMQ o RabbitMQ) por lo que no hay una forma directa de hacer lo mismo pero en este artículo voy a describir como aplicar comportamientos equivalentes.


Para comprender correctamente este articulo necesitas tener conocimientos básicos de Docker y Spring boot.

La forma mas sencilla de montar un "servidor" de Kafka es usar Docker, se puede usar el siguiente fichero de docker-compose:

docker-compose.yml 

version: '3'

services:

  zookeeper:

    image: wurstmeister/zookeeper

    ports:

      - "2181:2181"

    hostname: zookeeper

  kafka:

    image: wurstmeister/kafka

    command: [start-kafka.sh]

    ports:

      - "9092:9092"

    hostname: kafka

    environment:

      KAFKA_ADVERTISED_HOST_NAME: localhost

      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181

      KAFKA_ADVERTISED_PORT: 9092

    volumes:

      - /var/run/docker.sock:/var/run/docker.sock

    depends_on:

      - "zookeeper"

Una vez ejecutado este fichero, ya esta disponible Kafka en el puerto 9092.

El código del productor de mensajes y de consumidor de mensajes esta en https://github.com/rumberomelo/productor-consumidor-basico

Si descargas el código y lo ejecutas (y has arrancado Kafka como indico al principio) puedes comprobar el funcionamiento mas sencillo, un productor que escribe un mensaje de texto que lee un unico consumidor. Para hacer funcionar el ejemplo solo tienes que hacer la siguiente petición:

http://localhost:9000/envia/mensaje?texto=hola

Esta petición hará que el productor escriba en el tópico de Kafka "TOPIC_EJEMPLO" el mensaje "hola". Puedes comprobar en el log del consumidor que lo ha leido ya que aparecera un mensaje como INFO 47114 --- [ntainer#0-0-C-1] com.rumberomelo.kafka.consumer.Consumer  : Se ha consumido el mensaje hola.

Este ejemplo muestra como un consumidor lee un mensaje que produce un productor. Si lanzaramos un consumidor exactamente igual pueden pasar dos cosas (depende de como se configure Kafka):

• El nuevo consumidor es el unico que lee todos los mensajes de productor.
• El nuevo consumidor siempre queda a la espera (nunca lee ningun mensaje) y el viejo consumidor lee todos los mensajes.

Esto se puede comprobar en el ejemplo https://github.com/rumberomelo/productor-dos-consumidores y ver que solo un consumidor lee el mensaje. Si aplicamos un pequeño cambio y cambiamos el nombre de los grupos de cada uno de los consumidores como indican estos dibujos:

Al arrancar de nuevo los ejemplos se puede comprobar como los dos consumidores reciben en mensaje mirando el log de los consumidores. Este comportamiento es igual al tópico de frameworks como RabbitMQ o ActiveMQ.

Volvemos a dejar el nombre de los grupos como estaba. ¿Como se hace para que un mensaje lo lea uno de los consumidores (no siempre el mismo)? Se hace indicando las particiones en las que se quiere dividir el tópico. Cuando un productor escribe en un tópico que no existe (que es lo que se ha hecho al principio de este articulo) se crea automáticamente sin particiones, si tienes varias particiones entonces los consumidores se reparten dichas particiones de tal manera que cada consumidor solo lee de una de las particiones asignadas y como un mensaje se puede colocar aleatoriamente en cualquier particiones ya se ha logrado que sea un consumidor cualquiera el que lea el mensaje.

Para probarlo, se debe entrar en el contenedor de Kafka:

$ docker exec -it articulokafta_kafka_1 bash

Se puede comprobar que no hay particiones:

$ kafka-topics.sh --describe --zookeeper zookeeper:2181 --topic TOPIC_EJEMPLO

Topic:TOPIC_EJEMPLO PartitionCount:1 ReplicationFactor:1 Configs:

Topic: TOPIC_EJEMPLO Partition: 0 Leader: 1001 Replicas: 1001 Isr: 1001

Se añaden dos particiones:

$ kafka-topics.sh --alter --zookeeper zookeeper:2181 --topic TOPIC_EJEMPLO --partitions 2

Al arrancar de nuevo el ejemplo https://github.com/rumberomelo/productor-dos-consumidores y dejar el nombre de los grupos como estaban originalmente, si se hace la prueba de lanzar varios mensajes entonces se puede comprobar como a veces los lee un consumidor y a veces otro.