Bromas aparte, la comunicación fuera de los grupos técnicos es un área que la mayoría de los desarrolladores necesitan mejorar. Para empezar, entender qué problema hay que resolver y por qué es un problema es una habilidad que hay que perfeccionar. Esta comprensión es crucial, ya que nos ayuda a escribir mejor código y nos hace estar más comprometidos con el proyecto. Una comunicación eficaz nos conecta como equipo, garantizando que todos entendemos el problema y podemos trabajar juntos para resolverlo.
Debemos codificar con un propósito. Sin propósito no hay código. Una vez oí a un jefe de equipo orientado a los negocios decir: "No estamos aquí para escribir código. Estamos aquí para vender cosas". La empresa tenía un propósito más elevado que ese, lo que alejaba aún más la codificación del centro de atención.
Comprender este propósito superior, los objetivos empresariales, es crucial para los desarrolladores. Da sentido a nuestro código y hace que nuestro trabajo sea algo más que líneas de texto. Comprometerse con las partes interesadas y, lo que es aún más importante, comprender sus necesidades es crucial para alinearse con sus objetivos. A veces, estos objetivos pueden requerir una mayor exploración, y es nuestra responsabilidad profundizar en la conversación hasta que sus objetivos estén claros como el cristal.
Preguntas como "¿Qué solución en la nube busca?", "¿Qué pila tecnológica se adapta mejor a sus necesidades?", "¿El botón debe ser naranja o magenta?" o "¿Nos inclinamos por Figma o Balsamiq?" no son las adecuadas. No en este momento.
Un desarrollador puede ser introducido a Scrum uniéndose a un equipo que se reúne diariamente para discutir lo que hicieron el día anterior, mientras que uno de larga data es designado el Scrum Master. Ambos pueden no entender por qué existe el marco o qué problemas resuelve, concluyendo que "scrum no es para nosotros".
Para los desarrolladores, comprender los objetivos del proyecto y planificar su consecución, tanto en equipo como individualmente, es algo más que escribir código. Se trata de saber cuándo escribir código, qué prácticas de ingeniería y de personas seguir, y preocuparse por la calidad de la solución que creamos para cumplir el objetivo del producto, seguida de la calidad de la implementación. Este viaje de aprendizaje continuo y mejora de las competencias nos mantiene motivados e inspirados.
Para practicar los rudimentos de habilidades complejas, las dividimos en pequeños trozos y las ejecutamos en pasos más pequeños para que el ciclo de retroalimentación sea más rápido, lo que permite un aprendizaje y una corrección del curso más rápidos. Para ello, un sprint de dos semanas en un proyecto real puede parecer desalentador cuando tenemos que entregar algo al final del periodo.
¿Y si practicamos esas habilidades durante tres sprints en tres días? ¿Es demasiado poco tiempo? Añadamos un proyecto del que sabías muy poco y un equipo de personas que acabas de conocer. El equipo y sus integrantes aprenden rápidamente lo buenas que son sus habilidades de estimación (normalmente podrían ser mejores), cómo manejar la mezcla de voces altas y bajas y cómo perfeccionar su colaboración para alcanzar sus objetivos.
Si esto le resuena o le atrae, considere la posibilidad de comprobar hacia fuera nuestro Aplicando Scrum Profesional para Desarrolladores de Software clase.
