List<Stuff>

Como todos sabréis, Enterprise Library es un conjunto de componentes reutilizables que podemos usar para ahorrarnos trabajo en diversas tareas comunes de desarrollo, ya sea mediante su utilización directa, o viendo cómo han sido resueltos los distintos escenarios que aborda y aplicando ese conocimiento en nuestros propio código. La librería va por su versión 4.1 y es desarrollada por un equipo del área de  patterns & practices, la cual se ocupa de proporcionar guía ante problemas comunes de desarrollo y de mostrar cómo han sido abordados en Microsoft.

En este post no voy a contar nada acerca de detalles concretos de Enterprise Library (para eso hay gente mucho más capaz que yo); simplemente quiero hablar un poco de cómo han enfocado una actividad tan importante en todo proyecto de desarrollo como es la definición de los requerimientos. Los principios que han aplicado son los que están en el corazón de cualquier proyecto ágil, y si funcionan para un software y/o código que es utilizado por decenas de miles de desarrolladores en todo el mundo, imaginad hasta qué punto pueden ser aplicables en los proyectos en los que cualquiera de nosotros trabaja a diario.  

La construcción del product backlog

De cara al desarrollo de la próxima versión 5.0 de la Enterprise Library, el equipo (como buen equipo ágil), se dio cuenta de que el primer paso antes de poder a plantearse cualquier otra actividad, es construir una primera versión de la lista de requerimientos, que describa a alto nivel qué funcionalidad y características van a ser cubiertas por el producto. La forma más óptima de recoger estos requerimientos es en un backlog de producto; el propósito y las características de un buen backlog ya han sido detallados en muchas ocasiones, por ejemplo por mi compañero Rodrigo. Una de las premisas fundamentales del backlog es que refleje de forma clara las necesidades del cliente, por lo que para construirlo es imprescindible la colaboración y la comunicación continua con el cliente.

¿De dónde obtiene el equipo esta información? ¿quién determina qué características nuevas va a incorporar la siguiente versión de la Enterprise Library? Se podría pensar a priori, que alguien con el suficiente poder dentro de Microsoft decide estas cuestiones, y determina de esta forma el conjunto de características en las que trabajará el equipo. Esto es algo que se da en muchas organizaciones, pero que si nos paramos a valorar con calma, se revela como una aproximación claramente errónea, o al menos que no reflejará de forma fiel las verdaderas preferencias del cliente.

Pero entonces, ¿quién es el cliente para el equipo de la Enterprise Library? ¿quién determina si se ha producido el retorno de la inversión (ROI) que debería justificar la existencia de cualquier proyecto de desarrollo?

Como os podéis imaginar, el verdadero cliente para el equipo de Enterprise Library es la comunidad de desarrolladores que a diario utilizan los Application Blocks y se benefician de consultar los detalles de su implementación. Y el retorno de la inversión para esta comunidad de desarrolladores, no es otro que ver una siguiente versión de la librería que contenga las modificaciones y mejoras más utilizadas y solicitadas por todos.

Con el objetivo de incentivar la comunicación con el cliente y de obtener un product backlog que maximizase el ROI, el equipo de Enterprise Library publicó un post hace unos meses, en el cual invitaba a la comunidad a proporcionar el feedback necesario para llevar a cabo la construcción del backlog. Como podéis ver en el enlace, las respuestas obtenidas proporcionaron una información valiosísima al equipo para la construcción del backlog, y que difícilmente podría haberse obtenido por otros medios distintos a la comunicación directa con la comunidad de usuarios.

Como dato útil podéis ver que pidieron a la gente que utilizasen la técnica de «dinero en el backlog», consistente en asignar un «presupuesto» simbólico (en este caso fueron 100$) y asignar parte del dinero a cada una de las características que se desee incluir en la siguiente versión. Por poner un ejemplo corto extraído de la misma lista de comentarios, sería algo así:

$70 – Activerecord  implementation.

$20 – remove the policy injection block and merge it with the unity block.

$10 – make config administration less painful.

En los comentarios del post podéis encontrar muchos otros ejemplos bastante interesantes. Como resultado de este proceso de recogida de información, y combinando esta información con otras encuestas, mails recibidos y consultas, se obtuvo el backlog que guiará el desarrollo de Enterprise Library 5.0, formado por más de 100 elementos.

