You are on page 1of 27

Trabajando en equipo con Visual Studio ALM

Experiencias reales en desarrollo de proyectos de software


Bruno Capuano

TRABAJANDO EN EQUIPO CON VISUAL STUDIO ALM EXPERIENCIAS REALES EN DESARROLLO DE PROYECTOS DE SOFTWARE
No est permitida la reproduccin total o parcial de este libro, ni su tratamiento informtico, ni la transmisin de ninguna forma o por cualquier medio, ya sea electrnico, mecnico, por fotocopia, por registro u otros mtodos, sin el permiso previo y por escrito de los titulares del Copyright. Dirjase a CEDRO (Centro Espaol de Derechos Reprogrficos, www.cedro.org) si necesita fotocopiar o escanear algn fragmento de esta obra.

DERECHOS RESERVADOS 2011, respecto a la primera edicin en espaol, por Krasis Consulting, S. L. www.Krasis.com ISBN: 978-84-939036-9-5

Agradecimientos
Escribir siempre es una tarea agradable. En mi caso voy escribiendo a medida que voy aprendiendo con lo que mi blog o las pginas de este libro son un backup que puedo utilizar ms adelante cuando necesito refrescar informacin. Pero claro, todo este tiempo dedicado frente a un teclado es tiempo que le he quitado a otras cosas que tambin disfruto mucho. Es por esto que en primer lugar tengo que agradecer a mis nias Paola y Martina, que son mi soporte para poder sentarme y escribir una, dos o 50 pginas de un tirn. Tambin a mis compaeros de trabajo y de comunidad de ALM que, aunque no lo sepan, han servido de conejillos de indias en muchas ocasiones. Gracias Alfredo, Antonio, Carlos, Carmen, David, Edu, Fernando, Fran, Javi, Juan Antonio, JuanLu, JuanMa, JuanSa, Sergio, Vctor, y otros tantos que seguro me olvido. Tampoco quiero olvidarme de agradecer a la gente de Renfe que durante bastante tiempo me hacan Upgrades en los viajes a Alicante y a Barcelona para que pudiese tener electricidad y escribir sin problemas de batera en mi laptop. Y una vez ms a mi mujer, que me hizo darme cuenta que escribir un libro 100% tcnico no es lo mo, por algo Pao es Pao. Al resto de mi familia tambin le agradezco el soporte. Pero como somos 6 hermanos y una pila de primos; y ya empezamos a reproducirnos, si pongo todos los nombres seguro que tambin me dejo a alguien por el camino. Mami, Papi a ustedes les agradecer siempre algo que no me negaron nunca: la posibilidad de tener siempre un libro en mis manos. All naci mi pasin por leer durante los ltimos 30 aos. Ahora desde hace 2 aos, sufro la pasin de escribir en la que todava soy un newbie. Y finalmente al Valentino. Alguno se preguntar por qu a mi nio lo dejo solo al final? Es muy simple. Hace unos aos con el primer libro hicimos un trato con el Valentino. Todo el dinero que ingresara de la venta de libros ira a parar a su cuenta bancaria hasta que cumpliese 18 aos. La nica excusa que El Bruno tena para sacar ese dinero antes, era que con el mismo me pudiese comprar un Ferrari 0Km. Si bien el Valentino tena casi 2 aos y yo pens que entenda el trato, parece que ya se daba cuenta que escribiendo libros tcnicos jams llegara a los 500K. Y ahora disfruta cuando me ve escribir porque sabe que los beneficios sern todos para l. As que, hijo mo, cuando en unos aos aprendas a leer y te preguntes cmo hizo tu padre para conseguir un Ferrari, entenders por qu el ltimo libro que escribi tu padre no era de tecnologa, sino una novela de amor entre vampiros.

Contenido
AGRADECIMIENTOS ........................................................................................... iii CONTENIDO ......................................................................................................... vi 1.- APPLICATION LIFECYCLE MANAGEMENT ............................................. 11 1.- Por qu escribo este libro? .................................................................................................... 12 2.- Application Lifecycle Management ........................................................................................ 13 2.1.- La herramienta correcta para el problema adecuado. ......................................... 16 3.- Qu INCLUYE este libro? ..................................................................................................... 17 4.- Cmo ejecutar los ejemplos? ................................................................................................ 18 2.- SOURCE CONTROL ....................................................................................... 21 1.- Un poco de Branching .............................................................................................................. 22 1.1.- Opinin: El miedo al Merge ........................................................................................ 22 1.2.- Tutorial: Creacin de un escenario simple de ramas ........................................... 23 1.3.- Tip: Utilizar WinMerge con Visual Studio 2010 .................................................... 28 1.4.- Opinin: Cundo utilizar Branches? Has probado con Workspaces? .......... 29 1.4.1.- Test: Single Developer Test Mode .................................................................... 31 1.4.2.- Test: Multiple Developer Test Mode ............................................................... 32 2.- Desarrollos evolutivos y correctivos ................................................................................... 32 2.1.- Mala Prctica: Magia con Etiquetas ............................................................................ 33 2.2.- Mala Prctica: Magia con el File System ................................................................... 34 3.- Escenario simple con soporte a Desarrollo y Produccin ............................................. 35 3.1.- Rama Dev..................................................................................................................... 35 3.2.- Rama Main ................................................................................................................... 36 3.3.- Rama Release .............................................................................................................. 37 3.4.- Flujo de trabajo .............................................................................................................. 37 4.- Escenarios Complejos de Branching ..................................................................................... 40 4.1.- Gua de Branching de Visual Studio ALM Rangers ................................................ 40 4.2.- Gestionando Productos y Componentes ................................................................ 41 5.- Directorios de Trabajo ............................................................................................................ 45 5.1.- Organizacin de elementos dentro de una rama en el Source Control ......... 45 5.2.- Mala Prctica: Compartir componentes comunes en recursos de red ........... 47 5.3.- Opinin: Bibliotecas externas: referenciar ensamblados o incluir proyectos? 50 6.- Conclusin................................................................................................................................... 52 6.1.- Opinin: Qu aporta Visual Studio ALM? .............................................................. 52 6.1.1.- Polticas de CheckIn .............................................................................................. 53 6.1.2.- Integracin con Windows Explorer .................................................................. 56 6.1.3.- CheckIn Notes ....................................................................................................... 57
v

