¿Necesitamos más plantillas de proceso?

Uno de los puntos fuertes de Visual Studio Team System es que cuando creamos nuestros proyectos nos permite seleccionar la metodología con la que se gestionará el mismo. La metodología que elijamos marcará como distribuiremos y planificaremos todas las tareas necesarias para llevar a cabo el proyecto. Ya que existen una gran cantidad de metodologías y para hacer el producto lo mas versátil posible, se dotó a VSTS con un mecanismo para poder crear nuevas plantillas que definieran los procesos de cualquier metodología. Al producto la acompañan dos plantillas de proceso diferentes, la de MSF for Agile y MSF for CMMI, pero existen muchas otras plantillas, algunas creadas por Microsoft, como eScrum u otras de terceros como puede ser la famosa Scrum For Team System de Cochango. Algunas de estas plantillas han sido creadas como proyectos de código abierto, otras son simplemente gratuitas y también las hay de pago.

A pesar de la gran cantidad de plantillas que existen, la gran mayoría de ellas bajo mi punto de vista (y que conste que no soy un experto en metodologías ni mucho menos) están mas enfocadas al ciclo de creación de un nuevo software que al mantenimiento del mismo. Si bien Scrum por ejemplo puede ser utilizado para la gestión de Bugs, ya que solo dice como hay que organizarse no que estamos organizando, la realidad es que el departamento de desarrollo de nuevas aplicaciones y el de mantenimiento de las mismas se gestionan de formas muy diferentes normalmente. Por ejemplo, en muchas ocasiones los que nos dedicamos a la consultoría llegamos a un cliente hacemos un desarrollo a medida y es el cliente final el que se encarga de su mantenimiento.

Una vez que esta aplicación esta lista y pasa a un estado de mantenimiento, la mayoría de tareas que se hacen, basándome en mi experiencia, es bug fixing. Suele existir un grupo de personas que se encargan de trasladar los bugs encontrados por los usuarios al equipo de mantenimiento y estos en base a su criticidad, impacto o tipo asignan prioridades para la resolución de los mismos. En este punto el proceso se convierte en algo parecido a una cola donde se van apilando bugs y se van desapilando en base a su prioridad, ya no existen áreas e iteraciones, o sprints, no existe una fecha final, ni unos requisitos específicos, solo que corrijan los bugs de la versión que hay en producción y que los usuarios puedan utilizar el producto. Quizá esta visión este mas enfocada a esa gran cantidad de herramientas que poseen las compañías para la gestión interna de sus procesos y menos a un software que se venda como producto a un usuario final, pero este escenario que planteo es muy común y creo que todos lo hemos visto o vivido.

Llegados a este punto la pregunta es, ¿necesitamos nuevas plantillas de proceso?

A mí se me ha planteado este escenario recientemente y tras evaluar como gestionarlo con Scrum o con cualquier otra metodología, mi decisión ha sido crear una nueva plantilla de proceso. Para llegar a esta decisión me plantee una serie de preguntas y analice como de factibles eran con cada una de las opciones, plantilla nueva o una existente.

Por ejemplo, ¿cuando finaliza el desarrollo? ¿tenemos un objetivo claro?. Ante estas dos preguntas las respuestas son que no tenemos una fecha de fin ni un objetivo claro que alcanzar, solo que se corrijan los bugs que se encuentren. Si usasemos una plantilla existente de una metodología no podríamos crear sprints o áreas e iteraciones, porque no hay un objetivo tangible que alcanzar ni en una fecha concreta. En este aspecto, mi opinión es que al no haber un objetivo claro ni puntos en el tiempo que vayan marcando hitos, una metodología que se base en estas cosas no es adecuada, por lo tanto usar una plantilla ya existente es bastante complicado.

Pero si obviasemos el aspecto que he comentado anteriormente y optasemos por una plantilla existente, nos surgirían otros temas como por ejemplo si nos sirven o no los tipos de WorkItems de la plantilla. Ahora necesitamos información de otro tipo, como los datos aportados por el usuario, si sabe como replicar el bug, comentarios entre los que recogen los bugs que encuentran los usuarios y los desarrolladores, en definitiva, un montón de datos adicionales que requerirían de la personalización o creación de un nuevo tipo de Work Item.