La estimación y priorización del product backlog

  El siguiente paso en el proceso de construcción de un buen product backlog es la estimación y la priorización del mismo. La estimación permite tener en todo momento definido el estado del proyecto y el horizonte temporal del mismo, y su proceso de obtención nos proporciona datos valiosos que nos ayudan a entender mejor los requerimientos y cómo afrontar su implementación. La priorización garantiza que se va entregando valor según lo determinado por el criterio del cliente y guiándose por el ROI perseguido.

Es importante además tener una estimación a alto nivel cuanto antes, pues además de las ventajas ya mencionadas, permitirá que el cliente pueda guiar la priorización de determinados requerimientos en base al coste que supone implementarlos. Es posible que un requerimiento que en principio puede parecer poco importante, suba bastante en la clasificación si se determina que el coste de implementarlo es bajo; y lo contrario podría llegar a aplicarse para requerimientos muy costosos de implementar.

El equipo de Enterprise Library ha estimado el backlog en base a un procedimiento muy simple pero bastante útil, que les ha permitido que el cliente (la comunidad de desarrolladores) se pueda hacer una idea rápidamente del coste relativo que puede suponer la implementación de cada elemento del backlog. Se refieren al procedimiento como «T-shirt sizing» y consiste en asignar a cada requerimiento una «talla» de camiseta (S, M, L, XL o XXL), que de una idea de la magnitud relativa del coste de implementación del mismo con respecto al de los demás. Un ejemplo en el que se pueden ver casi todas las «tallas» es el fragmento del backlog correspondiente a los requerimientos del Application Block de configuración:

Config

CFG01 : Config decentralization (support for config stored in multiple sources) (S)

CFG02: Improved Config API (XL)

CFG03: Support for different sections of config in different media (not just files) (XL)

CFG04: Support for multiple pieces of config for a single block in multiple places (XXL)

CFG05: Making Unity configuration less verbose (M)

CFG06: Support other config schemas for Unity config (e.g. XAML-based config)

CFG07: Unity config auto-registration: expanded conventions and helper classes to reduce need for explicit configuration (M)

El coste de las historias o requerimientos que han utilizado es: S=1, M=2, L=4, XL=8 y XXL=20 (en lugar de una historia de usuario XXL se correspondería con lo que se puede denominar como épica). Se trata de medidas relativas que en principio no dan información del coste final; éste sería obtenido en posteriores revisiones del backlog.

Como se puede apreciar, basta un vistazo para que el cliente pueda hacerse una idea del coste relativo de implementación de cada elemento, y en base a esa información poder ser más específico en la priorización. Además como podéis ver el backlog está expresado en un lenguaje que cualquier usuario de Enterprise Library puede entender, sin entrar en ningún momento en detalles internos de la implementación o del funcionamiento de los distintos módulos.

En cuanto a la priorización, como no podía ser de otra forma para un equipo ágil, el encargado de definirla es el cliente, en este caso la comunidad de desarrolladores que utilizan Enterprise Library. El equipo ha utilizado una vez más el recurso de obtener información de la misma fuente, y para ello ha publicado otro post, en el que se invita a todo aquel que quiera a opinar en la priorización de los requerimientos, a participar en una encuesta orientada a recabar dicha información. Para completar la encuesta se recuerda que el presupuesto es de 100 $ o puntos que deben distribuirse entre los elementos del backlog.

La votación está abierta desde ya y cualquiera que desee aportar su opinión puede hacerlo. El equipo se ha comprometido a publicar los resultados y a utilizarlos para priorizar el backlog que será finalmente utilizado en el proyecto de desarrollo.

Conclusiones

¿Qué podemos sacar en claro de toda esta historia? (además de poder influir en la próxima versión de Enterprise Library, claro…) Voy a intentar hacer un pequeño resumen de lo que más me ha llamado la atención a mí; algunas de las cosas os parecerán evidentes pero no os podéis ni imaginar la cantidad de veces que no se cumplen en la vida real, al menos por lo que respecta a mi experiencia (y os puedo asegurar que he visto unos cuantos proyectos de desarrollo en los 10 años que llevo trabajando en esto…)