vi

Trabajando en equipo con Visual Studio ALM

- Experiencias reales en desarrollo de proyectos de software

7.- Extras ............................................................................................................................................ 58 7.1.- Tip: Herramientas fundamentales para trabajar con Source Control .............. 58 7.1.1.- Team Foundation Server Power Tools ............................................................ 58 7.1.2.- Team Foundation Server MSSCCI Provider ................................................... 58 7.1.3.- Team Foundation Sidekicks ................................................................................. 59 7.1.4.- TFS Source Control Explorer Extension ......................................................... 59 7.2.- Team Foundation para usuarios de SubVersion .................................................... 60 3.- GESTIN DEL TRABAJO .............................................................................. 63 1.- Un poco de sentido comn .................................................................................................... 64 1.1.- La herramienta adecuada para cada problema: El Valentino y su rayo de la muerte 66 2.- CMMI, AGILE, SCRUM; un poco de todo .......................................................................... 67 2.1.- Un poco de historia. ..................................................................................................... 67 2.2.- El comienzo de los problemas .................................................................................... 69 2.3.- Una alternativa saludable: Welcome to AGILE ...................................................... 70 3.- Gestin para dummies ............................................................................................................. 72 3.1.- Cmo gestionar las necesidades de los clientes? ................................................. 75 3.2.- Historias de Usuario en AGILE. ................................................................................. 78 3.2.1.- Frodo, Gandalf y las historias de usuario......................................................... 79 3.2.2.- Tutorial: Registrar User Stories utilizando Microsoft Excel e importarlas a Team Foundation. ............................................................................................................ 81 3.3.- Proyecto Valmar: Gestionando el inicio de un proyecto con Visual Studio ALM. 83 3.3.1.- Tutorial: Crear elementos iniciales para la gestin de un proyecto ......... 92 3.3.2.- Tutorial: Crear una consulta para mostrar el avance de las historias de usuario.................................................................................................................................... 98 3.3.3.- Tutorial: Analizar el avance de las historias de usuario utilizando Microsoft Excel. ................................................................................................................. 100 4.- Gestionando proyectos ......................................................................................................... 103 4.1.- The Inception Deck..................................................................................................... 104 4.1.1.- Qu sucede cuando no hablamos? ............................................................... 106 4.2.- La importancia de la gestin de riesgos ................................................................. 107 4.2.1.- Tutorial: Crear una hoja de gestin de riesgos ............................................ 108 4.3.- Estimar o adivinar el futuro?, mejor organizamos el trabajo. ......................... 111 4.4.- El Product Backlog....................................................................................................... 113 4.5.- Trabajando con iteraciones. ...................................................................................... 115 4.6.- Trabajando con iteraciones en Visual Studio ALM. ............................................ 117 4.6.1.- MSF for Agile, consultas y documentos por iteracin. .............................. 119 4.6.2.- Tutorial: Copiar consultas para una iteracin a partir de las consultas de la iteracin 1 ....................................................................................................................... 120 4.6.3.- Tutorial: Copiar documentos para una iteracin a partir de los documentos de la iteracin 1. ........................................................................................ 120 4.7.- Valmar: Comenzando a dar forma a la aplicacin ............................................... 122 4.7.1.- Configurando el Product Backlog .................................................................... 122 4.7.2.- Gestionando las Iteraciones ............................................................................. 125 4.7.3.- Relato: La princesa Martina, la caza del dragn y los planes al garete ... 129
vi

Contenido vii

5.- Kanban y Team Foundation .................................................................................................. 133 5.1.- Introduccin a Kanban ............................................................................................... 133 5.2.- Valmar: Gestionando un equipo de desarrollo con Kanban ............................. 138 5.2.1.- Tutorial: Cmo agregar un estado a la definicin de un WorkItem ...... 143 5.2.2.- Tutorial: Cmo agregar condiciones a los cambios de estado en la definicin de un WorkItem ............................................................................................ 145 6.- Conclusin................................................................................................................................. 147 4.- CALIDAD ....................................................................................................... 149 1.- Qu entendemos por calidad ............................................................................................... 150 1.1.- Relato: El piloto que pasa por produccin antes de terminar en la basura .. 153 2.- Calidad de Cdigo ................................................................................................................... 154 2.1.- Unit Testing, Code Coverage, TDD, Refactoring, Code Analysis, etc.: De 1 a 100 Km/h en 10 pginas ....................................................................................................... 155 2.2.- Team Build: Automatizando la evaluacin de parmetros de calidad ............ 166 2.3.- Opinin: Realmente de qu sirve la cobertura de cdigo? ............................. 172 2.4.- Team Build: Analizando el detalle de la ejecucin de un Build. ....................... 173 2.4.1.- Tutorial: Crear una Custom Activity para Team Build .............................. 178 2.4.2.- Tutorial: Incluir el anlisis de estilo de cdigo StyleCop en Team Build 182 2.5.- Opinin: Qu tipos de definiciones de Build debo crear para mi aplicacin? 190 2.6.- Sugerencia: Formato nombres para las definiciones de Builds......................... 192 2.7.- Team Build: Dnde almacenar los ensamblados comunes de las Builds? .... 194 3.- Testing funcional ...................................................................................................................... 196 3.1.- Opinin: Cmo gestionar los errores funcionales en mi equipo de desarrollo?................................................................................................................................ 198 3.2.- Microsoft Test Manager ............................................................................................. 199 APNDICE A: TCNICAS VARIAS .................................................................. 205 1.- Colaboracin ............................................................................................................................ 206 2.- Reuniones .................................................................................................................................. 208 NDICE ANALTICO .......................................................................................... 211