O también los tipos de reportes que necesitaría. En este aspecto ya no tienen mucho que ver los reportes que pueda aportarme una plantilla de Scrum como en Burndown chart o el Project Velocity de MSF Agile. Ahora quizás necesite ver cual es la tipología de los bugs, o el volumen de bugs solucionados por fechas, o porque no, el número de bugs que soluciona cada desarrollador, cuantos bugs se han rechazado, un punto de vista quizás mas enfocado al pasado-presente, que al presente-futuro que aportan las metodologías donde se tiene un objetivo que alcanzar.

A raíz de esto es muy probable que ponga posts relacionados con la creación y edición de plantillas de proceso, pero si me gustaría que antes de crear una plantilla de proceso os hagais estas y más preguntas para determinar si realmente necesitáis una plantilla de proceso. Yo a día de hoy aun no estoy seguro de si la decisión es correcta o no y eso lo iré viendo con el tiempo, por eso me gustaría lanzaros varias preguntas, ¿que opináis vosotros de todo este asunto? ¿os parece correcto usar Visual Studio Team System para este tipo de gestión? ¿creéis que es necesaria la creación de mas plantillas de proceso?

 

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?

Mejorar el rendimiento de nuestras Builds

Una de las prácticas de la Integración Continua que recomienda Martin Fowler es la de mantener lo más rápidas posibles nuestras Builds, aunque también podemos hacer aplicable esta práctica a todas nuestras Builds, no solo las de Integración Continua. Normalmente uno de los pasos en los que más suelen tardar las Builds es a la hora de obtener el código del repositorio y preparar el entorno para compilar, teniendo que limpiar el contenido de la última Build, regenerar el Workspace y obtener la ultima versión del código.

Tal y como ya contó el gran Luis Fraile en un post hace tiempo, lo ideal para mejorar el rendimiento es evitar que se realicen estos pasos que he comentado anteriormente añadiendo una serie de propiedades dentro de nuestro fichero TFSBuild.proj para hacer lo que se denomina Builds Incrementales. Este tipo de Builds se configuran para que solo se obtengan los ficheros modificados sobre los últimos que ya había en el Working Directory del Build Agent con lo cual se ahorra bastante tiempo. Si habéis leído el post de Luis (lectura recomendada), con Team Build 2005 se utilizaban 3 propiedades para configurar este tipo de Builds Incrementales.

<Project>
  <PropertyGroup>
    <SkipClean>true</SkipClean>
    <SkipInitializeWorkspace>true</SkipInitializeWorkspace>
    <ForceGet>false</ForceGet>
  </PropertyGroup>
</Project>

En Team Build 2008 han simplificado este proceso, que era bastante utilizado, por una sola propiedad llamada IncrementalBuild que simplemente tenemos que establecer a «true» y hará el mismo efecto que las 3 propiedades que teníamos que establecer en la versión anterior.

<Project>
  <PropertyGroup>
    <IncrementalBuild>true</IncrementalBuild>    
  </PropertyGroup>
</Project>


Simplemente con esto ya tendríamos nuestras Builds configuradas y probablemente hayamos ganado algo de velocidad a nivel global en el proceso de la Build.

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?

ALM Workshops: Integración continua con TFS 2008

Tras el evento que celebró Microsoft Ibérica la semana pasada en Madrid , el ALM Sessions 08, donde se impartieron multitud de sesiones, obviamente acerca de ALM, llegan una serie de Workshops llamados los ALM Workshops. Esta serie de eventos, que se celebrarán en Madrid y Barcelona durante Octubre, Noviembre y Diciembre, no hacen mas ampliar considerablemente (de 45 minutos a 4 horas) los contenidos presentados en dicho evento. A pesar de que no participe como ponente en ese evento (llegamos tarde), si que voy a ser ponente en uno de esos Workshops.
 

