Code control in Team Foundation Server 2010 with Windows Explorer

Hello,  somedays ago I was asked in twitter about connecting to Team Foundation Server without Visual Studio 2010 installed, and one of the simplest options is to use the TFS Power Tools September 2010

http://visualstudiogallery.msdn.microsoft.com/en-us/c255a1e4-04ba-4f68-8f4e-cd473d6b971f http://visualstudiogallery.msdn.microsoft.com/en-us/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

But, be careful, , these Power Tools, despite being developed by Microsoft, we have no official support for them, and also need at least Team Explorer 2010 installed on the machine.

Once downloaded the Power Tools, we will install it on our machine, with the typical installation is sufficient and we need to install the component.

SNAGHTML166c2a

Once installed, on the final screen we will an alert that warns us about we have to logoff and logon (and in some cases restart) again to activate the extension, so you know logoff and logon, or restart.

Are we back? Well, now, if we open in Windows Explorer any of the directories that we had connected through a workspace  of Team Foundation Server, and click right mouse button on any file or directory, we have the following menu:

image

That as you see we can work with source control without opening the Visual Studio 2010.

Easy right?

Another option is to use the Teamprise, Team Explorer Everywhere 2010, but that is for another post …

Una pequeña actualización

Hola a todos, os escribo este post para poneros un poco al día, ya que estoy planteándome a empezar a escribir en inglés, por diferentes motivos, el principal por practicar también el inglés a la hora de exponer contenidos. Si ya se que muchos pensaréis que si ya escribía poco en castellano ahora va a ser peor, pues puede ser, pero voy a probar.

La temática será la misma que hasta ahora, con la diferencia de que seguiré escribiendo en castellano en http://geeks.ms/blogs/lfraile y en inglés en http://www.lfraile.net, el feed actual, y al que supongo que algunos (espero que todos) estaréis suscritos no cambia, con lo que no tendréis problemas, si alguno quiere seguirme en el inglés, será este.

Y la verdad es que poco más voy a ver si preparo un primer post, orientado hacía mi antiguro artículo de las 12 reglas de Spolsky (número 57 de la revista DotNetMania en marzo del 2009) y lo que comentaba el compañero Bruno hace poco.

Así que os dejo hasta dentro de poco … espero.

[Evento] Developers, developers, developers y Visual Studio 2010 en Mallorca

Pues nada me voy casi de gira como quién dice, y el jueves estaré en Mallorca para hablar sobre las novedades para desarrolladores en Visual Studio 2010 y Team Foundation server 2010.

La charla estará centrada principalmente en los nuevos aspectos, que nos ayudarán a mejorar la calidad de nuestros desarrollos, temas como pruebas unitarias, análisis de código estático, code profiling, integración contínua, y lo que surja.

Si estáis por Mallorca el jueves de 19:00 a 20:00 estáis invitados a venir, para registraros aquí tenéis la URL (el abstract está mal … mea culpa):

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032467702&Culture=es-ES

¿A qué huele Scrum?

Cómo ya vengo comentando últimamente, cada vez hay más hype, o como lo queráis llamar con el tema de metodologías ágiles, y más concretamente Scrum, y la verdad es que cada vez que hablo de Scrum, más hay que poner énfasis en los valores de Scrum.

La gente, en algunas ocasiones, se pierde en el tema de las prácticas de Scrum, que si, que por si solas nos ayudan, y bastante, a organizarnos y centrar el trabajo, pero Scrum es más que eso, y lo realmente importante para mi son sus valores, la esencia que podríamos decir en el plano filosófico trascendental.

Lo primero, y algo que Rodrigo Corral no se cansará de decir, es que es una metodología empírica, esto es, tenemos que estar constantemente inspeccionando y adaptando nuestras decisiones y los procesos en tiempo real, basándonos en datos actuales y respondiendo rápidamente a las condiciones cambiantes del entorno. Esto es básico en todas las metodologías ágiles, ya sabéis, responder a los cambios antes que simplemente seguir los planes a ciegas.

