Agregando Bugs al Board de Web Access - Template MSF for Agile 5.0

por Victor Passador  17. diciembre 2012

TFS 2012 propone gestionar las tareas del desarrollo a través de un Web Access totalmente renovado desde su versión 2010. Utilizando esta herramienta, el PM podrá entre otras cosas, administrar las capacidades del equipo, crear y asignar User Stories, Taks, Bugs, planificar sprints, verificar estado de avance del proyecto a través del Burndown chart, del reporte de salud de los Builds, y varios etcéteras más.

La planificación propiamente dicha, se realiza a través del “Board” (un tablero muy útil en daily meetings además de otros momentos) y facilita la administración de tareas ya que no hay que trasladar el cambio de estado de los papelitos en el “tablero de corcho” a la herramienta, sino que se puede hacer directamente desde ésta.

Considero que la herramienta aporta mucho a la agilidad, pero en ciertos escenarios, se queda corta en posibilidades de personalización.

El caso que quiero plantear se da con un Team Project ya creado y migrado desde la versión anterior, con el template MSF for Agile 5.0, donde quisiéramos que aparezcan en ese board los bugs, además de las tareas.

Aquí se explica cómo es que funciona el board y cuáles son los tipos de Work Item que allí aparecen.

Si bien el texto es claro y con ejemplos, no cubre el 100% de la necesidad de nuestro escenario. Describiré más abajo cuáles son los pasos a seguir (tomando los pasos detallados en el link y ampliando con lo que estaba faltando):


Aclaración 1: Cada uno de estos pasos consiste en exportar desde TFS a un directorio local una sección del Process Template con el que fue creado el Team Project, modificar las entradas que sean necesarias y volver a incorporar esa sección modificada en el servidor, todo esto utilizando el comando witadmin

Aclaración 2: Como estamos modificando definiciones en un servidor que probablemente esté en producción, es buena práctica conservar una copia de cada archivo que obtengamos luego de ejecutar un comando “witadmin exportxxx …”. Si las cosas no salen como esperamos, teniendo un backup, siempre será posible volver todo a su estado inicial ejecutando el comando “witadmin importxxx …”


Paso 1: “Bajar” la definición de categorías del template para poder incluir a los bugs dentro de la categoría Task Category (hace un tiempo escribí aquí sobre categorías de Work Items)

witadmin exportcategories
     /collection:CollectionURL
     /p:ProjectName
     /f:"DirectoryPath\categories.xml"

Paso 2: Modificar la sección correspondiente para que quede como se muestra a continuación

<CATEGORY name="Task Category" refname="Microsoft.TaskCategory">
   <DEFAULTWORKITEMTYPE name="Task" />
   <WORKITEMTYPE name="Bug" />
</CATEGORY>

Paso 3: “Subir” la nueva definición

witadmin importcategories
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\categories.xml"

Paso 4: “Bajar” la definición de configuración para agregar los estados (metastates) y así unificar entre Task y Bugs

witadmin exportcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"

Paso 5: Modificar la sección correspondiente para que quede como se muestra a continuación

<TaskWorkItems category="Microsoft.TaskCategory">
    <States>
       <State value="Active" type="Proposed"/>
        <State value="Resolved" type="InProgress"/>
        <State value="Closed" type="Complete"/>
    </States>
</TaskWorkItems>

Paso 6: “Subir” la nueva definición

witadmin importcommonprocessconfig
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\CommonConfiguration.xml"


Atención: En el ejemplo del artículo de MSDN hay una entrada para el estado “New”, pero debemos eliminarla porque no existe ese estado en el template MSF for Agile 5.0.  Si omitimos ese cambio, obtendremos un error al ejecutar el comando witadmin importcommonprocessconfig


Paso 7: “Bajar” la definición de Bug para poder modificar el template y agregar el campo Activity

witadmin exportwitd
    /collection:CollectionURL
    /p:ProjectName
    /n:Bug
    /f:"DirectoryPath\Bug.xml"

Paso 8: Modificar la sección correspondiente para que quede como se muestra a continuación

