3 cosas que nunca deberías hacer como Jefe de Desarrollo

Read this article in english

A lo largo de mi vida como programador he vivido momentos difíciles en el trabajo diario. A veces sólo puedes apretar y apretar, sea cual sea la razón. Esto pasará, sin duda, y cuando pase tienes que hacer el esfuerzo. El trabajo tiene que salir.

Pero, sea como sea, pase lo que pase, intenta evitar estas 3 cosas.

1. Establecer fechas límite poco realistas

Todos hemos tenido deadlines, y sabemos que tenemos que atenernos a ellas. Pero cuando hablamos de programación, estas fechas tienen que ser realistas. La mejor manera de tener fechas realistas es consultando con el equipo de desarrollo. Sabrán trocear el proyecto en tareas más pequeñas y estimar la fecha de finalización con bastante exactitud. Y si el equipo usa Scrum lo harán todavía mejor.

Establecer deadlines poco realistas te retornará de varias formas:

  • Equipo estresado. «Tensión» está bien, pero el estrés no.
  • Baja calidad del código. Tendrán que correr para cumplir con el deadline, sin importar demasiado si las decisiones de implementación son correctas o no.
  • Deuda técnica. Habiendo leído el punto anterior, ¿pensabas que me iba a dejar la deuda técnica?

¿Estás dispuesto a pagar este precio?

2. Permitir deuda técnica

La programación implica deuda técnica. No tener deuda técnica es casi imposible y, con toda seguridad, demasiado caro. Así las cosas, lo que tenemos que conseguir es minimizar su impacto.

Profundizando en esto de la deuda técnica, ya hace algún tiempo, encontré un artículo muy interesante que además incluía un «Cuadrante de la Deuda Técnica» (de Martin Fowler). Te recomiendo encarecidamente la lectura de este artículo.

https://deviq.com/technical-debt/

Me encanta la definición de la primera frase del artículo:

Technical debt is a metaphor for all of the shortcuts, hacks, and poor design choices made for a given software system that compromised its quality, usually in an attempt to meet a deadline.

«La deuda técnica es una metáfora de todos los atajos, trucos y malas elecciones de diseño hechas para un sistema de software dado, que comprometió su calidad, generalmente en un intento de cumplir con una fecha límite.»

Como Jefe de Desarrollo, una de tus prioridades es entregar software, y entregarlo con buena calidad (minimizando, como decíamos antes, su deuda técnica). Por otro lado tenemos las fechas límite. Esto es siempre lo mismo: atenerte a las fechas límite y entregar buen software. ¿Todo? ¿¡Cómo!?

La mejor manera de «intentar» llegar a este objetivo es usando metodologías ágiles. Probablemente sabes que me encanta Scrum. Bueno, eso es porque te da a ti y al equipo de desarrollo una visión muy amplia de lo que se está desarrollando.

Y, por supuesto, las metodologías ágiles son el siguiente punto.

3. Evitar el uso de metodologías ágiles

Cuando tienes o formas parte de un equipo de desarrollo estable, deberías/deberían usar metodologías ágiles. Y a mi me encanta Scrum (¡Ah, que eso ya lo dije!). 🙂

Así que, si tienes un equipo de desarrollo, no asignes ‘n’ proyectos a ‘n’ individuos en un intento de paralelizar su trabajo. ¡Eso es un error terrible! Si haces eso, un proyecto pertenecerá a un programador, los demás no tendrán conocimiento sobre ese proyecto, y por ello el mantenimiento se verá seriamente afectado.

Usar Scrum le otorga al equipo algunas ventajas muy interesantes:

  • Todos participarán en la definición de la solución (sprint planning).
  • Todos hablarán cada mañana sobre sus logros y problemas del día anterior (daily meeting).
  • Todos sabrán qué se está haciendo.
  • Todos hablarán al final de cada sprint sobre lo que han aprendido en él (sprint retrospective).
  • Y mi favorita: aprenderán más y más sobre ellos mismos y serán capaces de estimar la duración de las tareas con mucha más exactitud.

Esta vez no he dicho nada sobre la calidad de código, pero estaba implícito en los tres puntos.  😉

8 cosas que he aprendido sobre los equipos de desarrollo

Read this article in english

Llevo muchos años programando en equipo y, a veces, liderándolos. Hay muchísimas cosas que aún aprenderé en el futuro, pero … mi años no han pasado en vano. 😉

1. La calidad es importante

Sí, la calidad del código es importante, tanto en cómo lo escribes y en cómo lo mantienes. No eres un buen programador hasta que no seas capaz de garantizar que tu código es bueno, y eso significa sin bugs, testeable y limpio (volveré sobre esto más tarde). Y cuando hablamos de calidad hay dos puntualizaciones a hacer: 1) el uso de patrones de diseño es prácticamente obligatorio, y 2) el código debe ser SOLID. No voy a profundizar en estos dos puntos en este artículo, pero lo haré en el futuro.