Este próximo Miércoles tendrá lugar el primero de esos Workshops y yo voy a ser el encargado de darlo. En él hablaré de como adoptar la Integración Continua con Team Foundation Server 2008. El enfoque será bastante practico y la intención es pasar la mayor parte del tiempo con Visual Studio y configurando todo el entorno para adoptar la Integración Continua de la forma más eficiente posible. Por aquí os dejo los datos de registro y la url por si alguno quiere/puede asistir.
 

Evento: Workshop ILITIA: Integración Continua con Team Foundation Server 2008
Fecha: Miercoles 22 de Octubre, de 10:00h a 14:00h
Lugar: Oficinas de Microsoft Ibérica en Pozuelo de Alarcón, Madrid
Coste del evento: 30€

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?

Laboratorios Virtuales de Visual Studio Team System 2008

Yo no soy muy partidario de poner posts con simplemente con links sin generar algún tipo de valor adicional, pero en esta ocasión voy a hacer una excepción. A finales de Marzo de este año Microsoft publico una máquina virtual muy completa con la versión RTM de Visual Studio Team System 2008 y de la que ya he hablado anteriormente. Junto a esta máquina virtual se publicaron también una serie de laboratorios con los que se podían ver y aprender muchas de las nuevas características del producto.

Pues bien, hoy he visto (y hasta ahora no había tenido constancia de ello) que algunos de estos laboratorios y otros nuevos están disponibles online, y que sin necesidad de descargar nada podéis realizarlos tranquilamente desde vuestro PC, en casa o en la oficina. Así que si más demora aquí os dejo los enlaces a estos laboratorios para podáis hacerlos.

Y bueno por si esto os parece poco, aprovecho también para dejaros unos enlaces a una serie de Web Casts que se han publicado los chicos del programa de partners y que están bastante bien:

  • Microsoft® Visual Studio® Team System 2008 : Serie de 6 Web Casts de una hora de duración cada uno que da un repaso a cada una de las versiones de VSTS así como a Team Foundation Server. Estos Web Casts están clasificados como nivel avanzado.
  • Microsoft Visual Studio Team System 2008 : Serie de otros 6 Web Casts de una hora de duración, y que en esta ocasión además de repasar las distintas versiones de VSTS y Team Foundation Server, ofrece una introducción a ALM. Estos son algo más leves en cuanto a contenidos, son de nivel intermedio.
  • Visual Studio Team Systems Web Seminar Series : Y por ultimo, una serie de Web Seminars, mucho más introductorios y que hacen un recorrido por las novedades del producto analizando cada una de las versiones de VSTS.

Y para concluir (y os prometo que ya paro de poner enlaces :-)) os dejo también la url de la pagina de eventos y web casts dedica a Visual Studio Team System donde se van publicando los nuevos Web Casts y laboratorios que van sacando del producto, ya hay incluso un Web Cast planeado para Marzo de 2009.

Espero que os sean de ayuda todos estos recursos de formación.

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?

Excluir el código generado de la cobertura de código

Una de las características que nos proporciona Visual Studio Team System es la Cobertura de código, que nos ayuda a saber que cantidad de código funcional cubren nuestras pruebas unitarias. El volumen de código que cubren nuestras pruebas es representado de forma porcentual y como cabe esperar lo ideal es mantener este porcentaje lo más alto posible, pero muchas veces debido al código que genera Visual Studio en algunas ocasiones, este porcentaje nunca alcanza el 100%.

Cubrir el 100% del código con nuestras pruebas unitarias es una tarea muy difícil pero si además tenemos código generado, que no debemos probar, y que también es contabilizado, podemos perder la perspectiva del nivel de cobertura que estamos alcanzando con nuestras pruebas. Lo ideal sería, al igual que se puede hacer con las reglas de Análisis estático de código, excluir el código generado del informe de cobertura de código, ¿no?.