¿Para qué vamos a dar soluciones a problemas que no tenemos?, esto es, partiendo de lo anterior, tenemos que estar atentos a los posibles problemas que nos vayan a surgir, por supuesto, pero hemos de ser flexibles, de nada nos vale intentar dar solución aun problema que nos puede surgir dentro de 3 meses, cuando no sabemos como el entorno va a evolucionar en estos 3 meses. Esto está muy relacionado con, por ejemplo, la arquitectura de las soluciones, en las que muchas veces el Big Upfront Design nos da como resultado una arquitectur totalmente inflexible, que no da respuesta ni aa los problemas actuales, ni a los que no conocemos aún que tenemos.

Muy importante en Scrum, y algo que no me cansaré de insistir, es la auto-organización, es básico, cuando acometemos un sprint es un compromiso (otro de los valores fundamentales), que adquirimos como equipo. Por tanto es importante conceder al equippo la capacidd de auto-gestionarse, para esto contaremos con equipos multidisciplinares, que tengan la capacidad de poder tomar las decisiones necesarias para crear productos de alta calidad y gestionar sus propios procesos, ¿quién puede tomar mejor las decisiones sobre un trabajo, más que el que lo va a hacer?. Ojo, nadie dice que esto sea fácil, pero tampoco quiere decir que necesitemos obligatoriamente un equipo de, únicamente, superhombres, héroes, o como queráis llamarlos, por supuesto, para producir productos de calidad, necesitas equipos de calidad, de gente predispuesta a enseñar y aprender (sí, las dos cosas), nadie nace sabiendo, y vamos aprendiendo por el camino, apoyándonos en gente que sabe más que nosotros y en gente que sabe menos, para esto lo importante es dejar a la gente auto-organizarse, y proporcionarle los medios necesarios para ello.

El compromiso, ufff, esto suena difícil ehh, pero es importante, cuando cerramos un sprint planning meeting, estamos adquiriendo un compromiso en ambos sentidos, por un lado el equipo, que se compromete a gestionarse para cumplir el objetivo, ya que ellos mismos han sido parte importante, mediante sus estimaciones, ¿cómo puedo comprometerme si no, a algo que yo no he sido partícipe?, si el equipo, reiteradamente, no se toma en serio este compromiso, incumpliendolo, o sin tomarselo en serio, lógicamente no podemos pedir que nos dejen auto-gestionarnos, en ese caso ya hemos demostrado que no sabemos hacerlo.

Esto no quiere decir jornadas de 16 horas trabajando, fines de semana, etc., esto siginifica tomarse en serio el compromiso y ser realistas con lo que nos comprometemos, no sentar falsas expactativas ni similares. Por supuesto, como dicen los americanos shit happens, pero lo importante es tener la información de en que punto estamos, hacia dónde vamos, como nos afecta el shit happens, etc., otra de las partes fundamentales, tener la información (¿recordáis lo que son los daily scrum?)

Y también, como no, compromiso por parte del Product Owner, que se compromete a no cambiarnos el ámbito del sprint, sin este compromiso, el equipo tampoco puede comprometerme, por qué, ¿cómo puedo comprometerme a cumplir un objetivo en un plazo de tiempo si me cambian el objetivo o el mismo no está claro?

Y llegamos a otro punto, bueno otros dos puntos, la priorización y los plazos de tiempo. Si tenemos que responder al cambio ¿por dónde empezamos?, priorizando, aquí entra en juego el Product Owner, que tiene que decidir que es lo más importante en el punto actual, y empezar a acometerlo. Y claro, para esto necesitamos fijarnos plazos, en Scrum, estos son de unas cuatro semanas, durante las que nos centraremos en lo que hemos priorizado como más importante, y el equipo ha estimado que se puede comprometer a ello, pasado ese tiempo, habrá que volver a juntarse, repriorizar el siguiente trabajo a acometer.

¿Qué fácil parece todo cuando está escrito verdad?, efectivamente no es fácil acometer esto, y requiere de un cambio organizacional importante. Todo esto del compromiso, la auto-organización, el trato directo con todas las partes implicadas en el proceso es muy importante, por desgracia, estamos acostumbrados al entorno de trabajo de “yo-mando-tu-haces”, y pasar de ahí a un entorno colaborativo no es fácil.

Hay que promover el coraje del cambio, la apertura a las aportaciones de todos, y a favorecer el avance colectivo, por encima de los héroes, o las personas imprescindibles. Todo esto se resume en el respeto mutuo a todos los niveles en las organizaciones.

Pero esto del cambio organizacional, el coraje, etc, ya lo dejo para otro post ….

