Carlos Ble

Carlos Ble

I am a professional software developer, I solve problems.

I also teach and mentor developers to build better software.

Developing software since 2001.

Can I help you?

  • Do you need high quality tailor-made software?
  • Need training on TDD, clean code or refactoring?
  • Do you need a technical consultant?
  • May I pair with you to write better code?

Events

Upcoming training courses:

  1. TDD - [en Español] - 6 y 7 Octubre
    Gran Canaria
  2. TDD - [in English] - October 20, 21 & 22
    London, UK
  3. TDD - [en Español] - 29, 30 y 31 de Octubre.
    Madrid, Spain

Conferences:

  1. I'll be at the Agile Testing Days 2014
  2. I'll be at the London Test Gathering Workshops.

Archive for April, 2012



Compartir la visión de equipo

Para que un grupo de desarrolladores trabaje como un equipo, tal vez sea importante que  todos sus miembros tengan el mismo concepto de equipo.
¿Cómo es el equipo que queremos ser? ¿cuáles son las características que nos gustaría que tuviese cada persona del equipo?

Si tenemos una visión diferente de cómo debe funcionar el equipo, no conseguiremos llegar a ella porque cada uno rema en una dirección distinta.

Puede que tan sólo sea cuestión de detenerse un momento, reflexionar y decidir qué significa ser integrante de este equipo. Consensuar con los demás los valores y principios que
nos parecen claves. Y que de ese consenso busquemos prácticas que nos ayuden a ser el equipo que queremos y nos hagamos fuertes.

Un principio que me gusta aplicar es el de hacer con los demás lo mismo que me gustaría que hiciesen conmigo.

Así que voy a pensar cómo me gustaría que fuese un compañero de mi equipo para poner yo mismo en practica esos hábitos.
Voy a hacer mi propia lista de "me gustaría...", la cual podemos completar entre todos los miembros del equipo. Aquí va.

Me gustaria que un compañero... (o compañera, por supuesto)

  • Me pudiese cubrir perfectamente cuando estoy enfermo o de vacaciones sin que me tengan que llamar por teléfono contínuamente o pedirme que me conecte remotamente cuando no me encuentro en condiciones para ello.
  • Se tomase el tiempo de explicarme lo que sabe para que cuando se marche de vacaciones o se ponga enfermo, no me sienta totalmente perdido.
  • Me pidiese ayuda o hiciese programación en pareja conmigo cuando conozco mejor el código o el negocio que él o ella, porque así ganamos tiempo y aprendemos todos a la vez.
  • Me pidiese ayuda o trabajásemos juntos cuando sabe que el código que tiene que modificar es complejo y prefiere estar seguro de que no rompemos nada.
  • Me enseñase técnicas y prácticas que conoce para ser mejor profesional.
  • No me hiciese contarle más de tres veces una técnica de desarrollo sin que la tenga anotada y estudiada.
  • Trate de asegurarse por todos los medios que los cambios que ha introducido en el código no rompen funcionalidad existente (no introduce defectos).
  • Ejecutase los tests antes de subir su código al repositorio para evitar que me tenga que poner a arreglar tests que se han roto con cambios que no he hecho yo.
  • Tuviese la iniciativa de arreglar un test que no ha roto él o ella, cuando el compañero que lo rompió por accidente, ha sido avisado, pero no se puede poner con ello en ese momento. (Si quien ha dejado el test roto no suele romperlos sino que se trata de un caso excepcional).
  • Revisase mi código para entenderlo, detectar mejoras o sugerirme alternativas.
  • Criticase mi código constructivamente para ayudarme a mejorarlo y a superarme yo mismo.
  • Usase las partes de la aplicación que he hecho yo, para darme feedback como usuario.
  • Me pudiese sustituir en cualquier momento dándome la seguridad de que lo va a intentar hacer igual de bien que lo intento yo.
  • Esté abierto a recibir críticas constructivas y a aprender cada día.
  • Reconozca sus errores y se esfuerce por no cometer el mismo muchas veces.
  • Se alegre por mi progreso profesional y me apoye para que siga mejorando.
  • Tenga la iniciativa de aplicar cambios sobre código que he escrito yo, cuando necesita ser ampliado funcionalmente y yo no lo pueda hacer en ese momento (porque esté ocupado con otra tarea). Que no me haga sentir que soy el cuello de botella sino que me ayude a quitarme la presión de encima. Y que cuando cambie el código se asegure de que todos los tests siguen pasando y ha puesto el mismo nivel de cuidado en el código que el que he puesto yo.
  • Cuando tiene que introducir deuda técnica porque no le queda más remedio, lo anote y vuelva al código a saldarla tan pronto como el momento de presión termine.
  • Cuando tiene que modificar código de baja calidad se esfuerza por mejorarlo y no sólo por añadir a trancas y barrancas la nueva funcionalidad sobre la maraña.
  • Se cuestione si está haciendo lo mejor posible en cada momento y rectifica para ir en esa dirección.
  • No haya que repetirle las cuestiones con las que ya en otra ocasión hemos acordado que nos vamos a comprometer.
  • Escriba código que puedo entender sin tener que preguntarle a nadie. Y además lo puedo ampliar y testear con facilidad.
  • Antes de tomar decisiones que tienen repercusión sobre los demás, las discuta con los implicados.
  • Si no está de acuerdo con algo que digo, tenga la sinceridad de decirmelo a la cara en el momento adecuado, mejor que a destiempo.
  • Por tanto el equipo que yo visualizo se mueve en bloque, es homogéneo porque comparte unos valores y principios.

En mi visión de equipo no entra esto de "yo hago mi parte y tu la tuya", y cuando pasa algo en la parte que es "tuya" te llamamos para que la arregles tu. En una situación excepcional si, no hay reglas fijas ni matematicas puras para el día a día.

En esta visión tampoco hay tareas que siempre hace la misma persona porque es la única que sabe y parece que siempre va a seguir siendo así.
No puede haber personas que parecen ser imprescindibles. En realidad nadie lo es por muy alto que sea su bus factor. La vida sigue aunque unos marchen y otros lleguen.

Pero mi visión de equipo no sirve si mis compañeros no la comparten.

El compañero al que recuerdo con una sonrisa es el que me lo pone fácil en el día a día. El que no me obliga a verme sometido a presión innecesaria por un trabajo que él o ella ha hecho con neglicencia. Que no me obliga a hacer horas extra por su falta de cuidado.

Ser un amigo no tiene por qué ser lo mismo que ser un buen compañero. Ser un tío majo y agradable no significa ser buen compañero. Es de agradecer tratar con compañeros agradables pero eso no hace un buen equipo por sí sólo.

Puedes rellenar este interesante cuestionario sobre el nivel de agilidad de tu equipo y reflexionar sobre los resultados: http://www.abetterteam.org/new

Animaría a los equipos a redactar su propia lista de cualidades de un miembro del equipo y a colgarla en una pared grande, donde siempre sea visible para todos. Que nuestro ego no se pase por el forro esa lista sin que se note, sino que de el cante y podamos poner a ese ego en su sitio en favor de los valores del grupo.

No es otro que el ego quien causa problemas a individuos y grupos. Hay que vigilarle.