CAPTULO

Application Lifecycle Management

Cuando haces las cosas bien, la gente no est tan segura de si has intervenido. Dios (Segn Futurama) Si buscas resultados distintos, no hagas siempre lo mismo. Albert Einstein

En cada proyecto de desarrollo de software en el que participamos hay diferentes desafos que hacen que ste sea interesante. En realidad todos los proyectos son casi iguales, pero la necesidad intrnseca de algunas personas de hacer las cosas diferentes cada vez, hace que siempre sean un desafo. Si ahora mismo reflexionamos sobre las decisiones que hemos tomado en anteriores proyectos, identificaremos aciertos y errores. De hecho, algunos de los errores cometidos sabramos corregirlos a da de hoy. Entonces, por qu no lo hemos hecho bien desde el inicio? Muy sencillo, la principal razn es que el paso del tiempo nos ha dado mucha ms experiencia y seguramente hoy tomara decisiones teniendo en cuenta otros parmetros. ALM se basa, en gran parte, en tomar decisiones relacionadas con la forma de trabajo, con las herramientas, con la forma de hacer Coaching en un equipo, etc.; y como toda decisin, la opcin elegida depende del contexto y de las variables que influyen en el mismo.

11

12 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

1.- POR QU ESCRIBO ESTE LIBRO?


Mi visin del desarrollo del software es 100% prctica. Durante mis aos de experiencia he tenido la suerte de pertenecer a variados equipos de desarrollo y de cumplir roles diferentes en cada uno de ellos. Si bien entiendo que, una formacin especializada para cada rol es necesaria, tambin creo que, trabajando se forman conocimientos duraderos y es por eso que el enfoque de este libro est orientado a mostrar escenarios reales con herramientas reales. Los que tengis este libro en vuestras manos no har falta que os explique por qu hablo principalmente de Visual Studio: es la herramienta con la que he madurado como profesional durante los ltimos aos. Pero esto tampoco implica que los escenarios comentados en este libro no se puedan llevar adelante con otra herramienta, ni tampoco que se descarten para entornos No Visual Studio. Mi libro anterior (Visual Studio 2010 .NET 4.0 y ALM: Actualzate desde la versin 2008) est enfocado a dar un repaso por las novedades de Visual Studio 2010. Al intentar abarcar un producto tan completo es inevitable que parte de los contenidos se descarten tras sucesivos borradores y acaben como material para posts de mi blog. En este libro el objetivo es diferente, no se centra en el producto propiamente dicho (aunque encontraris algunos tutoriales) sino ms bien en la experiencia adquirida trabajando con el producto. El ejemplo ms concreto es el de las dichosas User Stories/Requirements y las Tasks de las plantillas de Team Foundation. Muchas personas conocen como funciona Team Foundation, sin embargo siempre hacen las mismas preguntas: Cmo organizo mi equipo utilizando Team Foundation? Cmo organizo las tareas en mi equipo? De cuntas horas debe ser una tarea?, 4 40? Debo crear una tarea especial para las tareas de Refactoring? Etc.

Como parte de las experiencias que intento compartir en este libro, hay una gua inicial con 20 tareas que son propias PARA EL INICIO DEL 98% DE LOS PROYECTOS CON VISUAL STUDIO ALM (me dejo un 2% para las excepciones, gracias Murphy). Este libro est dirigido a aquellas personas que tienen un conocimiento bastante profundo de Visual Studio y Team Foundation. En muchas ocasiones comentar algn relato con una historia particular sobre un tema, y luego mi experiencia llevndola adelante con Visual Studio. Y si bien lo he intentado, no he podido dejar de hablar de los siguientes temas en este libro: Zombis

Application Lifecycle Management 13

Vampiros Dragones Gandalf (explicar por qu es una mala persona) El Valentino

por mencionar slo algunos. Cmo es posible empezar hablando de Visual Studio y terminar hablando del mago blanco? Sencillo, lo importante en este punto no son las herramientas ni la forma en la que trabajamos con las mismas. Lo verdaderamente importante es la experiencia que acumulamos al trabajar con estas herramientas y la capacidad que tenemos para adaptarla a nuestros problemas de negocio. Por ejemplo, as como las metodologas de desarrollo fueron cambiando en los ltimos 20 aos, las herramientas de desarrollo tambin. Lo que hoy conocemos como Entorno de Desarrollo Integrado (del ingls, IDE: Integrated Development Environment), representa una evolucin frente a los compiladores originales con los que se trabajaba hace 20 aos. Aplicndolo al mundo Microsoft, si bien es cierto que es posible escribir cdigo C# en el bloc de notas y compilarlo utilizando las herramientas de .NET Framework, nadie utiliza esta forma de trabajo para crear aplicaciones. Hoy aprovechamos que los IDEs ya no son slo un entorno de desarrollo, sino que adems brindan capacidades de depuracin, de diseo grfico, de gestin de proyectos, etc. Lo que hace 10 aos se realizaba usando 10 herramientas diferentes, hoy el paquete de Visual Studio + Team Foundation Server permite hacerlo desde un nico punto y con la informacin de los diferentes aspectos consolidada. Las herramientas han madurado, las metodologas han madurado, pero el proceso de creacin de software sigue siendo una tarea difcil, llena de obstculos, y por lo general definida por DeadLines y Budgets. Esto no quita que sea un desafo y que muchas veces sea divertido. Bueno lo de divertido, puede ser un poco subjetivo, pero os aseguro que ya sea programando o ayudando a que un equipo salga adelante con un proyecto, yo me lo paso bien.

