Abril 25, 2017 - No Comments!

Cómo aumentar… la organización de tus equipos mediante la delegación

Siguiendo con nuestra serie de post en los que analizamos desde un punto de vista psicológico los equipos de trabajo, hoy hablaremos sobre delegación y equipos auto-organizados. Por si te lo perdiste, en el primer post de la serie, hablamos sobre los pilares de la motivación y los cuatro ejes de la personalidad.

Es la primera vez que en la encuesta de la semana previa al post, tenemos un pleno: tod@s habéis votado la misma opción, y además es la opción correcta (seguramente sea porque las demás estaba claro que eran incorrectas, aunque quizá alguien piense que “aquí manda él” o que “delegación=caos”, pero está feo decirlo 😉 De lo que no estoy tan seguro es de que todos tengamos claro que es un equipo auto-organizado, por lo que vamos a empezar viendo qué es.

Tal como indica Brad Appleton y su propio nombre, un equipo auto-organizado es un equipo organizado y dirigido por sus propios miembros, con el objetivo en conjunto de cumplir los objetivos de la empresa u organización (o lo que sea), dentro de las limitaciones de su entorno. Sus características principales son las siguientes:

  • La gerencia de la organización (en caso de haberla), puede crear y dar forma al equipo, pero en ningún caso dicta los detalles de cuál es la solución o de cómo crearla (también se pueden crear equipos auto-organizados sin gerencia, como sucede por ejemplo en muchos proyectos online de software libre).
  • Por tanto, el equipo es responsable no sólo de dirigirse y organizarse, sino también de adaptarse para mejorar su propio desempeño, por lo que ya no es sólo responsabilidad del líder o jefe del equipo que el equipo funcione, sino de todos sus miembros.
  • De tal forma, no existe un único líder durante la vida del proyecto, si no que dependiendo del problema que se aborde en un determinado momento, la persona o personas que tomen una determinada decisión pueden variar.

No pretendo que de todo lo anterior se extrapole que no deberían hacer falta jefes o líderes en las organizaciones, si no más bien que para conseguir un equipo auto-organizado lo que habría que cambiar es el modelo de gerencia. Obviamente es positivo para la organización que haya una cabeza visible hacia el exterior por diversas razones, pero el trabajo de esta “cabeza visible” dentro de la organización no debería ser la de supervisar el trabajo del resto.

Me gustaría señalar como ejemplo un artículo que leí hace poco sobre la manera en la que Jeff Bezos, CEO de Amazon, promueve que todo el equipo pueda tomar decisiones y ser responsable de ellas.

Del mismo modo, no tiene por qué tener sentido delegar todas las responsabilidades de una organización a un determinado equipo. Por ello, en el próximo post veremos los diferentes niveles de delegación que existen (y os adelanto que seguramente sean más de los que esperáis, 7), y un método para ver qué nivel de delegación sería el correcto para cada caso.

Opina

Y tú… ¿crees que este modelo de trabajo es alcanzable y positivo o una mera utopía?

Ver resultados

Cargando ... Cargando ...

¿Me ayudas a compartir este post?

El 🙉 y yo te lo agradeceremos

Abril 11, 2017 - No Comments!

Cómo reducir…el número de bugs

En el post anterior abordamos uno de los aspectos más importantes en el desarrollo del software, la seguridad, en este me gustaría abordar otro de los aspectos principales como es la calidad del software.
Para ello, una de las mejores herramientas que tenemos son las pruebas automatizadas, las cuales nos permiten ejecutar continuamente una serie de pruebas, sin intervención manual.

Existen varios tipos de pruebas, los principales son:

  • Unit testing o pruebas unitarias, son pruebas unitarias, pequeñas y de ejecución muy rápida. Personalmente prefiero usar el unit testing para dirigir el desarrollo mediante TDD más que una forma de garantizar la calidad
  • Integration testing o pruebas de integración: este es el tipo de tests en el que nos centraremos, ya que es el más fácil de mapear historias de usuario o las funcionalidades
  • Pruebas de rendimiento o performance testing: en estas pruebas queremos probar que la aplicación responde correctamente bajo ciertas condiciones de carga, concurrencia, etc.. Se busca comprobar que la aplicación tiene características como escalabilidad, fiabilidad o concurrencia
  • Exploratory testing o pruebas de exploración: aquí buscamos nuevas formas de realizar pruebas en la aplicación. Se realiza el aprendizaje, diseño y ejecución de las pruebas de forma simultánea

Integration testing

Estas pruebas suelen ser más pesadas que los unit testing, suele haber bastantes menos y son más frágiles, aún así personalmente las prefiero para garantizar la calidad del software ya que me es más fácil crear pruebas de integración que cubran funcionalidades completas de la aplicación o historias de usuarios que con pruebas unitarias.

Spring, Spring Boot y MongoDB

Como la red está llena de artículos sobre pruebas unitarias y de integración, nos vamos a centrar en cómo realizar dichas pruebas con Spring, Spring Boot y MongoDB, dicha documentación es más difícil de encontrar. Estas pruebas se deben poder lanzar de forma automatizada, por lo que deberemos simular o iniciar los procesos externos con los que se interactua.

Para ello veremos como poder realizar pruebas de integración a un Api Rest que recupera datos de una base de datos MongoDB.

Lo primero que debemos es configurar en nuestro pom.xml para diferenciar las pruebas unitarias de las de integración, para ello configuramos el plugin failsafe de maven:

Con esto todas las clases que se encuentren bajo "src/test" y terminen en IT (integration test) se ejecutaran en la fase de verificación, por ejemplo:

Para la base de datos nos apoyaremos en la biblioteca "de.flapdoodle.embed.mongo" que nos permite arrancar un MongoDB embedido al arranque del test, para ello simplemente debemos especificar en el fichero pom.xml la dependencia:

Gracias al uso de Spring Boot y su soporte para dicha biblioteca mediante la clase EmbeddedMongoAutoConfiguration al incluir dicha biblioteca en el pom.xml automáticamente descargará la base de datos MongoDB y arrancará una instancia que estará activa mientras ejecutamos las pruebas.

Si ya tenemos un MongoDB en la máquina para desarrollo en local, podemos modificar el puerto en el cual arrancará anotando la clase de test con la anotación @TestPropertySource:

Si queremos importar un fichero json con valores de una colección inicial, podemos crearnos una clase utilidad:

Si usamos Spring Data MongoDB podemos aprovechar las variables que exporta dicha biblioteca:

Para ejecutar scripts iniciales de BBDD, deberemos especificar en cada Test qué fichero cargar. Como JUnit no permite ejecutar un método antes de todos los tests que no sea un método estático, podemos recurrir a una variable global estática para simular esto, una solución muy poco elegante, pero funcional:

Una vez configurado Maven y la base de datos, podemos indicar en la clase que es un test de integración con la anotación @SpringBootTest:

Mock y Stubs en los tests

Para realizar mocks y stub, Spring incluye la biblioteca Mockito que nos permite crear mocks, stubs, spy, etc... Por ejemplo, si realizamos pagos y queremos que en las pruebas de integración no se realicen, podemos realizar un mock de la clase que se encarga de los pagos de la siguiente forma:

Esta es una clase estática que podemos incluir en el mismo fichero del Test. Luego podemos usarlo como un bean más:

Luego podemos comprobar que se ha utilizado dicho bean en el test:

Para poder realizar llamadas al Api, Spring Boot nos facilita un bean de tipo TestRestTemplate ya configurado para realizar estas llamadas:

Conclusión

Como vemos, Spring Boot  nos realiza gran parte del trabajo de configuración de las pruebas de integración: inicio de la base de datos, inicio del servidor, configurar restTemplate, etc., lo cual nos facilita la realización de dichas pruebas. Si que es cierto que el tiempo de ejecución es mayor que las pruebas unitarias, pero el resultado de las pruebas nos dará una mayor seguridad respecto a la calidad de la aplicación.

¡Dejad vuestros comentarios y os respondemos a todas las dudas!

Opina

¿Cómo de importante es la métrica "code coverage" al medir la calidad?

Ver resultados

Cargando ... Cargando ...

¿Me ayudas a compartir este post?

El 🙉 y yo te lo agradeceremos

Marzo 28, 2017 - No Comments!

Cómo reducir…las dudas sobre dónde establecer mi espacio de trabajo

Por Luis Manuel Pérez

Vale, ya sé qué proyecto quiero hacer, ya sé si voy a hacerlo solo o con un equipo y sé qué pasos debo seguir pero…¿dónde voy?

Cuando empiezas un proyecto sueles empezar ‘donde sea’: encerrándote en tu habitación para que nadie te moleste, en casa de tu compañero junto a la cafetera o juntándote con el equipo en la biblioteca, pero llega un momento en el que, si el proyecto funciona, hay que dar el paso de establecer un lugar de trabajo oficial, ‘la oficina’ que siempre se ha dicho.

Pero los tiempos cambian y los sitios donde trabajar, también. Desde hace tiempo tenemos más alternativas a la clásica oficina, cada una con sus ventajas e inconvenientes y más o menos adecuada para según qué tipo de proyecto.

En este post nos centraremos en analizar las ventajas y desventajas de los siguientes espacios de trabajo:

  • Oficina tradicional
  • Oficina compartida
  • Co-working
  • Vivero de startups

Oficina tradicional

A todos se nos viene alguna imagen al pensar en una oficina tradicional.

Jefe rándom de oficina

Suele ser utilizado por empresas de medio o gran tamaño.

Alquilar una oficina suele ser más caro, al fin y al cabo estás alquilando o comprando un bien inmueble en el que desarrollar tu actividad profesional aunque, por otra parte, tiene la ventaja de que casi cualquier edificio puede ser una oficina, no está ligado a una ubicación específica como puede suceder con los espacios de co-working, que luego veremos.

En una oficina no hay actividades ni mentoring a no ser que tú lo organices y deberás contratar los servicios que quieras que tengan tus empleados, como puede ser un servicio de impresión.

Por otra parte, a diferencia de otros espacios de trabajo, todos los trabajadores suelen compartir un mismo objetivo o tienen el desarrollo de la empresa como objetivo en común.

Por último, las oficinas tienen la fama de ser un lugar más ‘serio’ para trabajar. Ojo, ¡esto no es ni bueno ni malo! Cada proyecto es un mundo.

Oficina compartida

En muchos sitios se utiliza indistintamente las palabras oficina compartida y la palabra co-working, pero me gustaría resaltar que en este caso los vamos a tratar como conceptos diferentes y veremos por qué.

Una forma sencilla de explicar qué es una oficina compartida es imaginarse una oficina tradicional grande y un equipo que tan solo utiliza la mitad de la oficina. ¿Qué se puede hacer con la media-oficina que no se utiliza? Pues alquilarla a otro equipo, por ejemplo.

Imagen de la serie 'The Office', muy al caso del post

Siendo tu equipo el que llega para utilizar la parte de la oficina en desuso, obtendrás una oficina similar a la tradicional a priori más barata que alquilando una oficina completa del mismo tamaño que utilizas.

En este caso las actividades y servicios son o bien los que ya utilice la empresa con la que ahora compartes la oficina, con la que se suele llegar a un acuerdo para compartir gastos o bien los que tú contrates.

Una gran diferencia con la oficina tradicional es que en este caso, en mayor o menor medida, compartes espacio de trabajo con otro equipo con otro objetivo, pero compartes, con lo que suele requerir cierta conciencia social para convivir y, a diferencia de los espacios de co-working, no se suele compartir oficina para beneficiarse mutuamente de conocimientos o servicios, si no que pueden ser empresas con proyectos de ámbitos muy distintos.

Por lo general, este tipo de espacio de trabajo, aunque no sea muy habitual, suelen utilizarlo equipos pequeños que por algún motivo no desean trabajar en un espacio de co-working, no tienen acceso a un vivero de startups o empresas pero tampoco pueden o quieren, por el momento, correr con los gastos de una oficina tradicional.

Co-working

Los espacios de co-working, entendido como una evolución del trabajo colaborativo, se podría explicar como una oficina compartida donde los trabajadores suelen ser autónomos, freelance o emprendedores con equipos muy pequeños o de una sola persona y donde se busca un ambiente de colaboración y equipo.

Puede que por co-working te imagines algo así:

Co-working en modo relax

Pero en realidad suelen ser algo más parecido a esto:

Co-working en modo trabajo

Los espacios de co-working han ido emergiendo desde hace algunos años y, actualmente, sobre todo en grandes ciudades, hay una gran variedad de opciones a elegir.

Esta variedad de espacios de co-working ha propiciado que el precio de estos sea bastante variable, aunque por lo general se suele encontrar alguna opción asequible para considerarlo como espacio de trabajo.

Al trabajar en un espacio de co-working debes adoptar una mentalidad abierta ya que la colaboración y el compartir espacio produce situaciones de intercambio a diario. De hecho, es habitual que el fundador del espacio proponga actividades y reuniones con el objetivo de generar networking entre los usuarios del espacio.

Por otra parte, es posible que te encuentres en situaciones en las que haya demasiado ruido cuando necesites concentrarte o todo lo contrario, que te incomode cortar el silencio con ese Skype que tienes que hacer con tu cliente.

Vivero de startups o empresas

Los viveros se podrían llamar los hermanos mayores de los espacios de co-working, ya que suelen caracterizarse por ser un espacio físico, como un edificio, donde conviven diversas pequeñas empresas o start-ups, cada una con su propio espacio, despacho u oficina y que comparten otros espacios comunes como salas de reuniones, servicios y actividades como puede ser mentoring o networking.

Suelen ser bastante más baratos que una oficina compartida o tradicional y en algunos viveros se debe hacer una entrevista para ser aceptado, para conseguir que las start-ups participantes se encuentren en un estado parecido.

Otra particularidad es que puede haber una duración limitada para formar parte del vivero, aunque tiempo suficiente para comprobar si tu empresa puede o no crecer según lo previsto.

Es una opción perfecta para start-ups que no tanto necesiten colaboración directa para crecer pero sí quieran estar cerca de otras start-ups o, como se suele decir, ‘estar en el mundillo'.

Todas las descripciones y opiniones de este post se basan en el uso habitual de cada tipo de espacio de trabajo. No son ninguna norma establecida ni significa que, por ejemplo, una oficina tradicional enorme no la pueda utilizar una sola persona para trabajar si quiere y puede 🙂

¡Cualquier duda podéis dejarla en los comentarios!

Opina

¿Crees que las oficinas tradicionales tienden a desaparecer?

Ver resultados

Cargando ... Cargando ...

¿Me ayudas a compartir este post?

El 🐏 y yo te lo agradeceremos