Sharing data between microservices

 

Since I started working with microservices, I learned a lot of basic rules like:

 

•        The microservices must be isolated.
•        The microservices must be small and they must have only one responsibility into business.
•        The microservices must be developed by isolated and multidisciplinary teams.
•        The only way to access to microservice business is using the API.
•        One database can´t be shared by two microservices.

 

And about this last rule I want to discuss because, in my opinion, there are a lot of points of view we have to keep in main to reach the best approach that fits to our company. Everybody agrees that only one microservice can modify the data in one data base but … Who bad would it be if each microservice will be able to read all databases that the microservice need?

 

One rule said that API is the only one microservice contract but if the development team are using the same technology to implement the microservices then microservices develop teams can sign other contracts like libraries that other  microservices develop teams can use it for accessing the data directly without access to the API.

 

Keep in mind, nowadays, the databases technology has a high performance and the databases are implemented with a great users connection capacity. If we only have a one application (the microservice) using the database then we are losing the database performance. In addition, the connection that should be used by other microservices are read only connections. It means that other improvement more because the connection will be read only.

 

Then, may be, the two contracts case would be able to much bad idea.

 

I am going to describe the “two contracs case” by JAVA implementation library. A common communication between microservices would be:

 

 

 

If microservice client “data layer - read” is treated like an API then no development teams lose their independency only sing a other contract. “two contracts case” would be:

 

 

How you can see in the pictures, the sales microservice saves the book microservice call and use the same library to get the books data (the microservice books development team is free to make any change). This solution allows to keep the low couple and avoid inconsistency data (only the owner can write data into database).

 

In conclusion, I know  “two contracts case” is anti-pattern microservice but it would be able to fit to your environment and solve the performance issues. If the  “two contracts case” doesn’t fit your environment at least I recommend you using CQRS but you should not create a view or using other data base. Use the same database for both microservices where one microservice can read/modify data and the other microservice is a query microservices.

 

Jenkins para gestión de despliegues en Kubernetes. ¿Desplegar el Jenkins dentro del cluster de kubernetes o fuera del cluster?

No cabe duda de que Jenkins es la opción numero 1 cuando se piensa en automatizar el despliegue de aplicaciones en un clúster Kubernetes. Existen cada vez más opciones (aparte de Jenkins) y más orientadas a Kubernetes Jenkins (Jenkins esta para automatizar cualquier cosa). En este post particularizo en Jenkins, pero los puntos que se exponen a continuación se pueden extrapolar a la mayoría de los mecanismos de automatización.

Cuando una empresa piensa en automatizar sus tareas de desarrollo con Jenkins y tener una estrategia de CI/CD para despliegue en un clúster de Kubernetes una de las primeras preguntas es ¿El Jenkins se despliega en un pod dentro de algún namespace del clúster de Kubernetes o fuera del cluster de kubernetes con alguna otra solución?

Vamos a analizar puntos relevantes para tomar esta decisión

Modo de instalación y mantenimiento

Para desplegar en Jenkins en el cluster de Kubernetes se deberán crear los ficheros que creen los objetos Kubernetes correspondientes (deployment, Pod, configmaps,etc..) mientras que en una maquina fuera del cluster de kubernetes se puede instalar de cualquier manera (incluso usando tecnologías de contenedores como docker que utilizan métodos parecidos a los usados por Kubernetes). Por lo que este punto las cuestiones son:

• Se va a usar imágenes para las aplicaciones de mi negocio (ya que se quieren desplegar en un cluster de kubernetes) pero ¿quiero una solución basada en imágenes para todos los elementos de TI? Recordemos que Jenkins no es para negocio, es para los técnicos.
• ¿Existe alguna normativa en la empresa que me obliga a seguir un procedimiento determinado? ¿Ese procedimiento es incompatible con el despliegue en un clúster de kubernetes?
• El equipo técnico ¿se tiene más conocimiento en algún tipo de instalación diferente al de kubernetes y se identifica como más fiable?
• Analizar el mantenimiento de Jenkins como aplicación (ampliar recursos, plugin, tolerancia a fallos, etc..). Tras analizarlo ¿se ajusta mejor desplegarlo en un clúster de kubernetes o fuera del clúster de kubernetes?

Explotación

En este punto si que estoy claramente en contra de desplegar Jenkins en el clúster de kubernetes (pero esta es mi opinión y pude no ajustarse a la realidad de la organización) por los siguiente:

• En un clúster de kubernetes, por regla general, se deben desplegar aplicaciones que sigan la filosofía de microservicios (es decir, ligeras que van a requerir escalado, etc..) y Jenkins no sigue dicha filosofía.
• En un clúster de kubernetes, los pods luchan por lo recursos y Jenkins es una aplicación que va a “dar guerra” cuanto mas se use por lo que no se puede justificar el hecho de que no funcione una aplicación en el clúster de kubernetes porque esta Jenkins.

 Continuidad del servicio de Jenkins