• Lo primero y más importante en todo proyecto de desarrollo es construir una lista de requerimientos o product backlog de partida, tener su contenido claro, y que el cliente también lo tenga: en el ejemplo que nos ocupa, qué es lo que se quiere incorporar o mejorar en los application blocks de configuración, acceso a datos, seguridad, etc. Comenzar a trabajar, y no digamos escribir una sola línea de código, sin un product backlog o lista de requerimientos, es como subirse en un coche y comenzar a conducir sin saber a dónde nos dirigimos. Y en muchas ocasiones nos damos cuenta de que estamos en la dirección equivocada cuando llevamos recorridos cientos de kilómetros!!!
• El cliente o interesado último en el resultado de lo que se está desarrollando, debe de ser también el que determine qué es lo que se desarrolla. Para la Enterprise Library está claro que son los usuarios de la librería los que tienen más criterio para decidir esto
• El desarrollo debe siempre ir guiado por el retorno de la inversión. En este caso por las características que más agradecerán los usuarios de la Enterprise Library, que van a ser convenientemente priorizadas
• La elaboración de estimaciones sirve, entre otras cosas, para dar mucha información útil para la priorización de los elementos del backlog

Pero aparte de toda la base teórica de la que ya se ha hablado de sobra, lo que más me gusta del caso que nos ocupa es, que sin ser el objetivo principal del mismo, nos está dando ejemplos, técnicas y herramientas que son de gran valor y que podemos aplicar en nuestros propios proyectos desde ya mismo. Por ejemplo:

• La comunicación con el cliente es fundamental y en ocasiones hay que ser creativos y hacer uso de todo tipo de recursos para mejorarla; en este caso se ha hecho uso del blog, el correo electrónico, las encuestas on-line…
• Tenemos técnicas que nos ayudan a estimar el backlog de una forma bastante sencilla e intuitiva; por ejemplo el «T-shirt sizing» es algo que no conocía pero que me ha parecido excelente y que pienso utilizar en cuanto tenga la oportunidad
• Tenemos técnicas que nos ayudan a priorizar también de forma sencilla e intuitiva y que podemos utilizar con nuestros clientes para simplificar el proceso, en este caso el «dinero en el backlog» (ésta sí la conocía 😉 )
• El backlog preparado por el equipo de Enterprise Library nos puede servir para compararlo con los nuestros y coger ideas. Por el tipo de proyectos en los que suelo estar involucrados mis backlogs suelen ser algo más detallados e incluyen una descripción en forma de historias de usuario, pero también hay que tener en cuenta que el backlog que hemos visto en el ejemplo aún será más elaborado y refinado en el futuro próximo

Por último me gustaría resaltar que todo lo que he comentado en las conclusiones debería ser tenido en cuenta también en la preparación de propuestas o presupuestos que vayamos a presentar a clientes, una actividad en la que suelo estar bastante involucrado (muy a pesar mío jeje)… ¿Cómo vamos a saber cuánto tenemos que cobrar por algo o qué equipo es necesario, si no sabemos con un mínimo detalle qué necesita el cliente? Pero bueno, esto puede dar para varios artículos, quizá un día me anime a escribir mi opinión sobre ello más detenidamente 😉

Si os interesa Enterprise Library animaos a votar  en la priorización. Cuando se publiquen los resultados seguramente tendremos mucha más información útil del proceso así que seguramente os vuelva a obsequiar con otro ladrillo similar a este post 🙂

Un saludo!!!

Según cómo nos estemos conectando a Team Foudation Server (por ejemplo es común si lo hacemos a través de internet), es posible que cada vez que abramos Visual Studio, nos encontremos con una pantalla de login, resultado de que Team Explorer está intentando conectarse al servidor TFS.

Si queremos evitar tener que introducir nuestras credenciales cada vez que tengamos que trabajar con TFS, podemos añadirlas al administrador de contraseñas de red de Windows (Panel de control – cuentas de usuario – administrar sus contraseñas de red).

Esto también funciona si estamos accediendo al control de código fuente de TFS a través de MSSCCI, por ejemplo desde el IDE de Visual Basic 6.

Además, es la única forma que tenemos, por el momento, de configurar el acceso para las extensiones de shell de las últimas Power Tools de TFS, que permiten acceder al control de código fuente desde cualquier ventana del explorador de Windows. Es decir, que si tenemos que introducir las credenciales de acceso a TFS en Visual Studio, las extensiones de shell no funcionarán a menos que incluyamos explícitamente las credenciales de acceso en el administrador de contraseñas de red de Windows.

Un saludo!!!

