Sample VSTS Build and Release Management task for Yarn package manager

During this weekend I wanted to try the new package manager Facebook created: Yarn, one of it’s bigger claims is to be faster than normal npm, although it uses the same package repositories as npm. this is done, as far as I know, using improvements in transfer the files along with a local package cache, so you don’t have to go always to npm to restore a package you already restored previously for other project.

As locally it was everything working smoothly, I decided create a new build task for VSTS so I can use it in my builds. First point it is only based to be used with your own agents for several reasons: first it has a demand which requires yarn to be installed (hosted agents does not have it … yet …), second, as said previously it uses a local cache to be faster, so at this moment, it made no sense to me to prepare something to be used with hosted agents, remember hosted agents are created on-the-fly so unless you need to restore packages for  several projects per build (next scenario I will try to cover), Yarn will be not necessary (well I agree it also improves download speed, but …).

So, for this first version, I just looked at the code of the current npm task and modified it to use Yarn, it is pretty simple and straightforward. The code is in my github account:

Feel free to see it, modify it, play with it and install it, I will be reviewing it for some improvements.

PD: Just as I was writing this post, I noticed something I should have look before … There is already a Yarn task in the Marketplace, hehehe, as I mention in my talk about creating custom tasks: always look if there is something available before build it … so well .. my fault … but, still, I will continue trying to improve it.

Creating custom tasks for VSTS Team Build and Release Management slides

Recently I gave a talk a out creating custom tasks for Team Build and Release Management for VSTS and also for Team Foundation Server, as also I’m starting again to write here (with lots of articles at first with ideas I had in my mind) I thought it also could be a good idea to leave links to content here.

It is in Spanish, but well, there is a bunch of useful links in the PPTX. It was mainly based on creating tasks with Javascript but I cover also Typescript (well both of them are Javascript executed with NodeJS at the end of the day) and PowerShell.

So here are the slides:

And also the source code used in the demos, it was a very basic set of tasks for .NET Core projects to restore packages, build and publish:
Have fun.

Configure Work Item Field as team field in Team Foundation Server

Recently, working on a customer, due to the teams and project structure they have, and the reporting needs for this structure (a correct structure BTW), we came to a situation in which dividing the Teams by areas was not so useful, and didn’t helped us in our work item and reports strategy, as you probably already have observed, it is not so easy to create the reports per team with complex structures, as areas are tree views.

So I came up to this article, which helped in creating a Work Item field to define the teams, I found it very useful for this and other situations, being honest, I find this even more comfortable than using areas for this.

For what is coming in this blog post I assume you already have knowledge about how to divide the work between teams in the same Team Project and feel comfortable with TFS Work Items personalization’s. Also this article is entirely based on Team Foundation Server On Premises.