<FIELD name="Activity" reportable="dimension" type="String" refname="Microsoft.VSTS.Common.Activity">
    <HELPTEXT>Type of work involved</HELPTEXT>
    <SUGGESTEDVALUES expanditems="true">
        <LISTITEM value="Development"/>
        <LISTITEM value="Requirements"/>
        <LISTITEM value="Design"/>
        <LISTITEM value="Testing"/>
        <LISTITEM value="Deployment"/>
        <LISTITEM value="Documentation"/>
    </SUGGESTEDVALUES>
</FIELD>

Paso 9: “Subir” la nueva definición

witadmin importwitd
    /collection:CollectionURL
    /p:ProjectName
    /f:"DirectoryPath\Bug.xml"


Aclaración: Si bien estamos agregando este campo a la definición del bug porque el bug ahora pertenece a la categoría TaskCategory (paso 1) y requiere de esta definición, no es necesario modificar el Layout de edición a menos que queramos tener acceso a ese campo al momento de editar un bug.


Conclusión

Como ven en la captura, ahora tenemos visibilidad de los Bugs en el board Agile, y además, se ve una nueva columna (Resolved) que muestra los bugs en ese estado. Por favor no tomen en cuenta el Burndown Chart, es sólo un proyecto para pruebas Smile

image
 
Si después de realizar todo el proceso, los bugs siguen sin aparecer, por favor revisen que estén vinculados a la respectiva User Story.

Hasta la próxima!

Tags: , ,

ALM | Gestión de Proyectos | TFS

Testing unitario y TDD con Visual Studio 2010

por Victor Passador  4. agosto 2011

“Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.” ExtremeProgramming.org

 

Un poco de contexto

Como generalmente sucede en todos los ámbitos, una de las cosas más difíciles de conseguir es el equilibrio, y la creación de Tests Unitarios no queda fuera de esta premisa.

Por un lado es imposible negar los beneficios que aporta contar con pruebas automatizadas, pero por otro lado también se hace difícil contradecir a aquellos que argumentan que es muy costoso su mantenimiento ante cambios en los requerimientos.

No es la idea de este post entrar en un debate interminable defendiendo una postura u otra, sólo me limitaré a decir que no somos fanáticos de los extremos y que si bien consideramos que es indispensable contar con un buen set de pruebas unitarias, tampoco perdemos de vista el costo de su mantenimiento y vamos adaptando el modelo según las necesidades y posibilidades.

Antes de ir directamente a la herramienta, repasemos algunas definiciones.

 

El ABC de las pruebas unitarias

Toda prueba unitaria que se precie de tal, deberá contar sí o sí con las siguientes características:

  • Ejecución rápida
  • Ambito limitado
  • Automatizable y repetible
  • Cualquiera puede ejecutarlo
  • Independiente
  • Alta cobertura de código

 

El ABC del TDD

En el Desarrollo Guiado por Pruebas (Test-Driven Development – TDD) se dice que no existe ningún motivo para escribir código salvo alguna prueba que esté fallando. Esto obliga (a modo de resumen) a trabajar con un ciclo de vida que incluye los siguientes pasos:

  • Ante cada nuevo requerimiento, escribir un test. El test inevitablemente fallará porque no hay código que implemente ese requerimiento todavía.
  • Escribir el código que pase el test. Se deben enfocar los recursos a que el test pase, sin preocuparse por cuestiones “superfluas” (.. del tipo “ya que estamos, agrego una sobrecarga que reciba tal parámetro porque probablemente lo necesite más adelante”). Tampoco por la elegancia del código. El único objetivo es que el test pase.
  • Refactorizar: Es aquí donde se modifca el código para mejorar cuestiones como mantenibilidad, limpieza de código duplicado, etc., sin afectar obviamente la funcionalidad. Esto se comprueba corriendo sucesivamente las pruebas (aquí se ve el beneficio de pruebas que se puedan ejecutar en poco tiempo).

 

Entrando ahora sí de lleno en la herramienta, veamos qué nos aporta en este sentido.

 

Ayudas en la edición de código

Como soporte a la práctica de TDD, Visual Studio 2010 cuenta con algunas funcionalidades orientadas a la mejora en la productividad en este ámbito:

Code Snippets: permiten rápidamente generar clases de test (“testc”) o métodos de test (“testm”)

imageimage

Al escribirse primero las pruebas, obviamente fallaran las referencias a las clases a testear, pero con la generación automática de código, se facilita la tarea de crear el esqueleto de esas clases:

image

image

Intellisense en modo Suggestion: En el modo al que estábamos acostumbrados a usar Intellisense (modo Completion), era fácil agregar una referencia a un tipo o variable existente, pero esto no es muy “TDD Friendly”. En VS2010 existe también el modo Suggestion (se activa con Ctrl+Alt+Space) que muestra, mientras estamos tipiando, un cuadro de texto sobre la lista de tipos sugeridos sin obligarnos a seleccionar ninguno.

image

Ejecución de pruebas unitarias

En cuanto a la ejecución de las pruebas unitarias, más allá de nuestro objetivo de ver muchos iconitos verdes, una de las metas buscadas es conseguir una alta cobertura de código. De nada sirve tener toda una batería de pruebas unitarias si estamos cubriendo (probando) menos de la mitad del código escrito.

La cobertura de código (Code Coverage) es una métrica importantísima que deberíamos obtener para poder certificar que nuestros casos de prueba están cubriendo la totalidad (o la mayor parte posible) del código de la aplicación.

Para habilitar los reportes de Code Coverage en VS2010 tenemos que modificar el archivo “Local.testsettings” y dentro de la opción “Data and Diagnostics” marcar el check correspondiente a “Code Coverage”

CodeCoverageSettings

Una vez ejecutadas las pruebas, en la ventana Code Coverage Results, podremos ver los porcentajes de ese indicador y a su vez, en el editor de código, ver resaltadas las líneas afectadas por la prueba.

CodeCoverageResults

Posts anteriores de esta serie:

Para ir calentando motores …

Contribuyendo a la mejora de calidad de software

Algunas referencias más:

http://geeks.ms/blogs/adiazmartin/archive/2010/01/12/m-225-s-r-225-pido-con-visual-studio-2010-intellisense-para-tdd.aspx

http://blogs.msdn.com/b/ukvsts/archive/2010/03/17/test-driven-development-with-visual-studio-2010.aspx

 

Hasta la próxima!

Tags: , ,

Testing | Visual Studio | ALM

ALM BootCamp–Video de las presentaciones

por Daniel Laco  23. mayo 2011

 

El pasado 28 de Abril participamos como oradores con Victor Passador en el ALM BootCamp en Microsoft Argentina.

También participaron Juan Pablo Díaz, Maxi Accotto y Eric Delahaye.

Aquí les dejo los videos de las presentaciones y que las disfruten !

 

Apertura - Juan Pablo Díaz:

 

 

Control de Versiones - Daniel Laco:

 

 

Versionado de Base de Datos - Maxi Accotto:

 

 

Arquitectura - Eric Delahaye:

 

 

Testing- Victor Passador:

 

 

Testing con VSTS 2010–Contribuyendo a la mejora de calidad de software

por Victor Passador  19. abril 2011

Como habíamos prometido, daremos inicio con este post a la serie de publicaciones con las que intentaremos mostrar de qué manera se puede incrementar la calidad del software que nuestra empresa produce, mejorando el proceso de testing en las diferentes formas que toma a lo largo del ciclo de vida de la aplicación.

Tipos de testing vs. herramientas de testing

En las primeras etapas del ciclo de vida de la aplicación, en aquellas donde se comienzan a implementar mayormente requerimientos no funcionales (APIs, frameworks, etc.), se requiere de un tipo de tester especializado, con altos conocimientos de programación, que genere casos de pruebas unitarias con un alto grado de automatización (cuando digo alto apunto al 100% de automatización)

A medida que las iteraciones avanzan y se empiezan a obtener las primeras piezas funcionales, aparece la necesidad de un testing totalmente diferente, opuesto, donde el tester necesita altos conocimientos del proceso de negocio y pocos o nulos conocimientos de programación.

Si trazáramos una línea, podríamos decir entonces que tenemos en una punta un testing de tipo “especializado”, con mayoría de casos de test automatizados construidos por expertos en programación, y en la otra punta un testing más “generalista” con gran cantidad de casos de test manuales a cargo de especialistas en el negocio en cuestión, con toda una escala de grises en el medio.

Generalista vs. Especialista 001