2.- APPLICATION LIFECYCLE MANAGEMENT


La sigla de moda hoy es ALM (Gestin del Ciclo de Vida de una Aplicacin), pero la problemtica del desarrollo del software existe desde hace varias dcadas y, lamentablemente, las bases de los problemas no han cambiado. El objetivo final de una implantacin de ALM, como por ejemplo Visual Studio y Team Foundation Server, es eliminar estos problemas y acercar las capacidades del departamento de IT a las lneas de negocio en una organizacin. La finalidad de ALM no es solo controlar el ciclo de vida de una aplicacin, sino ayudar a identificar una idea o un requerimiento de negocio y brindar las capacidades para llevarlo adelante, incluyendo la implantacin y mantenimiento del mismo.

14 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

Lo ms importante de la adopcin de una solucin de ALM es la innovacin. Pero que todo el mundo est de acuerdo sobre un tema, no significa que sepamos cmo sacarlo adelante. A la hora de innovar lo principal es proporcionar los mecanismos que permitan que llevar a cabo las propuestas y evaluar los resultados. Al final siempre perseguimos lo mismo: ser el primero o ser el mejor. Un ejemplo prctico: Pensemos un segundo en la primera aerolnea que comenz a utilizar estaciones de CheckIn automtico en los aeropuertos. Utilizando este sistema sac una gran ventaja sobre sus competidores durante un tiempo. La segunda aerolnea que lo implement, sac un poco menos de ventaja sobre sus competidores, pero segua siendo un diferencial frente a la competencia. Actualmente es un gasto establecido en todas las aerolneas de un nivel medio y aquellas que no lo asumen, estn un paso por detrs de sus competidores. Adems de la innovacin y de los mecanismos para identificar proyectos innovadores, es necesario que la plataforma de ALM sea una plataforma robusta y est adaptada a las estrategias de la organizacin. Ninguna implementacin de ALM con las configuraciones que vienen por defecto en el producto es una solucin adecuada para una empresa. Veamos otro ejemplo (Todava en las primeras pginas y me he centrado ms en comentar ejemplos que en de hablar de Visual Studio ALM, ste no parezco yo!): Ahora pensemos en una organizacin con una gestin realmente muy complicada de un producto de software que se desarrolla por un equipo interno de la empresa. Este producto, adems, est instalado en 3 clientes diferentes lo cual implica la personalizacin del mismo para cada uno. Por otro lado, los requerimientos y los cambios solicitados por cada cliente suelen quedar perdidos en una coleccin de correos. Para solventar este problema, esta empresa pens que desplegando la solucin de Visual Studio ALM todos sus problemas quedaran eliminados mgicamente a partir de ese momento. Cuando llegamos a esta organizacin, lo primero que hicimos, antes siquiera de pensar en cambiar sus productos actuales o su forma de trabajo, fue sentarnos con ellos e intentar conocerlos. Es decir, realizar un pequeo anlisis sobre su proceso actual de desarrollo. Este anlisis nos permiti darnos cuenta de que muchas de las carencias y problemas que tenan se podan solucionar sin la necesidad de utilizar Visual Studio ALM; pero que, si adems sumbamos la potencia de Visual Studio ms Team Foundation a su ciclo de vida, el resultado sera un win/win. Por ejemplo, a la hora de organizar el cdigo fuente existan diferentes ramas para cada implementacin de su producto, adems de una rama principal donde se gestionaba el Core del producto. Uno de los problemas ms grandes era que la gestin de las caractersticas o funcionalidades que se agregaban en cada rama se realizaba utilizando hojas Excel. Lo mismo suceda con los Bugs. Esto ocasionaba que,

Application Lifecycle Management 15

muchas veces, un mismo bug se solucionaba por duplicado para diferentes ramas, duplicando as el gasto de mantenimiento del producto. Pero esto no es todo, adems, era comn que la solucin del mismo Bug en cada una de las ramas se realice de forma diferente, con lo que la estabilidad del cdigo tampoco es la ideal; y para terminar de complicarlo, si alguien solucionaba un Bug en una rama, y por las prisas no completaba la hoja Excel, este mismo Bug quedaba vivo en otras implantaciones del mismo producto. Cuando un cliente encuentra un Bug en un producto desplegado esto tiene varias implicaciones asociadas. La ms obvia es que hay un problema que arreglar, y esto es algo que hay que hacer s o s. Pero adems, tiene un coste que es muy difcil de medir: el que se genera con la prdida de calidad de tu producto.

Nota: Para hacernos una idea del dao que puede ocasionar tener productos de mala calidad, lo mejor es pensar en el tipo de prensa que recibe Microsoft cuando se descubre un problema en Windows.

