En el anterior artículo de esta serie he tocado por encima las metodologías de trabajo, desde su concepto más arquitectónico hasta los frameworks más utilizados como RUP, XP o SCRUM.
Ahora voy a meter las manos en la masa y, haciendo una breve descripción de la metodología y de las piezas de software que se utilizan, voy a realizar la descripción más detallada de las capacidades del ecosistema de desarrollo en .Net. La potencia de todas estas aplicaciones que tienen un nivel de comunicación y usabilidad muy alto.
Obviaré todo lo relacionado con descargas, instalaciones y configuraciones del ecosistema por dos razones fundamentales: Primero esto es un blog de desarrolladores, asique voy a la chicha que utilizo todos los días; aunque a estas alturas pueda instalar un TFS con los ojos cerrados. Y segundo, que existe una máquina virtual gratuita que ya trae todo el ecosistema montado y listo para funcionar hasta su periodo de expiración.
Scrum
En 1986, Hirotaka Takeuchi y Ikujiro Nonaka describieron una forma de desarrollar software, en la búsqueda de mayor flexibilidad y velocidad, que nombraron rugby approach.
En los años 90, Jeff Sutherland y Ken Schwaber , conformaron lo que se conoce actualmente por SCRUM al publicar Scrum methodology que describe el framework que se ha convertido en la forma de construir software con mayor crecimiento en la industria actualmente.
SCRUM es un desarrollo Iterativo y Creciente que propone una serie de prácticas a realizar en cada una de las iteraciones. En este framework se prima por encima de todo la comunicación entre los miembros del equipo y de ellos con el cliente. Así, partiendo de esta premisa se puede realizar las tareas sin tener que dedicarle prácticamente tiempo a procesos más formales como el análisis funcional, técnico, a los prototipos o a las demostraciones.
Los roles que están implicados en SCRUM son tres:
Product Owner: Es el dueño del producto. Es decir la persona que sabe qué es lo que se quiere hacer y los resultados que se han de obtener para considerar como éxito el desarrollo de la aplicación. Es el encargado de añadir tareas al Product Backlog y ordenarlo.
Scrum Master: Es la persona encargada de facilitar al PO y al equipo la correcta implementación de la metodología. Ayudando al PO a realizar y ordenar el PO. Organizando y moderando las reuniones de los sprints. Y también deben proteger al equipo de interrupciones o desviaciones durante el mismo.
Equipo: Son los encargados de hacer las cosas. Son los responsables y los que toman las decisiones durante los sprints.
Las reuniones en SCRUM están muy bien definidas. Y en líneas generales son:
Reunión de planificación: Al inicio del sprint divida en dos partes. Una con el PO en donde se organiza el PB añadiendo o quitando Historias de Usuario; y ordenando por el criterio de mayor importancia. La segunda parte de la reunión es solamente el equipo en donde se construye el SB, desglosando las historias de usuario en tareas más pequeñas, no más de 16 horas, y decidiendo qué y en qué orden se va a realizar durante el sprint que se va a iniciar.
Reunión diaria: el equipo se junta de pie y cada uno responde a tres preguntas. ¿Qué hice ayer?¿Qué voy a hacer hoy?¿Qué me impide continuar? Ojo, no es una reunión de control de lo realizado. Es una reunión para compartir la información entre todo el equipo.
Revisión del Sprint: Se realiza al finalizar el sprint con el Equipo y el PO para revisar el Valor construido en el sprint, que el PO valide que se han cumplido los criterios de aceptación y señale las faltas que detecte, para tratarlas en la siguiente reunión de inicio de sprint.
Retrospectiva: Indudablemente la reunión más importante. El equipo revisa su trabajo, la forma de trabajar, el entorno y todo aquello que sea reseñable para plasmarlo en papel y buscar la forma de mejorar en todos los aspectos.
Los artefactos que indica SCRUM(*) en su definición a utilizar durante la duración del proyecto son:
Product Backlog: Listado con los requisitos y criterios de aceptación escritos en forma de Historias de Usuario y contenidos en fichas.
Sprint Backlog: Listado que se construye en cada sprint en donde se desglosan en tareas aquellas fichas del Product Backlog a las que el equipo se compromete a realizar.
Burn Down(*): Métrica que puede ser del PB y/o del SB en donde se indica el número de tareas ideal que se ha de finalizar para cumplir los objetivos del sprint; y el estado actual.
No me voy a extender mucho más, porque este tema da para libros enteros. Pero si quiero señalar que SCRUM es una herramienta que produce una intensa motivación al equipo de desarrollo al ponerlo en el centro de la acción y de las decisiones. Huyendo del modelo de ordeno y mando en donde trabajábamos con orejeras.
Piezas del ecosistema
Me voy a dejar de tanta teoría y, obviando todo aquello relacionado con descargas, instalaciones y configuraciones de las aplicaciones; entro a detallar someramente las aplicaciones que componen el ecosistema de desarrollo .Net y que son:
Visual Studio 2010 Ultimate con SP1: Este es el IDE por antonomasia en el desarrollo de aplicaciones .NET.
Team Foundation Server 2010 con SP1: El centro del ALM en el ecosistema .NET. Soporta la integración continua, el LDAP de datos, el repositorio de código y su versionado y la interrelación entre las aplicaciones que acceden y manipulan la información.
SQL Server 2008 R2 con SP1: Base de datos que soporta el ecosistema.
Reporting Services 2008: Servidor de reportes e informes, está basado en SQL Server 2008.
Shareporint Services 2007: Portal de documentación del TFS en donde los equipos tiene acceso por defecto al gestor documental, a las Wiki, a visualizar los reportes, etc.
Office: Como no podía ser de otra forma, en el ecosistema .Net la integración con Office y en especial con Outlook y Excel, es estrecha. También se utiliza Microsoft Project para la gestión de los proyectos.
Otros sistemas Microsoft: Si bien en esta serie no los vamos a tocar, este ecosistema se integra de forma transparente con el sistema de mensajería Exchange Server y con el Directorio Activo de Windows.
Otros Sistemas no Microsoft: No es obligatorio utilizar Visual Studio para conectarse con el TFS, pudiéndose realizar con Eclipse tanto en Mac como en Linux (a través de una herramienta de pago). Así mismo soporta realizar la integración continua con otros constructores que no sean MSBuild.
Todo lo que estoy señalando se obtiene de forma gratuita por un periodo de prueba que finaliza en noviembre de este año 2011; en una máquina virtual que corre sobre VirtualPC o Hyper-V.
Yo lo que he hecho es utilizar el contenido de la máquina virtual a excepción del Visual Studio que lo tengo instalado en el ordenador matriz y desde donde me conecto al TFS de la máquina virtual. Es cierto que eso ha implicado hacerle un aumento de memoria RAM al ordenador, pero así tengo más flexibilidad en la redacción de estos artículos.
Y con esto creo que es suficiente por ahora. En el próximo capítulo de esta serie entraremos a crear un Product Backlog con Historias de Usuario, Un Sprint Backlog con tareas y veréis lo sencillo que es mantener las métricas al día con un simple click.
(*) En la última revisión de Jeff y Kent han dado más libertad al framework y ahora no es necesario priorizar, ni tener una métrica BurnDown.
Más información | Explicando Scrum a mi abuela, Scrum Alliance, ScrumManager
Más información | Blog de El Bruno, Microsoft Visual Studio
Descargas | Máquina Virtual del ecosistema