Según algunos estudios, se indica que la mayoría de las herramientas de apoyo al testing apuntan a la parte “especialista”, siendo que el grueso del esfuerzo que realiza la empresa se ubica en la parte “generalista”

Generalista vs. Especialista 002

VSTS 2010 como solución ALM ante la problemática del testing

Con este enfoque como guía, iremos mostrando en sucesivas entregas, de qué manera VSTS 2010 contribuye a la mejora del proceso de testing en todo el espectro.

Comenzaremos mostrando las herramientas que propone la solución de MS desde el extremo más especialista, hasta llegar al punto opuesto, abarcando los siguientes tópicos:

  • Testing unitario y las mejoras para aplicación de técnicas de TDD (Test Driven Development)
  • Intellitrace
  • Coded UI Test
  • Lab Management
  • Integración Continua

 

Hasta la próxima !

Tags: , , ,

ALM | TFS | Testing | Visual Studio

ALM Day 1–Exitósa jornada de ALM sobre Team Foundation Server

por Daniel Laco  3. marzo 2011

 

Ayer 2 de Marzo realizamos exitósamente el evento de ALM (Application Lifecycle Management) sobre TFS.

La jornada se desarrolló en las instalaciones del MUG.

La sala estaba completa, y la inscripción se completo varios días antes de las charlas.

Se pueden bajar las presentaciones aquí

Testing con VSTS 2010 – Para ir calentando motores …

por Victor Passador  18. febrero 2011

Estamos preparando una serie de post dedicados a testing con VSTS 2010 en las diferentes variantes en que se presenta a lo largo del ciclo de vida de la aplicación, y para ir introduciendo el tema quisiera dejarles unos links para que tengan a mano.

Se trata del blog de Mathew Aniyan, PM de Microsoft. En su blog, Mathew ha estado publicando una serie de Tips relacionado a lo que se conoce como Coded UI Test (Pruebas programáticas de Interfaz de Usuario).

Al momento de publicar este post, llegó hasta el N° 8, posteado con fecha enero/2010. Esperamos que retome la iniciativa y siga publicando más trucos.

Pueden ver la serie de tips aquí.

Saludos !

Tags: , , ,

ALM | TFS | Visual Studio | Testing

TFS 2010–”The server returned content type text/html, which is not supported” al hacer Get Latest Version

por Victor Passador  20. enero 2011

En realidad este error lo obtuvimos inicialmente al intentar encolar una build en un proyecto recientemente “trasplantado” desde otro servidor. Obviamente en el servidor de origen no había problemas.

Como era muy escasa la información registrada en los diferentes logs, investigamos un poco y nos dimos cuenta que el error ocurría cuando el build server intentaba descargar la propia definición del build (basada en el DefaultTemplate.xml) para hacer su trabajo. Podíamos obtener ese mismo error desde Visual Studio intentando descargar cualquier otro template de la carpeta BuildProcessTemplates del Source Control.

Sabiendo que no era un tema del build server sino algo más genérico, volvimos a buscar y apareció la solución. Hay que seguir estos pasos:

  • Detener IIS
  • Borrar la caché local del servidor TFS (buscar en C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\_tfs_data)
  • Reiniciar IIS

 

Voilà !!

Hasta la próxima !!

Tags: , , ,

ALM | TFS | Visual Studio | Build Automation

TFS y los productos de terceras partes (cont.)

por Victor Passador  3. enero 2011

Hace unos días publiqué un post donde mencionaba los recaudos mínimos que deberíamos considerar al momento de instalar algún Add-on para TFS (vale también para VS).

Como no quiero que me consideren “apocalíptico” ni mucho menos trataré, por un lado, de mostrar las herramientas que nosotros hemos instalado y utilizado largamente y que nos han facilitado la vida en muchas oportunidades (o que estamos testeando con TFS 2010). Por el otro, me gustaría que ustedes comenten acerca de las experiencias que han tenido para que este post sirva, de alguna manera, como referencia de las herramientas que todo administrador o usuario de TFS debiera tener en su toolkit.

Empiezo yo:

Administración General

  • Team Foundation Server Tools 2010: Un viejo conocido, en su versión para TFS 2010, que entre otras cosas incluye:
    • Alerts Explorer: UI gráfica que permite suscribirse a los diferentes eventos del servidor (cambio de un work-item, build terminado, nuevo check-in, etc.)
    • TFS Backups: administra un schedule para backups de la base de datos de configuración, de los proyectos de la colección, sharepoint (si se instaló con la integración de esa herramienta), reporting services (ídem)
    • Best Practices Analyzer: Verifica problemas de deploy, data usage, etc.
    • Pack de políticas de check-in
    • Mejoras para Team Explorer
    • Editor de Templates
  • Team Foundation Sidekicks: Excelente herramienta de Attrice que permite visualizar/administrar entre otras cosas:
    • Historial de archivos del Source Control
    • Status (cheched out, locks, etc.)
    • Workspaces
    • Labels
    • Etc.

 

Sidekicks

Seguridad

  • Team Foundation Server Administration Tool: Uno de los problemas recurrentes al administrar proyectos de TFS es el de configurar permisos de usuarios. Hay que administrar seguridad tanto en el servidor TFS, el servidor de reportes y el sitio Sharepoint, cada uno con sus particularidades. Esta herramienta permitirá hacerlo todo junto desde un mismo lugar

 

Templates

 

Visual Studio

  • Productivity Power Tools (no es puramente TFS, pero los programadores –y otros- agradecidos) 
    • Solution Navigator: Permite ver clases (y sus miembros) desde el Solution Explorer, con filtros para visualizar solamente archivos abiertos, sin grabar, etc., vistas previas, y más.
    • Tab Well UI: Permite más posibilidades de manejo de ventanas del IDE para uso con múltiples monitores, tabs fijos (para que no desaparezcan cuando hay muchos documentos abiertos), coloreo de tabs según ciertas condiciones (soporta expresiones regulares), etc.
    • Searchable Add Reference Dialog: Ahora podemos hacer búsquedas al agregar referencias a nuestro proyecto !
    • Y mucho más …

TFS Power Tools

Otros

 

Creo que tengo alguna otra más para compartir, pero les dejo la posta a Uds. …

Saludos !

Tags: , ,

ALM | Gestión de Proyectos | TFS

TFS y los productos de terceras partes

por Victor Passador  7. diciembre 2010

Me acabo de cruzar con un post de la gente de Urban Turtle, que me pareció muy interesante.

Habla de herramientas de terceras partes que extienden la funcionalidad de TFS.

Es cada vez mayor la cantidad de herramientas que aparecen en la web que se valen de la extensibilidad que brinda TFS y que proponen complementar y/o optimizar los diferentes aspectos que cubre la solución ALM de MS (además, no sería loco pensar que esta tendencia se vaya acentuando con cada nueva versión de la plataforma).

Si bien esto supone un gran beneficio, aunque más no sea por la cantidad y variedad de la oferta, me pareció interesante difundir algunos de los cuidados que según Mario Cardinal (y quien suscribe) deberíamos tener al momento de elegir alguna de estas herramientas. Todo esto sin mencionar cuestiones de costos por licenciamiento, sólo enfocándonos en cuestiones más bien técnicas.

Antes de que sigan leyendo vale una aclaración. Yo sé que muchos van a pensar que la mayoría de estas cuestiones son más que obvias, pero también sé que ante alguna necesidad concreta de esas que queman, no tenemos demasiado tiempo para andar pensando a mediano o largo plazo y se vuelve muy tentador instalar alguna solución para salir rápidamente del escollo.

Propongo que nos detengamos un minuto y hagamos una checklist que incluya, al menos, alguno de estos puntos:

Soporte

  • Qué tipo de soporte se ofrece?
  • Cuándo fue publicada la última versión? Cada cuanto se publican? Sigue en Beta?
  • Está disponible el código fuente?

Evolución de la plataforma ALM

  • Será fácil migrar cuando aparezca la próxima versión de TFS? (aquel que pueda responder este tipo de preguntas rápidamente, que por favor se contacte por privado porque necesito que me preste la bola de cristal por algunos días)

Relación con el servidor TFS

  • Modifica el esquema de Base de Datos de TFS?
  • Requiere modificación de los templates de proyectos ya creados?
  • Tengo varios proyectos creados con diferentes templates, alguno de ellos personalizado. Se adapta a todos los proyectos?.
  • Y a todos los tipos de Work Item?
  • Tengo varios proyectos, en diferentes versiones de TFS. Aplica a todas las versiones?
  • Qué impacto tiene el hecho de que esa herramienta no aplique para todos mis proyectos y/o versiones de TFS?
  • Qué pasa con el Data Warehouse y con los reportes ?
  • Los que ya están van a seguir funcionando?

 