Error de DNS depurando con Visual Studio (Cassini) e IE9

Seguro que muchos de vosotros tenéis ya instalada la beta de IE9, y si trabajáis con aplicaciones ASP.NET, seguro que también habéis sufrido ya este error al depurar con el servidor web Cassini de Visual Studio:

image

Pues según leo en el blog del compañero MVP de Visual Studio ALM, Etienne Tremblay, se debe (como sospechaba) a que IE9 arranca demasiado rápido para el pobre Cassini, con lo que da el error, y hay que esperar un poco y refrescar.

Y lo mejor es que hay una solución, y es editar el fichero c:\windows\system32\drivers\etc\hosts (seguro que más de uno ya lo conocéis), y descomentar la entrada:

localhost 127.0.0.1

Y también comentar la entrada:

::1             localhost

Por lo visto esto se produce especialmente en Windows 7 que trae las dos líneas comentadas por defecto.

Yo lo acabo de probar y, en efecto, funciona.

ASí que ya sabéis, a seguir  utilizando IE9 …

Vulnerabilidad en ASP.NET y su efecto en Team Foundation Server

Como seguro que sabéis, hace poco se ha detectado una vulnerabilidad en ASP.NET, y aunque ya se está trabajando en su solución, mientras tanto, hay una serie de configuraciones que se pueden aplicar en nuestros websites para evitar vernos afectados, y que ScottGu ya puso en su blog

Team Foundation Server, está basado en ASP.NET, tanto para los webservices que lo forman como para otras partes del servidor, y por tanto, esta vulnerabilidad afecta a los siguientes servicios de TFS, y que necesitaremos “parchear” temporalmente mientras que salga la solución definitiva:

  • TFS Web Services
  • Team Web Access
  • TFS Proxy
  • Sharepoint
  • Reporting Services
Por lo que Brian Harry, ha publicado en su blog, un documento, para parchear todos estos servicios, excepto la parte de Reporting, para la que el equipo de SQL aún no ha publicado los pasos a seguir para parchearlo.
El documento lo podéis encontrar aquí:

 

La necesidad de probar … y el iPhone 4

Últimamente, en varias listas de correo y foros variados, estabamos comentando la necesidad de probar, todo lo que hacemos y desarrollamos desde el principio.

Y cuando decimos desde el principio, decimos desde la primera línea de código, y es que no debería de haber ni una sóla línea de código sin una prueba, no voy a discutir si usar TDD o cualquier otra técnica, da igual, pero no debería de haber ni una sóla línea de código sin una prueba. Con esto nos aseguramos, entre otras muchas cosas, que cuando metamos mano a ese código, podamos estar seguros de que lo dejamos funcionando, y que cuando venga alguien y vea ese código pueda estar seguro de que funciona.

En esta primera categoría entran pruebas unitarias y de integración, y pueden sernos de gran ayuda tanto las propias herramientas de Visual Studio 2010, como los frameworks tipo nUnit o Gallio.Con esto ya tenemos nuestra primera capa de pruebas creada.

OJO, aquí sólo estamos asegurando los componentes y/o su integración entre ellos, aún no estamos asegurando que la aplicación haga lo que tiene que hacer, mucho cuidado, que esto  no es suficiente aún.

Y es que ¿cómo sabemos que cierta característica de la aplicación está terminada? aquí entran las pruebas funcionales y de aplicación, que tienen que describir, para cada caracterísitca, que condiciones se tienen que dar para que aporte valor, y esto es importante, que aporten valor al cliente, este es el objetivo último de lo que quiera que estemos construyendo, que aporte valor, y esto lo tenemos que describir (junto con el cliente), tanto para el sistema completo, como para cada una de sus características, y que no haya duda razonable de cuando está “hecho” algo.

Para esto, podemos apoyarnos en herramientas como las nuevas herramientas de testing de Visual Studio 2010, con el Test Manager, y también, usando técnicas como Behaviour Driven Development, que intentan promover la colaboración entre desarrolladores, departamento de QA, y gente de nivel de negocio, y que por ejemplo a nivel técnico, podemos implementar usando MSpec.

Vale, hasta aquí con estas dos capas de pruebas, que no es poco, vamos bien, por supuesto luego hay más pruebas que muchos productos tienen que pasar, como por ejemplo pruebas de accesibilidad para pasar la AAA, pruebas de usabilidad para ver como se adaptan los usarios al software, pruebas de rendimiento, de escalabilidad, etc.