Si de alguna forma fuese posible anticiparse a estos problemas (todos sabemos que no existe el software perfecto, salvo SkyNet); la confianza en un producto sera mucho ms fcil de gestionar. Para continuar con el ejemplo, volvamos al tema Windows. Todos los mircoles recibo una serie de actualizaciones utilizando el sistema de actualizacin automtica de Windows llamado Windows Update. Estoy convencido de que las actualizaciones que se distribuyen con Windows Update mejorarn la calidad de mi Sistema Operativo. Si la empresa a la que antes hacamos referencia pudiese desplegar parches proactivamente para estabilizar su software en las 3 implantaciones del mismo, se ahorrara muchos problemas de gestin con los clientes con los que trabaja. Hasta aqu en ningn momento hemos hablado de implantar Visual Studio ALM. Adems, Visual Studio ALM no posee ningn mecanismo out of the box para solventar esta casustica. Pero, s podemos aprovechar las capacidades de Visual Studio ALM para encarar estos escenarios con una solucin mucho ms robusta y adaptada a las necesidades puntuales requeridas. Y en esto consiste ALM: identificar los procesos de trabajo de una empresa para la creacin de artefactos de software y dar solucin a los mismos utilizando las mejores herramientas posibles. A qu nos referimos con las mejores herramientas posibles? Sabemos que las personas son importantes, pero las herramientas tambin. Y ALM tambin es parte de esto ayudando a lograr que las personas puedan dar su mximo potencial posible utilizando las herramientas adecuadas en cada momento.

16 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

2.1.- La herramienta correcta para el problema adecuado.


Muchas veces hemos escuchado la frase cuando tienes un martillo en tu mano, todo te parece un clavo; y aunque es triste reconocerlo, muchas veces intentamos adaptar un problema para que pueda ser solucionado con un determinado enfoque o herramienta. El gran inconveniente de esta forma de trabajo es que ensuciamos el problema original aadiendo un sobre esfuerzo no estimado a la solucin. En estos casos es usual que: A. Se piense en adaptar el problema original a nuestro enfoque o herramienta. B. Se piense en la solucin al problema original. Ahora bien, como la solucin del problema es algo que termina llegando s o s (es increble como en nuestra profesin los problemas siempre se terminan solucionando de una forma u otra, un flag en esta lnea); centramos todos nuestros esfuerzos en el punto A. Esto es una tendencia natural que se da en los equipos de desarrollo ya que, frente a la opcin de solucionar un problema conocido o la oportunidad de crear un nuevo producto, la segunda opcin es mucho ms atractiva puesto que, muchas veces, involucra un desafo tcnico que seguramente podr ser reutilizado en el futuro. Para que pueda ser reutilizable es necesario hacerlo bien: aplicar las mejores prcticas, tener un buen diseo de la arquitectura del producto, implementar un ciclo de pruebas correcto, gestionar correctamente el despliegue y utilizacin, etc. Esto es un producto! Como probablemente se implementar utilizando un enfoque gil, en poco tiempo ser posible mostrar una primera versin a un usuario final. Eso permitir depurar el producto, mejorarlo y hacerlo ms adaptable a futuros problemas que desconocemos, ya que nunca se sabe cundo podr ser necesitado. En la segunda iteracin y con el producto ya estable la idea es ir ms lejos, es intentar que el producto no sea una solucin a un problema especfico, sino que sea la solucin a todos los posibles problemas. Esto que parece complicado, y que la humanidad est intentando conseguir desde hace un par de milenios, es muy simple en manos de un equipo de desarrollo: el diseo del producto soporta un esquema de configuracin extensible que permite que el producto se adapte a cualquier situacin. Y manos a la obra!: clases, interfaces, configuracin extensible, una buena herramienta de configuracin, etc. Todo esto sigue su curso natural hasta que se cumple un nuevo trimestre y todava el problema del punto B sigue vivo y quedan menos de 2 das para solucionarlo. Empiezan entonces los apretones por parte de gerencia, la venta del producto desarrollado por parte del equipo de desarrollo y nos encontramos al final del camino sin haber alcanzado un acuerdo ya que: A. La solucin al problema original no existe. B. Existe un producto mgico que parece solucionar todos los problemas, pero implementarlo es bastante caro.

Application Lifecycle Management 17

Podramos seguir dndole vueltas a esta historia, ya que por lo general en este punto suele aparecer un bombero que es encargado de apagar todos los incendios; pero el punto inicial de esta seccin es: Para cada problema existe una herramienta adecuada para solucionarlo Y lo importante en este punto es tener en cuenta que en nuestro trabajo, las herramientas son imprescindibles y saber utilizarlas allana el camino. El conocimiento de las herramientas sumado al conocimiento del negocio hace que la aplicacin de la tecnologa para un negocio resulte realmente rentable.

Nota: Me encanta leer! De pequeo lea casi todo lo que caa en mis manos y recuerdo con especial cario una serie de libros de zombis que estaban ambientados en el siglo XIX. En esta poca, la lucha con los zombis se realizaba a machetazo limpio. Eran luchas donde la poca velocidad de los zombis se vea compensada por la tozudez y la cantidad de los mismos. Cuando un protagonista de la novela descuartizaba a un zombi con un hacha, le aparecan dos ms detrs de la puerta. Huelga decir que despus de 3 pginas este personaje era uno ms de los infectados y bueno os podis imaginar el resto. Hoy cuando juego al Call Of Duty en la XBOX360 y viene una oleada de zombis, una de las opciones que tengo es sacar mi cuchillo de marine y defenderme con el mismo. Pero adems dispongo de una escopeta recortada que, aunque no da mucha precisin en el disparo s aumenta el rango de disparo. Es decir, sigo la regla la herramienta correcta para el problema adecuado.

3.- QU INCLUYE ESTE LIBRO?