Como ya adelantó Rodrigo, durante este mes de febrero de 2009 vamos a llevar a cabo una pequeña gira de eventos en varias ciudades españolas, en la que trataremos de mostrar cómo aproximarnos al desarrollo de software desde las metodologías ágiles, y cómo Visual Studio Team System puede ser una herramienta de gran ayuda para apoyar la metodología. Hablaremos de metodologías ágiles en general, de Scrum, de MSF Agile y de cómo usar Visual Studio Team System para facilitar el trabajo diario en el marco de la metodología que elijamos.

Yo seré el ponente en el evento de Valencia el 25 de febrero, así que espero veros por allí. Podéis ver la agenda en el post de Rodrigo y apuntaros en la página de registro del evento.

Un saludo!!!

Ha sido detectada una vulnerabilidad en Team System Web Access 2008 SP1, la cual ha sido comunicada por Hakan Eskici, Program Manager de Microsoft para TSWA, como podemos ver en su blog.

No se dan muchos detalles de en qué consiste la vulnerabilidad, pero se recomienda actualizar inmediatamente las instalaciones de TSWA, sobre todo si están accesibles a través de internet. La actualización es en realidad una versión completa, por lo que es necesario desinstalar la versión actual antes de hacer la actualización.

En el anuncio se indica además que próximamente se publicará un artículo en la knowledge base dando más detalles del problema.

Para comprobar si tenemos la última versión actualizada, podemos hacerlo en el menú Help – About; la versión que aparece debe ser la 9.0.3275

Un saludo!!!

Durante el trabajo con Team Foundation Server en distintos equipos de desarrollo, al usar la integración con MS Project, he podido comprobar que surgen dudas recurrentes, sobre todo relacionadas con la sincronización de las fechas de inicio y fin de las tareas (Start Date y Finish Date). En este post voy a comentar una serie de recomendaciones para trabajar con dichas herramientas y un par de métodos para minimizar los problemas de sincronización de fechas, las cuales por otra parte sólo son editables desde Project y Excel según vienen configuradas por defecto en las plantillas metodológicas de CMMI y MSF for Agile.

«Buenas prácticas» de trabajo con TFS + MS Project

Un escenario que ilustra bastante bien una forma de trabajar correcta con las herramientas sería el siguiente:

• Comenzar por introducir las tareas de nuestro proyecto como elementos de trabajo (work items) de TFS
• En el momento en que necesitemos usar Project, podemos exportar las tareas desde Team Explorer (por ejemplo desde el menú contextual asociado a los resultados de una consulta de elementos de trabajo)
• Una vez en Project podemos modificar las tareas a nuestro gusto; cambiar la fecha de inicio, calendario, duración o cualquier otro dato asociado. Si usamos la opción de publicar del addin de Project para TFS (menú Team en MS Project), estos cambios se verán reflejados en TFS
• Al finalizar los cambios, guardaremos el fichero .mpp para poder usarlo posteriormente. Lo mejor es que lo publiquemos en el portal de proyecto alojado en Sharepoint, de modo que sea accesible para otros miembros del equipo que lo necesiten

Una vez hecho esto (y aquí es donde está la fuente de confusión más común), cuando queramos trabajar con las tareas de TFS, lo mejor es que el fichero de Project actúe como «maestro» de la información y no al revés. Es decir:

• Si queremos actualizar el fichero de Project con cambios en las tareas que se hayan hecho en TFS, abriríamos dicho fichero desde el portal de proyecto e incorporaríamos los cambios usando la opción de refrescar que nos proporciona el addin de Project para TFS
• Si queremos incorporar nuevas tareas añadidas en TFS a nuestro fichero de Project, podemos usar la opción de obtener work items proporcionada por el addin
• También podemos añadir tareas nuevas en Project y publicarlas en TFS como comenté anteriormente
• Al acabar de trabajar, guardaríamos los cambios en el portal de proyecto para que estén disponibles para el resto del equipo

De esta forma el fichero de Project siempre estará sincronizado con las tareas de TFS y nos ahorraremos los problemas de los que voy a hablar a continuación.

Problemas de sincronización de fechas de inicio y fin de tareas

En las plantillas metodológicas de MSF for Agile y CMMI que vienen de serie con TFS, en el mapeo de campos con MS Project, el modo de sincronización por defecto de los campos de fecha de inicio y fin de tarea está establecido a «Publish only». Esto quiere decir que sólo se guardarán cambios en esos campos cuando guardemos en sentido Project -> TFS, pero no cuando guardemos en sentido TFS -> Project. Esto nos puede llevar a problemas si tenemos escenarios como el que describo a continuación:

