MSF for Agile y XP

Recientemente Alcides me mandó un correo en donde una persona pregunta sobre las similitudes y diferencias entre MSF for Agile y XP, y si es posible usarlos juntos o usar XP con la suite de herramientas de Microsoft.

Antes de entrar en tema me parece correcto aclarar que MSF for Agile no es una metodología, ni un proceso de desarrollo--como si lo es XP. MSF for Agile es lo que Microsoft denomina un “marco de soluciones”. Es decir, se limita a proporcionar a sus usuarios con algunos artefactos, modelos, conceptos y guías.

En particular, si se observa el MSF for Agile Software Development Process Template y el MSF for Agile Software Development Process Guidance, uno puede ver de inmediato que están pensados para usarse con Scrum. Aunque se supone que MSF es agnóstico en cuanto a metodologías se refiere, existe una muy fuerte influencia de RUP y de Scrum.

Ahora bien, desde ahí existe una diferencia sin necesidad de entrar en más detalle. Hablando llanamente, Scrum y XP fueron pensadas y diseñadas desde dos puntos de vista diferentes:

• Scrum está pensado como un proceso ágil de administración de proyectos, mientras que
• XP está pensado como un proceso ágil de desarrollo de software.

De hecho, en cierta forma se puede pensar en ellos como procesos ortogonales:

• Scrum se ocupa primordialmente de los aspectos de gestión y comunicación del proyecto e intencionalmente deja fuera los aspectos referentes a las prácticas técnicas específicas usadas durante el proyecto.
• XP por otra parte, se concentra en los aspectos más técnicos de la ejecución del desarrollo. Aunque XP contiene prácticas orientadas a la planeación y administración del proyecto, estas tradicionalmente han sido poco explicadas y por ende, poco comprendidas.

Un dato relevante al respecto es que de hecho, Ken Schwaber recomienda el uso de las prácticas de ingeniería de XP (ver figura) cuando se desarrolla un proyecto de software usando Scrum.

Así, mientras que Scrum puede ser usado para gestionar cualquier clase de proyecto, XP es específicamente para el desarrollo de software. Es por ello que Scrum es tan aludido recientemente: Es más fácil de entender para los gerentes y demás personas de perfil no-necesariamente-técnico.

En cuanto a su relación con MSF, éste principalmente se dedica a promover algunas prácticas específicas para el uso con productos de Microsoft durante la mayor parte del ciclo de vida del desarrollo. Provee de guías, plantillas de documentos, sitios web, y demás cosas para aplicarlas durante el proyecto.

¿No tienes un formato oficial para casos de uso? MSF for Agile Software Development Process Template trae plantillas en formato Word.

¿Necesitas realizar un documento de Backlog para tu proyecto/sprint? MSF for Agile Software Development Process Template trae plantillas de Excel para ello.

¿Necesitas un sitio de colaboración para tu equipo de trabajo? MSF for Agile Software Development Process Template contiene una plantilla de sitio Web para Sharepoint, incluyendo blog, wiki y otras monerías.

Además, Microsoft Team System incluye software para control de versiones, seguimiento de pendientes, integración continua, reportes, etc.

Es verdad que Microsoft ha incluido varias características en sus productos que pueden resultar atractivas a los equipos de desarrollo ágiles, pero en ningún momento se puede decir que se trate de productos para el desarrollo ágil.

Un proyecto ágil puede llevarse a cabo igualmente usando herramientas Open Source para las mismas tareas:

• SharpDevelop como entorno de desarrollo (si requieres de uno).
• Subversion o CVS para control de versiones.
• Bugzilla para seguimiento de bugs y pendientes.
• CruiseControl.NET para integración continua.
• NAnt para la construcción automática de proyectos.

Y un largo, largo etcétera.

Microsoft ha integrado documentación, plantillas, artefactos y herramientas de desarrollo en un paquete que espera que sea lo suficientemente atractivo para que los desarrolladores decidamos usarlo en vez de alguna otra alternativa.

Por lo tanto, si lo que estamos tratando de resolver es cuál método usar para nuestros proyectos, la pregunta MSF o no-MSF no es siquiera relevante. Primero debemos revisar los principios detrás de los métodos que estamos evaluando y ver qué tanto se adaptan dichos principios a la cultura actual de mi empresa, mi equipo de trabajo (o a lo que quiero que llegue a ser dicha cultura) y a las necesidades de mi proyecto.

Si nos decidimos por usar Scrum o RUP y además estamos usando o planeamos usar la suite de herramientas de Microsoft, entonces es conveniente darle un vistazo a MSF, siempre recordando que este no es un fin en si mismo, sino una herramienta más que habrá de usarse y adaptarse a mis necesidades para resolver el problema que tengo entre manos.

Saludos.