Consejo: si eres programador y no sabes qué es esto de patrones y SOLID… empieza hoy. Créeme.

2. Lenguaje ubicuo

No solamente entre los miembros del equipo, sino también con el Product Owner y el negocio. Es necesario que usemos las mismas palabras para referirnos a los mismos conceptos. Esto evitará malentendidos y, consecuentemente, costes añadidos. Empieza por tener un buen ‘DoD’ (Definition of Done, Definición de ‘Hecho’).

Y esto no sólo es aplicable a nuestro lenguaje natural. Lee el siguiente punto.

3. Código limpio, limpio, limpio

«¿Código limpio? ¿Para qué? ¡Esto es la vida real!». No cometas este error. ¡El código limpio es prácticamente obligatorio! Di la verdad: ¿cuántas veces has tenido que releer tu código, escrito sólo unas semanas antes, porque no entendías nada? Esto se puede evitar si haces las cosas bien.

La mejor manera de escribir código limpio desde cero es adoptando algún standard. En PHP, sigue *al menos* lo que indica PSR-2 y ya estarás en el buen camino.

Y una cosa más… código limpio también significa darle nombres correctos a clases, métodos, variables, etc. Por ejemplo, no pongas el nombre ‘ClientBasket’ a una clase cuando claramente es ‘Order’. (sin bromas; esto lo he visto).

Y hazte esta pregunta: ¿Has tenido alguna vez un jefe que te diera tiempo para limpiar tu código? 😉

4. Testear es esencial

Obviamente no podía dejar de mencionar PHPUnit, Jasmine, Mocha, Ghost Inspector, Cucumber, … Cuando creas una aplicación, tener testeo automatizado es el pasaporte a la tranquilidad. Si quieres dormir por las noches (o ir a tomar algo, o lo que sea), testea tu código. Este punto es tan importante que incluso tenemos un acrónimo. Bueno, tenemos acrónimos para casi todo. En este caso, TDD – Test Driven Development. Por favor, créeme. Testear todos tus métodos [públicos] desde el principio mantendrá tu código perfecto. Créeme (a mí, no a tu código) y testea. 😉

5. La formación no es esencial, pero a nosotros, los programadores, nos encanta.

Nuestro sector evoluciona a un ritmo altísimo, y siempre queremos estar al día. En mi caso, me gustaría tener la certificación de AWS Solutions Architect. Otros querrán certificarse como Scrum Master o Product Owner. Otros querrán dominar Docker. Cualquiera que sea su objetivo, dales esa formación. Eso es motivación «de la buena» para ellos (para nosotros).

6. Escucha a los miembros del equipo

Tus compañeros de equipo tienen cosas que decir. Pueden tener inquietudes, otros puntos de vista y, aunque algunos de estos puntos no serán aplicables, otros seguro que sí. Pueden tener dificultades en explicar con exactitud cuáles son sus necesidades, pero escúchales igualmente, o lee entre líneas. Me han sorprendido (agradablemente) tantas veces que simplemente no podía dejar este tema sin mencionar.

7. Usa metodologías ágiles

Las metodologías ágiles me encantan, pero hay una que destaca sobre las demás: Scrum. Esta metodología le aporta diferentes beneficios al equipo de desarrollo: confiabilidad, reducido tiempo de deploy, mejor ROI, y mi favorito: calidad.

En el uso de Scrum, pide a tu equipo que además haga revisión cruzada de código. Esto les hará interactuar aún más. Me encanta Scrum.

8. Usa herramientas de colaboración/automatización

Nosotros, los programadores, tenemos un montón de buenas herramientas a nuestra disposición. Sólo por mencionar unos cuántos: git, Bitbucket/Github, PHPUnit, gulp, grunt, composer, Jira, Trello, Jenkins, Docker, Kubernetes, …

Como programador, no los uso todos en cada uno de mis proyectos, pero puedo asegurar algo: el uso de estas herramientas hace que mi vida sea mucho, mucho, mucho más fácil. Algunas de estas herramientas son gratis, y otras no. Cuando sea necesario, paga por ella. Punto.

Comentario extra: Desacoplamiento

¿Alguna vez has oído aquello de “El programador resolvió un problema, pero estropeó otra cosa”? Seguro.

Si quieres impresionar a alguien cuando hables de programación, usa la palabra «desacoplamiento«. Esto puede sonar muy «top», pero significa simplemente que una determinada funcionalidad de tu código está encapsulado en pequeños métodos, de manera que cuando necesites modificar o añadir algo, probablemente no vayas a romper nada más.

Y si a esto le añades testeo automatizado, patrones de diseño, SOLID y código limpio… ¡Boom!  ¡Súper código!