• Un miembro del equipo introduce una serie de tareas en TFS, modifica la fecha de inicio y la duración en Project y publica los cambios de vuelta a TFS. En este punto, las tareas en TFS tienen las fechas de inicio y fin correctas
• Otro miembro del equipo (o el mismo 🙂 ) exporta desde TFS a Project las tareas, usando un fichero de Project nuevo. Como el contenido de los campos de fecha no viaja en sentido TFS -> Project, la fecha de inicio de las tareas en Project será la del día de hoy (de todas las tareas, por lo que incluso se pierde la ordenación entre las mismas). De hecho el usuario lo suele percibir como que se ha perdido el trabajo de planificación que había realizado, cuando en realidad las fechas siguen intactas en TFS
• Si después de trabajar con el Project dicho usuario publica los cambios a TFS, las tareas se guardarán con la fecha errónea y entonces sí que se pierden todos los cambios que se habían realizado en la anterior publicación

Solucionar los problemas de sincronización: método fácil y rápido

El método más simple para solucionar el problema descrito es ceñirse a las buenas prácticas que describí anteriormente. Si todo el equipo trabaja siempre sobre el mismo fichero de Project (alojado en Sharepoint), y de la forma descrita, nunca sobreescribiremos las fechas de las tareas en TFS con datos erróneos.

Solucionar los problemas de sincronización: método menos fácil y menos rápido

La otra solución pasa por modificar el mapeo de los campos de fecha de TFS a Project para eliminar la restricción «Publish only». De esta forma se elimina el riesgo de sobreescribir la fecha de las tareas en TFS, ya que al exportar en sentido TFS -> Project los valores de esos campos también serán actualizados. En cualquier caso, aunque se siga este segundo método, creo que sigue siendo muy ventajoso complementarlo con las buenas prácticas descritas.

Para eliminar la restricción «Publish only» procederemos de la siguiente forma:

• Descargar y abrir la plantilla metodológica correspondiente (lo mejor es usar el editor proporcionado por las power tools de TFS)
• Dentro del apartado «Areas & Iterations», seleccionar «MS Project Mapping»

• Hacer doble click en el elemento «Microsoft.VSTS.Scheduling.StartDate». Desmarcar «Publish only» y pulsar OK
• Lo mismo para «Microsoft.VSTS.Scheduling.FinishDate»
• Guardamos los cambios y subimos la plantilla metodológica al servidor de TFS, sobreescribiendo la actual. A partir de este punto las fechas de inicio y fin se sincronizarán en ambos sentidos para los proyectos nuevos

Para aplicar estos cambios en proyectos existentes, haremos lo siguiente:

• Una vez guardada la plantilla metodológica, los cambios en el mapeo se habrán reflejado en el fichero FileMappings.xml ubicado en la carpeta Classification, dentro de la carpeta que obtenemos al descargar la plantilla metodológica
• Incorporaremos los cambios a cualquier proyecto existente importando el nuevo FileMappings.xml en él. Para ello podemos usar la herramienta TFSFieldMapping.exe ubicada normalmente en C:Program FilesMicrosoft Visual Studio 9.0Common7IDE (y accesible desde un símbolo de sistema de Visual Studio):

TFSFieldMapping upload http://servidortfs:8080 NombreDeProyecto "C:...Plantilla MetodologicaClassificationFileMappings.xml"

Una vez ejecutado el comando, la sincronización de fechas para las tareas comenzará a ser bidireccional.

Y eso es todo… espero que haya sido de ayuda para los que trabajan con MS Project y TFS.

Un saludo!!!

Steve Ballmer ha anunciado durante su keynote en el CES la disponibilidad de Windows 7 Beta, el cual ya está disponible para descargar para suscriptores de MSDN, TechBeta y TechNet, según podéis ver en el comunicado de prensa. Para el público en general será descargable en el sitio web de Windows 7 a partir del 9 de enero.

He echado un vistazo por la MSDN y efectivamente está disponible para descargar no sólo Windows 7 Beta (tanto en versiones x86 y x64), sino además los símbolos de depuración y los paquetes de idioma localizados. La instalación va como la seda y por el uso en general da la impresión de que se trata de una release bastante madura y estable; seguramente os cuente más detalles en algún post próximo. Por ahora deciros que en un netbook con 512 Mb de RAM se ha instalado perfectamente y no es que vaya como el rayo pero al menos es bastante usable (con sólo 512 Mb!!!); en cuanto termine con la ampliación de RAM espero que el rendimiento mejore significativamente, siempre que el disco SSD se lo permita…