Basically the procedure (go to the article for the details) is:

  1. Define a Global List for your list of teams.
  2. Add a new field for Features, Epics (the article doesn’t mention this first two but we also added to them=, Product Backlog Items, Bugs, Tasks and Test Plans. At the end of the day, any Work Item type which can be used to work in backlogs. It is important to define the field with the same name in all Work Item Types, and also be sure to make this reportable as dimension if you plan to use it in Reporting.
  3. Specify this field to have values from the Teams Global List as allowed values.
  4. Use witadmin command line tool to export the process, and modify the process to specify the new field as the field defining the team the work item belongs to. (<TypeField refname=»MyCompany.Team» type=»Team» />).

When you go to admin your Team Project (all of this is done at Project Level) you will see the possibility to define the value for the new field for each Team, so the backlogs and panels are filtered correctly.Make sure to specify this value for all of your teams, if you don’t do it, you will receive alerts about your team is not correctly configured. Also remember a particular team in TFS can own different values for this field, which is particularly useful for Product Owners views or management views.


Also, there is another point in the article, which allows you to be able to specify the team you want the Work Item to belong during its creation from the Product Backlog view, something like the next image. But this configuration brought me a small problem, when someone from within a team, selects to create the Work Item for a different team, the backlog view produces an error as is it weren’t able to save the Work Item, so I disabled this configuration.


And as for final conclusion of this, well I haven’t been still a lot of time with this solution in production let’s say, but at this moment I find it very useful, as it allows me to improves some reports and Queries so I can clearly see the team a work Item belongs to, without any trick to truncate the area path or something to make the information easy to filter and more readable, specially in reports.

If you are going to need this or you will follow this article, please, test it thoroughly before going live, customizations in Work Items are always tricky, and specially in this level in which we are modifying the default behavior of TFS.

Also I tested it in a TFS “15” preview environment, and it also worked successfully as expected, so going forward to next version of TFS is expected to work.

Code Search extension for VSTS and Team Foundation Server “15”

Recently Microsoft put as Generally Available a very interesting extension in the Visual Studio Marketplace, the Code Search extension. Install it on your VSTS is as simple as go to the previous link and click install, then select the Visual Studio Team Services account in which you want to install the extension, of course you need to be an Administrator to install it.

To install on Team Foundation Server “15”, is just as simple as install it during the installation phase of TFS.


But, what enables this extension? Once you install it, on your team projects you will have, in the menu bar, a search box in which you can select to search code:



When you select code, you will be presented some of the main options to search for code.

But there are even more options you can check in the help page.

The interesting thing of this Code Search extension, is it not only look for text inside the code files, that would be easy, it searches  across all projects or just the ones  you want.

But it also allows you to put filters like for example look only for classes named like the term you are looking for, or comments, references and a lot of more, I’m really impressed on how rich it is. Of course you can refine your queries with AND, OR, NOT terms.

Also it integrates with history, so when you find what you are looking for, you can see its history, compare with previous versions, and you can even see annotations within the code.

Just as a conclusion a pretty nice extension you can start installing and using on your VSTS to search for code, but far beyond the usual look in files functionality.

As technology it uses in the behind, if you look here you will see it uses:

  • Elasticsearch
  • Oracle Server JRE, yes for TFS you will need to install it on the server, but you can install Code Search on a separate server. Of course for VSTS you don’t need to care about this.
  • Mardowndeep.
  • Roslyn (hype increasing on this one)

And about languages it supports, currently it supports C#, C++, C, VB.NET, and recently they added support for Java also, and it is ok to think they will be updating the list of languages.

So go ahead, install it and try it, you can find more options and documentation here.

I’m back! Executing Entity Framework migrations from VSTS Release Management

Uff there has been a long, long time since last time I wrote here … but, several people have lately asked me about my blog, so there I go, and better than write a bla bla article about the last time and why I haven’t wrote so much, let’s get technical.

In this article I assume you have the basic knowledge of creating Team Build definitions, and Release Management definitions. I’m not covering this topics in this article, as it would make it so long to read. If you are not familiar with this, I would recommend you to read about it here

When we are deploying applications with a database, there are several ways we can do, usually we will deploy differential scripts to update the DB, or DACPAC and other technologies, but we can also use Entity Framework migrations, although I still have to think if it is the best way to do it …

Usually migrations are executed Entity Framework initializers, but if we need to execute them before deployment, so we can be sure we updated the DB even before deploy our application, there is a tool named “migrate.exe” included in the NuGet package of Entity Framework.

There is a couple of steps we need to take to be able to execute this tool from Release Manage:

  1. Build our migrations Assembly
  2. Copy the tool migrate.exe from the tools folder in the EF Nuget package folder to the same directory as the migrations assembly
  3. Execute migrations

Let’s go with the first two steps, which we will do in a Team Build definition which publishes the results, as artifacts, to the Release Management definition. The build step is easy, usually our migrations assembly will be included in the Solution we are building to deploy our application, if not, well include it in the solution or build it in a separate build step in the same build definition, no tricks in this one.

Copy the migrate.exe tool includes a couple more of steps. First I would copy the result binaries from building the migration project to a separate folder we will publish as an artifact. This is done with a Copy task in the build steps, which we will configure this way:


The parameters:

  • Source folder: we point to the binaries result of our migration assembly, notice I have oversimplified the directory, with /MigrationAssembly/ be sure to include the full path to it. And I have used a couple of variables $(build.sourcesdirectory) a system variable which points to the root of sources downloaded by the agent, and a custom variable $(buildConfiguration) which points to the current build configuration (i.e.: Debug, Release or whatever you use).
  • Contents: ** so we copy all results.
  • Target folder: I’m copying to a new folder automatically created in the artifacts staging directory, as configured with the system variable $(build.artifactstagingdirectory), you don’t need to create a complex folder structure under this one, but be sure to at least create a folder structure which allows you to separate different results and artifacts.

Next step, copy the migrate.exe file, again we use a copy task:


With the parameters:

  • Source folder: we point to NuGet packages folder, which is usually at the same level of the solution we are building, but be sure to check this correctly, probably this path is one of the trickiest paths of this configuration.
  • Contents: “migrate.exe” well, no comments …
  • Target folder: I’m copying to a the same folder we copied the results of the migration assembly in the previous step. This is very important for all of this work, so be sure to check it twice.

And the last step in the build, publish the artifacts, usually as simple as this one, which will publish all the folder structure we have in the artifacts directory to a server artifact:


Final steps will be seen like this:


Once we have done this, we can queue this build definition, and once finished, in the resulting artifacts just check you have your binaries from the assembly migration along with the migrate.exe tool in the same folder within the artifacts.

For the Release to execute the migrate.exe file it is just a simple task of execute a command line, of course one gotcha of this is to link the build definition with the Release Management definition (again, I assume you are already familiar with this).

So within the desired environment of our Release definition, we will just add a Run on agent task of type Run script, one important point, remember this tasks runs on the agent, so you need to ensure your agent can communicate with your SQL Server or SQL Azure.

We will configure this task in this way, before the deploying task for the application:


The parameters we are using:

  • Path: here we configured the path to migrate.exe within the build artifacts we are using, you can take advantage of the “…” button to look for it, again, remember: you must have linked your Release Management definition to your Build definition for this to be available.
  • Arguments: there is different arguments you can use here, even just point to a *.config file with all the values (check full documentation), in this case I just pointed to a custom variable containing the connection string (be sure to make it secret to protect it hehe), and as I pointed to a connection string, it is mandatory to configure the parameter of “Connectionprovidername”, which in my case is just SQL Server.

Some important gotchas here, be sure to test thoroughly your migrations, and be sure to enable the appropriate backups of databases for the rollback cases, this is not easy, and you have to really take care about it, so have different environments of Release Management for test all the deployments and migrations.

Once you have this, next  time you run this Build and Release definition, your database will be (hopefully if you have done it correctly) updated to last migration from Entity Framework.

And hopefully, see you later around here with more articles Smile

[TFService] ¿Dónde está el panel Kanban?

Buenas, ni voy a comentar el tiempo que hace que no escribo …. al tema.

Desde que se empezó a hablar del nuevo panel Kanban de Team Foundation Service, hay una pregunta que ya me han hecho varias veces ¿dónde está la plantilla de proyectos con el panel de Kanban? , y la respuesta es, en ningún sitio Sonrisa.

Efectivamente el panel de Kanban NO es una plantilla nueva, es un nuevo panel que está en Team Foundation Service y en Team Foundation Server 2012 Update 1 (sí, necesitáis el Update 1 de TFS 2012), y acceder es bien sencillo, desde la página principal del panel web de un Team Project, podemos, en la parte de la derecha, bajo Activities, acceder al Backlog:

Backlog TFSService

Una vez accedemos al backlog podemos acceder al Board, dónde encontraremos el panel Kanban.


Una vez en el panel Kanban, podemos comprobar que podemos personalizar el número de elementos WIP de las swimlanes de Active y Resolved, y eso es todo, ya podemos empezar a usar nuestro panel Kanban ,moviendo elementos entre las swimlanes, una cosa que yo echo de menos es el poder reordenarlas en cuanto a prioridad por cierto … quizá lo veamos en futuros updates. También, en la esquina superior derecha, podemos pulsar y obtener el informe de Cumulative Flow, o lo que es lo mismo el flujo de trabajo que hemos ido realizando y que tenemos en cada uno de los estados.


Así que ya sabéis dónde tenéis el panel Kanban Sonrisa

Novedades en Windows Azure y la importancia del ciclo de vida

La semana pasada, el 7 de junio, Scott Guthrie anunció las novedades de Windows Azure, y entre otras muchas cosas que me encantaron se aunciaron un par de cosas que a mi personalmente me pareceron muy interesantes:

  • Apertura a prácticamente cualquier plataforma para usar los servicios de la nube, con SDK, open-source, y así poder usar tecnologías como node.js, java, php, incluso en servidores Linux.
  • Integración con Git y TFS, para soportar la publicación directa.

La apertura a nuevas plataformas, me parece muy importante e interesante. Cada vez hay más base de desarrolladores no ya en un entorno o en otro, si no en entornos de desarrollo heterogéneos, para esto es de vital importancia contar con herramientas que faciliten la vida al equipo de desarrollo y no solo a ellos, también a los responsables de los sistemas.

Esto dentro de la tan comentada ahora DevOps es vital, los ciclos de desarrollo se acortan a medida que los equipos cada vez son más ágiles, y esto plantea nuevos retos de mantener los sistemas al día y controlar los despliegues. Aquí entra la nube (Windows Azure por ejemplo) que nos permite una mayor flexibilidad a la hora de crecer y escalar nuestros servicios, así como a la hora de facilitar el mantenimiento de los sistemas, pudiendo olvidarnos de cosas como infraestructura física de los servidores, sistemas de redes, y concentrándonos en lo que nos aporta valor, nuestros servicios a los clientes.

También aquí entra el segundo punto, la integración con Git y TFS para soportar la publicación de nuestras aplicaciones en un entorno de entrega continua. Muy importante también por la misma razón, el negocio del software se mueve cada vez más deprisa, y cada vez vemos más aplicaciones que sacan versiones más frecuentes, tenemos que estar preparados para esto, responder rápidamente ante nuevas necesidades de negocio.

Por supuesto esto no es “gratis” necesitamos procesos, herramientas, y un equipo totalmente centrado en la calidad y el valor del software que vamos a desplegar. De nada nos vale sacar versiones frecuentes si estas no funcionan, no cumplen con las expectativas de los usuarios, o nos resultan imposibles de mantener a lo largo de su vida.

Aquí es dónde cobran mayor importancia todos nuestros procesos de ciclo de vida, y por encima de todos ellos, nuestra implicación y responsabilidad como equipo en obtener la mayor calidad en nuestro software.

En definitiva, tiempos interesantes están llegando a todos los niveles, y que creo que van a ser muy divertidos y desafiantes para todos los que nos gusta nuestra profesión.

Gestión de dependencias de proyectos con Visual Studio y Team Foundation Server

Cuando abordamos un proyecto de desarrollo de software, casi invariablemente, vamos a tener referencias externas. Estas referencias pueden ser de otras compañías, como puedan ser componentes tipo Entity Framework, Unity, Log4Net, ELMAH, etc. estas referencias, en el caso de Visual Studio, lo tenemos resuelto mediante NuGet, que casi seguro que todos conocéis, y que facilita la vida a la hora de compilaciones automatizadas, despliegues, y montar los entornos de desarrollo.

Sin embargo, cuando hablamos de dependencias de nuestros propios componentes la cosa a veces se complica más, ya que son componentes que frencuentemente tienen unos ciclos de despliegue más cortos, teniendo nuevas versiones más rápido. Así mismo nos tenemos que asegurar, que al obtener las dependencias durante las compilaciones y despliegues, sea las versiones correctas.

A pesar de que en algunos entornos nos encontramos con soluciones como parpetas compartidas de referencias, ramas de control de código fuente con las dependencias, si bien en un modo básico esto puede llegar a funcionar, siempre estamos añadiendo un trabajo extra a la hora de montar los entornos, y lo que es más importante, a la hora de asegurar que durante el desarrollo, compilación y despliegue, estemos usando la versión correcta.

Para solucionar estos problemas, del modo más eficiente y automático posible, os propongo dos distintas aproximaciones:

AIT Dependency Manager

Esta extensión de Visual Studio, desarrollada por los MVP de Visual Studio Neno Loje y Sven Huberth, nos permite crear ficheros Xml de configuración de dependencias, que nos permite traer las dependencias de: control de código fuente, resultados de una Team Build, carpetas compartidas.

Los ficheros de configuración son de este estilo:

<Dependency Type="BinaryDependency">
<Provider Type = "BuildResult">
<Settings Type="BuildResultSettings">
<Setting Name="TeamProjectName" Value="DemoScrum" />
<Setting Name="BuildDefinition" Value="SolutionRefs" />
<Setting Name="BuildNumber" Value="SolutionRefs_20120305.2" />
<Setting Name="RelativeOutputPath" Value=".Lib"/>

También, mediante otro componente desarrollado por ellos, nos permite usar unas plantillas de Team Build personalizadas, para poder interpretar y resolver las dependencias en las compilaciones automatizadas.

La verdad es que el componente funciona bastante bien (aún tiene algunos defectos), pero la principal dificultad que he encontrado es el desplegar el componente en todas las máquinas, configurar las definiciones de build con ese componente adicional, en definitiva, una configuración inicial bastante manual, y tediosa. ¿Por qué investigué esta opción? inicialmente por hacer de beta tester Smile

Por ello, mi recomendación va más por la siguiente opción:

Servidor propio de NuGet

Al igual que podemos usar dependencias de terceros desde NuGet, también podemos montar nuestro propio servidor NuGet, y la verdad es que me ha, hasta sorprendido, la “sencillez” de montarlo.

Todo lo que tenemos que hacer es crearnos en Visual Studio un proyecto ASP.NET vacío, e instalar, desde el propio NuGet el paquete NuGet.Server, esto configurará el sitio web con todo lo necesario para albergar nuestro servidor propio de NuGet, creando, dentro de el, un directorio “Packages” por defecto, que será donde dejaremos nuestros paquetes propios *.nupkg. Este sitio web lo desplegaremos a cualquier servidor de IIS coroporativo que tengamos.

El siguiente paso es, en nuestros Visual Studio, configurar nuestro servidor NuGet como una fuente de confianza, esto lo hacemos desde Tools / Options en Visual Studio, si, aquí también tenemos configuración, pero de un modo bastante más estándar e integrado.

A partir de aquí, cuando vayamos a agregar nuevas dependencias, via NuGet, podremos explorar las que hayamos agregado a nuestro servidor corporativo, ya sean nuestras o de terceros, creando de este modo el servidor de dependencias estándar.

Por supuesto, tenemos un modo de publicar nuestros paquetes como dependencias directamente desde Team Build, para esto os recomiendo este componente:, y por supuesto revisad la documentación de como crear un paquete NuGet y todo lo que nos permite como ejecución de PowerShell de configuración de proyectos (algo que no tenemos con la primera opción).

En definitiva, también tiene algo de trabajo de configuración, pero de un modo mucho más estándar dentro del propio Visual Studio, basándonos en algo que casi todo desarrollador de Visual Studio conoce como es NuGet.


Ya no tenéis excusa para empezar a tener un buen ciclo de vida de vuestras dependencias, mi recomendación como ya os he dicho es la creación de vuestro propio servidor de NuGet, pero si esto no es posible, la primera opción os puede ayudar bastante.

Así que ya sabéis, si queréis gestionar vuestras dependencias entre proyectos, aquí tenéis una base, que seguro os iremos contando en próximos artículos más detalladamente.

[Windows8] He actualizado a Windows 8 y ¿dónde se han ido mis aplicaciones?

Buenas, seguro que muchos de vosotros habréis hecho una instalación limpia de la Consumer Preview (Beta) de Windows 8, pero algunos inconscientes valientes, hemos hecho una actualización de nuestro Windows 7.

Después de actualizar a Windows 8, en el inicio lo primero que vemos es el nuevo panel:


Y nos damos cuenta de que no aparecen todas las aplicaciones que ya teníamos instaladas, con lo que nos vamos al escritorio antiguo, y vemos con más sorpresa que nuestro antiguo amigo, el botón de inicio, ya no está … ¿y mis apps? miedo, terror, pánico.

Bueno, nuestras apps siguen ahí, pero un poco escondidas, si en el nuevo panel, en cualquier parte que no hay aplicaciones, pulsamos botón derecho, veremos como en la parte inferior nos aparece esto:


Si pulsamos en ese All apps, nos vamos a un nuevo panel en el que tenemos toas las aplicaciones que ya teníamos instaladas y desde el que podremos ejecutarlas. Pero hay más, si en el nuevo panel, directamente, nos ponemos a escribir, automáticamente nos aparecerá la nueva pantalla de búsqueda a la derecha, que buscará la aplicación que queremos lanzar entre todas las nuevas y las antiguas.

Y mejor aún, si cuando hemos localizado la aplicación que queríamos ejecutar, pulsamos botón derecho sobre ella, en la parte inferior nos aparecen estas nuevas opciones:


Entre las que tenemos la opción “Pin to start” que nos permitirá agregar un nuevo Tile para lanzar esa aplicación desde el nuevo panel de aplicaciones.

La verdad, me encanta el nuevo interterfaz Metro de Windows 8, tiene un montón de nuevas opciones a probar.

Por cierto, todo esto lo descubrí durante el MVP Summit, junto al gran Unai Zorrilla, competidor, pero ante todo amigoSmile

Feedback frecuente en tu ciclo de desarrollo. Visual Studio 11 Feedback Manager

Todos sabemos que uno de los valores de las metodologías ágiles es la entrega frecuente que software que aporte valor. Para esto, a parte de otros valores como transparencia y comunicación, y relacionado con esto, es la colaboración, en forma de feedback frecuente.

El feedback es fundamental, especialmente en ciclos de desarrollo cortos, recordad que en el software no es lo mismo que funcione, que el que entregue valor, y que podamos realizar la mejora constante. Por ello necesitamos feedback, información que nos puedan proporcionar las partes interesadas en la aplicación (comunmente Product Owners y stakeholders). Este feedback nos tiene que proporcionar ideas, mejoras, nuevas funcionalidades, que podamos añadir a nuestra aplicación, y que hagan que mejore la experiencia de usuario, que ganemos nueva cuota de mercado, mayor competitividad, recordad,  ciclos de desarrollo cortos, que nos permitan ser ágiles ante estos cambios.

¿cuándo recogemos este Feedback?, hay muchos puntos del ciclo de desarrollo. Vamos a ver algunos.

El primero de ellos puede ser justo después del primer prototipo o storyboard, a partir de ese momento ya podemos empezar, con esos proptotipos a recibir feedback, para asegurar que vamos en el camino adecuado, y evitar la típica situación en la que lo que acabamos teniendo no es lo que habíamos descrito con el cliente en un principio.

Por supuesto durante el sprint, que vayamos a entregar software que sea potencialmente entregable al fin de la iteración, no quiere decir que durante la misma no podamos ir entregando partes o enseñando partes de lo que hemos construido, recordad que en las metodologías ágiles tampoco tenemos que caer en un modelo mini-waterfall, y que tenemos que intentar llevar siempre a cabo procesos de entrega contínua. No hay que olvidar que este tipo de proceso, requiere que impliquemos de un modo constante a todas las partes del proyecto, que si bien es lo ideal, no siempre se puede conseguir, y también hay que tener claros los objetivos de ese feedback, cuando se implementará y como nos afectará, esto no es fácil en cualquier caso.

Terminaré con otro punto fundamental de feedback, en Scrum tenemos la Sprint Review, que precisamente es esto, una reunión dónde vamos a tener feedback sobre lo que se ha entregado (recordad que no es una demo), que nos siente las bases de por dónde vamos a continuar.

Y ahora que tenemos clara la importancia del feedback ¿cómo lo gestionamos?, con la llegada de Visual Studio 11, tenemos una nueva herramienta, el Feedback Manager, que nos va a permitir realizar este proceso.

Esta herramienta, basada en parte en Microsoft Test Manager, y la nueva herramienta de exploratory testing, nos va a permitir ejecutar sesiones de feedback, y almacenar los resultados en forma de Work Items.

En la imagen podéis ver el aspecto general de la herramienta en ejecución, que nos permite, mientras que exploramos la aplicación de la que queremos dar feedback, agregar comentarios, realizar capturas de pantalla, etc.


Además durante la ejecución podremos grabar vídeo, y audio, para poder ir haciendo comentarios a la vez que ejecutamos la aplicación de la que queremos dar feedback.

Este feedback, se puede realizar de modo general, simplemente arrancando el Feedback Manager y empezando a probar la aplicación, o bien, podemos, desde Team Foundation Server 11, solicitar feedback para un requisito o historia de usuario. Con este último sistema, a través de la aplicación web de TFS 11, se generará un Work Item de petición de feedback, asociado al requisito, y se enviará una notificación por correo electrónico, al usuario al que solicitemos feedback.

Una vez que el usuario termina de generar el feedback, ya sea general o asociado a un requisito, este ser almacena, con todos sus comentarios, vídeo, audio e incluso valoración (de 1 a 5), acerca de la aplicación. Esta información se almacena en forma de Work Item, que en el caso de ser feedback sobre un requisito, se asocia a ese requisito.

Con lo que este feedback estará disponible para las personas que tengan acceso a los Work Items del proyecto, quedando todo perfectamente accesible, y facilitando la comunicación.

En definitiva, recordad que es muy importante la gestión del feedback, en todos los momentos del proyecto, y por supuesto, toda la información que podamos proporcionar de feedback, aportará valor a nuestro ciclo de desarrollo de software.


Luis Fraile  @Globe ALM