Empecemos con la lista de exclusiones: Material tcnico y didctico relacionado con temticas de gestin de proyectos. Es evidente que aquellos que deseen conocer como certificarse en CMMI, o las bases de AGILE, o que quieran ser un SCRUM Master Certificado, escogern a una lectura ms orientada a cada uno de los casos. Pginas y pginas con detalles de metodologas de trabajo. Es decir, todos aquellos que conocen las ventajas de AGILE no necesitan que les recuerden por qu es importante que el cliente sea uno ms en el equipo. Manuales de usuario de la herramienta. Si bien algunos trucos de Visual Studio y Team Foundation son comentados paso a paso, la referencia de MSDN sigue siendo el mejor sitio para aprender a conocer estas herramientas. Silver Bullets.

18 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

Lo realmente importante de este libro es que ensea cmo dar los primeros pasos hacia la gestin de proyectos utilizando Visual Studio, lo cual permite tener el control sobre los diferentes elementos que componen un proyecto. En los prximos captulos veremos algunos escenarios sobre gestin del cdigo fuente, intentando ir un poco ms all de una simple estrategia de Branching y Merging. Tambin veremos como la gestin de requerimientos, bugs, y otros elementos nos pueden ayudar a mejorar la calidad de nuestras aplicaciones. Y finalmente cuando hablamos de calidad, veremos como el Testing, la automatizacin de compilaciones y de otras acciones nos ayudan a tener controladas esas mtricas de calidad.

Figura 1- Trabajo con Team Foundation.

La imagen anterior muestra un pequeo ejemplo sobre como Team Foundation ayuda a controlar estos puntos. Lo interesante en este caso es que no son elementos independientes entre s, sino que a partir de la informacin relacionada de los mismos podemos tomar decisiones de gestin. Si por ejemplo, la calidad de una compilacin de una aplicacin en produccin no es buena, podremos ver con qu nivel de aceptacin se decidi dar el visto bueno a la produccin de la misma. Y adems, ver si lo que se despleg es lo que realmente sali del laboratorio como aprobado. Estos casos y algunos ms sern explicados en las prximas secciones del libro.

4.- CMO EJECUTAR LOS EJEMPLOS?