Creo que la liberación de la Beta es una gran noticia para todos los que quieran hacerse una idea de cómo va a ser el próximo Windows.

Por reseñar algún inconveniente, parece que hay características que aún no están presentes en la Beta según se instala, siendo necesario hacer algunos ajustes en el registro. No queda muy claro si estas características aparecerán en versiones específicas (ultimate, tablet, surface…), si serán eliminadas o si finalmente se incorporarán al producto final; el tiempo lo dirá…

En cualquier caso hay un montón de funcionalidad nueva que explorar así que os animo a que os pongáis manos a la obra.

Que disfrutéis la beta y un saludo!!!

Me he animado a participar en el reto friki-navideño-hexadecimal iniciado por Pablo e impulsado por Rodrigo y Octavio.

Siempre me ha gustado la potencia que te dan los lenguajes de script para trabajar con texto. En el caso de PowerShell además tenemos a nuestra disposición toda la funcionalidad de la biblioteca de clases de .NET. He intentado aprovechar estas dos ventajas para descifrar el mensaje de Pablo; mis conocimientos de PowerShell son todavía un poco precarios, pero aún así he llegado a una solución que creo que es bastante compacta:

$message = "%46%65%6C%69%63%65%73%20%46%69%65%73" +

      "%74%61%73%2C%20%63%61%63%68%6F%20%66" +

      "%72%69%6B%69%21%20%41%68%6F%72%61%2C" +

      "%20%64%65%6A%61%74%65%20%64%65%20%74" +

      "%6F%6E%74%65%72%69%61%73%20%79%20%76" +

      "%65%74%65%20%61%20%65%6D%62%6F%72%72" +

      "%61%63%68%61%72%74%65%20%75%6E%20%70" +

      "%6F%71%75%69%6E%21%21%20%4B%65%65%70" +

      "%20%52%6F%63%6B%69%6E%27%21%21"

Measure-Command{$message.Split('%', [System.StringSplitOptions]::RemoveEmptyEntries) |

    % {[Convert]::ToInt32($_, 16)} |

    % {[Char] $_} |

    % {$result += $_}}; $result

De todas formas yo no paso de friki aficionado; creo que los auténticos frikis deberían ser capaces de entender el mensaje sólo con leerlo en hexadecimal 😉

Un saludo!!!

Ya tenemos disponible en Codeplex la nueva versión de la guía de branching para TFS: TFS Branching Guide 2.0.

La nueva versión de la guía consta de nada menos que de nueve documentos organizados en cinco grupos (aunque si contamos el material que viene en distintos formatos o está casi repetido en realidad tenemos seis documentos). A lo largo de los documentos se hace un recorrido muy amplio por las distintas opciones que tenemos para afrontar desarrollos en los que tengamos que mantener en paralelo varias versiones de la misma base de código… ¿hay algún proyecto hoy en día en el que no nos tengamos que enfrentar a esto?

El material incluido es el siguiente:

• Un documento llamado «Main» que hace una descripción de los conceptos generales manejados durante la definición y el uso de una política de branching. Se centra sobre todo en el escenario básico de ramas Desarrollo – Integración – Producción (Development – Main – Release) el cual sirve como punto de partida para adaptarlo a múltiples casos que nos podemos encontrar en nuestros proyectos. También introduce las premisas básicas para integrar nuestro código entre distintas ramas, y para establecer el conjunto de builds a mantener sobre nuestro código y que aseguren la calidad del mismo

• Un documento llamado «Scenarios» que hace un recorrido por tres políticas de branching que aparecen con mucha frecuencia. Es un documento muy útil porque nos ayuda no sólo a definir las distintas ramas y la forma de combinar el código entre ellas, sino que también incluye el mapeo con los distintos entornos (desarrollo, testeo, preproducción, producción…) y el establecimiento de las builds correspondientes. Los ejemplos incluidos son:
  • Dar soporte a un sólo equipo de desarrollo que vaya teniendo que liberar y mantener versiones sucesivas de una aplicación
  • Dar soporte a un producto que reciba hot fixes y service packs mientras se sigue trabajando en la siguiente versión del mismo
  • Sacar todo el partido de trabajar con etiquetas en combinación del trabajo con ramas. Ojo, digo «en combinación» y no «en lugar de»; esto último es una práctica frecuente sobre todo en equipos procedentes de SourceSafe, que no permite aprovechar al máximo las posibilidades que ofrece el branching & merging