Y ¿por qué saco todo esto sin más?, pues porque recientemente, y gracias a mi operadora, me han regalado un iPhone 4, si ese que si lo agarras “mal” pierde cobertura, y la verdad es que tenía intriga por ener uno entre mis manos y ver la realidad del tema, ya que incluso en foros por ahí, hablan de que Apple, había sacado otro modelo sin el fallo de diseño y sin hacerlo público, claro, como si cambiar una línea de producción fuese rápido y barato, en fin …

Por supuesto, lo primero que hice cuando tuve mi nuevo cacharro en las manos, fue probar el tema del famoso agarre, y sorpresa, es perfectamente reproducible, especialmente en sitios dónde la cobertura no es óptima. Y esto me lleva a preguntarme ¿cómo hacen las pruebas los señores de Apple?, porque está claro que nadie ha probado que un móvil, al ser agarrado, no pierda su principal valor, que es la cobertura o bien dicho la capacidad de llamar con la mejor calidad posible.

Tampoco veo que hayan hecho pruebas de usabilidad en ese sentido, ya que cualquier persona que lo hubiese cogido con ánimo de probarlo, se habría dado cuenta.

¿Entonces?, la verdad es que el iPhone 4, en otros términos es un buen producto, la pantalla es muy buena, la funcionalidad es buena, etc., pero han fallado en algo básico, y esto ha hecho que se desate, y con razón, toda la red con comentarios negativos. si, es cierto que los usuarios  más acérrimos lo negarán, pero es algo que ocurre, que está ahí y que es reproducible, y que pueden dar al traste, y dejar mal sabor de boca, a un producto que no es malo (hasta que venga Windows phone 7 y le de un repaso jejeje).

Por tanto ¿cómo probáis vuestras aplicaciones?¿cumplís con el valor que tienen aportar?¿tenéis claro cúal es ese valor que tienen que aportar? … ahí dejo eso, os dejo que creo que me llaman … vaya al coger el móvil he perdido cobertura Smile

Versión de septiembre de las TFS Power Tools 2010

Ya tenemos la versión de septiembre de las (a mi juicio) indispensables TFS Power Tools, y que podréis descargar de aquí: http://visualstudiogallery.msdn.microsoft.com/en-us/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

Se han actualizado tanto la herramienta de línea de comandos tfpt.exe, como el TFS Best Practices analyzer (para comprobar despliegues de TFS 2010).

Pero lo que más me ha gustado de esta nueva versión es la nueva herramienta de backups de TFS. Cómo muchos sabéis y muchos habréis sufrido, el backup de TFS, suele ser trabajoso, ya que incluye no sólo las bases de datos propias de TFS, si no también las de Sharepoint y las de Reporting.

Con esta nueva herramienta, desde la consola de administración de TFS 2010 (en el servidor), podremos establecer una tarea programada para hacer backups de las bases de datos de configuración de TFS, de cada Team Project Collection, y si tenemos Sharepoint y/o Reporting, también hará backup de esas bases de datos, nosotros sólo tendremos que preocuparnos de decirle cuando y dónde queremos los backups.

Y por su puesto, trae también un wizard d e restauración de los backups, que suele ser otro de los temas complejos.

Ah, sólo una cosa más, cuando tengáis Reporting, también tendréis que hacer backup de la llave de encriptación de Reporting, esto sólo hay que hacerlo una vez, y NO se incluye en esta herramienta de backups, precisamente por eso, porque sólo se hace una vez.

Y ahora nada, a descargar las TFS Power Tools y probarlas.

¿Es “agile” una moda, tendencia, la mejor opción … la única opción?

Hola a todos, es cierto, hace tiempo que no escribía, una mezcla entre pereza, falta de “creatividad”, acumulación de trabajo, etc., bueno quizás más de lo primero, pero espero volver a reincorporarme poco a poco.

La cosa es que leyendo hoy uno de los blogs que sigo bastante habitualmente: http://navegapolis.net/ (y que recomiendo a cualquiera interesado en Scrum), leo un post acerca de la inversion de tendencias entre CMMI y agile, en las búsquedas de google.