Este punto cabria en el anterior, pero me lo he encontrado en tantas ocasiones cuando he tenido que implantar Jenkins en una organización que prefiero destacarlo a parte. Si se cae el clúster de kubernetes ¿Merece la pena que siga funcionando Jenkins? La respuesta es sí por dos grandes motivos:

• No todas las tareas que se incluyan en Jenkins tienen porque actuar sobre el clúster de kubernetes por lo que si desplegamos Jenkins en el cluster de kubernetes estamos perdiendo esa funcionalidad.
• Los clústeres de kubernetes son un sistema muy robusto y raramente he visto un cluster de kubernetes caerse. El clúster de kubernetes, antes de caerse, hace que las aplicaciones no funcionen (los famosos estados “Evicted” de los pods) por falta de recursos. Pero se puede seguir trabajando con ellos. Es decir, si Jenkins esta desplegado en un clúster de kubernetes y este cluster entra en este estado entonces Jenkins no funcionaría, pero si estuviera fuera del cluster de kubernetes podría seguir trabajando con Jenkins y Jenkins atacando al cluster de kubernetes. El gran problema sería que no veríamos las aplicaciones que Jenkins a desplegado en el clúster de kubernetes, pero estas aplicaciones están declaradas en el cluster y una vez solucionado el problema de los recursos del cluster de kubernetes todo funcionar correctamente, por lo que nunca se ha perdido la funcionalidad.

 

Conclusion

El negocio y los programadores

Durante el desarrollo de una aplicación software desde cero, los programadores suelen centrarse en las tareas técnicas muchisimo mas que en entender la funcionalidad de la aplicación. Esto provoca que muchas veces los programadores no sepan como afrontar desarrollos cuando el gestor piensa que si que podrian ya que han hecho en el pasado desarrollos parecidos.

Este efecto no pasa con aplicaciones en mantenimiento ya que la necesidad de innovar, inventar, etc.. es menor. Suelen ser todas las tareas sota, caballo y rey. Esto abre la mente de los programadores a problematica mas funcional.

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.

VisualVM OQL. Get size of objetcs between two size values

 select sum(map(heap.objects("[C"),function(heapString){
  if(sizeof(heapString) < 100 && sizeof(heapString) > 50){
    return sizeof(heapString);
  }
  else{   
    return 0;
  }
}));

Aprender las cosas como son

Cuando a alguien se le encarga gestionar el desarrollo de una aplicación (o parte de esa aplicación), su principal tarea es ver que falla de la tarea, como plantearla, como planificarla, etc.. y el gran problema es que el gestor esta obligado a hablar de asuntos tecnicos cuando se supone que un gestor "no debe saber nada" de tecnología.

Se debe abandonar los hábitos de poco esfuerzo (ser gestor y no querer saber nada técnico). No debe saber lo mismo que un técnico pero tiene que hablar el mismo idioma.

¿Como sabes que estas hablando el mismo idioma?
 - Si lo único que un gestor le dice a un técnico es "¿cuanto te queda?", "¿como vas?  y acto seguido le dice el gestor que le queda (se nota que no ha entendido la explicación de como va)". Esto es síntoma de que el gestor y el tecnico no hablan el mismo idioma.

Solución: Gastar tiempo del gestor y del tecnico y que el tecnico le explique al gestor como esta implementando la tarea. Ojo, el gestor nunca tiene que hacer "nada tecnico" pero debe ser capaz de entender lo que el tecnico le dice y ser capar de pedir cambios (en el idioma del tecnico).

Estimation by approach. Always usefull

Sometimes the project manager people think the agile methods cant be used in the projects developed by a traditional approach. The things are not always black or white, we can use agile methods for all kind of projects. For example, the estimation by approach, we can use it for estimating task in projects with a traditional way of work.

In addition, the estimation by approach is always the best way for estimating task if you want a real estimation. The one way for a real estimation is to know the time a developer have spent in some task. This is the great true and, in conclusion, the bes† way to estimate a task is to use the known duration of some task and use this duration for estimating other task.

The estimation by approach is very simple, if we know that a developer spend 3 days for completing a login screen and we suppose the list of costumer screen has four times the login screen size then a good estimation for a list of costumer screen is 12 days.

How you can see, we are using a estimation by approach without change the way of work. 

Desenredar los cables

Cuando has trabajado en varios proyectos de desarrollo de software de mediano-gran tamaño te das cuenta que la tendencia normal es que no exista documentación que te guíe por el código, los compañeros te ayudan pero como mejor saben (y cada uno a su manera), etc.. Esto hace que cuando se le pide a un programador que implemente sus primeras tareas este tenga la sensación de tener que "desenredar los cables" para poder empezar.

