Scrum

A menudo me encuentro frente a situaciones donde se confunde “programador” con “desarrollador”, o más aún, “desarrollador” con “programador”.

Antes de seguir, aclaro que mi postura es la de definir al programador como aquel que no se especializa en otra cosa que no sea codificar nuevas funcionalidades en función de diseños recibidos. No contribuye a escribir o entender las especificaciones. Ni se le ocurre escribir pruebas automatizadas. No colabora para mantener el build actualizado. Ni que hablar de las pruebas. No ayuda al cliente a comprender sus necesidades ni a resolver sus problemas. Se dedica solo a eso, a escribir código.

La tendencia actual del desarrollo de software y las metodologías ágiles está comprendiendo cada vez más la necesidad de contar con equipos multidisciplinarios, o en otras palabras, personas que contribuyan de distintas maneras al objetivo buscado, en lugar de personas que solo se especialicen en una parte del proceso y que no tengan una visión completa de él.

De esta manera, todos son igual de responsables por alcanzar los logros y la existencia de fracasos (si la hubiera). La solución más razonable que algunas organizaciones están ofreciendo frente a los contextos de negocios cambiantes es aumentar la flexibilidad. Incluso es lógico deducir que el hecho de contratar solo especialistas en determinadas áreas generará muchos mayores costos económicos e incluso de comunicación dentro del equipo, lo que puede atentar contra el desarrollo exitoso del producto.

¿Qué se espera de un desarrollador? El desarrollador es básicamente quien aunque no hace TODO al mismo tiempo (eso sería un absurdo), conoce el proceso de principio a fin y por eso logra detectar “a tiempo” cualquier “contratiempo” que pudiera surgir. En otras palabras, sería como esas nuevas cámaras digitales que obtienen una imagen panorámica que ofrece una visión completa de la escena fotografiada.

Entre las tareas de un desarrollador se encuentran:

• Entender el negocio y los objetivos que se están persiguiendo
• Colaborar con el Product Owner para identificar las historias de usuario y sus criterios de aceptación
• Ser parte protagonista a la hora del armado y mantenimiento del entorno de trabajo
• Garantizar las prácticas ágiles de desarrollo de software como Integración Continua, TDD, ATDD
• Participar en el diseño de la solución, tanto lógico como arquitectónico

Por un mundo mejor, las responsabilidades del desarrollo del producto deben estar compartidas entre todos los involucrados en el proyecto, con la salvedad de que el Product Owner no requiere, en la mayoría de los casos, tener conocimientos técnicos. Sí, percibo que la siguiente pregunta es: ¿y el Scrum Master? Mi respuesta es otra pregunta ¿Cómo podría el Scrum Master remover impedimientos y garantizar al equipo un adecuado entorno de trabajo si no tiene los conocimientos técnicos necesarios de los desarrolladores? Cito:

“Un conocimiento íntimo y detallado de cómo algo funciona incrementa las posibilidade de que el líder ayude al equipo a descubrir las cuestiones técnicas más sutiles que deban ser tratadas” (LaFasto & Larson, When teams work best, 2001, p. 133).

En el fondo, aunque el equipo sea el encargado principal de desarrollar el producto y naturalmente es quien mejor conoce su desarrollo, el Scrum Master no debería desconocer los aspectos del desarrollo y en algunos casos, hasta debería ser quien mejor los conozca si es que se quieren evitar problemas de comunicación, interpretación y estimación; pero sobre todo, si se pretende alcanzar un objetivo exitoso.

Volviendo al comienzo: lo que necesitamos son verdaderos desarrolladores, personas que cuenten con las herramientas y prácticas necesarias para lograr un proceso de desarrollo exitoso y un producto de alta calidad. Esto no quiere decir que no se necesite también de los programadores, pero no confundamos un desarrollador o “developer” con un simple programador. Incluso un excelente programador podría ser un pésimo desarrollador y un Scrum Master que no ha adquirido estas herramientas a lo largo de su formación podría eventualmente ser percibido por el equipo de desarrollo como falto de las habilidades necesarias para cumplir su función.

Si apenas podemos entender estas diferencias fundamentales, habremos dado un paso más hacia un mundo de trabajo mejor.