Y como no, me viene a la cabeza, todas las opiniones que leo y escucho (bueno algunas sólo las oigo), y me empiezo a preguntar, ¿es la “agilidad” sólo una moda?, cada vez si que es cierto que veo más interés por este tipo de metodologías, incluso en personas, que hace un tiempo, eran bastante incrédulos ante las ideas de la “agilidad”, es más, y lo que más me preocupa, ya empiezo a escuchar las voces que propugnan agile, o algunos de sus proceso y prácticas, como la única verdad.

Y me preocupa porque, o yo no entiendo el tema de “agile” (me considero un mero aprendiz pero eso da para otro post), o la gente se hace muchos líos en la cabeza, ahora resulta que el que no hace ciertas cosas está equivocado, vaya, yo que pensaba que precisamente el manifiesto ágil iba, entre otras cosas, en contra de las balas de plata, y que lo que funciona para unas personas puede no funcionar para otras (people over processes and tools).

Y es que, como siempre decimos muchos, no hay una bala de plata, llámese “agile” (partiendo de lo más genérico), scrum o CMMI.

También es cierto, que soy un poco, como decirlo hmmm, toca narices??? por no decir otra cosa, y es que cuando veo que mucha gente empieza a crear uina “moda”, tiendo a desconfiar de eso, lo se, no debería de desconfiar inmediatamente, pero soy así y lo hago.

Y es que, ¿si haces agile no puedes hacer CMMI?, si que es cierto que muchos de sus principios son contrapuestos, pero ¿dónde dice en scrum que no se puedan tratar los entregables de CMMI como parte del producto a entregar en un sprint?, o ¿dónde dice en CMMI que no se pueden hacer sprints, retrospectivas o daily scrums?.

En definitiva, que me gusta que la gente se interese por el movimiento “agile”, pero ojo con esto de las modas, ni todo es tan bonito como lo pintan los que lo venden, ni todo es tan feo como lo pintan los que se oponen, hay que probar, investigar, adaptar, hay mucho trabajo que hacer antes de poder empezar a sacar provecho de cualquier cosa.

Ojo, tampoco defiendo que cada uno haga lo que buenamente le venga en gana sin fijarse en más, hay que leer mucho, compartir opiniones, probar las cosas “según el libro”, antes de poder adaptar o afirmar si algo funciona o no, y siempre teniendo en cuenta que lo que me funciona a mí, puede no funcionarte a tí, y eso no lo hace ni mejor ni peor.

Lo dicho, a empaparse de las cosas, a aprender, a probar, y no sólo dejarse guiar por las tendencias.

Ya disponible Microsoft Visual Studio Scrum 1.0

Hola a todos, hace poco os hablaba de la nueva plantilla de Scrum de Microsoft para TFS 2010, en aquel momento estaba en beta.

Bueno pues hoy se ha anunciado oficialmente en el blog de Aaron Bjork, y trae algunas novedades con respecto a la beta, como el cambio de nombre, que pasa a ser oficialmente llamada Microsoft Visual Studio Scrum 1.0.

Otras novedades son 4 nuevos informes, dos para las builds, y otros dos para los casos de tests.

Como toda plantilla de TFS, y esto es importante por supuesto, ya dispone de su guía de proceso que podemos encontrar en MSDN: http://msdn.microsoft.com/en-us/library/ff731587.aspx

También ha habido cambios a nivel de Work Items:

  • Se ha cambiado el campo “Owned By” para usar el estándar “Assigned to”, que si bien rompe un poco con la terminología de Scrum, es más estándar a nivel de TFS a la hora de la integración.
  • Las builds que fallan ya no crean un work item de tipo Bug, esto lo podéis ver en el post de Aaron. Según lo que nos pone, esto también rompía con el modo en el que se tratan los fallos en Scrum durante un sprint, que son tareas a realizar en el propio sprint, al contrario que los defectos que se añaden como bugs en el product backlog, hmmm bueno esto me da para un post …
  • Un nuevo campo de prioridad.
  • Nuevas transiciones. To Do –> In Progress –> Done o Done –> In Progress –> To Do
  • Recuperar como “New” work items previamente marcados como “Removed”
  • Una nueva consulta para los test cases

Bueno todo esto lo podéis ver también en el post de Aaron, así como una pequeña FAQ acerca de esta plantilla.

Así que ya sabéis, a ver como encaja esta nueva plantilla en vuestros procesos.