Al analizar esta situación en detenimiento, todo esto se traduce en muchos factores no deseados:

• Insatisfacción y frustración del programador.
• Costes de aprendizaje que se multiplican.
• Sensación de mala estructura del proyecto.

Siempre se debe tener un mecanismo de formación "automático" (quiero decir que no necesite de una tercera persona, es decir se le puede decir al miembro del equipo "toma esto" y con lo que se le de entonces puede formarse) para que un miembro del equipo pueda consultarlo y pueda usarlo como guia.

El procedimiento para tener un mecanismo de formación automático es tener una documentación técnica apropiada. Esta documentación tiene que tener las siguientes características:

• Estar escrita en un idioma de programadores. Lo cual garantiza que no se "hace larga de leer" y va directa al grano.
• Estar escrita en un formato cómodo de leer para un programador. Recomiendo una pagina web antes que un documento de texto.
• Que sea facil de mantener. Importante. Se debe mantener y que sea facil hacerlo ya que si no es facil de mantener entonces se abandonara.

Integración continua. Cuando lanzar las pruebas

¿Cuando se deben lanzar las pruebas automáticas? Existen muchas tendencias en función de un factor:

- Numero de cambios de código (Cada cuantos cambios de código se lanzan las pruebas):

• Ante cualquier cambio: Tiene la ventaja de que se detectan mejor los fallos pero tiene la desventaja de que puede relentizar el desarrollo ya que hace que el programador se centre demasiado en las pruebas.
• Ante cambios en una funcionalidad: Tiene la ventaja de favorecer el desarrollo pero si la funcionalidad es muy grande se corre el riesgo de no hacer las pruebas lo suficientemente buenas.
• ....

Como se ve a medida que se amplia el ratio se gana en velocidad de desarrollo y se pierde en calidad de pruebas.

- Tiempo (se establece un tiempo periodo de ejecución para lanzar las pruebas)

• Cada dia: Son pruebas bastante periódicas y pueden detectar un fallo antes. Lo malo es que es un tiempo fijo y corto y puede no tener en cuenta los ciclos de desarrollo (como un sprint de SCRUM)
• Cada fin de semana: al ser mas tiempo es mas facil que se alinien con los ciclos de desarrollo pero se tarda mas en detectar un fallo.
• ...

Como se ve a medida que se amplia el ratio se gana en alinear las pruebas con ciclos de desarrollo y se pierde en detección temprana de errores.

-...

Hay muchas tendencias y dentro de cada tendencia hay diversas opciones que pueden mejorar y empeorar un factor u otro. Es una locura entonces cual elegir. La mejor elección es no tener en cuenta los factores si no la que obtiene mejor resultado. Lo que sede hacer es elegir una tendencia y dentro de la tendencia elegir una opción, darle un tiempo y ver que resultados se obtienen. Si son malos resultados entonces probar con otra hasta que se de con la opción y la tendencia que mejor se ajuste al equipo y al tipo de producto.

Por que merece la pena arreglar las pruebas automaticas

Cuando se hacen pruebas automaticas sobre un software tiene el GRAN (e histórico) problema de que al modificar el software se debe modificar las pruebas automaticas y eso siembre se ha visto como una perdida de tiempo y un handicap para no hacer pruebas automaticas.

El problema es el enfoque, tener que adaptar la prueba automatica implica:

• Conocer como funciona la prueba (lo cual permite mejorar y ampliarla).
• Probar de una manera distinta a como lo hace el programador y tener mas exito en la busqueda de errores.
• Ya que se tiene que adaptar la prueba, se pueden crear nueva.

Se le debe dar este enfoque para que los programadores no tengan el problema de verlo inútil y aburrido. ¿Como se hace mas ameno una prueba? No haciéndola muy simple. Un ejemplo muy bueno es el siguiente:

1) Se cambia el parametro de la funciona suma de int suma (int a, int b) a int suma (int a, int b, int c).

2) Se le pide a un programador que lo cambie en 100 ficheros. 

Esto es aburrido y frustrante.

Sin embargo, si la prueba automatica tiene mas magnitud el programador lo vera de otra manera. Ejemplo,

1) Se cambia la interface web donde el usuario suma ahora 3 valores y no dos

2) Se pide al programador que cambie la petición html que prueba la pagina web que por debajo llama a la nueva funcion int suma (int a, int b, int c).

3) Ademas se le pide medir tiempos, aumentar las pruebas a 10000 iteranciones, etc..

Esto es mas desafiante y seguro que prueba mas el software que una simple prueba para llamar a un método.

El otro gran motivo es que al automatizar las pruebas siempre se descrubren errores de plantemaiento ya que te obliga a mirar el codigo desde otra perspectiva. Es decir, se pueden encontrar fallos despues de la famosa frase del programador: "yo he probado todo y funciona"