• Una recopilación de preguntas (y respuestas) frecuentes que todos nos hemos encontrado al trabajar con el control de versiones en general y con ramas en particular: dónde encajan los work items, qué es el baseless merge, uso correcto de las etiquetas…

• Un par de Labs que muestran paso a paso cómo implementar una política de branching para un equipo de desarrollo que se ocupa también del mantenimiento de la aplicación. Los ejemplos se pueden seguir perfectamente utilizando alguna de las máquinas virtuales de prueba que tenemos disponibles. Como pequeña crítica a los autores, indicar que los dos Labs son prácticamente iguales y perfectamente podrían haber liberado sólo uno de ellos, o incluir algún otro ejemplo distinto

• Un conjunto de gráficos relacionados, incluyendo un póster que muestra de un sólo vistazo diversos escenarios (en formatos pdf, jpg y visio), y un powerpoint que nos va a ser muy útil como plantilla para definir y documentar nuestra propia política de branching

En general supone una magnífica actualización de la anterior versión de la guía, que en un sólo documento ya contenía información muy útil para afrontar la definición de una política de branching que permita el mantenimiento de nuestra base de código.

Además, aunque una parte de la guía es de aplicación sobre todo en Team Foundation Server (sobre todo los Labs), gran parte de la información recogida puede ser de gran utilidad sea cual sea el sistema de control de versiones que estemos utilizando, mientras permita la utilización de ramas y la combinación posterior de cambios.

Que lo disfrutéis y un saludo!!!

He subido la presentación powerpoint que utilicé durante el workshop del martes pasado dedicado a Team System para desarrollos .NET y Java. Aunque el temario fue bastante extenso y no se pudo profundizar en ninguno de los temas, creo que fue una buena oportunidad para acercarse a Team System en general y a su aplicación en proyectos Java.

Aquí podéis descargar la presentación del Workshop ALM.

Muchas gracias a los que asistieron por su atención, y reitero mis disculpas por el pobre rendimiento de mi equipo, que hizo que alguna demo llevase más tiempo de lo necesario.

Un saludo!!!

En los próximos días van a tener lugar una serie de workshops organizados por Microsoft, que servirán para profundizar en los temas tratados durante las Sesiones ALM’08, las cuales tuvieron lugar el pasado 16 de Octubre en Madrid.

Tanto si tuviste ocasión de asistir a las Sesiones ALM’08 como si no lo hiciste, los ALM Workshops son una buena oportunidad para obtener un montón de información útil acerca de la gestión del ciclo de vida de las aplicaciones, y de cómo las herramientas de Team System pueden facilitarnos mucho todo el proceso.

Desde Plain Concepts vamos a colaborar con Microsoft en dos de estos Workshops. Uno de ellos lo impartirá Rodrigo el 18 de noviembre, y tratará sobre Control de proyectos con Metodologías Ágiles y Team System. Del otro me voy a encargar yo, y tratará sobre Aplicación de Team System para desarrollos .NET y Java. En él daremos una visión general de las posibilidades ofrecidas por Team System para la gestión del ciclo de vida de las aplicaciones, y veremos cómo podemos beneficiarnos de estas posibilidades incluso en organizaciones con entornos de desarrollo mixtos en los que tengamos proyectos tanto basados en tecnologías .NET como en Java. El programa completo es el siguiente:

• Uso de múltiples metodologías (CMMI, Agile, Scrum)
• Generación de diseños con VS 2008
• Buenas prácticas con Team System, FxCop, StyleCop
• Integración continua en los desarrollos Software 
• Métricas de calidad con VS 2008
• Pruebas
• Aplicación de políticas de Backup con VS 2008
• Uso de Team System para gestión de proyectos Java

El workshop tendrá lugar el próximo martes 4 de noviembre, de 10:00 a 14:00 horas, en las oficinas de Microsoft Ibérica en Pozuelo (Madrid). Podéis encontrar más detalles y apuntaros en la página de registro.

Nos vemos en el workshop… un saludo!!!