Pues bien, a pesar de que no es una funcionalidad tal cual, es más bien un Workaround, existe la forma de excluir el código generado para que no contabilice cuando se esta realizando la cobertura de código, incluso hacer que el código generado no aparezca en el reporte de cobertura de código. El Tip/Trick/Hack o como queráis llamarlo surge a raíz de como es realizada la medición de la cobertura, que se basa en el Debugger para saber porque líneas de código se ha pasado, con lo que si conseguimos que el Debugger no pase por el código generado evitamos que ese código sea contabilizado, pero voy a dejar ya de dar tanto detalle y vamos a ver un poco de código.

Partiendo de un proyecto de librería de clases recién creado, tenemos una clase con el código que sigue:


using
System; using System.Collections.Generic; namespace Managers { public class ManagerClass { public List<Book> GetBooksByName(string bookName) { return null; } } }

Este código no hace absolutamente nada, con lo que si generamos un test unitario con el código que se muestra a continuación deberíamos obtener una cobertura del 100%, ¿no?
 

[TestMethod]
public void GetBooksByNameExpectedNull()
{
    // Arrange
    ManagerClass target = new ManagerClass();

    // Act
    List<Book> val1 = target.GetBooksByName(String.Empty);

    // Assert
    Assert.IsNull(val1);
}

Sin embargo tras ejecutar la prueba unitaria, obtenemos a nivel de ensamblado un 28,57% de cobertura, lo cual resulta un poco extraño. Si miramos el reporte de la cobertura de código vemos que el espacio de nombres Managers si tiene una cobertura del 100%, pero tenemos un tal Managers.Properties que representa una parte importante de nuestro código y que no esta probado, lo que hace que la media porcentual caiga en picado.

ExcluirCoberturaDeCodigo-1

La clase Settings dentro de Managers.Properties es código generado por Visual Studio y en este ejemplo representa un porcentaje muy alto de todo el código que hay en el proyecto, lo que hace que al no estar probado, nuestro índice de cobertura sea muy bajo. Para excluir este código de la medición lo único que tenemos que hacer es abrir el fichero Settings.cs y añadir, en este caso a nivel de clase, el atributo DebbugerNonUserCode o DebuggerHidden, con lo que el depurador no pasará por ese código y no se incluirá en el reporte.

using System.Diagnostics;

namespace Managers.Properties 
{    
    [global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute(
        "Microsoft.VisualStudio.Editors.SettingsDesigner." +
        "SettingsSingleFileGenerator", "9.0.0.0")]
    [DebuggerNonUserCode] /* Atributo para la exclusion */

    internal sealed partial class Settings 
        : global::System.Configuration.ApplicationSettingsBase 
    {
        private static Settings defaultInstance = 
            ((Settings)(global::System.Configuration.
            ApplicationSettingsBase.Synchronized(new Settings())));
        
        public static Settings Default 
        {
            get 
            {
                return defaultInstance;
            }
        }
    }
}

Como podéis comprobar en la siguiente imagen ya no hay rastro de Managers.Properties y nuestro porcentaje a nivel de ensamblado ya es real.

ExcluirCoberturaDeCodigo-2

Este es un ejemplo muy básico, y la proporción entre código funcional y código generado hace que no probar el código generado tenga mucho impacto, pero muestra como conseguir el objetivo del post perfectamente. Si lo probáis en un proyecto en el que tengais DataSets, o referencias a servicios Web podréis observar el resultado real.

Por ultimo, solo comentar que si decidimos usar este método para obtener una cobertura de código real, debemos tener presente que el código que este marcado con este atributo no cuenta en ningún aspecto para el depurador, con lo que si necesitamos poner un punto de interrupción en este código, éste será obviado por completo. Además si Visual Studio necesitara regenerar el código, por ejemplo una referencia a un servicio Web o un DataSet, como es lógico los atributos se borrarán y el código volverá a aparecer en el reporte de cobertura.

teamsystem.es
Este post es contenido cross-posting desde www.teamsystem.es y estoy muy interesado en tu opinión. ¿Porqué no te acercas y dejas un comentario para que todos podamos aprender?