Deployment y mantenibilidad

  • Sirve para cualquier proyecto que ya esté en marcha o sólo para nuevos proyectos?
  • Requiere instalar algún componente en los clientes?
  • Qué tan compleja es esta instalación?
  • Qué tipo de desarrollos soporta (Winform, Web, WPF, etc.) ?

 

Localization

  • Es compatible con la configuración de mi servidor TFS?
  • Y con la configuración de Collation de mi SQL Server?

 

Verifiquemos por favor que en lugar de encontrar una solución no estemos encontrando un nuevo problema.

Saludos !

Tags: ,

ALM | TFS

Reportes Agiles en Team Foundation Server – Stories Progress Report

por Viviana Chelini  25. noviembre 2010
Última entrega sobre comentarios de reportes ágiles, debajo está la lista de comentarios que hemos ido realizando:

Bug Status Report

Bug Trend Report

Reactivation Report

Build Quality Indicators Report

Burndown and Burn Rate Report

Remaining Work Report

Status on All Iterations Report

Stories Overview Report

 

Stories Progress Report

 

Información que proporciona el reporte

El reporte de Progreso de los Casos de Uso muestra el estado de realización determinado por las tareas definidas para implementar el mismo.

 

Este informe muestra para cada caso de uso, la siguiente información:

 

  • Progreso (% completado): valor numérico que representa el porcentaje de trabajo completado.
  • Horas completadas: representación visual de las horas completadas, que se muestra como una barra de color verde oscuro.
  • Completado recientemente: representación visual de las horas completadas en el intervalo de tiempo especificado para Días recientes (calendario), que se muestra como una barra de color verde claro.
  • Horas restantes: Horas restantes correspondientes a todas las tareas vinculadas al caso de uso o sus casos secundarios.

 

Para que el reporte sea fiable se deben de alimentar correctamente los siguientes parámetros de los elementos de trabajo:

  • Definir los casos de uso y las tareas, crear un vínculo Secundario de cada tarea al caso que implementa y crear un vínculo Secundario de las subtareas a su tarea primaria.
  • Definir y actualizar los campos Completado y Restante para cada tarea o subtarea durante la iteración o el lanzamiento.
  • Especificar las rutas de acceso de Iteración y Área para cada caso y tarea.

Análisis del reporte

El reporte permite visualizar el volumen de trabajo realizado por el equipo durante la última semana o un período de tiempo reciente. Se puede encontrar respuestas a las siguientes preguntas:

  • ¿En qué casos el equipo progresó y cuáles están a punto de completarse?
  • ¿En qué casos no ha trabajado el equipo?
  • ¿A qué casos de uso les queda el mayor volumen de trabajo para completarse?
  • ¿Hay trabajo bloqueado en algún caso?

    Los casos que no muestran una banda de color verde claro en la barra de progreso pueden indicar un problema de bloqueo.

  • ¿Se puede entregar todo lo que se ha planeado? ¿Qué objetivos se deben suprimir y cuáles deben ser objeto de un cambio de ámbito?

 

Versión positiva del reporte

Un reporte positivo muestra que el equipo ha completado recientemente trabajo (color verde claro) en todos los casos que se espera estén en curso.

Versión negativa del reporte

Un reporte negativo podría mostrar una o más de los siguientes indicadores:

  • No se muestra trabajo en uno o varios casos.

    Los casos con 0% de progreso o 0 horas restantes no tienen definido esfuerzo previsto ni tareas para ellos.

  • Muchos casos de uso no tienen trabajo completado recientemente.

    Cuando varios casos indican ningún volumen o volúmenes muy pequeños de trabajo completado, el progreso del equipo es lento.

 

Acerca de los Autores

Este es el blog del equipo de VEMN SA 
Presentaremos temas que nos parezcan de interés sobre tecnología .NET, Procesos y Metodologías y todo aquello relacionado con el proceso de desarrollo de Software

Month List

BlogRoll

Download OPML file OPML