Presentando Azure DevOps

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps

¿Qué es lo que esperamos de nuestros Scrum Masters?

Normalmente en los artículos y conferencias vinculados a la agilidad se nota mucho el enfoque de como los Scrum Master (y Agile Coaches) pueden ir mejorando, evolucionando y lograr lo mejor de los equipos para conseguir los objetivos esperados de la organización, pero… ¿cuantas veces hemos reflexionado sobre que es lo que esperamos los miembros “de base” de los equipos ágiles de nuestros respectivos SM? (*)

Es así que en la pasada reunión de Agile Perú, propuse el tema así que comparto las reflexiones de dicha reunión sumado a los comentarios de entonces y los que luego tuve en conversaciones posteriores.

Como punto de partida previo, hay que tener claro que no se esperaba que el Scrum Master fuera un “cargo” institucionalizado, si no mas bien un “rol” dentro de los integrantes del equipo; lamentablemente, por la deriva que ha tenido la “escena ágil”, la figura se ha consolidado, tanto por el movimiento de ex PMs que se acercaron a la agilidad, como por los profesionales que buscan ir a la rama de “gestión” esquivando lo técnico, esa es la realidad y si bien hay que recordar cual era la intención original del rol, también es bueno procurar canalizar de manera adecuada la situación en aras de lograr lo mejor para los equipos.

Con esto como base, soy de los que considera que el objetivo del Scrum Master es volverse prescindible para el equipo ya que ha procurado que este haya llegado a un grado de madurez que permite se pueda confiar en su auto-organización, esto implica muchos retos, pues el perfil de cada equipo es diferente, puede tratarse de profesionales con poca experiencia en las practicas ágiles (o en el dominio tecnológico respectivo) por lo que corresponderá un acompañamiento adecuado para que esto se vaya impregnando en el hacer de los miembros del equipo, o también tratarse de un equipo de rockstars con mucha experiencia tanto tecnológica como en agilidad y que por lo mismo tocara hacer los esfuerzos para que las diversas personalidades logren la sinergia y colaboración esperada. Como se ve, retos diferentes pero con el (se supone) mismo objetivo, convertir un grupo de personas en un equipo auto-organizado, así que creo que el éxito de la carrera de un SM (**) debe apreciarse por como (y a cuantos) ha contribuido a lograr que los equipos hayan llegado a ese estadio, que (por cierto esta en el Manifiesto Ágil) : “Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados“. Finish Reading: ¿Qué es lo que esperamos de nuestros Scrum Masters?