Como hemos comentado al inicio, ste no se trata de un libro de gestin puro y duro. Aqu la idea es desglosar los diferentes aspectos de la gestin de un proyecto utilizando las herramientas de Visual Studio Application Lifecycle Management. Con el objetivo de que cualquiera pueda probar los ejemplos del libro sin coste alguno (o mnimo), todos los ejemplos se han realizado con las mquinas virtuales que distribuye gratuitamente Microsoft y en las que se puede encontrar todo el software incluido en el paquete de Visual Studio ALM. Actualmente estas mquinas virtuales se pueden descargar desde la pgina de descarga oficial de MSDN (http://bit.ly/nuJSKw). Tienen instalado el siguiente software.

Application Lifecycle Management 19

Windows Server 2008 SQL Server 2008 Microsoft Office 2010 Visual Studio 2010 Ultimate Team Foundation Server 2010

Adicionalmente es recomendable instalar las siguientes extensiones para Visual Studio y Team Foundation puesto que se utilizarn durante los ejemplos prcticos del libro.
Tabla 1- - Extensiones adicionales para Visual Studio 2010.

Herramienta Team Foundation Server Power Tools TFSSCExplorerExtension TFS Workbench Inmeta Build Explorer TFS Build Extensions StyleCop

Link http://j.mp/j6N9eS http://bit.ly/r6FF16 http://bit.ly/nzszAv http://bit.ly/roTvY2 http://bit.ly/mRUQL7 http://bit.ly/niG5Y4

Asimismo estas mquinas virtuales poseen ya configurados una serie de usuarios con sus roles correspondientes. Los usuarios que posee la mquina virtual y que utilizaremos en el libro son:
Tabla 2- - Roles y usuarios

Usuario Administrator Abu Obeida Bakhach April Stewart Chris Barry Christine Koch Doris Krieger Michael Affronti Robin Wood Adrian Gonzalez Bruno Capuano

Id WINGS9GMUJITS8\administrator WIN-GS9GMUJITS8\abuobe WIN-GS9GMUJITS8\aprist WIN-GS9GMUJITS8\chriba WIN-GS9GMUJITS8\chriko WIN-GS9GMUJITS8\dorikr WIN-GS9GMUJITS8\michaf WIN-GS9GMUJITS8\robiwo WIN-GS9GMUJITS8\agon WIN-GS9GMUJITS8\elbruno

Rol Server Administrator Developer Developer Lead Stakeholder Tester Developer Project Manager End User IT Guy ALM Tech Buddy

Para dar soporte a cuestiones de infraestructura en algunos ejemplos del libro, se ha creado el usuario Adrian Gonzalez. Y tambin, para darme visibilidad, he creado un usuario Bruno Capuano, para que cuando Bing/Google indexe este PDF tenga una buena posicin en el resultado de las bsquedas.

20 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

Tambin ha sido exportada la Team Project Collection que se ha utilizado a lo largo de todo el libro ALMBook; para que el lector tenga acceso al cdigo fuente, a las definiciones de Build y a las definiciones de WorkItems.

Figura 2 - Team Project Collection con ejemplos.

En el sitio web del libro o en mi blog http://www.elbruno.com estar el link disponible para descargar la Team Project Collection. Los siguientes links pueden ayudarte a realizar este procedimiento: [TFS2010] HowTo: http://bit.ly/qm7Jk8 [TFS2010] HowTo: http://bit.ly/nk4hfY Desadjuntar Adjuntar un un Team Team Project Project Collection Collection

Finalmente si te animas, ha sido creado un BackUp diario de los elementos en la mquina virtual que pueden ayudarte a tener todo el entorno configurado en pocos minutos. Para restaurar este BackUp necesitas la mquina virtual con la ltima versin de las Power Tools de TFS y un poco de conocimiento sobre cmo realizar esta accin.

CAPTULO

Source Control

Si no has adoptado una estrategia de gestin del cdigo fuente, tu proyecto est predestinado al fracaso. Alguien lo coment en los VS ALM Rangers. Save your imagination for your product and not your branch plan. Tambin los ALM Rangers.

Es increble la cantidad de proyectos en los que he participado donde el repositorio de cdigo fuente era simplemente eso un repositorio. Si bien las herramientas lo tienen contemplado desde hace muchas versiones, la adopcin de una estrategia de Branching y Merging parece ser un imposible en muchos de los casos. Los sistemas tradicionales de gestin de ficheros como SubVersion, CVS o inclusive Visual Source Safe soportan Branching y Merging; pero el desconocimiento muchas veces hace que se pierdan estas funcionalidades y se comience a buscar soluciones alternativas y muy ingeniosas para dar soporte a las situaciones ms clsicas en los proyectos de desarrollo. En este captulo veremos algunas opciones que pueden ayudar a la configuracin inicial de un repositorio de cdigo fuente y algunos consejos sobre cmo trabajar con el mismo.

21

22 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

1.- UN POCO DE BRANCHING


Antes de comenzar a desarrollar el captulo, es necesario sentar algunos conceptos que, aunque probablemente el estimado lector ya posee, nunca est dems revisar lo obvio. Como dice el dicho: Un buen programador es aquel que antes de cruzar una calle de un nico sentido mira a ambos lados. En primer lugar vamos a explicar el concepto de rama o Branch en un repositorio de cdigo fuente. Esta es la definicin de Branching segn Wikipedia (http://j.mp/mgZypv) Branching, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file, or a directory tree) so that modifications can happen in parallel along both branches. En otras palabras, una rama o Branch es una copia de un elemento en un repositorio sobre el que luego es posible realizar modificaciones. El aspecto ms interesante de las ramas es que permiten acciones a posteriori para comparar con los elementos originales de las mismas o acciones de integracin (Merge) para unificar los cambios entre diferentes ramas. Esta es la definicin para la accin de Merge segn Wikipedia (http://j.mp/mUln3T) Merging (also called integration) in revision control, is a fundamental operation that reconciles multiple changes made to a revision-controlled collection of files. Most often, it is necessary when a file is modified by two people on two different computers at the same time. When two branches are merged, the result is a single collection of files that contains both sets of changes.

1.1.- Opinin: El miedo al Merge


El miedo al Merge es un clsico, ms o menos como lo que pasa con los vampiros ahora en el ao 2011. Me explico: cuando yo era un cro (hace unos 20 aos), un vampiro era una cosa muy seria, haba que tenerle miedo. Por lo general, el estereotipo de un vampiro era una persona de algn pas de Europa del Este, tradicionalmente de Transilvania, con la piel muy blanca y una capa negra. Adems de tener una mirada que te dejaba helado, un buen vampiro sola tener un par de ayudantes malvados, que tenan un buen corazn, pero con las ideas un poco torcidas. Si por algn motivo cometas el error de invitar a un vampiro a tu casa ah empezaban tus verdaderos problemas. Seguramente el vampiro se enamorara de tu madre, de tu hermana o de tu novia, y con la promesa de amor eterno, en algn momento le querra chupar toda la sangre. Dependiendo del tipo de vampiro, podra

Source Control 23

incluso querer comrsela con mayonesa o ktchup (siempre pens que los vampiros eran ms de ktchup). Esta idea de los vampiros estaba muy extendida y la gente se asustaba al ver a una persona de estas caractersticas por la calle, entonces llegaron las escritoras de novelas juveniles para cambiar el concepto que tenemos de los vampiros. Ahora los vampiros del siglo XXI son chicos que parecen no tener ms de 20 aos, que pueden caminar bajo el sol pero siguen teniendo la piel ms blanca que la nieve. Por lo general se enamoran de la chica ms guapa del pueblo, pero sin la intencin de comrsela. Al contrario, la ayudan si es atacada por un hombre lobo, o si se la quieren comer otros vampiros con ms hambre. Las cosas han cambiado mucho, pero la idea sigue estando all: Los vampiros son seres de cuidado que en cuanto puedan te darn un problema. Pues algo parecido pasa con los Branches y con las acciones de Merge. En muchos proyectos, se le tiene miedo al Merge y es por esto que no se utilizan Branches. Pero al igual que ha pasado con los vampiros, los Branches y Merges han cambiado mucho ltimamente. No es un trabajo tan artesanal como era hace 15 aos, las herramientas que disponemos ahora realmente ayudan a que la experiencia del desarrollador sea ms amigable y mucho menos dolorosa. Pero ojo, siguen siendo Branches y Merges y en malas manos pueden traernos, no uno, sino muchos dolores de cabeza; al igual que pasa con los vampiros modernos.

1.2.- Tutorial: Creacin de un escenario simple de ramas


A continuacin haremos un ejemplo muy simple utilizando Visual Studio 2010 y Team Foundation Server 2010. Dicho ejemplo consiste en crear un directorio principal, agregar contenido y por ltimo crear una rama a partir del mismo. Si ya sabes realizar estas acciones ve directamente al siguiente epgrafe. Los pasos a seguir son: 1. Abrir Visual Studio 2010. 2. Conectarse a un servidor Team Foundation donde sea posible realizar pruebas de trabajo con Source Control. 3. Acceder al panel Source Control Explorer. 4. En el Source Control Explorer crearemos un directorio llamado Main. 5. En este punto debemos marcar este directorio para que Team Foundation lo trate como un Branch. Para ello se selecciona este directorio, se despliega el men contextual y por ltimo se selecciona la opcin Branching and Merging // Convert to Branch. 6. Dentro del mismo agregaremos un archivo de texto plano llamado demo.txt.

24 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

7. Editamos el archivo de texto y agregamos el siguiente texto dentro del mismo:


Hola Martina Hola Valentino

8. Protegemos los cambios en el repositorio de cdigo fuente. En este momento el repositorio debera tener una estructura similar a la que se muestra en la siguiente imagen:

Figura 1- Creacin de la rama Main y un archivo dentro de la misma.

El histrico de cambios del directorio Main debe mostrar informacin relacionada con la creacin de la rama y del archivo que hemos agregado en la rama. 9. A continuacin crearemos una rama a partir de Main. Para esto seleccionamos la rama Main, desplegamos el men contextual y seleccionamos la opcin Branching and Merging // Branch, definiendo como Child el nombre de la nueva rama. Aclaracin: Esta opcin crea una nueva rama, pero tenemos que tener en cuenta que podemos crear la misma a partir de la ltima versin de cdigo en local, de una etiqueta, de una fecha determinada, etc. 10. Una vez creada la rama podremos ver que la misma aparece en el Source Control con un apariencia similar a la mostrada a continuacin:

Source Control 25

Figura 2 - Creacin de la rama Child a partir de Main

11. Una vez creadas las ramas podemos comenzar a ver las funcionalidades que nos ofrece Visual Studio 2010 para trabajar con ellas. Por ejemplo, tras seleccionar la rama Main, desplegamos el men contextual y seleccionamos la opcin Branching and Merging // View Hierarchy, veremos la estructura de padres e hijos que poseen las ramas que hemos configurado.

Figura 3 - Vista de jerarquas de Branches en Visual Studio 2010

Veamos ahora qu sucedera al modificar los contenidos de los documentos en las diferentes ramas. 12. Editamos el archivo Main\demo.txt y modificamos el siguiente cdigo en dicho archivo y lo protegemos.
Hola Martina :D Hola Valentino

13. Editamos el archivo Child\demo.txt y modificamos el siguiente cdigo en dicho archivo y lo protegemos.

26 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

Hola Martina Hola Valentino :D

14. En este momento tenemos dos versiones diferentes del archivo Demo.txt, por lo que, llegados a este punto lo lgico es realizar un Merge de los contenidos del archivo entre las ramas Main y Child. La siguiente imagen muestra la lnea temporal con este cambio, desde la rama Main hacia la rama Child.

Figura 4 - Ejemplo de lnea temporal

15. Para realizar un Merge seleccionamos la rama Main, desplegamos el men contextual y seleccionamos la opcin Branching and Merging // Merge, seleccionando Child como rama de destino. 16. Como los contenidos de ambos archivos son diferentes aparecer una ventana para resolver dicho conflicto donde se muestran las siguientes opciones: a. Mantener el contenido de la rama origen.

b. Mantener el contenido de la rama destino. c. Realizar un Merge automtico

d. Realizar un Merge manual.

Source Control 27

Figura 5 - Resolucin de conflictos en una accin de Merge

17. Haciendo un Merge manual y utilizando las nuevas lneas de cada versin el contenido del archivo sera el siguiente:
Hola Hola Hola Hola Martina Martina :D Valentino :D Valentino

18. Visual Studio 2010 muestra en el histrico de cambios los diferentes estados por los que ha pasado el archivo; desde su creacin en la rama Main hasta la modificacin en la rama Child. Tambin permite ver estos cambios en una lnea temporal como muestra la siguiente imagen. En la misma podemos ver como se han propagado los cambios entre las diferentes ramas y las fechas en las que se han realizado estos cambios.

Figura 6 - Vista histrica en Visual Studio 2010

28 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software

1.3.- Tip: Utilizar WinMerge con Visual Studio 2010


La herramienta que trae por defecto Visual Studio para comparar y realizar Merge entre archivos es bastante til, sin embargo, existen muchas herramientas en el mercado que brindan mejores capacidades a la hora de realizar estas tareas. Un ejemplo de ello lo constituye WinMerge (http://j.mp/mQDgHP). Se trata de una alternativa gratis y mucho ms potente que la incluida por defecto junto con Visual Studio. Los siguientes pasos describen como configurar Visual Studio para utilizar WinMerge como herramienta de comparacin y Merge de archivos. 1. Abrir Visual Studio 2010 2. Acceder al menu Tools // Options 3. Presionar el botn Configure User Tools 4. Seleccionar la opcin Add 5. Agregar la opcin de Comparar, pero en este caso utilizando WinMerge empleando los siguientes valores: a. Extension: .*

b. Operation: Compare c. Command: C:\Program Files (x86)\WinMerge\WinMergeU.exe

d. Arguments: /e /x /s /wl /dl %6 /dr %7 %1 %2 6. Confirmamos la configuracin con OK 7. Agregamos la opcin de Merge con WinMerge utilizando los siguientes valores: a. Extension: .*

b. Operation: Merge c. Command: C:\Program Files (x86)\WinMerge\WinMergeU.exe

d. Arguments: /e /s /x /ub /dl %6 /dr %7 %1 %2 %4 8. Confirmamos la configuracin con OK A partir de este momento, cuando dentro de Visual Studio se hagan acciones de comparar archivos o realizar Merge, la herramienta que lanzar el IDE ser WinMerge.

Te interesa este libro?


Cmpralo en nuestra tienda: www.campusmvp.com

En papel o en formato electrnico Sin DRM Imprimible Busca en el contenido

Especialistas en formacin online y libros de tecnologas Microsoft.

Sguenos y descubrirs los mejores trucos y recursos: