y utilizarlo en todos los dispositivos pertenecientes a su ... · pdf fileagradecimientos...
TRANSCRIPT
Este documento PDF no tiene protección DRM por lo que es posible imprimirlo
y utilizarlo en todos los dispositivos pertenecientes a su comprador
(ordenadores, lectores de ebooks, etc…).
Sin embargo no está permitido compartirlo o cederlo a terceros.
Si has obtenido una copia impresa o digital de este libro a través de un centro
de formación u otra empresa y no lleva tu nombre y apellidos impresos en el
lateral se trata de una copia ilegal. Por favor notifícanoslo a través de nuestra
web para poder tomar las medidas legales oportunas. De ello depende que
podamos sacar otros libros de calidad en el futuro.
Aparte de las marcas de agua y encabezados con los datos del comprador visibles
en el documento, el PDF ha sido marcado con técnicas esteganográficas para
que siempre sea posible relacionarlo de manera unívoca con el comprador
aunque se retirasen dichos elementos visibles.
Gracias por su comprensión.
AVISO IMPORTANTE COPYRIGHT
Trabajando en equipo con
Visual Studio ALM
Experiencias reales en desarrollo de
proyectos de software
Bruno Capuano
*
09/0
8/20
13
C
onte
nido
lic
enci
ado
a:
Cla
udio
V
arga
s A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
TRABAJANDO EN EQUIPO CON VISUAL STUDIO ALM
EXPERIENCIAS REALES EN DESARROLLO DE PROYECTOS DE
SOFTWARE
No está permitida la reproducción total o parcial de este libro, ni su tratamiento informático, ni la
transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia,
por registro u otros métodos, sin el permiso previo y por escrito de los titulares del Copyright.
Diríjase a CEDRO (Centro Español de Derechos Reprográficos, www.cedro.org) si necesita
fotocopiar o escanear algún fragmento de esta obra.
DERECHOS RESERVADOS © 2011, respecto a la primera edición en español, por
Krasis Consulting, S. L.
www.Krasis.com
ISBN: 978-84-939036-9-5
**
Cla
udio
Var
gas
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
l
icen
ciad
o
a:
Agradecimientos
Escribir siempre es una tarea agradable. En mi caso voy escribiendo a medida que voy
aprendiendo con lo que mi blog o las páginas de este libro son un backup que puedo utilizar
más adelante cuando necesito refrescar información. Pero claro, todo este tiempo dedicado
frente a un teclado es tiempo que le he quitado a otras cosas que también disfruto mucho.
Es por esto que en primer lugar tengo que agradecer a mis niñas Paola y Martina, que son
mi soporte para poder sentarme y escribir una, dos o 50 páginas de un tirón.
También a mis compañeros 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,
Víctor, y otros tantos que seguro me olvido.
Tampoco quiero olvidarme de agradecer a la gente de Renfe que durante bastante tiempo
me hacían Upgrades en los viajes a Alicante y a Barcelona para que pudiese tener
electricidad y escribir sin problemas de batería en mi laptop. Y una vez más a mi mujer, que
me hizo darme cuenta que escribir un libro 100% técnico no es lo mío, por algo Pao es Pao.
Al resto de mi familia también 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
también 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 pasión por leer durante los últimos
30 años. Ahora desde hace 2 años, sufro la pasión de escribir en la que todavía soy un
newbie.
Y finalmente al Valentino. Alguno se preguntará ¿por qué a mi niño lo dejo solo al final?
Es muy simple. Hace unos años con el primer libro hicimos un trato con el Valentino. Todo
el dinero que ingresara de la venta de libros iría a parar a su cuenta bancaria hasta que
cumpliese 18 años. La única excusa que El Bruno tenía para sacar ese dinero antes, era que
con el mismo me pudiese comprar un Ferrari 0Km.
Si bien el Valentino tenía casi 2 años y yo pensé que entendía el trato, parece que ya se
daba cuenta que escribiendo libros técnicos jamás llegaría a los €500K. Y ahora disfruta
cuando me ve escribir porque sabe que los beneficios serán todos para él.
Así que, hijo mío, cuando en unos años aprendas a leer y te preguntes cómo hizo tu padre
para conseguir un Ferrari, entenderás por qué el último libro que escribió tu padre no era de
tecnología, sino una novela de amor entre vampiros.
-
09/0
8/20
13
Con
teni
do
lic
enci
ado
a:
Cla
udio
V
arga
s A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
v
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.- ¿Cómo ejecutar los ejemplos? ................................................................................................ 18
2.- SOURCE CONTROL ....................................................................................... 21
1.- Un poco de Branching .............................................................................................................. 22 1.1.- Opinión: El miedo al Merge ........................................................................................ 22 1.2.- Tutorial: Creación de un escenario simple de ramas ........................................... 23 1.3.- Tip: Utilizar WinMerge con Visual Studio 2010 .................................................... 28 1.4.- Opinión: ¿Cuándo 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 Práctica: Magia con Etiquetas ............................................................................ 33 2.2.- Mala Práctica: Magia con el File System ................................................................... 34
3.- Escenario simple con soporte a Desarrollo y Producción ............................................. 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.- Guía de Branching de Visual Studio ALM Rangers ................................................ 40 4.2.- Gestionando Productos y Componentes ................................................................ 41
5.- Directorios de Trabajo ............................................................................................................ 45 5.1.- Organización de elementos dentro de una rama en el Source Control ......... 45 5.2.- Mala Práctica: Compartir componentes comunes en recursos de red ........... 47 5.3.- Opinión: Bibliotecas externas: ¿referenciar ensamblados o incluir proyectos?
50 6.- Conclusión................................................................................................................................... 52
6.1.- Opinión: ¿Qué aporta Visual Studio ALM? .............................................................. 52 6.1.1.- Políticas de CheckIn .............................................................................................. 53 6.1.2.- Integración con Windows Explorer .................................................................. 56 6.1.3.- CheckIn Notes ....................................................................................................... 57
*
Con
teni
do
licen
ciad
o
a:
Cla
udio
V
arga
s A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
vi Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
vi
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.- GESTIÓN DEL TRABAJO .............................................................................. 63
1.- Un poco de sentido común .................................................................................................... 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.- Gestión para dummies ............................................................................................................. 72 3.1.- ¿Cómo 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 gestión 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 gestión de riesgos ................................................................. 107 4.2.1.- Tutorial: Crear una hoja de gestión 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 iteración. .............................. 119 4.6.2.- Tutorial: Copiar consultas para una iteración a partir de las consultas de
la iteración 1 ....................................................................................................................... 120 4.6.3.- Tutorial: Copiar documentos para una iteración a partir de los
documentos de la iteración 1. ........................................................................................ 120 4.7.- Valmar: Comenzando a dar forma a la aplicación ............................................... 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 dragón y los planes al garete ... 129
*
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Con
teni
do
l
icen
ciad
o
a:
Contenido vii
5.- Kanban y Team Foundation .................................................................................................. 133 5.1.- Introducción a Kanban ............................................................................................... 133 5.2.- Valmar: Gestionando un equipo de desarrollo con Kanban ............................. 138
5.2.1.- Tutorial: Cómo agregar un estado a la definición de un WorkItem ...... 143 5.2.2.- Tutorial: Cómo agregar condiciones a los cambios de estado en la
definición de un WorkItem ............................................................................................ 145 6.- Conclusión................................................................................................................................. 147
4.- CALIDAD ....................................................................................................... 149
1.- Qué entendemos por calidad ............................................................................................... 150 1.1.- Relato: El piloto que pasa por producción antes de terminar en la basura .. 153
2.- Calidad de Código ................................................................................................................... 154 2.1.- Unit Testing, Code Coverage, TDD, Refactoring, Code Analysis, etc.: De 1 a
100 Km/h en 10 páginas ....................................................................................................... 155 2.2.- Team Build: Automatizando la evaluación de parámetros de calidad ............ 166 2.3.- Opinión: ¿Realmente de qué sirve la cobertura de código? ............................. 172 2.4.- Team Build: Analizando el detalle de la ejecución de un Build. ....................... 173
2.4.1.- Tutorial: Crear una Custom Activity para Team Build .............................. 178 2.4.2.- Tutorial: Incluir el análisis de estilo de código StyleCop en Team Build
182 2.5.- Opinión: ¿Qué tipos de definiciones de Build debo crear para mi aplicación?
190 2.6.- Sugerencia: Formato nombres para las definiciones de Builds......................... 192 2.7.- Team Build: ¿Dónde almacenar los ensamblados comunes de las Builds? .... 194
3.- Testing funcional ...................................................................................................................... 196 3.1.- Opinión: ¿Cómo gestionar los errores funcionales en mi equipo de
desarrollo? ................................................................................................................................ 198 3.2.- Microsoft Test Manager ............................................................................................. 199
APÉNDICE A: TÉCNICAS VARIAS .................................................................. 205
1.- Colaboración ............................................................................................................................ 206 2.- Reuniones .................................................................................................................................. 208
ÍNDICE ANALÍTICO .......................................................................................... 211
.
..
Con
teni
do
lic
enci
ado
a:
Cla
udio
V
arga
s A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
11
CAPÍTULO
Cuando haces las cosas bien, la gente no está tan segura de si has intervenido. Dios (Según 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 desafíos que hacen que éste sea interesante. En realidad todos los
proyectos son casi iguales, pero la necesidad intrínseca de algunas personas de
hacer las cosas diferentes cada vez, hace que siempre sean un desafío.
Si ahora mismo reflexionamos sobre las decisiones que hemos tomado en
anteriores proyectos, identificaremos aciertos y errores. De hecho, algunos de
los errores cometidos sabríamos corregirlos a día de hoy. Entonces, ¿por qué no
lo hemos hecho bien desde el inicio? Muy sencillo, la principal razón es que el
paso del tiempo nos ha dado mucha más experiencia y seguramente hoy tomaría
decisiones teniendo en cuenta otros parámetros.
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 decisión, la opción elegida depende del contexto y de las
variables que influyen en el mismo.
Application Lifecycle
Management
1
-*
09/0
8/20
13
C
onte
nido
l
icen
ciad
o
a
: C
laud
io
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om
12 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
1.- ¿POR QUÉ ESCRIBO ESTE LIBRO?
Mi visión del desarrollo del software es 100% práctica. Durante mis años 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 formación
especializada para cada rol es necesaria, también 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 tengáis 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 años. 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: Actualízate desde la versión 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 encontraréis algunos tutoriales) sino más bien en la experiencia adquirida
trabajando con el producto.
El ejemplo más 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:
¿Cómo organizo mi equipo utilizando Team Foundation?
¿Cómo organizo las tareas en mi equipo?
¿De cuántas 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 guía
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é algún
relato con una historia particular sobre un tema, y luego mi experiencia llevándola
adelante con Visual Studio.
Y si bien lo he intentado, no he podido dejar de hablar de los siguientes temas en
este libro:
Zombis
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a
: C
laud
io
Var
gas
Ale
jos
Application Lifecycle Management 13
Vampiros
Dragones
Gandalf (explicaré por qué es una mala persona)
El Valentino…
por mencionar sólo algunos.
¿Cómo 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 metodologías de desarrollo fueron cambiando en los
últimos 20 años, las herramientas de desarrollo también. Lo que hoy conocemos como
Entorno de Desarrollo Integrado (del inglés, IDE: Integrated Development
Environment), representa una evolución frente a los compiladores originales con los
que se trabajaba hace 20 años.
Aplicándolo al mundo Microsoft, si bien es cierto que es posible escribir código 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 sólo un entorno de desarrollo, sino que además brindan capacidades de
depuración, de diseño gráfico, de gestión de proyectos, etc.
Lo que hace 10 años se realizaba usando 10 herramientas diferentes, hoy el paquete
de Visual Studio + Team Foundation Server permite hacerlo desde un único punto y
con la información de los diferentes aspectos consolidada.
Las herramientas han madurado, las metodologías han madurado, pero el proceso
de creación de software sigue siendo una tarea difícil, llena de obstáculos, y por lo
general definida por DeadLines y Budgets. Esto no quita que sea un desafío 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 (Gestión del Ciclo de Vida de una Aplicación), pero
la problemática del desarrollo del software existe desde hace varias décadas y,
lamentablemente, las bases de los problemas no han cambiado.
El objetivo final de una implantación 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 líneas de negocio en una organización. La finalidad de ALM
no es solo controlar el ciclo de vida de una aplicación, sino ayudar a identificar una
idea o un requerimiento de negocio y brindar las capacidades para llevarlo adelante,
incluyendo la implantación y mantenimiento del mismo.
-
Cla
udio
V
arga
s
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
Con
teni
do
lic
enci
ado
a:
14 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Lo más importante de la adopción de una solución de ALM es la innovación. Pero
que todo el mundo esté de acuerdo sobre un tema, no significa que sepamos cómo
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 práctico:
Pensemos un segundo en la primera aerolínea que comenzó a utilizar estaciones de CheckIn automático en los aeropuertos. Utilizando este sistema sacó una gran
ventaja sobre sus competidores durante un tiempo. La segunda aerolínea que lo
implementó, sacó un poco menos de ventaja sobre sus competidores, pero seguía siendo un diferencial frente a la competencia. Actualmente es un gasto establecido
en todas las aerolíneas de un nivel medio y aquellas que no lo asumen, están un paso por detrás de sus competidores.
Además de la innovación 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 organización. Ninguna implementación de ALM
con las configuraciones que vienen por defecto en el producto es una solución
adecuada para una empresa.
Veamos otro ejemplo (Todavía en las primeras páginas y me he centrado más en
comentar ejemplos que en de hablar de Visual Studio ALM, ¡éste no parezco yo!):
Ahora pensemos en una organización con una gestión realmente muy complicada de un producto de software que se desarrolla por un equipo interno de la empresa.
Este producto, además, está instalado en 3 clientes diferentes lo cual implica la personalización del mismo para cada uno. Por otro lado, los requerimientos y los
cambios solicitados por cada cliente suelen quedar perdidos en una colección de
correos. Para solventar este problema, esta empresa pensó que desplegando la
solución de Visual Studio ALM todos sus problemas quedarían eliminados
mágicamente a partir de ese momento. Cuando llegamos a esta organización, 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 pequeño análisis sobre su proceso actual de desarrollo. Este análisis nos permitió darnos cuenta de que muchas de las
carencias y problemas que tenían se podían solucionar sin la necesidad de utilizar
Visual Studio ALM; pero que, si además sumábamos la potencia de Visual Studio más Team Foundation a su ciclo de vida, el resultado sería un win/win.
Por ejemplo, a la hora de organizar el código fuente existían diferentes ramas para
cada implementación de su producto, además de una rama principal donde se
gestionaba el “Core” del producto. Uno de los problemas más grandes era que la
gestión de las características o funcionalidades que se agregaban en cada rama se realizaba utilizando hojas Excel. Lo mismo sucedía con los Bugs. Esto ocasionaba que,
-*
09/0
8/20
13
Con
teni
do
lice
ncia
do
a
: C
laud
io
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om
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, además, era común que la solución del mismo Bug en cada
una de las ramas se realice de forma diferente, con lo que la estabilidad del código 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 más obvia es que hay un problema que arreglar, y esto es
algo que hay que hacer sí o sí. Pero además, tiene un coste que es muy difícil de medir:
el que se genera con la pérdida de calidad de tu producto.
Nota: Para hacernos una idea del daño 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 sería mucho
más fácil de gestionar.
Para continuar con el ejemplo, volvamos al tema Windows. Todos los miércoles
recibo una serie de actualizaciones utilizando el sistema de actualización automática de
Windows llamado Windows Update. Estoy convencido de que las actualizaciones que
se distribuyen con Windows Update mejorarán la calidad de mi Sistema Operativo.
Si la empresa a la que antes hacíamos referencia pudiese desplegar parches
proactivamente para estabilizar su software en las 3 implantaciones del mismo, se
ahorraría muchos problemas de gestión con los clientes con los que trabaja.
Hasta aquí en ningún momento hemos hablado de implantar Visual Studio ALM.
Además, Visual Studio ALM no posee ningún mecanismo “out of the box” para
solventar esta casuística. Pero, sí podemos aprovechar las capacidades de Visual Studio
ALM para encarar estos escenarios con una solución mucho más robusta y adaptada a
las necesidades puntuales requeridas.
Y en esto consiste ALM: identificar los procesos de trabajo de una empresa para la
creación de artefactos de software y dar solución 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 también. Y ALM
también es parte de esto ayudando a lograr que las personas puedan dar su máximo
potencial posible utilizando las herramientas adecuadas en cada momento.
-
Cla
udio
Var
gas
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a
:
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 añadiendo un sobre esfuerzo no estimado a la solución.
En estos casos es usual que:
A. Se piense en adaptar el problema original a nuestro enfoque o herramienta.
B. Se piense en la solución al problema original.
Ahora bien, como la solución del problema es algo que termina llegando sí o sí (es
increíble como en nuestra profesión los problemas siempre se terminan solucionando de una forma u otra, un flag en esta línea); 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 opción de solucionar un problema conocido o la oportunidad de “crear un
nuevo producto”, la segunda opción es mucho más atractiva puesto que, muchas veces,
involucra un desafío técnico que seguramente podrá ser reutilizado en el futuro.
Para que pueda ser reutilizable es necesario “hacerlo bien”: aplicar las mejores
prácticas, tener un buen diseño de la arquitectura del producto, implementar un ciclo de
pruebas correcto, gestionar correctamente el despliegue y utilización, etc. ¡Esto es un
producto! Como probablemente se implementará utilizando un enfoque ágil, en poco
tiempo será posible mostrar una primera versión a un usuario final. Eso permitirá
depurar el producto, mejorarlo y hacerlo más adaptable a futuros problemas que
desconocemos, ya que nunca se sabe cuándo podrá ser necesitado. En la segunda
iteración y con el producto ya estable la idea es ir más lejos, es intentar que el producto
no sea una solución a un problema específico, sino que sea la solución 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 diseño
del producto soporta un esquema de configuración extensible que permite que el producto se adapte a cualquier situación. ¡Y manos a la obra!: clases, interfaces,
configuración extensible, una buena herramienta de configuración, etc.
Todo esto sigue su curso natural hasta que se cumple un nuevo trimestre y todavía
el problema del punto B sigue “vivo” y quedan menos de 2 días 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 solución al problema original no existe.
B. Existe un producto mágico que parece solucionar todos los problemas, pero
implementarlo es bastante caro.
-
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a:
Cla
udio
V
arga
s
Ale
jos
Application Lifecycle Management 17
Podríamos seguir dándole 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 sección 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 aplicación de la
tecnología para un negocio resulte realmente rentable.
Nota: ¡Me encanta leer! De pequeño leía casi todo lo que caía en mis manos y
recuerdo con especial cariño 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 veía
compensada por la tozudez y la cantidad de los mismos.
Cuando un protagonista de la novela descuartizaba a un zombi con un hacha, le
aparecían dos más detrás de la puerta. Huelga decir que después de 3 páginas este
personaje era uno más de los infectados y bueno… os podéis 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 además dispongo de una escopeta recortada que,
aunque no da mucha precisión 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 técnico y didáctico relacionado con temáticas de gestión 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, escogerán a una lectura más orientada a cada uno de los casos.
Páginas y páginas con detalles de metodologías 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 más 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.
-
*
Cla
udio
V
arga
s A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lice
ncia
do
a
:
18 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Lo realmente importante de este libro es que enseña cómo dar los primeros pasos
hacia la gestión de proyectos utilizando Visual Studio, lo cual permite tener el control
sobre los diferentes elementos que componen un proyecto.
En los próximos capítulos veremos algunos escenarios sobre gestión del código
fuente, intentando ir un poco más allá de una simple estrategia de Branching y
Merging. También veremos como la gestión 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 automatización de compilaciones y
de otras acciones nos ayudan a tener controladas esas métricas de calidad.
Figura 1- Trabajo con Team Foundation.
La imagen anterior muestra un pequeño 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 información relacionada de los mismos
podemos tomar decisiones de gestión.
Si por ejemplo, la calidad de una compilación de una aplicación en producción no
es buena, podremos ver con qué nivel de aceptación se decidió dar el visto bueno a la
producción de la misma. Y además, ver si lo que se desplegó es lo que realmente salió
del laboratorio como “aprobado”.
Estos casos y algunos más serán explicados en las próximas secciones del libro.
4.- ¿CÓMO EJECUTAR LOS EJEMPLOS?
Como hemos comentado al inicio, éste no se trata de un libro de gestión puro y
duro. Aquí la idea es desglosar los diferentes aspectos de la gestión 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 mínimo), todos los ejemplos se han realizado con las máquinas 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 máquinas virtuales se pueden descargar desde la página de
descarga oficial de MSDN (http://bit.ly/nuJSKw). Tienen instalado el siguiente
software.
-
-
Cla
udio
V
arga
s
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a:
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 utilizarán durante los ejemplos prácticos del
libro.
Tabla 1- - Extensiones adicionales para Visual Studio 2010.
Herramienta Link
Team Foundation Server Power Tools http://j.mp/j6N9eS
TFSSCExplorerExtension http://bit.ly/r6FF16
TFS Workbench http://bit.ly/nzszAv
Inmeta Build Explorer http://bit.ly/roTvY2
TFS Build Extensions http://bit.ly/mRUQL7
StyleCop http://bit.ly/niG5Y4
Asimismo estas máquinas virtuales poseen ya configurados una serie de usuarios
con sus roles correspondientes. Los usuarios que posee la máquina virtual y que
utilizaremos en el libro son:
Tabla 2- - Roles y usuarios
Usuario Id Rol
Administrator WIN-
GS9GMUJITS8\administrator
Server Administrator
Abu Obeida Bakhach WIN-GS9GMUJITS8\abuobe Developer
April Stewart WIN-GS9GMUJITS8\aprist Developer Lead
Chris Barry WIN-GS9GMUJITS8\chriba Stakeholder
Christine Koch WIN-GS9GMUJITS8\chriko Tester
Doris Krieger WIN-GS9GMUJITS8\dorikr Developer
Michael Affronti WIN-GS9GMUJITS8\michaf Project Manager
Robin Wood WIN-GS9GMUJITS8\robiwo End User
Adrian Gonzalez WIN-GS9GMUJITS8\agon IT Guy
Bruno Capuano WIN-GS9GMUJITS8\elbruno ALM Tech Buddy
Para dar soporte a cuestiones de infraestructura en algunos ejemplos del libro, se ha
creado el usuario “Adrian Gonzalez”. Y también, para darme visibilidad, he creado un
usuario “Bruno Capuano”, para que cuando Bing/Google indexe este PDF tenga una
buena posición en el resultado de las búsquedas.
-
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lice
ncia
do
a:
Cla
udio
Var
gas
A
lejo
s
20 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
También 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 código 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: Desadjuntar un Team Project Collection
http://bit.ly/qm7Jk8
[TFS2010] HowTo: Adjuntar un Team Project Collection
http://bit.ly/nk4hfY
Finalmente si te animas, ha sido creado un BackUp diario de los elementos en la
máquina virtual que pueden ayudarte a tener todo el entorno configurado en pocos
minutos.
Para restaurar este BackUp necesitas la máquina virtual con la última versión de las
Power Tools de TFS y un poco de conocimiento sobre cómo realizar esta acción.
20128
**
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s
21
CAPÍTULO
Si no has adoptado una estrategia de gestión del código 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.
También los ALM Rangers.
Es increíble la cantidad de proyectos en los que he participado donde el
repositorio de código fuente era simplemente eso “un repositorio”. Si bien las
herramientas lo tienen contemplado desde hace muchas versiones, la adopción
de una estrategia de Branching y Merging parece ser un imposible en muchos de
los casos.
Los sistemas tradicionales de gestión 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 más clásicas en los proyectos de desarrollo.
En este capítulo veremos algunas opciones que pueden ayudar a la
configuración inicial de un repositorio de código fuente y algunos consejos
sobre cómo trabajar con el mismo.
Source Control
2
-
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
l
icen
ciad
o a
: C
laud
io
Var
gas
A
lejo
s
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 capítulo, es necesario sentar algunos conceptos
que, aunque probablemente el estimado lector ya posee, nunca está demás 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 código fuente. Esta es la definición de “Branching” según 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 más
interesante de las ramas es que permiten acciones a posteriori para comparar con los
elementos originales de las mismas o acciones de integración (Merge) para unificar los
cambios entre diferentes ramas.
Esta es la definición para la acción de “Merge” según 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.- Opinión: El miedo al Merge
El miedo al Merge es un clásico, más o menos como lo que pasa con los vampiros
ahora en el año 2011. Me explico: cuando yo era un crío (hace unos 20 años), un
vampiro era una cosa muy seria, había que tenerle miedo.
Por lo general, el estereotipo de un vampiro era una persona de algún país de
Europa del Este, tradicionalmente de Transilvania, con la piel muy blanca y una capa
negra. Además de tener una mirada que te dejaba helado, un buen vampiro solía tener
un par de ayudantes malvados, que tenían un buen corazón, pero con las ideas un poco
torcidas.
Si por algún motivo cometías el error de invitar a un vampiro a tu casa ahí
empezaban tus verdaderos problemas. Seguramente el vampiro se enamoraría de tu
madre, de tu hermana o de tu novia, y con la promesa de amor eterno, en algún
momento le querría chupar toda la sangre. Dependiendo del tipo de vampiro, podría
-
--
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
licen
ciad
o
a
: C
laud
io
Var
gas
A
lejo
s
Source Control 23
incluso querer comérsela con mayonesa o kétchup (siempre pensé que los vampiros
eran más de kétchup).
Esta idea de los vampiros estaba muy extendida y la gente se asustaba al ver a una
persona de estas características 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 más de 20 años,
que pueden caminar bajo el sol pero siguen teniendo la piel más blanca que la nieve.
Por lo general se enamoran de la chica más guapa del pueblo, pero sin la intención de
comérsela. Al contrario, la ayudan si es atacada por un hombre lobo, o si se la quieren
comer otros vampiros con más hambre.
Las cosas han cambiado mucho, pero la idea sigue estando allí: Los vampiros son
seres de cuidado que en cuanto puedan te darán 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 años, las
herramientas que disponemos ahora realmente ayudan a que la experiencia del
desarrollador sea más 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: Creación de un escenario simple de ramas
A continuación 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 epígrafe. 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 opción “Branching and
Merging // Convert to Branch”.
6. Dentro del mismo agregaremos un archivo de texto plano llamado
“demo.txt”.
-
*
C
onte
nido
lic
enci
ado
a:
Cla
udio
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
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 código fuente. En este
momento el repositorio debería tener una estructura similar a la que se
muestra en la siguiente imagen:
Figura 1- Creación de la rama “Main” y un archivo dentro de la misma.
El histórico de cambios del directorio “Main” debe mostrar información
relacionada con la creación de la rama y del archivo que hemos agregado en la
rama.
9. A continuación crearemos una rama a partir de “Main”. Para esto
seleccionamos la rama “Main”, desplegamos el menú contextual y
seleccionamos la opción “Branching and Merging // Branch”, definiendo
como “Child” el nombre de la nueva rama.
Aclaración: Esta opción crea una nueva rama, pero tenemos que tener en
cuenta que podemos crear la misma a partir de la última versión de código 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 continuación:
*
09/0
8/20
13
C
onte
nido
li
cenc
iado
a:
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
Source Control 25
Figura 2 - Creación 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 opción “Branching and Merging // View
Hierarchy”, veremos la estructura de padres e hijos que poseen las ramas
que hemos configurado.
Figura 3 - Vista de jerarquías de Branches en Visual Studio 2010
Veamos ahora qué sucedería al modificar los contenidos de los documentos
en las diferentes ramas.
12. Editamos el archivo “Main\demo.txt” y modificamos el siguiente código en
dicho archivo y lo protegemos.
Hola Martina :D
Hola Valentino
13. Editamos el archivo “Child\demo.txt” y modificamos el siguiente código
en dicho archivo y lo protegemos.
**
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
l
icen
ciad
o
a
: C
laud
io
V
arga
s
Ale
jos
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 lógico es realizar un “Merge” de los
contenidos del archivo entre las ramas “Main” y “Child”.
La siguiente imagen muestra la línea temporal con este cambio, desde la
rama “Main” hacia la rama “Child”.
Figura 4 - Ejemplo de línea temporal
15. Para realizar un Merge seleccionamos la rama “Main”, desplegamos el
menú contextual y seleccionamos la opción “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 automático
d. Realizar un Merge manual.
-
*
Cla
udio
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Con
teni
do
licen
ciad
o
a:
Source Control 27
Figura 5 - Resolución de conflictos en una acción de Merge
17. Haciendo un Merge manual y utilizando las nuevas líneas de cada versión
el contenido del archivo sería el siguiente:
Hola Martina
Hola Martina :D
Hola Valentino :D
Hola Valentino
18. Visual Studio 2010 muestra en el histórico de cambios los diferentes
estados por los que ha pasado el archivo; desde su creación en la rama
“Main” hasta la modificación en la rama “Child”. También permite ver
estos cambios en una línea 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 histórica en Visual Studio 2010
-
Con
teni
do
licen
ciad
o
a: C
laud
io
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
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 más potente que la incluida por defecto junto con Visual
Studio.
Los siguientes pasos describen como configurar Visual Studio para utilizar
WinMerge como herramienta de comparación y Merge de archivos.
1. Abrir Visual Studio 2010
2. Acceder al menu “Tools // Options”
3. Presionar el botón “Configure User Tools”
4. Seleccionar la opción “Add”
5. Agregar la opción 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 configuración con “OK”
7. Agregamos la opción 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 configuración 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.
-
--
Con
teni
do
lice
ncia
do
a: C
laud
io V
arga
s
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
Source Control 29
1.4.- Opinión: ¿Cuándo utilizar Branches? ¿Has probado con
Workspaces?
Para ilustrar en qué ocasiones es recomendable crear un nuevo Branch usaremos
como ejemplo un proyecto en el que participé hace unos años. Este proyecto además de
tener numerosos problemas relacionados con la aplicación que se desarrollaba, estaba
bastante descontrolado en lo referido a la organización del Source Control.
Aunque se utilizaba Team Foundation como gestor de código fuente, nadie se había
tomado la molestia de definir una forma de trabajo para el equipo de desarrollo. Como
consecuencia durante dos años varias personas se dedicaron a modificar y proteger
código sin ningún criterio definido.
La estructura del árbol de código fuente carecía de coherencia, es decir, no
respondía a ningún patrón. Tras un breve análisis se detectó que:
Cuando se desplegaba una nueva versión de la aplicación, dependiendo de
la persona asignada a esa tarea, se creaba un nuevo Branch, un Label, o
absolutamente nada que permitiese acceder al código desplegado.
La nomenclatura para la creación de Branches y Labels no estaba
procedimentada. Era posible encontrar ramas llamadas “01-02_Paco” o
algunas más coherentes como por ejemplo “Prueba”, “Prueba1” y
obviamente “Prueba2”.
Con el tiempo se llegó a la conclusión de que por ejemplo “Prueba1” se
correspondía con el código desplegado de la aplicación en un país. Pero,
para llegar a esto hubo que descompilar los ensamblados desplegados en
producción, comparar los mismos con los del Source Control y tomar como
base de “código estable”, el desplegado en producción.
En pocas palabras, los Branches se creaban para pruebas aisladas de cada
desarrollador, para identificar un despliegue o en algún arranque de
intención de poner orden sobre el Source Control que lamentablemente
quedaba a la mitad.
Lo más preocupante de este escenario es que ninguno de los integrantes del equipo
o los managers que participaban en el proyecto, veían esto como un problema. Para
todos ellos el repositorio de Source Control es un File System con histórico y poco
más. Uno de los puntos de mejora propuestos por nuestra empresa era definir una
estrategia de branching acorde al funcionamiento del equipo de desarrollo, pero nos
encontrábamos ante un grupo de personas que no veían el problema así que recurrimos
a la analogía sobre el miedo a los zombis. La conversación transcurrió como sigue, los
nombres de los managers son inventados para preservar su intimidad.
- Bruno (yo): ¿Tenéis miedo a los zombis?
- Juan (manager): Los zombis no existen.
*
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lice
ncia
do
a:
30 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
- María (manager): Menuda tonterías suelta este.
- Bruno: Ya sé que no existen, pero y si existiesen, ¿les tendríais miedo?
- Juan: Pues claro.
- María: Yo no. Los zombis son lentos. Puedo escaparme fácilmente.
- Bruno: Eso seguro, pero el principal problema de los zombis, no es su
necesidad de devorar cerebros humanos, ni tampoco su lentitud, ¿saben cuál es
el principal problema de los zombis?
- María: ¿Cuál?
- Bruno: La manera en que se reproducen. Un zombi es alguien que hace unos minutos era un humano. Es decir, alguien que estaba de nuestro lado y por
algún motivo fue atacado, convertido y ahora es nuestro enemigo. Y además ya
no puede volver a ser humano. Eso es lo verdaderamente importante a tener en cuenta cuando se lucha contra zombis. Llegará un momento en que por más
que nos esforcemos, todos se convertirán en zombis. Si tienes suerte, puedes ser
el último, pero a la larga terminarás como ellos …
- Juan: ¿Y eso qué tiene que ver con el Source Control?
En este punto no sé si Juan estaba asustado o enfadado, pero se notaba que
estaba un poco incómodo. Aproveche la situación y decidí atacar.
Bruno: Pues que las decisiones mal tomadas en la gestión del Source Control son zombis. No se pueden volver atrás y llega un momento en que estamos
desbordados por estas malas decisiones atacándonos desde frentes distintos. Por ejemplo, en estos momentos, no sabemos que versión está desplegada en
producción, o por qué en el ordenador de Juan sí funciona pero en producción
no, es decir, “estamos a punto de ser convertidos”. Se nos han acabado las opciones y no tenemos armas para organizarnos. Los errores nos terminan
venciendo. Es por eso que es tan importante tomar una decisión al respecto. Según mi
opinión, están a un error del “punto de no retorno” donde luego solo quedará
tirar el Source Control y comenzar desde cero, cruzando los dedos para no perder nada y a nadie en el camino.
Uno de los managers se quedó pálido. Probablemente se nos fue un poco la mano
exagerando la situación. El Source Control no es tan peligroso como una horda de
zombis, pero sirvió de ejemplo para ilustrar nuestro punto de vista y todos estábamos
de acuerdo en que debíamos hacer algo al respecto (algunos bastante asustados). En el
próximo capítulo encontrarás la sencilla solución que se propuso para abordar esta
compleja situación. En ella se crea una rama para desarrollo evolutivo y luego una
rama para cada versión desplegada, sin embargo todavía queda pendiente una solución
-
*-
Cla
udio
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lic
enci
ado
a:
Source Control 31
para las pruebas locales o pruebas temporales que a menudo hacemos los
desarrolladores.
Veamos ese ejemplo en el siguiente epígrafe.
1.4.1.- Test: Single Developer Test Mode
Si las pruebas son en “Single Developer Test Mode”, es decir, no es necesario
compartirlas luego con otros compañeros del equipo, una opción es utilizar un
Workspace dedicado a pruebas.
Un Workspace es un artefacto en Team Foundation que posee un mapeo entre la
estructura definida en el Source Control de un Team Project y los directorios locales de
un equipo. Cada Workspace está asociado a un usuario, a un nombre de un PC y se
identifica por un nombre definido para el mismo. Con estas bases es posible tener un
Workspace de trabajo en un directorio en local y crear otro para las pruebas.
La siguiente tabla muestra un ejemplo con definiciones de dos Workspaces en un
mismo ordenador para el mismo usuario, pero que poseen diferentes mapeos en el
disco local para bajar el código fuente de una aplicación.
Tabla 1- Utilizar Workspaces para realizar pruebas
WorkSpace Owner Computer Server Path Local Path
DEV Aprilst Local $\Dev\ C:\src\Dev
DEV_Test Aprilst Local $\Dev\ C:\test\Dev
Por ejemplo, podemos establecer que el trabajo que se realiza en el Workspace
“DEV” es para el trabajo diario en la rama “$\DEV\App1”, y que el Workspace
“DEV_Test” es para realizar pruebas puntuales sobre el código de esta rama. Estas
pruebas pueden o no ser subidas posteriormente al repositorio de código fuente. En el
caso de que se decidan abandonar los cambios realizados en este Workspace, pues
simplemente se descartan los cambios realizados sobre estos archivos, simplemente se
elimina el Workspace.
La siguiente imagen muestra un ejemplo en el que es posible ver como se han
editado diferentes archivos en los Workspaces “DEV” y “DEV_Test” para un mismo
usuario. Esta información aparece en la columna “User”.
Figura 7- Edición de archivos de prueba en diferentes Workspaces
-
*
Cla
udio
V
arga
s
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3 C
onte
nido
lic
enci
ado
a
:
32 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Por último comentar que cuando se elimina la definición de un Workspace, se
eliminan también todos los cambios pendientes relacionados con el mismo. En el
ejemplo anterior, una vez finalizada la prueba en el Workspace “DEV_Test”, cuando se
elimine el mismo se eliminarán los archivos modificados en este Workspace.
1.4.2.- Test: Multiple Developer Test Mode
Al siguiente escenario que deriva del anterior “Single Developer Test Mode” le
llamaremos “Multiple Developer Test Mode”.
Tras realizar una serie de pruebas en un Workspace es posible que sea necesario
trabajar con otro integrante del equipo para llevar adelante otra prueba. Esto significa
que necesitamos compartir una base de código fuente y que dos o más personas puedan
trabajar sobre el mismo.
En este caso, la recomendación es crear una nueva rama a partir de la rama de
desarrollo sobre la que se realizan las pruebas y trabajar en ella. La gestión de ramas de
Team Foundation es lo suficientemente flexible como para definir permisos específicos
de seguridad para esta rama, en el caso de que fuese necesario restringir los permisos, o
incluso dar acceso de solo lectura a otras personas.
En conclusión:
Si las pruebas se pueden realizar en modo aislado por un desarrollador, es
recomendable utilizar un Workspace para realizar estas pruebas.
Si en cambio es necesario que participen dos o más personas, es
recomendable crear una rama en el repositorio de código fuente.
Finalmente, nunca debemos olvidarnos de aplicar un poco de sentido común, ya que
si hay componentes externos como bases de datos, servidores externos, etc.; que
afectan a la prueba, tal vez el escenario no sea tan simple como el planteado en estas
páginas, aunque la base puede servir como referencia.
2.- DESARROLLOS EVOLUTIVOS Y CORRECTIVOS
Un escenario muy común en el desarrollo de aplicaciones, es el de tener que dar
soporte a desarrollos evolutivos y también a desarrollos correctivos. Es decir, tener que
mantener al mismo tiempo una versión en producción de una aplicación e ir realizando
cambios para una nueva versión de la misma.
Veamos un ejemplo más claro de esta casuística:
1. Un equipo de desarrollo ha trabajado durante varios meses de una forma muy
organizada para sacar adelante el desarrollo de un producto “Aplicación A”.
2. Una vez validada una entrega, el equipo ha liberado una versión de su
producto “Aplicación A, versión 1.0” a Producción.
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lice
ncia
do
a: C
laud
io
Var
gas
A
lejo
s
Source Control 33
3. Para dar más un poco de robustez al proceso de desarrollo, el equipo ha creado
una etiqueta, una revisión, un archivo comprimido (Zip), o un SnapShot con el
código de la versión liberada.
4. Como la aplicación ya está liberada y ha pasado todo el ciclo de pruebas
correspondiente, se comienza el desarrollo de la nueva versión “Aplicación A,
versión 2.0”.
5. Pasa un poco de tiempo, y se reporta un error de la aplicación en producción.
Recordemos que era “Aplicación A, versión 1.0”.
6. Como la base de código en la que se está trabajando “Aplicación A, versión
2.0” es diferente a la liberada comienzan los problemas.
Existen numerosos caminos para atacar la situación anterior. En este libro nos
centraremos en los dos escenarios que suelen ser los más comunes y que
denominaremos las primeras malas prácticas en el trabajo con repositorios de archivos.
2.1.- Mala Práctica: Magia con Etiquetas
En este caso el equipo de desarrollo recupera la etiqueta de la versión desplegada en
producción “Aplicación A, versión 1.0” en un directorio local diferente al de trabajo
actual “Aplicación A, versión 2.0”.
Si pensamos en un File System tradicional su estructura sería como sigue:
C:\Sources\
o Aplicación_v1.0\
bin
src
o Aplicación_v2.0\
bin
src
Una vez configurados directorios diferentes para cada versión, se solucionan los
bugs reportados desde producción sobre el directorio correspondiente. En este caso
sobre “C:\Sources\Aplicación_v1.0”.
Aquí el gran inconveniente es que, una vez solucionados los problemas en la
versión 1.0, es necesario realizar un “Merge” de dichos cambios con los propios de la
versión en desarrollo, la versión 2.0.
Esta tarea suele ser muy manual, ya que se deben identificar los archivos que han
cambiado en la versión 1.0 y llevar los mismos a la versión 2.0. En el mejor de los
-
-*
Con
teni
do
lic
enci
ado
a: C
laud
io
V
arga
s A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
34 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
casos, los cambios se trasladan con un simple “copy & paste”, pero si la nueva versión
ha evolucionado, se han refactorizado clases o se ha trabajado mucho sobre la misma,
habrá que solucionar los bugs de una forma diferente en la versión 2.0.
Escenarios más complejos, como por ejemplo dar de alta una versión específica de
un esquema de base de datos, o una configuración específica de unas colas de trabajo,
no han sido contemplados puesto que no arrojarían más luz al concepto explicado.
Además del problema de la sincronización manual de archivos, o “Manual Merge”,
en el histórico de los cambios del repositorio de ficheros queda mucha información que
en realidad no refleja la vida real del proceso de desarrollo. A la larga, la gestión de
esta información puede ser un problema para ver la evolución desde la versión 1.0 a la
versión 2.0 de la aplicación A.
2.2.- Mala Práctica: Magia con el File System
En este caso el equipo de desarrollo intenta modificar el estado actual en la versión
“Aplicación A, versión 2.0”, hasta dar con una versión “similar” a la que está
desplegada en producción. Esto suele ser un trabajo más que artesanal, tirando de la
memoria de los desarrolladores más conocedores de la versión anterior para que la
versión 2.0 sea igual a la versión 1.0.
Supongamos que las personas que llevan esta tarea adelante como saben que no es
exactamente la versión 1.0 llaman a esta versión “Aplicación A, versión 1.1”.
La organización del Source control en el File System quedaría:
C:\Sources\
o Aplicación_v1.1\
bin
src
o Aplicación_v2.0\
bin
src
Sin tener una estadística oficial, podemos afirmar que en el 99% de los casos pasa
lo siguiente:
Se solucionan los errores reportados sobre la versión 1.1 y se generan una
serie de parches.
Se sube a producción los parches para esta versión.
Algo comienza a fallar.
20128
-
-*
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
li
cenc
iado
a:
Source Control 35
La versión 1.1 no es compatible con la versión 1.0 tal y como se creía
inicialmente. Además pueden haberse desplegado funcionalidades de la
versión 2.0 que no debían estar desplegadas en la versión actual.
A todo ello debemos sumar los problemas del escenario anterior, a saber:
Sincronización de código entre diferentes versiones.
Pérdida real del histórico.
Usuarios finales enfadados.
Al igual que el anterior, éste escenario tampoco es recomendado. Estas situaciones
son provocadas por los apuros y prisas, las cuales además hacen que desmerezca la
calidad del trabajo realizado.
Pero no todo son malas prácticas, en el capítulo 4 veremos un par de consejos para
ayudar a mantener una buena calidad de código en nuestras aplicaciones y un buen
nivel de calidad en el desarrollo de aplicaciones.
3.- ESCENARIO SIMPLE CON SOPORTE A
DESARROLLO Y PRODUCCIÓN
Esta sección describe una solución propuesta muy simple para dar soporte a
desarrollos evolutivos y también, para dar soporte a desarrollos correctivos. Aunque
existen diferentes escenarios posibles, aquí usaremos el más simple, que, por lo
general, suele ser suficiente.
Para este ejemplo utilizaremos Visual Studio y Team Foundation Server trabajando
sobre el Source Control para montar una estructura de ramas que nos permita tener
desarrollos evolutivos y correctivos. Este mismo modelo puede ser usado con otras
herramientas de control de código fuente para obtener el mismo resultado.
La base de este modelo se centra en tener una rama principal, generalmente llamada
“Main” a partir de la cual se crea una rama para los desarrollos evolutivos, así como
ramas para cada una de las entregas o Releases de un producto determinado.
Cada una de estas ramas posee además determinados grupos de trabajo y
configuraciones de compilación que son las que dan valor a las mismas.
3.1.- Rama “Dev”
Esta rama es sobre la cual se desarrolla el producto o aplicación. Se recomienda
tener en ella una o más configuraciones de Build con integración continua para
asegurar la calidad del contenido de la misma.
Por lo general, el código que se protege en esta rama se basa en las siguientes
premisas:
-
**
09/0
8/20
13
Con
teni
do
lic
enci
ado
a
: C
laud
io
V
arga
s
A
lejo
s
cla
udio
cva@
hotm
ail.c
om
36 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
El código de esta rama puede no estar preparado para ser desplegado en
producción. En otras palabras, es posible proteger funcionalidades no
completas para una aplicación en esta rama.
Si bien el código puede no estar preparado para ser desplegado, si es
recomendable que todo el código protegido pase las pruebas de calidad
definidas para la rama (véase el capítulo 4).
El código de esta rama puede ser empaquetado como una versión no
estable de una aplicación o producto. Por ejemplo, para realizar una
reunión de seguimiento o una demostración de funcionalidad de una
aplicación.
Cuando una funcionalidad se completa en la rama “Dev” se recomienda
realizar un Merge hacia la rama “Main” para evitar posteriores procesos de
Merge muy complejos.
3.2.- Rama “Main”
Sobre esta rama se estabiliza el producto o aplicación. Además de contar con varias
definiciones de Build para asegurar la calidad del código de esta rama, la misma se
basa en las siguientes premisas:
El código de esta rama está listo para ser desplegado en producción. A este
código se lo conoce como “deliverable” o entregable. En las aplicaciones
de esta rama no deben existir funcionalidades incompletas.
El código de esta rama puede ser empaquetado como una versión estable de
una aplicación o producto.
El equipo encargado del control de la calidad (QATeam) de una aplicación
o producto realizará las pruebas sobre Releases generadas a partir de esta
rama.
La generación de Releases se debe implementar utilizando procesos
automáticos, por ejemplo definiciones de Build de Team Foundation.
Cada generación de una Release debe crear una etiqueta con un SnapShot
del código fuente y los artefactos utilizados para la generación de la
Release.
Se recomienda realizar acciones de “Merge” desde la rama “Dev” de
funcionalidades cerradas periódicamente para evitar procesos de Merge
complejos.
-
--
C
onte
nido
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Source Control 37
Cuando una Release es considerada válida por el equipo de calidad
(QATeam), se crea una nueva rama (Branch) a partir de la etiqueta
establecida en la generación de la Release.
Nota: Cuando hemos hecho referencia al QATeam alguno de vosotros habrá
pensado, “pero si yo no tengo eso en mi empresa”. No nos equivoquemos, el
equipo de QA es el encargado de validar las pruebas definidas para comprobar que
las funcionalidades de una aplicación se ejecutan correctamente. En muchas
ocasiones esta tarea la realiza el mismo equipo de desarrollo a lo largo de la vida
del proyecto.
3.3.- Rama “Release”
Esta rama se genera a partir de una versión aprobada por el equipo de calidad
(QATeam). Por lo general esta versión es la que se despliega en los entornos de
PreProducción y de Producción.
El trabajo en estas ramas se basa en las siguientes premisas:
Como esta rama representa el código de una aplicación o producto
desplegada en producción, los errores que se reporten sobre la aplicación o
producto se solucionarán sobre dicha rama.
Cuando se realicen modificaciones sobre los archivos de la rama “Release”
es recomendable realizar un Merge hacia la rama “Main” para sincronizar
los cambios de una manera continua.
Puede ocurrir que los cambios en la rama “Release” no se pueden combinar
(Merge) con la rama “Main”. En este caso, para aplicar los cambios en la
rama “Main”, se deben realizar las acciones de Refactoring
correspondientes. Esto es muy importante para no perder la trazabilidad
entre los cambios que se aplican en producción y los cambios que se
aplican en el desarrollo evolutivo.
Para la generación de Releases se debe implementar un proceso
automático, por ejemplo una definición de Team Build de Team
Foundation.
3.4.- Flujo de trabajo
El flujo de trabajo con este esquema sería similar al siguiente:
1. Creación de la rama “Main” en el repositorio de código fuente con la
estructura recomendada para el desarrollo de aplicaciones.
-
**
09/0
8/20
13
Con
teni
do
licen
ciad
o
a
: C
laud
io
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om
38 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
2. Creación de una rama “Dev” (un Branch) a partir de “Main” donde se
realizarán los nuevos desarrollos, es decir, los desarrollos evolutivos.
3. Generación de un producto en la rama “Dev”. Para este ejemplo crearemos
una biblioteca de clases con operaciones de trabajo sobre cadenas de texto
con una serie de pruebas unitarias para validar la misma. Llamaremos a
este producto “App1”.
4. Cuando el producto está completo para una versión 1.0 se realiza un Merge
desde la rama “Dev” a la rama “Main”.
5. A partir de la rama “Main” se crea la primera versión lista para desplegar
en producción del producto en una rama llamada “V1.0”. La siguiente
imagen muestra una línea temporal de este proceso.
Figura 8- Creación de Main, Dev y V1.0
6. En este punto tenemos un set de código “idéntico” en las ramas “Dev”,
“Main” y “V1.0”. Esto nos permitirá trabajar en paralelo en los nuevos
desarrollos y en los desarrollos correctivos.
7. En la rama “Dev” se comienza a trabajar sobre la versión 1.1 de la
aplicación “App1” agregando nuevas funcionalidades a la misma.
8. Paralelamente en la rama “V1.0” se solucionan una serie de incidentes
reportados en producción. Esta situación es muy común en desarrollos
evolutivos y correctivos al mismo tiempo.
*-
09/0
8/20
13
Con
teni
do
lice
ncia
do a
: C
laud
io
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
Source Control 39
Importante: En este punto es muy importante recalcar el papel que
juega la rama “Main” como rama donde se estabilizan los cambios de las
demás. Se recomienda realizar acciones de Merge frecuentes desde
“Dev” hacia “Main” y desde “V1.0” hacia “Main”, para tener
sincronizados los desarrollos en ambas ramas. Asimismo los Merge
desde “Main” hacia “Dev” aseguran que todos los bugs encontrados en el
entorno de Producción y corregidos en la rama “V1.0” también se
incorporarán en el desarrollo de la versión 1.1 que actualmente se
encuentra en la rama “Dev”.
9. La siguiente imagen muestra una línea temporal con desarrollos evolutivos
y correctivos y con diferentes acciones de Merge entre diferentes ramas.
Figura 9- Desarrollo evolutivo y correctivo en paralelo
10. Si en la rama de desarrollo se termina el desarrollo de la versión 1.1 de la
aplicación “App1”, la misma se puede promocionar hacia la rama “Main” y
luego crear una rama “V1.1” que representará la aplicación desplegada en
producción.
11. La siguiente imagen muestra la línea temporal donde se ha terminado la
versión 1.1 y a partir de la misma se crea una rama “V1.1” para el
-
-
Con
teni
do
lic
enci
ado
a
: C
laud
io
V
arga
s
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
40 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
mantenimiento correctivo. Además la rama “V1.0” se da como inútil ya
que no se realizará ningún tipo de desarrollo sobre la misma.
Figura 10- Generación de V1.1
4.- ESCENARIOS COMPLEJOS DE BRANCHING
4.1.- Guía de Branching de Visual Studio ALM Rangers
Hasta ahora hemos descrito un escenario simple de trabajo utilizando ramas, pero el
mundo real del desarrollo de software es mucho más complejo. Existen muchas
variables que influyen en la decisión final de la estrategia de Branching a utilizar;
además también depende del tipo de herramienta que se utilice para gestionar el código
fuente.
Si tienes este libro en tus manos, las probabilidades de que utilices o pienses en
utilizar Team Foundation son del 99%, y como la casuística de trabajo con Team
Foundation es particular en algunos aspectos, lo mejor es seguir el trabajo que han
hecho orientado a Branching y Merging con Team Foundation el equipo de Visual
Studio ALM Rangers (http://j.mp/kTGC3p).
Este equipo de personas, formado por personal de Microsoft, MVPs y expertos en
diferentes áreas, trabajan en su día a día con las herramientas de Visual Studio ALM y
como parte de su trabajo, comparten las experiencias a modo de guías y
recomendaciones de utilización.
20128
-
*-
09/0
8/20
13
Con
teni
do
lice
ncia
do
a:
Cla
udio
V
arga
s
Ale
jos
clau
dioc
va@
hotm
ail.c
om
Source Control 41
Las guías disponibles en Visual Studio 2010 Team Foundation Branching Guide
2010 (http://j.mp/h7Gtj5), describen cuatro escenarios de Branching y Merging que
van desde un escenario simple de bifurcación, hasta un escenario avanzado, donde se
incorporan conceptos como Service Packs, HotFixes, etc. Además se describen
escenarios donde las ramas se crean por versión, por funcionalidad, etc.
Lo más interesante de este trabajo es que es un conjunto de documentación “vivo”
basado en las experiencias reales de los diferentes profesionales que trabajan con
Visual Studio y Team Foundation. Esto asegura que las propuestas se basan en
soluciones reales que se han aplicado en otros proyectos.
4.2.- Gestionando Productos y Componentes
Para desarrollar este apartado usaremos como ejemplo un caso real de uno de
nuestros clientes. El cliente, al cual nos referiremos como “Org_A”, se dedica a la
creación de un producto llamado “App4” que luego puede ser personalizado para
diferentes clientes. Para simplificar el caso supongamos que las personalizaciones se
realizan para los clientes: “CusA”, “CusB” y “CusC”.
En un esquema de desarrollo ideal se crearían, a partir de una definición de
producto general, las ramas correspondientes con las personalizaciones asignadas a
cada cliente tal y como muestra la siguiente imagen.
Figura 11- Esquema de aplicación simplificado
Obviamente este modelo simplificado, requiere incluir el concepto de desarrollo
evolutivo y correctivo para cada aplicación. Aplicando los cambios mínimos para tener
un río “Dev/Main/Releases”, el esquema de ramas quedaría:
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lice
ncia
do
a:
Cla
udio
V
arga
s
Ale
jos
42 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 12 - Aplicaciones personalizadas con soporte evolutivo y correctivo
Un detalle a tener en cuenta es que las personalizaciones para los diferentes clientes,
se realizan a partir de una versión final en “Release” de la aplicación principal. Otra
opción sería crear las ramas de personalización de cada producto a partir de la rama
“App4\Main”.
Este método de trabajo es bastante común, y si bien parece complicado de llevar
adelante, lo importante en estos casos es ser muy constante con las acciones de Merge
entre las diferentes ramas.
Veamos un escenario de ejemplo donde ocurre lo siguiente:
A partir de la versión desplegada en el cliente “CusC”, se reporta una
incidencia.
Al mismo tiempo el cliente “CusA” da de alta una nueva funcionalidad que
despliega en producción.
Estas dos situaciones, suponen una modificación en una personalización de un
cliente. Tras un análisis detallado se concluye que ambas modificaciones se deben
subir a la rama principal de la aplicación “App4 Main”, para luego ser desplegadas en
las demás personalizaciones. Es en este momento cuando comienza el trabajo de “subir
estos cambios” hasta la rama principal. No olvidemos que después es necesario “bajar
los cambios” hacia cada una de las personalizaciones. Este trabajo se realiza con
Merges (Forward Integration y Reverse Integration, según la Branching Guide), y
estabilizando el producto en cada rama.
Ahora compliquemos un poco más el ejemplo (teniendo en cuenta que en este caso
“complicar” significa “acercar a casos reales”).
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
licen
ciad
o a:
Cla
udio
V
arga
s
Ale
jos
Source Control 43
Supongamos que la aplicación se divide internamente en un grupo de componentes
comunes y un grupo de componentes de aplicación. En relación a la organización de la
empresa, a cada grupo de elementos los mantiene un equipo de desarrollo diferente.
Este es un escenario clásico donde existen grupos de “arquitectos” que mantienen
los componentes comunes, y un equipo de “desarrolladores” que mantienen los
componentes de aplicación.
Figura 13 - Separación de componentes por equipos de trabajo
Si cada equipo de desarrollo trabaja de forma aislada, y tanto los componentes
comunes como la aplicación principal y las personalizaciones de la misma se tratan
como productos diferentes, el esquema de ramas queda similar al de la siguiente
imagen:
Figura 14 - Componentes comunes y de aplicación separados
En este punto la organización de las ramas de código fuente es lo suficientemente
robusta como para dar soporte a diferentes variaciones, pero surge un nuevo problema
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a
: C
laud
io
Var
gas
Ale
jos
44 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
cuando incorporamos el concepto de “Producto”. Antes de continuar con este ejemplo
aclaremos el concepto de producto.
Producto: Grupo de ensamblados que surgen de la compilación de uno o más
componentes en un momento determinado del tiempo.
Bajo este criterio podemos tener diferentes implementaciones de producto para cada
uno de los clientes. La siguiente tabla muestra un ejemplo donde para cada
personalización se genera diferentes versiones que a su vez, utilizan diferentes
componentes comunes en cada versión.
Tabla 2 - Implementaciones de producto con diferentes componentes
Cliente Versión Común Aplicación
CusA 1.0 V1.0 $/App4_CusA/Rel/V1.0
CusA 1.1 V1.0 $/App4_CusA/Rel/V1.1
CusB 1.0 V1.0 $/App4_CusB/Rel/V1.0
CusB 1.1 V1.1 $/App4_CusB/Rel/V1.1
CusC 1.0 V1.0 $/App4_CusA/Rel/V1.0
CusC 1.1 V1.1 $/App4_CusA/Rel/V1.1
CusC 1.2 V1.2 $/App4_CusA/Rel/V1.2
CusC 2.0 V2.0 $/App4_CusA/Rel/V2.0
Una vez definidas las guías sobre las que se trabajará y la estructura general con la
que se organizarán los componentes, es importante definir un buen mecanismo de
generación que permita obtener los componentes desde las ubicaciones específicas
utilizando los mismos para crear el producto completo. En este caso, el uso de los
componentes comunes puede hacerse a partir de los ensamblados compilados de cada
versión, suele ser la práctica más recomendada; o bien, incorporando el código de los
componentes comunes en una solución general que compile todo lo necesario para la
creación de un producto. Ambas opciones son válidas, lo importante es tener un
mecanismo robusto que soporte estos escenarios.
Visual Studio ALM nos presenta la opción de trabajar con MSBuild y Team Build,
ambas tecnologías son lo suficientemente flexibles para dar soporte a estos escenarios.
En el capítulo 4 veremos cómo implementar las compilaciones para este caso además
de ver cómo afecta un escenario compuesto de este tipo a la gestión de bugs, de tareas,
etc.
-
*
C
onte
nido
lic
enci
ado
a
: C
laud
io
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Source Control 45
5.- DIRECTORIOS DE TRABAJO
5.1.- Organización de elementos dentro de una rama en el
Source Control
La siguiente frase tiene que quedar grabada a fuego en las personas que mantengan
una estructura de Source Control.
La base de la organización del código fuente es tener dentro del repositorio
TODOS los elementos necesarios para la generación de un paquete en una
aplicación.
Más adelante hablaremos nuevamente del concepto de producto, pero en este punto
podemos pensar que dentro del repositorio de código fuente deben estar todos los
elementos necesarios para compilar, ejecutar pruebas, desplegar, etc. Esto es
importante ya que si hiciese falta volver atrás a una versión específica, debemos poder
“obtener del repositorio de código fuente” todo lo necesario para poder recrear el
paquete desplegado.
Esto no significa que se deba GUARDAR TODO en el repositorio de código fuente.
Un BackUp de base de datos o una imagen de un DVD con un software utilizado para
el desarrollo de un producto tal vez sea demasiado, pero todo lo relacionado con el
desarrollo debería estar en el repositorio.
Sobre esta premisa, y como una primera propuesta que se debe adaptar a cada
situación específica, cada rama en el Source Control debería tener los siguientes
directorios:
Bin En el mismo se almacenan todos los archivos generados de la compilación
de la aplicación.
Build En el mismo se almacenan todos los archivos necesarios para procesos de
compilación propios de la aplicación.
Lib En el mismo se almacenan todas las librerías o módulos externos que se
utilicen en el desarrollo de la aplicación.
Src En el mismo se almacenan todos los archivos de código fuente propios de
la aplicación.
Esta propuesta de organización se aplica a cada rama, con lo que se repetirá para
cada rama definida, por ejemplo:
*-
Con
teni
do
lice
ncia
do
a:
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
46 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 15 - Organización de Source Control por ramas
Con la utilización de este esquema es posible recuperar diferentes versiones, no solo
de los archivos propios de código fuente (en Visual Studio, usualmente, archivos con
extensión CS o VB) sino también los archivos utilizados para compilar, los
componentes comunes, etc.
La siguiente imagen muestra un ejemplo con diferentes versiones para una
aplicación. En ella podemos ver como la versión 0.5 y la versión 1.0 coinciden en los
elementos utilizados para la creación de los componentes finales. Estos componentes se
almacenan en la carpeta “Bin” y en estas dos versiones sólo se genera un archivo
llamado “A.dll”.
Con la versión 1.1 el modelo de trabajo cambia un poco, ya que se agrega un nuevo
componente común, ahora se utilizan “Common.dll” y “Log.dll”; y además se agrega
una nueva clase al proyecto. Como resultado la salida de la compilación de esta
aplicación son dos ensamblados llamados “A.dll” y “B.dll”.
20128
-
-*
Con
teni
do
lic
enci
ado
a:
Cla
udio
Var
gas
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Source Control 47
Figura 16 - Evolución de los diferentes componentes
Si en determinado momento se requiere volver a la versión 1.0, ésta se obtiene
desde la rama correspondiente, y en la misma se podrá trabajar con los archivos de
código fuente de dicha versión, con los componentes comunes, con la definición de
compilación que se utilizó para esta versión, etc.
Como hemos dicho al inicio de esta sección, la utilización de estos cuatro
directorios es una sugerencia, y se debe adaptar a cada escenario. Es posible utilizar
otros directorios adicionales, como por ejemplo:
Data: En el mismo se almacenan todos los archivos de código fuente
relacionados con base de datos, por ejemplo scripts con los objetos de una
base de datos, scripts para cargas masivas de datos, etc.
Test: En el mismo se almacenan todos los archivos relacionados con
pruebas. Pueden ser definiciones de pruebas, scripts de casos de pruebas,
resultados de las pruebas, etc.
5.2.- Mala Práctica: Compartir componentes comunes en
recursos de red
Con el tiempo se aprende que cada persona posee una forma propia de organizar su
trabajo. Si llevamos esto a la gestión de código fuente vemos que cada aplicación tiene
su propia organización.
Las plantillas de proyecto de Visual Studio nos brindan un marco de trabajo
coherente, pero aun así, si no hay un poco de control sobre la organización de los
elementos de una solución, la cosa se puede complicar bastante.
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
l
icen
ciad
o
a:
Cla
udio
Var
gas
A
lejo
s
48 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Veamos un ejemplo que si no es real, solo me equivoco con los nombres.
Valentino, Martina y el Bruno participan en el desarrollo de la aplicación “App2”.
A Bruno le han pedido que incorpore capacidades de trazas un poco complicadas dentro de la aplicación, por lo que después de investigar un poco el tema, encuentra en
un sitio de internet un ensamblado público que le brinda esta funcionalidad. Bruno descarga este ensamblado, lo prueba y lo incluye dentro de la aplicación.
Como Bruno es una persona muy organizada, además ha creado las pruebas
correspondientes que aseguran que en el ordenador de Bruno todo funciona correctamente.
En el momento de proteger el código, el servidor de integración continua lanza una
serie de excepciones avisando que no puede compilar las modificaciones que ha introducido Bruno porque no tiene acceso al componente para trazas. Al mismo tiempo
Valentino ha descargado la última versión de la aplicación y claro, tampoco puede compilar.
Así que, además de tener que poner un €uro en la tarrina de los errores, Bruno
tiene que dar una solución. Y claro, como el problema es que el componente no está compartido, la solución pasa por crear un recurso compartido de red en el servidor de
compilación:
\\BuildServer\ComponentesComunes
Y después, modificar los proyectos para que utilicen las referencias desde esa
ubicación. ¡Esta solución es excelente!, piensan todos ya que una vez aplicados los
cambios, las compilaciones vuelven a funcionar y además Bruno, Valentino y Martina pueden seguir trabajando.
Tip: No recuerdo cuando pero sí recuerdo que fue al gran Rodrigo Corral
(@r_corral) al primero que escuché nombrar el ejemplo de “poner un €uro en la
hucha/alcancía”. Este ejemplo se aplica a los equipos de desarrollo y básicamente
consiste en que cada vez que una persona realiza una modificación en el código de
una aplicación que rompe la build, debe poner un €uro en la hucha.
De esta forma logramos que una penalización mínima ayude a que los
integrantes de un equipo de desarrollo velen no solo por crear código de buena
calidad que funcione correctamente, sino que además se integre correctamente con
el código de sus compañeros. Estamos dando, un pequeño paso hacia la propiedad
colectiva del código que propone XP.
Si aquí acabase la historia esta sección sería aburrida, así que, para ponerle más
emoción llega el día en que Martina (que es muy inquieta) ve que existe una nueva
versión del componente de trazas y decide actualizarlo. Descarga la nueva versión e intenta copiar esta versión del componente al directorio compartido; pero se
encuentra que el archivo está “tomado por otro usuario”.
**
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Con
teni
do
lice
ncia
do a
:
Source Control 49
Después de analizar las sesiones abiertas en el recurso compartido con sus compañeros de equipo, llegan a la conclusión de que cuando decidan actualizar un
componente común, todos deben cerrar los proyectos en Visual Studio que utilicen
estos componentes y detener el servidor de compilación. Esto como solución es válido, pero en el futuro les traerá algún que otro problema porque Valentino está trabajando
en un componente común, que se almacena en ese directorio y sobre el que realiza cambios constantemente.
Pero bueno, la moral del equipo es alta, y se organizan para seguir adelante,
deteniendo el trabajo individual cuando sea necesario. Con el tiempo aparece un nuevo problema. Una vez que la versión 1.0 de la
aplicación “App2” ha sido desplegada en producción, se reportan errores sobre la
misma. Como Bruno, Martina y Valentino son personas organizadas, tienen un esquema de Branching que les permite aislar el código de la versión desplegada en
producción para trabajar con la misma. El problema surge en el momento de intentar compilarla. Entonces se dan cuenta de que necesitan la versión anterior del
componente de trazas y la de otros componentes que se almacenaban en el directorio
compartido. Entonces la cosa se complica un poco más, porque o bien reemplazan todos los
componentes de la versión 1.0 en el recurso de red hasta que se solucione el problema,
o bien, modifican las rutas de acceso de los componentes comunes en los proyectos a
otra ruta compartida para la versión 1.0, por ejemplo:
\\BuildServer\ComponentesComunes1.0
Esta segunda opción permite que Bruno trabaje en la resolución del error de la versión 1.0 y paralelamente Valentino y Martina sigan adelante con la versión 2.0.
Con el tiempo, y con otras aplicaciones en desarrollo los directorios de componentes comunes quedan:
\\BuildServer\ComponentesComunes
\\BuildServer\ComponentesComunes1.0
\\BuildServer\ComponentesComunes1.1 \\BuildServer\ComponentesComunesApp3_1.0
\\BuildServer\ComponentesComunesApp3_1.1
\\BuildServer\ComponentesComunesApp3_20110622_Test
Y muchos más, ya que cada recurso compartido se corresponde con una entrega o
despliegue de un producto en un momento específico del tiempo. Es en este punto cuando Martina, Bruno y Valentino se hacen la siguiente pregunta:
¿Por qué no almacenar los componentes comunes en el repositorio de código
fuente? Allí podremos versionar los mismos, asociarlos con las Releases que estamos
entregando en cada branch, tener la capacidad de crear branches específicas para
pruebas, etc.
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
li
cenc
iado
a:
Cla
udio
V
arga
s
Ale
jos
50 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Y termina esta historia, a la que seguro alguno de vosotros podría aportar un poco
más de luz. El objeto de la misma era demostrar como la mala gestión del código
fuente puede crear problemas que, aunque inicialmente parecen sencillos, a la larga
generan complicaciones de muy difícil solución.
5.3.- Opinión: Bibliotecas externas: ¿referenciar
ensamblados o incluir proyectos?
Por lo general, los proyectos de desarrollo exigen cumplir unos requisitos que se
escapan de los que brinda la plataforma sobre la que se construyen. Por ejemplo, en el
caso de .Net Framework, es posible utilizar las bibliotecas que se incluyen en .Net
Framework para guardas trazas en una aplicación (usualmente conocidos como Logs);
pero si la complejidad de los requerimientos se incrementa, es momento de tomar una
decisión al respecto.
En la mayoría de los casos, si hay tiempo y recursos, es probable que los propios
integrantes del equipo se dediquen a desarrollar una solución para un requerimiento
especial. Pero en el caso de las trazas, existen muchas soluciones gratis disponibles en
el mercado que ya proveen soluciones concretas a escenarios de trazas, por ejemplo
Apache Log4Net (http://j.mp/mJkxx4) o Enterprise Library (http://j.mp/iuC7kL).
Cuando estas soluciones se distribuyen con el código fuente además de los
ensamblados, la opción más utilizada es agregar una referencia al ensamblado. En el
90% de los casos el código fuente queda como una referencia para aprender del mismo.
Pero existen casos donde este escenario se puede torcer un poco. Por ejemplo,
suponed un proyecto donde se utilice el bloque de Logging de Enterprise Library para
gestionar las trazas de una aplicación distribuida. Una de las ventajas del bloque de
Logging es que implementa un modelo en el que las trazas se pueden enviar utilizando
colas Message Queuing MSMQ (http://j.mp/kCxX9s) sin tener que modificar el
código fuente de la aplicación.
Dicho de otra manera: una vez definidos los puntos de traza en una aplicación y
agregado el código para implementar los mismos; la configuración del bloque de trazas
de Enterprise Library define qué repositorio se utilizará para guardar las trazas; por
ejemplo:
Una base de datos como repositorio.
Un archivo de texto.
El visor de eventos de Windows.
Un repositorio central sincronizado por colas.
Etc.
En este caso la capacidad de gestionar trazas distribuidas y asíncronas (4) es una
funcionalidad que ahorraba mucho trabajo al equipo de desarrollo.
-
Con
teni
do
lic
enci
ado
a:
Cla
udio
V
arga
s A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
Source Control 51
Así que, una vez descargada una versión de Enterprise Library, se agregan los
ensamblados de Enterprise Library como referencias a la solución y se comienza a
trabajar con la misma.
En este punto la aplicación se organiza simplemente con una estructura similar a la
siguiente:
App
o Lib. Directorio con los ensamblados de Enterprise Library.
o Src. Directorio con el código de la aplicación.
El utilizar componentes externos como referencia es una opción rápida y efectiva, la
cual recomendamos para estos escenarios sin pensarlo dos veces.
Ahora bien, resulta que el sistema de mensajería distribuido es muy potente y ya
está implementado. Entonces, en un determinado momento del proyecto, se decide
utilizarlo, además de la gestión de trazas de aplicación, como sistema de intercambio
de información entre los diferentes nodos de la aplicación. Esto es posible ya que el
bloque de Logging de Enterprise Library está diseñado bajo un patrón de proveedores y
factorías en el que para crear una nueva implementación o un nuevo proveedor solo es
necesario implementar un par de interfaces.
Después de crear este nuevo proveedor de mensajería, se compila este ensamblado
y se agrega al mismo dentro del directorio “Lib”.
En el repositorio de código fuente veríamos, a partir de ese momento, lo siguiente:
App
o Lib. Directorio con los ensamblados de Enterprise Library y el
nuevo proveedor de mensajería.
o Src. Directorio con el código de la aplicación.
Los proyectos de la solución hacen referencia a los componentes del directorio
“Lib” y todo funciona correctamente, tanto las trazas de la aplicación, como el sistema
de mensajería.
El problema surge cuando la complejidad del sistema de mensajería empieza a
crecer de manera muy rápida y además él mismo comienza a aproximarse más al
negocio de la aplicación que a la funcionalidad propia de la mensajería.
Llegados a este punto, el día a día del equipo de desarrollo es muy poco ágil, ya que
para cada cambio necesario en el sistema de mensajería se debe actualizar en primer
lugar el ensamblado de Logging de Enterprise Library, y después la propia aplicación.
Al estar más cerca de la lógica de negocios, se decide entonces incorporar este proyecto
de Logging dentro de la solución, ya no como una referencia externa en el directorio
“Lib”, sino como un nuevo proyecto en la solución.
Con el paso del tiempo, este proyecto se convirtió en varios proyectos, asociados a
líneas funcionales de la aplicación y desde un punto de vista organizacional,
**
09/0
8/20
13
Con
teni
do
l
icen
ciad
o
a:
Cla
udio
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om
52 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
efectivamente es recomendable que el código fuente sea parte de la solución completa
como un todo, y no como una referencia externa relacionada con los Logs.
Personalmente considero que una referencia externa (por ejemplo un ensamblado en
proyectos .Net) debe ser siempre tratada como una “referencia externa”. Sólo se debe
comenzar a trabajar con el código de la misma como parte de una solución mayor,
cuando dicha referencia esté atada al funcionamiento propio de la aplicación.
Nunca se debe hacer esto para “mejorar el proceso de depuración”, ya que si el
contrato de trabajo de lo que se requiere de ese componente externo está bien definido,
y el mismo está construido con sus determinadas pruebas que determinan la
funcionalidad de ese contrato; esto debería bastar para que una referencia a una “dll”
sea suficiente.
En cambio, si al mismo tiempo que se modifica el código de negocio de una
aplicación, es necesario modificar el código de este componente externo, es muy
probable que éste no deba ser tratado como un componente externo sino que sea parte
de la lógica y de la estructura de la aplicación.
6.- CONCLUSIÓN
En este capítulo no se han tratado tópicos comunes de la gestión del Source Control
como bloqueo de archivos, gestión de Workspaces, etc., sino que hemos centrado
nuestra atención en contar casos reales asumiendo que el lector posee una cierta
experiencia con el producto.
Es por ello que la conclusión de este capítulo de Source Control es muy simple, de
hecho, sería más adecuado considerarla una recomendación en vez de una conclusión:
Antes de comenzar a trabajar con un repositorio de código fuente, SIEMPRE se
debe implementar un esquema básico de Branching y Merging (como el de esta
sección en su forma más simple) y SIEMPRE se debe tener una definición inicial de
la organización que poseerá el repositorio del Source Control.
Cuando no se adopta una estrategia de este tipo al principio de un proyecto, a la
larga encontraremos mayores problemas en el momento que queramos reorganizar
el código, intentar dar soporte a desarrollos evolutivos y correctivos, etc.
6.1.- Opinión: ¿Qué aporta Visual Studio ALM?
Desligándonos de toda la responsabilidad de crear guías y comentar experiencias; y
dejando todo este trabajo a los ALM Rangers o a gurús de internet, es probable que en
este momento estéis pensando en utilizar este libro para estabilizar la pata de una mesa
o como papel borrador para que aprendan a pintar con colores vuestros niños. No
seremos tan vagos y os contaremos qué es lo que nos gusta de Visual Studio ALM y os
daremos algunos consejos sobre lo que hemos aprendido durante estos años trabajando
con VS ALM.
Es frecuente oír comentarios del tipo: la gestión de código con Team Foundation es
de peor calidad que con otros productos, por ejemplo SubVersion, o encontrar
comparaciones con sistemas distribuidos de control de código fuente como GIT o
-
*-
09/0
8/20
13
C
onte
nido
lic
enci
ado
a:
Cla
udio
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
Source Control 53
Mercurial. Objetivamente, Team Foundation cumple con lo básico que debe poseer un
gestor de código fuente (con lo básico y mucho más, pero lo básico está).
Por ejemplo, es muy probable que si estáis acostumbrados a trabajar con GIT, no
veáis tan ágil o dinámica la capacidad de crear y trabajar con ramas que posee Team
Foundation; claro GIT es un sistema distribuido y Team Foundation es un sistema
centralizado. Es comparar peras con manzanas o zombis con vampiros, ambos dan
miedo pero si te muerden no te afectan igual.
En cualquier caso, tras estas críticas tan sólo se esconde la resistencia al cambio y a
la adaptación de un nuevo esquema de trabajo y de una nueva herramienta. Porque en
realidad, frente a la pregunta de esta sección: ¿Qué aporta Visual Studio ALM?, la
respuesta es que obtendremos una gran flexibilidad a la hora de adaptar cualquier
forma de trabajo, incluso las específicas de una determinada metodología de gestión de
proyectos, en las mismas herramientas de trabajo que utiliza el equipo de
desarrolladores. Dicho de otra forma, lo importante está en la capacidad de definir una
serie de directivas, o una forma de trabajo, en este caso con el Source Control, e
intentar seguir las mismas para asegurar un resultado predecible.
Para terminar, encontraréis descritas en detalle un par de funcionalidades que posee
Visual Studio ALM que se recomiendan usar en todos los proyectos en los que
participéis como Program Managers o como consultores.
6.1.1.- Políticas de CheckIn
La siguiente figura es una de las principales a tener en cuenta en este libro, ya que
detalla las relaciones que existen entre los diferentes elementos con los que puede
trabajar Visual Studio ALM:
Figura 17 - Relación de elementos en Visual Studio ALM
-
-*
09/0
8/20
13
C
onte
nido
l
icen
ciad
o a
: C
laud
io
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om
54 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Elementos de Source Control
Elementos de la gestión de WorkItems (gestión del trabajo, seguimiento de
bugs, etc)
Definición y ejecución de Builds
Lo principal a tener en cuenta sobre la relación entre todos los elementos, es que a
partir de estas fuentes de datos se centraliza la información en una única base de datos
que luego nos permite analizar las relaciones entre estas fuentes. Este tema se abordará
con más en detalle en otro capítulo.
Volviendo a las políticas de CheckIn (Checkin Policies), éstas se ejecutan
previamente a la acción de CheckIn de forma local en el IDE de un desarrollador y
validan una serie de condiciones antes de proteger el código.
Por ejemplo, una política muy utilizada “obliga” a los desarrolladores a poner un
comentario en la acción de CheckIn. Esto garantiza que antes de hacer un CheckIn se
deba escribir “algo” para describir la acción de CheckIn.
En el caso de que un desarrollador decida no cumplir una política de CheckIn, por
ejemplo no escribir un comentario, el IDE de Visual Studio mostrará una ventana en la
que se advierte que nos estamos “saltando” una política de CheckIn.
Esto luego queda registrado en la base de datos de Team Foundation y es posible
hacer un seguimiento de estas excepciones para validar la causa de las mismas y dar
una solución a estos escenarios.
Si bien existen varias políticas de CheckIn que vienen por defecto en Visual Studio
ALM y otras tantas que se distribuyen con las Team Foundation Server Power Tools;
es recomendable utilizar siempre el siguiente par.
ChangeSet Comments Policy. Esta política requiere que las personas que
hacen un CheckIn escriban un comentario en el formulario de CheckIn.
WorkItems. Esta política requiere que se asocie uno o más WorkItems en
el formulario de CheckIn.
Para activar una política de CheckIn, simplemente seleccionamos el Team Project
desde el panel “Team Explorer”, desplegamos el menú contextual y seleccionamos la
opción “Team Project Settings // Source Control”.
A continuación seleccionamos la pestaña “Check-in Policy” y podemos configurar
las mismas desde esta sección.
-
*
09/0
8/20
13
Con
teni
do
lic
enci
ado
a: C
laud
io
V
arga
s
A
lejo
s
clau
dioc
va@
hotm
ail.c
om
Source Control 55
Figura 18 - Agregar políticas de CheckIn
Cuando una acción de CheckIn, no cumple una o más políticas de las definidas en
un proyecto, veremos en el formulario de CheckIn qué políticas no estamos
cumpliendo y además una descripción asociada a la misma. En este punto es posible
saltarse la política, y en ese caso deberemos escribir el motivo por el que no se ha
cumplido la política de CheckIn.
Figura 19 - Advertencia cuando no se cumple una política de CheckIn
-
-
Cla
udio
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
licen
ciad
o
a:
56 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Otras políticas de utilidad en el desarrollo de aplicaciones son:
Code Análisis. Esta política requiere que se cumplan las reglas de análisis
de código asociadas a los proyectos antes de subir el código fuente de los
mismos al repositorio.
Custom Path Policy. Esta política se asocia a otra política de CheckIn y
evita que a bloques específicos de los archivos que se están subiendo al
repositorio se aplique la otra política de CheckIn asociada. Un ejemplo,
puede ser, cuando habilitamos la política de Code Analysis, no forzar a que
todos los proyectos que se suben al repositorio de código fuente cumplan
esta política.
Testing Policy. Esta política requiere que una serie de pruebas unitarias se
hayan pasado exitosamente antes de proteger el código.
6.1.2.- Integración con Windows Explorer
Utilizando las Team Foundation Server Power Tools tenemos acceso a una de las
funcionalidades más requeridas en un gestor de código fuente:
La integración con Windows Explorer. Es decir poder realizar acciones de
Source Control directamente desde Windows Explorer.
La siguiente imagen muestra un ejemplo sobre como a partir de un directorio es
posible realizar las mismas acciones que están disponibles en el Source Control de
Visual Studio, para trabajar con él. De la misma manera podemos trabajar con un
archivo o con un conjunto de archivos.
Figura 20 - Integración con Windows Explorer
--
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s
Source Control 57
6.1.3.- CheckIn Notes
Las notas asociadas a un CheckIn (CheckIn Notes) permiten asociar MetadData
adicional a la acción de CheckIn para luego trabajar con la misma. Por defecto una
acción de CheckIn posee tres notas asociadas que podemos completar de manera
opcional:
Code Reviewer
Security Reviewer
Performance Reviewer
Adicionalmente, desde la administración de un Team Project en la sección Source
Control podemos administrar estas notas y agregar nuevas, incluso de manera
requerida.
Por ejemplo, si agregamos una nueva nota llamada “ALMBook Comment”, en el
momento de proteger un cambio y si no la completamos veremos el siguiente mensaje:
Figura 21- Validación en CheckIn Note
-
*-
09/0
8/20
13
C
onte
nido
li
cenc
iado
a
: C
laud
io
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
58 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
7.- EXTRAS
7.1.- Tip: Herramientas fundamentales para trabajar con
Source Control
7.1.1.- Team Foundation Server Power Tools
Team Foundation Server Power Tools es un set de herramientas adicionales para
Visual Studio y Team Foundation desarrolladas por Microsoft y distribuidas de forma
gratuita a través de Visual Studio Gallery (http://j.mp/j6N9eS).
El detalle completo de funcionalidaes que proveen estas Power Tools se puede ver
en su página de descarga, sin embargo, es importante remarcar algunas de ellas:
Team Foundation Server BackUps. Esta funcionalidad disponible solo
para Team Foundation Server 2010 y superiores, permite realizar un
BackUp de las diferentes bases de datos que utiliza Team Foundation
Server de manera centralizada. Su importancia radica en que TFS no solo
guarda una base de datos por cada Team Project Collection, sino que
además existe información relacionada almacenada en SQL Reporting
Services, en SharePoint, etc.
Process Editor. TFPT incorpora un editor para los tipos de WorkItems
definidos en un Team Process Template y para el propio Team Process
Template. Este editor está integrado en Visual Studio y presenta una
interfaz amigable para editar estos contenidos.
Windows Shell Extensions. TFPT agrega las extensiones a Windows
Explorer para poder realizar las tareas típicas de Source Control desde el
explorador de archivos de Windows.
7.1.2.- Team Foundation Server MSSCCI Provider
Team Foundation Server MSSCCI Provider es una extensión tambien desarrollada
por Microsoft que permite utilizar las capacidades de Team Foundation desde otros
entornos de desarrollo diferentes a Visual Studio. Actualmente soporta los siguientes
entornos:
Visual Studio .NET 2003
Visual C++ 6 SP6
Visual Visual Basic 6 SP6
Visual FoxPro 9 SP2
-
*-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s
Source Control 59
Microsoft Access 2007
SQL Server Management Studio
Enterprise Architect 7.5
PowerBuilder 11.5
Microsoft eMbedded VC++ 4.0
7.1.3.- Team Foundation Sidekicks
Este producto, desarrollado por Attrice, se puede descargar gratuitamente
(http://j.mp/kb1iMD) y agrega funcionalidades adicionales para el trabajo con el
Source Control.
Las funcionalidades están disponibles integradas desde Visual Studio o en una
herramienta externa. Del amplio abanico de funcionalidades cabe destacar:
Workspace Sidekick. Esta funcionalidad permite administrar fácilmente los
Workspaces definidos en un Team Project.
Status Sidekick. Esta funcionalidad permite analizar el estado de los
ficheros almacenados en el Source Control y trabajar con los mismos. Es
especialmente útil para el típico escenario de “desbloquear un fichero
tomado por un desarrollador”.
7.1.4.- TFS Source Control Explorer Extension
Esta extensión para TFS permite realizar tareas con el Source Control no incluidas
en el IDE de Visual Studio. Por ejemplo:
Move/Branch To Folder. Parece muy simple, pero lamentablemente el
IDE no soporta las acciones de mover o realizar Branches de más de un
archivo hacia un directorio. Con esta extensión es posible realizar esta
tarea.
Drag & Drop. Una vez más, da soporte a un “must have” en una
herramienta de este tipo.
Destroy. En Team Foundation es posible destruir completamente un
elemento del Source Control, pero solo a través de la línea de comandos.
Esta extensión presenta esta opción directamente integrada en el IDE.
*
Con
teni
do
lic
enci
ado
a
: C
laud
io
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
60 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
7.2.- Team Foundation para usuarios de SubVersion
Durante los últimos años he participado en varios proyectos de migración de
repositorio de código fuente de SubVersion (SVN) a Team Foundation. Estas
migraciones se realizaban principalmente para aprovechar las capacidades de Team
Foundation como herramienta integrada de gestión de elementos de trabajo, Source
Control, Builds, etc., frente a escenarios de diferentes herramientas integradas entre sí
manualmente para lograr el mismo resultado.
Cuando un usuario de SVN comienza a trabajar con Team Foundation, el principal
cambio radica en comprender este concepto de herramienta integrada; ya que los
conceptos de ramas, branching, etiquetas/revisiones, etc. son similares.
La principal diferencia para un usuario puede radicar en la forma en la que ambos
productos trabajan con los archivos. Por un lado, SVN agrega una carpeta llamada
“.svn” en la que se almacenan los archivos modificados en cada directorio de trabajo
mientras que Team Foundation trabaja con Workspaces. Los Workspaces guardan la
información en el servidor de Team Foundation y es en ellos donde se registran los
archivos que se marcan para editar, los archivos tomados por un usuario, etc.
Esto significa que un usuario de SubVersion no puede trabajar directamente desde
el explorador de archivos como hace habitualmente con TortoiseSVN
(http://j.mp/k0oQVZ); sino que tiene que trabajar desde el IDE de Visual Studio o
con las extensiones de las Power Tools que permiten trabajar desde el explorador de
archivos.
Otro cambio importante hace referencia al trabajo desconectado o en modo OffLine.
SubVersion nace como un sistema de control de archivos para escenarios
principalmente desconectados, con lo que esta sitaución la tiene bastante resuelta.
Team Foundation por su parte está pensado para entornos empresariales, con lo que se
asume que la conexión es algo que no se debería perder usualmente y si bien el soporte
a modo “offline” está disponible, no es tan potente como en SVN.
La siguiente tabla muestra algunos conceptos que son propios de un gestor de
código fuente y como aplican en SubVersion y Team Foundation.
Tabla 3- Terminologías de SubVersion y Team Foundation
SVN TFS Comentarios
Check - out Get Latest En ambos casos es necesario tener
configurado un Workspace Update Get Latest o Get Specific
Version
Commit Check - in Se agregan las capacidades de
relación con WorkItems e
integración con Team Build
Revision Changeset Un Changeset posee toda la
información del Source Control
además de la relación con los
WorkItems relacionados
Add Add Estas acciones son similares en
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a:
Cla
udio
Var
gas
Ale
jos
Source Control 61
Delete Delete ambos productos
Copy Branch
Move Move
Revert Rollback La acción de rollback se realiza a
nivel de Changeset
Status Status
Diff Compare
Blame Annotate
Log History
*
-
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
l
icen
ciad
o
a:
63
CAPÍTULO
No soy el único de mi equipo, pero en mi equipo soy único.
Dr. Gregory House
En un equipo de buenos profesionales, la metodología de trabajo y las herramientas no son esenciales. Una vez que un proyecto está en marcha, el
equipo madura constantemente hasta alcanzar el máximo nivel de eficiencia
posible.
Valentino Capuano en el 2020
Pues listo, si has entendido esas frases te puedes ahorrar las siguientes 90
páginas. Aunque claro, también estaría muy bien ver un poco de qué va todo
esto de las metodologías y la gestión de un proyecto de desarrollo de software.
Gestión del trabajo
3
-
--
C
onte
nido
lice
ncia
do
a: C
laud
io
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
64 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
1.- UN POCO DE SENTIDO COMÚN
La experiencia nos dice que el 99,99% de los proyectos informáticos que fallan no
se deben a una mala decisión técnica, ni a un problema de implementación, sino que en
la mayoría de los casos es un problema de gestión del proyecto. Un proyecto fallido es
aquel que no termina en tiempo, o donde el producto entregado no se corresponde con
las expectativas del usuario final, o aquel que dobla el presupuesto inicial asignado, etc.
Estos problemas no son nuevos en el mundo del desarrollo de software, y para cada
uno de los escenarios anteriores han ido surgiendo soluciones que han ayudado a
mitigar estos problemas. Por ejemplo, para que el usuario final no se encontrase con
una solución que no era la esperada, inicialmente se mostraba al usuario un diseño de
una aplicación, una planificación de seis meses de trabajo para sacar adelante este
diseño y cuando se tenía el “GO” por parte del usuario, se comenzaba a trabajar en la
solución.
Con el tiempo, este modelo de trabajo ha demostrado que seis meses sin interactuar
con un usuario final es mucho tiempo, y que lo más aconsejable es tenerlo “lo más
cerca posible” y convertirlo en parte del equipo de trabajo. Esto no quita que se
cumplan una serie de acuerdos y contratos y que un equipo tenga un objetivo claro a
conseguir en un periodo de tiempo.
Para dar forma a estos contratos y procesos de trabajo existen diferentes
metodologías que definen el “cómo” se debe trabajar en proyecto de software, algunas
de ellas son: CMMI, AGILE, SCRUM, etc. Sin necesidad de entrar en detalles sobre
las mismas, se puede afirmar que los resultados en un proyecto de desarrollo no son
una consecuencia directa de la elección de la metodología, sino que dependen de lo
bien o mal que se lleve la misma.
Nota: Si en un equipo de desarrollo cuentas con cinco profesionales de
excelente nivel que además trabajan con las mejores herramientas, no importa la
metodología de trabajo que tengan que seguir, el proyecto será un éxito
garantizado.
Hay expertos de CMMI o de metodologías estilo waterfall, cuyo único objetivo es
controlar al máximo el trabajo de un programador, para lo cual gestionan proyectos
basándose en la cantidad de líneas de código escritas por el programador. En otras
ocasiones, obligan a que exista un diseño técnico detallado y aprobado por un comité
de analistas antes de crear un paquete/clase/función para asegurarse de que no se
escriba una línea de código sin “su documentación asociada”. Esta forma de trabajo y
este tipo de controles se suelen aplicar por varios motivos. Por lo general, en algunos
casos estas personas vienen de entornos HOST donde sí se realizan este tipo de
controles, y en otros casos es simplemente un caso de fanatismo del control sobre las
acciones de un equipo pero no de la productividad del mismo. Esta forma de gestionar
un proyecto suele traer, a largo plazo, más problemas que beneficios.
-
-
09/0
8/20
13
C
onte
nido
lic
enci
ado
a
: C
laud
io V
arga
s
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
Gestión del trabajo 65
Veamos a continuación otro caso real el cual trata de un proyecto muy ambicioso en
el que se manejaba un presupuesto de aproximadamente 5 millones de euros. En él
participaban diferentes equipos geográficamente distribuidos en Madrid, Bangalore y
Chicago para las tareas de diseño, construcción y testing. En las fases iniciales del
proyecto participaba un experto agilista con amplia experiencia en la gestión de
proyectos con SCRUM, pero con poco sentido común.
Uno de los momentos más extraños del proyecto fue cuando dicho experto, al que
llamaremos “Steve”, presentó la dinámica de trabajo para organizar los diferentes
equipos. En la reunión preparó un tablero de trabajo estilo Kanban, y con notas de
papel (PostIts) comenzó a mostrar diferentes escenarios de trabajo. A priori la idea
parecía buena, ya que la base de la gestión de un proyecto es conocer el trabajo
pendiente, el trabajo activo y el trabajo realizado; pero a medida que avanzaba la
reunión se evidenció que el tablero de trabajo con PostIts no era un ejemplo, sino “¡¡¡la
herramienta con la que pensaba gestionar el trabajo de 200 personas!!!”. Después de
una discusión orientada a encontrar una alternativa más viable, se descartó la idea del
tablero, aunque basándose en ella se optó usar un soporte informático.
Otro gran momento con Steve se produjo a la hora de planificar el trabajo (repartir
las tareas, funcionalidades, definir cuándo comenzaba a trabajar cada equipo, etc.)
puesto que creía firmemente que definir el trabajo a realizar con exactitud de una
persona o un grupo de trabajo de aquí a seis meses era una tarea imposible además de
inútil.
La premisa de Steve se apoya en que en la dinámica de un proyecto de desarrollo de
software, existen muchas variables que no podemos controlar y que pueden tener un
impacto imprevisible. Quizás existan muy pocos proyectos que en base a una
planificación inicial de un año de trabajo, llegado el mes 12, realmente han cumplido
con los objetivos marcados inicialmente. Pero esto no quita que en un proyecto deban
existir hitos a cumplir en una fecha estimada con el fin de no perder el objetivo del
proyecto. Como casi todas las variables en el desarrollo de software, estos hitos irán
cambiando, descartando los que se queden obsoletos o inválidos y agregando aquellos
que se detecten como nuevos. Este es el concepto que existe detrás de la agilidad, la
capacidad de adaptarse al cambio y la gestión del mismo.
Tras este inciso, volvamos al ejemplo. Cuando Steve recibió una planificación
inicial creada con Microsoft Project, su comentario: “No tengo ningún software para
abrir este archivo, porque este software es una máquina de generar mentiras”, terminó
de sacar de quicio a más de un participante del proyecto. En este punto, el responsable
económico del proyecto hizo la siguiente reflexión:
Steve, tú me dices que no crees en la planificación y yo respeto esa opinión, ya que el experto en gestión de proyectos de desarrollo eres tú. Sin embargo, tengo un
dilema relacionado con los costes del proyecto, que es el aspecto que me toca
regular a mí. Como sabes, nuestro equipo en la India se encargará de la parte del
Testing, para este caso en particular y para los escenarios de Testing de
integración, utilizaremos un software montado en unos entornos de HOST que no pueden estar disponibles al 100% para nosotros. Para poder reservar los tiempos
de Testing sobre ese entorno, necesito conocer una fecha estimada para ir
*
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a: C
laud
io
Var
gas
Ale
jos
66 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
gestionando esta petición, ya que si no lo gestionamos con meses de antelación los costes se triplican (te recuerdo que yo debo velar por la cuestión económica del
proyecto). De la misma manera, cuando el equipo de Testing comience a trabajar
en este entorno, debemos gestionar una línea de transferencia de datos entre Chicago y Bangalore que permita al equipo de desarrollo, interpretar los datos de
las pruebas para realizar todo tipo de análisis. En este punto, tengo un problema mayor, ya que si bien no hay recargo adicional en la petición de estas líneas, si hay
un problema de logística y de tiempos, porque el proveedor necesita 20 días para
poder montar esta infraestructura. Como ves, la planificación “a largo plazo” puede no ser una constante para el desarrollo de software pero si es una realidad
para la gestión de un proyecto.
Steve, por decisión propia, abandonó el proyecto y durante el año y medio los hitos
y tareas cambiaron muchas veces, pero siempre adaptándose a los requerimientos y
cambios que pedía el equipo asignado por el cliente como parte integral del equipo
(más adelante comentaremos el porqué de Agile).
Con este ejemplo no ser pretende desestimar ninguna metodología ni ninguna forma
de trabajo. Como hemos dicho al principio, el éxito de un proyecto no depende de la
metodología escogida, sino de su aplicación durante el proyecto. Además, debemos
tener en cuenta que para lograr un resultado exitoso es recomendable tener las mejores
herramientas posibles y a los mejores profesionales disponibles. Esto, que parece una
utopía, debe ser una premisa para quien lidere un proyecto de desarrollo de software.
1.1.- La herramienta adecuada para cada problema: El
Valentino y su rayo de la muerte
Tras varias interesantes conversaciones con “el Valentino” (mi niño de 3 años)
sobre “el rayo de la muerte” hemos concluido que el rayo de la muerte es el arma más
poderosa del mundo y puede destruir una avispa que nos molesta en la piscina,
descacharrar un coche amigo de Rayo McQueen, o destruir un planeta donde viven
muchos personajes muy malos. Un día estábamos jugando en la piscina y vimos una
avispa que nos molestaba, le pregunté cómo podíamos sacarnos a la pesada avispa de
encima, y teniendo a mano veinte cosas que podríamos haber utilizado, la respuesta del
Valentino fue: “¡la quemamos con el rayo de la muerte!”. Valentino no se anda con
chiquitas y apuesta fuerte en cada jugada.
Intenté explicarle que para espantar a una avispa una simple revista es suficiente. Si
tuviésemos un rayo de la muerte a mano podríamos hacer cosas más divertidas que
matar a una simple avispa; como por ejemplo, hacer un hueco en el océano Atlántico
para que se arme el remolino de agua más grande del mundo. Y claro, por un lado el
Valentino entendió la idea, pero por otro se quedó decepcionado por no usar el rayo de
la muerte. Eso sí, cuando nos pusimos a tirarle cosas a la avispa para que se fuese, le
dimos al panal y nos empezó a perseguir un enjambre de los buenos. A la diversión le
siguió una charla relacionada con jugar con avispas y lo peligroso de estas situaciones
dada por “la mamá”.
-
-
Con
teni
do
licen
ciad
o
a:
Cla
udio
V
arga
s
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Gestión del trabajo 67
Esta anécdota se puede extrapolar a nuestro trabajo a la hora de elegir la
herramienta o el grupo de herramientas adecuadas a cada problema, eso sí, sin tener
que recurrir al rayo de la muerte.
Por ahora con Valentino lo tenemos claro:
A las avispas les tiramos lo que tengamos a mano para espantarlas. Ahora bien,
si alguna vez llega una nave espacial llena de marcianos malhumorados, ahí
sacamos el rayo de la muerte y nos hacemos una fiesta liquidando marcianos.
2.- CMMI, AGILE, SCRUM; UN POCO DE TODO
Antes de comenzar a explicar cómo puede ayudar Visual Studio ALM a darnos un
empujón en la gestión de un proyecto, es recomendable darle un vistazo rápido al
estado en el que nos encontramos actualmente.
2.1.- Un poco de historia.
Después de más de 30 años donde la ingeniería del software intentaba aplicar una
gestión de proyectos predictiva, los cambios producidos en los últimos 10 años han
provocado que algunos pilares fundamentales estén comenzando a tambalearse (y a
perder bastante apoyo).
Hagamos un poco de historia, volvamos hacia atrás, casi a los inicios. Después de la
década de los ’50, cuando comenzaron a aparecer los ordenadores, los proyectos
dejaron de ser cosa de científicos y personas individuales y surgió la necesidad de dar
un poco de forma al trabajo que se realizaba con “estas máquinas”.
Pero no fue hasta 1968 cuando se definió el término Ingeniería del Software para
dar respuesta a la necesidad de aplicar un enfoque sistemático, disciplinado y
cuantificable al desarrollo, operación y mantenimiento del software. En la actualidad,
la guía SWEBOK, por sus siglas en inglés: Software Engineering Body of Knowledge
(http://bit.ly/qk1Ipt), es el documento que más se acerca a brindar un enfoque
orientado a la Ingeniería del Software (http://bit.ly/mWkCje).
Nota: El SWEBOK es parte de una serie de proyectos que intentan cubrir
varias áreas relacionadas con el desarrollo del Software. Los demás documentos
son los siguientes:
PMBOK — Project Management Body of Knowledge
EABOK — Enterprise Architecture Body of Knowledge
BABOK — Business Analysis Body of Knowledge
*
-
C
onte
nido
licen
ciad
o
a
: C
laud
io
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
68 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
CMBOK — Configuration Management Body of Knowledge
ABOK - Automation Body of Knowledge
Como suele suceder en muchos aspectos de la tecnología, el primer paso en definir
una forma organizada en procesos y métodos fue dado por el ejército. En proyectos
donde era necesario coordinar el trabajo de diferentes equipos interdisciplinarios era
necesaria una guía o una serie de reglas que permitieran llevar adelante esta
colaboración.
Y así es que, 20 años después, en la década del ’80, se definieron los objetivos a
cumplir en un proyecto de desarrollo del software:
El proyecto se debe ejecutar en el tiempo planificado.
El proyecto se debe ejecutar sin desbordar el presupuesto estimado.
El proyecto se debe ejecutar satisfaciendo las necesidades del cliente.
Sobre esto hay mucha historia y muchos libros interesantes para leer al respecto,
pero lo que más llama la atención, es que en esa época los cambios se medían en
décadas cuando actualmente tenemos una avalancha diaria de novedades para
interpretar, elegir y aplicar en los proyectos.
Es en la época actual cuando se comienza a hablar en términos de “ciclo de vida”,
donde a partir de una planificación inicial se divide el desarrollo en diferentes fases
escalonadas que dan vida a la gestión de un proyecto.
A partir de esta definición de fases y de esta forma de trabajo, nace una de las
palabras que peor suena en boca de los gestores de proyecto actuales “Waterfall”
(http://bit.ly/pYiEgL). La planificación y la ejecución en este modo de trabajo,
básicamente, permite representar la organización de un proyecto en fases secuenciales,
es decir, para poder comenzar una fase, se debe dar por finalizada la anterior.
Un ejemplo de un proyecto “en cascada” es el siguiente:
1. Definición de requisitos
2. Diseño
3. Construcción
4. Verificación y Despliegue
5. Mantenimiento
Este es un modelo muy clásico y muy robusto, ya que permite, sobre el principio de
aplicar una planificación que respeta siempre la misma estructura; la ejecución basada
en la repetición de actividades. Como los modelos y las planificaciones parten de una
-
*
Cla
udio
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lice
ncia
do
a:
Gestión del trabajo 69
base común, se incrementó la implantación de modelos de trabajo basados en factorías.
La informática maduró y comenzaron a surgir nuevos modelos que dejaron de trabajar
sobre la creación de un producto de software, sino que se centraron en la
especialización de los procesos para la creación de ese software.
Un ejemplo de un modelo para la mejora y evaluación de procesos de desarrollo,
mantenimiento y operación de sistemas de software es Capability Maturity Model
Integration (CMMI, http://bit.ly/nR4rxf). CMMI define cinco niveles de “madurez”
para una organización.
Para evaluar el nivel de madurez en una organización ésta debe realizar un
“appraisal” o evaluación que define el nivel de madurez que poseen sus procesos.
Si bien existen buenas prácticas recomendadas durante una evaluación, un nivel de
CMMI sólo indica de qué manera se cumplen los procesos definidos en una
organización, pero no significa que la definición de estos procesos sea la adecuada.
Otros modelos de Desarrollo de Software como Personal Software Process
(PSPSM, http://bit.ly/pwmePl) o ISO 15504 también conocida como SPICE (por sus
siglas en inglés Software Process Improvement Capability Determination,
http://bit.ly/oKnmZe), también están diseñados para solucionar estos problemas con
un enfoque similar.
Sin embargo, la experiencia indica que en muchos proyectos guiados con estas
técnicas, no fue posible encontrar una correspondencia entre los planes originales con
los que se definió el proyecto y cómo se terminó realmente. Por lo general, esto ocurre
porque cumplir el plan inicial ha dejado de ser el objetivo principal de los proyectos.
Las cosas han cambiado, para simplemente, conseguir un buen nivel de satisfacción de
los clientes (que en estos casos se logra en la entrega, no al inicio del proyecto).
2.2.- El comienzo de los problemas
Este tipo de organización y gestión de proyectos de software ha generado bastante
polémica en los últimos años. Por una parte, la definición de un objetivo claro y
conciso que dé base a un plan detallado de trabajo, genera una sensación de control que
es muy confortable al momento de comenzar un proyecto. Pero, por otra parte, surgen
dudas como por ejemplo:
¿Cómo es posible conocer con detalle los requerimientos de una aplicación
si no se ha creado ni siquiera un prototipo de la misma?
¿Cómo es posible asegurar que un requerimiento de negocio no cambiará
durante un período de tiempo?
¿Qué sucede si un cliente no queda conforme con parte de la aplicación,
por ejemplo su apariencia? ¿Cómo es posible prever este tipo de
situaciones?
Estas preguntas y otras han dado lugar a un nuevo enfoque para la ejecución de un
proyecto, ya que en muchas ocasiones, el problema no estaba relacionado con la
-
09/0
8/20
13
Con
teni
do
li
cenc
iado
a
: C
laud
io
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om
70 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
gestión del proyecto propiamente dicha, sino más bien con la mala elección de los
mecanismos para hacerlo.
Para conocer la cantidad de proyectos que actualmente fracasan, primero
deberíamos poder poner métricas para ver el concepto de fracaso, lo cual resulta
ambiguo en muchas ocasiones. Una forma de ver la repercusión de estos temas es
realizar una búsqueda en Bing o Google y ver que la misma arroja más de 15000000 de
resultados. Si realizamos un análisis de los resultados de estas búsquedas veremos los
siguientes conceptos relacionados con el porqué del fallo de los proyectos de software:
Requisitos poco claros: La mayoría de la gente no sabe cómo definir un
requisito porque nunca ha construido una aplicación. La mala gestión de los
requisitos conlleva la construcción de una aplicación que no refleja la realidad
de los deseos de los usuarios.
La falta de feedback por parte de los usuarios: Es muy común que los
desarrolladores no hablen con la gente que va a utilizar el software.
Estimaciones muy “apretadas”: Es común pensar que proponer un agresivo plan
de trabajo permitirá adelantar trabajo, pero en realidad lo suele retrasar. Por
ejemplo, una toma de requisitos apresurada, seguida de un diseño superficial,
para poder saltar directamente a la codificación, suele terminar en un producto
con una calidad defectuosa que luego se paga en la estabilización.
Falta de apoyo del equipo ejecutivo de una organización: Cuando la
organización no se compromete con los proyectos que se realizan dentro de la
misma, por lo general, están destinados al fracaso.
Resumiendo, las metodologías tradicionales, de las que hablamos en puntos
anteriores implican que si un programador pudiese anticipar el conjunto completo de
requisitos, y los mismos no cambiasen durante la vida de un proyecto, sería posible
evitar el sobre coste de la adecuación a los cambios. Este escenario es razonable e ideal
en entornos estables pero no es cierto en la mayoría de los entornos donde el
dinamismo de un negocio obliga a cambiar constantemente.
2.3.- Una alternativa saludable: Welcome to AGILE
Como consecuencia de todo esto han aparecido nuevas metodologías ágiles con el
objetivo de dar solución a estas necesidades. Pero para hablar de AGILE es necesario
comenzar por XP - eXtreme Programming (http://bit.ly/nkCvqa). XP nace de la
mano de Kent Beck a partir de su trabajo como asesor en Chrysler en el proyecto
Chrysler Comprehensive Compensation System (C3) en el año 1996.
Debido a la mala calidad del sistema actual de liquidación para Chrysler, Kent Beck
toma una de las decisiones que más nos gusta en el desarrollo de software: “tirarlo todo y comenzar desde cero”. A partir de este punto, el equipo de trabajo de Kent,
**
09/0
8/20
13
Con
teni
do
lic
enci
ado
a:
Cla
udio
Var
gas
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
Gestión del trabajo 71
comienza a utilizar y madurar las prácticas que él fue desarrollando y probando a lo
largo del tiempo.
El proyecto fue un éxito y como salida del mismo, Kent Beck dio origen a XP. Pero
Kent Beck no creó todo el contenido de la definición de XP, algunas de las prácticas de
XP existen desde mucho antes y fueron incorporadas por Kent Beck a su modelo de
desarrollo. Por ejemplo, el concepto de “Test First Development” fue utilizado por la
NASA en la década de los ’60 para su proyecto Mercury (http://bit.ly/qA0lzq). En
este proyecto, además de unas especificaciones iniciales, existía un equipo que se
disponía a crear diferentes sets de pruebas para los elementos del proyecto, antes de
que existiesen los mismos.
En 1999 Kent Beck publica su libro “Extreme Programming Explained” donde
pone de manifiesto sus experiencias con las buenas prácticas aplicadas en el proyecto
C3, y explica sus recomendaciones personales. A partir de 1999 XP comienza a ser una
forma de trabajo muy popular entre diferentes equipos porque su mayor contribución
consiste en adoptar un set de buenas prácticas y adaptarlas a los diferentes entornos y
proyectos.
Pero Kent Beck no podía quedarse quieto y en marzo de 2001 convocó a 17
expertos en procesos, gestión de proyectos y gurús del sector para discutir sobre el
estado del desarrollo de software. Fue en esa reunión donde oficialmente nació el
concepto de AGILE, o de “metodologías ágiles” como una alternativa a las
metodologías formales, más rígidas y muy atadas a los conceptos de planificación
estructurada.
En esa reunión se creó el denominado “Manifiesto Ágil” donde se establecieron los
cuatro valores en los que se basan las metodologías ágiles:
Centrados en el individuo y en sus interacciones más que en el proceso y en las
herramientas.
Centrados en desarrollar software que funciona más que en obtener una buena
documentación.
Centrados en la colaboración con el cliente más que en la negociación de un
contrato.
Centrados en responder a los cambios más que en seguir una planificación.
Hoy, varios años después de esta reunión, las metodologías ágiles han crecido y han
madurado mucho, siendo las principales referencias para los desarrollos de software.
Ejemplos de esto son: eXtreme Programming (XP), Lean Development (LD) o
SCRUM. Todas ellas tienen como objetivo la satisfacción del cliente, la flexibilidad
para adaptarse a los cambios y la entrega frecuente de Releases para obtener un
feedback rápido sobre el estado del proyecto.
Existen muchos libros dedicados a AGILE, SCRUM, XP, etc., y el objetivo de este
libro no es describir estas metodologías. Lo que sí encontrarás en este libro son
ejemplos en los que se usan estas metodologías junto con Visual Studio ALM. Estos
casos también se aprovechan para comentar cómo se pueden ajustar algunos
-
Cla
udio
V
arga
s A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
C
onte
nido
l
icen
ciad
o a
:
72 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
parámetros para que un equipo pueda funcionar coordinadamente con las herramientas
necesarias para lograr un objetivo claro y conciso.
3.- GESTIÓN PARA DUMMIES
Después de repasar las diferentes tendencias en gestión de proyectos de software,
volvamos a las bases comenzando por la gestión, o dicho de otra manera, por la
“organización estructurada del trabajo”. Antes de adentrarnos en los escenarios más
comunes (Visual Studio ALM, un equipo de desarrollo de varias personas,…),
describiremos el día a día en el que nos movemos para ver como sacamos adelante las
tareas más simples.
Nota: Los mejores profesionales comparten una serie de características
comunes que les ayudan a llevar adelante proyectos complejos. Una de estas
características es una aptitud natural para el orden y para romper con esquemas
preestablecidos adaptándose a los cambios.
Imaginad, aunque sea ficticio, un escenario donde un equipo de trabajo tiene
todo perfectamente organizado, la gestión de su trabajo, su proceso de integración
continua, su proceso de despliegue y gestión de Releases, etc. El líder del proyecto,
está muy feliz, conoce a la perfección cómo trabaja su equipo y todas las piezas
funcionan en un sincronismo perfecto. Después de mucho trabajo ha logrado tener
un esquema general de “orden” en el equipo que le da un control total sobre los
objetivos que se persiguen.
Pero en determinado momento este “orden” se ve alterado por un factor
externo. Puede ser un cambio técnico, como por ejemplo una actualización en la
versión del runtime de ejecución, que obliga a actualizar la aplicación, repensar el
modelo de despliegue e integración continua, etc. Puede ser un cambio de negocio,
donde uno de los componentes básicos de la aplicación debe ser reescrito por
completo ya que una nueva normativa gubernamental ha cambiado el curso normal
de trabajo. O incluso, puede ser un cambio de personal, uno de los integrantes del
equipo ha decidido aceptar un nuevo desafío y abandona el equipo.
En todos estos casos, tanto el líder de proyecto como los participantes del
equipo tienen que hacer un esfuerzo para adaptarse a estos cambios y lograr un
nuevo “orden” en el trabajo del equipo.
Cuando el líder es resistente al cambio al cabo de un par de años se encontrará
con un equipo desmotivado, un producto desfasado y otros problemas que no son
menores. Pero si el líder, tras evaluar el cambio y determinar los beneficios que
aporta, lo afronta con optimismo y define un camino de acción para que su equipo
se adapte al mismo y pueda seguir trabajando, el resultado será muy diferente.
La gestión de proyectos se puede aplicar también en la vida personal. Imaginemos
una pareja con hijos que utiliza PostIts en la nevera para conocer las tareas y su estado
(pendientes, en progreso y terminadas). Para ello, utilizan un tablero de 3 columnas
*
Cla
udio
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
li
cenc
iado
a:
Gestión del trabajo 73
donde cada PostIt representa una tarea y cada columna, de izquierda a derecha,
representa el estado de las mismas. Esta lista es tan dispar que puede contener
elementos como:
Cambiar las lamparitas de luz del baño de la habitación principal.
Imprimir y colgar en el muro el certificado de Inglés del Valentino
Comprar comida y arena para los gatos
Llamar a su mamá (Esta tarea se suele postergar bastante en el tiempo y
más aún en época estival)
En la siguiente imagen se muestra una foto de la nevera con los PostIts donde se
puede ver que las tareas no están ordenadas por prioridad, ni tienen una persona
asignada, ni tampoco hay una estimación de cuánto tiempo llevará cada tarea.
Figura 1- Gestión en casa
Cuando esta familia decidió, en una asamblea democrática, qué tipo de
organización aplicarían a las tareas de la casa, se decantaron por Kanban como proceso
de trabajo.
Ahora bien, si bien es cierto que Kanban (http://bit.ly/qoAmpk) generalmente se
aplica gestionando el flujo de estados por los que pasa una tarea y controlando el
trabajo de un equipo en base a la capacidad de trabajo de ese equipo (WIP), en la
implementación familiar, cualquiera es capaz de realizar cualquier tarea y eso sirve de
excusa para que las tareas se acumulen.
Su WIP no es fijo, sino que viene a ser el piso de la cocina, pues cuando la lista de
PostIts llega hasta el piso, eso significa que “se les viene la casa encima”.
-
Cla
udio
V
arga
s
Ale
jos
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
74 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Nota: En una sección posterior explicaremos, de una forma más sencilla,
Kanban y además, cómo implementar un proyecto utilizando Visual Studio ALM.
Véase “Kanban y Team Foundation”.
Si intentamos trasladar este modelo de trabajo a un equipo de desarrollo, podremos
ver que es lo suficientemente flexible para gestionar el trabajo de un equipo pequeño.
La experiencia nos indica que en algunos proyectos además de las columnas anteriores,
existen otras secciones para el trabajo propuesto, para las tareas bloqueadas, para las
tareas resueltas pero no cerradas, además de variaciones como asignar un color de
PostIt diferente para una tarea o un error, o pegar una sobre otra tareas/PostIts que son
de alcance o resultados similares.
Como modelo de trabajo este esquema es muy útil, pero lo mejor es que vaya
acompañado de un soporte informático. Además, en este modelo, no suele existir una
clasificación de tareas por categoría o bloques funcionales. Si trasladamos a un tablero
de este tipo, que básicamente es una representación del trabajo realizado, las tareas que
están en progreso y las pendientes de realizar de un proyecto real; y añadimos un nuevo
elemento que represente los requerimientos relacionados con el proyecto, cada tarea/
PostIt estaría relacionada con un requerimiento. De esta forma podríamos ver el estado
de cada requerimiento en el proyecto en un “mini tablero de trabajo”.
Volviendo al ejemplo de la familia, inicialmente trabajan con 3 bloques funcionales:
Compras
Tareas de casa
Varios
Basándonos en estas categorías las tareas de trabajo podrían ser organizadas como
se muestra en la siguiente tabla:
Tabla 1- Organización de tareas por categoría.
Categoría Tarea Estado
Compras
Comprar arena para los gatos Pendiente
Comprar comida para los gatos Completo
Tareas de casa
Cambiar lamparitas del baño Completo
Imprimir y colgar en el muro el certificado
de Inglés del Valentino
En progreso
Varios
Llamar a mi mamá Pendiente
-
**
09/0
8/20
13
C
onte
nido
lice
ncia
do
a
: C
laud
io
V
arga
s A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
Gestión del trabajo 75
Ahora bien, dependiendo del estado de las tareas que componen una categoría,
podríamos definir estados para cada categoría.
Tabla 2 - Estados por categoría.
Categoría Tarea Estado
Compras Pendiente
Comprar arena para los gatos Pendiente
Comprar comida para los gatos Completo
Tareas de casa En Progreso
Cambiar lamparitas del baño Completo
Imprimir y colgar en el muro el certificado
de Inglés del Valentino
En progreso
Varios Pendiente
Hablar con mi mamá Pendiente
Con este esquema en casa, ya saben que cuando compren la arena para los gatitos,
no habrá más compras que realizar por algún tiempo; y que, una vez colgado el
diploma del Valentino, las tareas de la casa también estarán completas.
Si trasladamos la definición a una metodología ágil, un requerimiento es una
historia de usuario (User Story) que una vez validada con un usuario, puede dar a lugar
a la creación de una o más tareas para dar una solución a la misma.
3.1.- ¿Cómo gestionar las necesidades de los clientes?
En la mayoría de los proyectos de software las necesidades de un cliente se
denominan “requerimientos”. La mala gestión de estas necesidades suele ser la causa
de muchos de los problemas en los proyectos de desarrollo. Además, en ocasiones los
equipos trabajan sin una dirección clara y guiados por una serie de premisas que no
ayudan a mejorar el trabajo del equipo.
En realidad, la correcta gestión de estos elementos viene dada por el sentido común
para el trabajo en equipo. Se trata de mantener a un equipo sincronizado con los
clientes, manteniendo una visibilidad constante del trabajo realizado y del estado del
proyecto. En todo momento, todos los integrantes del equipo deben tener en claro,
QUÉ se está construyendo y POR QUÉ se está construyendo una determinada pieza de
software o una aplicación.
Nota: Requerimiento es una palabra que no termina de convencer a muchos
agilistas. Si vemos su definición formal en la Real Academia Española
encontramos tres acepciones:
1. m. Acción y efecto de requerir.
2. m. Der. Acto judicial por el que se intima que se haga o se deje de ejecutar
20128
*
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Con
teni
do l
icen
ciad
o
a:
76 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
algo.
3. m. Der. Aviso, manifestación o pregunta que se hace, generalmente bajo fe
notarial, a alguien exigiendo o interesando de él que exprese y declare su
actitud o su respuesta.
Kent Beck en “Extreme Programming Explained” comenta lo siguiente en
relación a la palabra requirement:
“Software development has been steered wrong by the term requirement,
defined in the dictionary as something that is mandatory or obligatory. The word carries a connotation of absolutism and permanence, inhibitors for embracing
change.
And the word “requirement” is just plain wrong. “Out of the thousands of pages used to describe requirements, if you deliver the right 5, 10 or 20 percent,
you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80 percent? Not requirements—they weren’t mandatory or
obligatory.”
Al margen de estas cuestiones, en esta sección seguiremos utilizando
“requerimiento” como el vocablo para definir la herramienta de recogida de
información con un cliente. Más adelante veremos que dependiendo de la
metodología, esto se puede transformar en una User Story, o incluso en otros
elementos más técnicos como un diagrama de estados, etc.
La siguiente frase contiene nuestra definición de requerimiento:
Un requerimiento describe un objetivo a alcanzar que pueda luego ser testeado
para verificar si se ha cumplido.
Un requerimiento puede ser una descripción de la funcionalidad de la aplicación,
del aspecto gráfico de la misma, etc. Puede ser definido utilizando diferentes
herramientas o lenguajes, por ejemplo: simple texto, prototipos o modelos gráficos.
Independientemente del lenguaje, el contenido del requerimiento tiene que ser lo
suficientemente completo para que un equipo pueda comenzar a construir una
aplicación y para que se puedan definir las pruebas que aseguren su calidad.
En los proyectos actuales es probable encontrarnos con cientos de requerimientos
que definen los aspectos más importantes de una aplicación. Sin embargo, hasta que no
se comienza a crear la aplicación, no es posible verificar si los requerimientos son
coherentes entre sí. Por ejemplo, es muy común que durante la fase de planificación de
una aplicación se creen muchos requerimientos de diferentes fuentes, por un lado los
clientes finales pueden darnos una descripción a grandes rasgos de lo que se desea de la
aplicación; el equipo de diseño gráfico puede crear una serie de MockUps o prototipos
que describan el look and feel que debe poseer la aplicación; un equipo de QA puede
definir aspectos técnicos como por ejemplo la cantidad mínima de transacciones por
20128
*
Cla
udio
V
arga
s
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a:
Gestión del trabajo 77
segundo que debe soportar la aplicación; entre otras. Estos requerimientos se van
agregando y organizando por prioridad, funcionalidad, peso, valor, etc.
Generalmente al inicio del proyecto, se define un plan de entregas donde se indica
qué requerimientos serán incluidos en cada entrega así como un calendario inicial con
las entregas para el proyecto. Es a partir de este punto cuando podemos hablar de
requerimientos reales, ya que tras la primera entrega, es muy probable que sea
necesario revisar los requerimientos ya definidos para ir acomodando los mismos a las
necesidades del proyecto. Pero teniendo siempre presente que, independientemente de
si hablamos de iteraciones (AGILE), Sprints (SCRUM), fases (CMMI), etc., los
requerimientos cambian constantemente y la mejor forma de evaluar dichos cambios es
ir dando vida a un producto de forma que permita validar e implementar los
requerimientos.
Por esto, es muy importante encontrar las herramientas adecuadas para poder
plasmar los requerimientos teniendo en cuenta que se cumplan las siguientes premisas:
Los requerimientos deben describir una necesidad. De forma que sea
posible dar solución a los mismos y poder validarlos con la ejecución de
una o más pruebas.
Por ejemplo, un requerimiento del tipo “Necesito un sistema de cartera de clientes”,
describe una necesidad, pero necesita mucho más trabajo de refinamiento hasta poder
dar con el detalle de un requerimiento detallado. Otro ejemplo sería “el sitio web debe
ser rápido”, en este caso se define una idea pero no un criterio que permita probarlo;
sería mucho más efectivo definir un requerimiento con la frase “la carga de las páginas del sitio web no debe superar 1 segundo”.
Todos los integrantes del equipo deben comprender los requerimientos.
Idealmente, todos los integrantes del equipo deben ser multidisciplinarios y
comprender todos los aspectos del problema que se ataca. Pero si, por ejemplo, solo
una persona conoce como funciona un tema específico y cuando escribe el
requerimiento lo hace con un lenguaje incomprensible para el equipo o el cliente,
entonces se debe modificar la descripción del requerimiento para que sea entendible
por todos los integrantes del equipo.
Independientemente de su complejidad, TODOS son requerimientos.
No importa si se toman apuntes en una pizarra o un MindMap
(http://bit.ly/nfUMSC), o si un requerimiento es un caso de uso formal de UML; toda
la información que se maneje en un proyecto es relevante para el mismo. Muchas veces
dejamos de lado información por considerarla poco importante y esto a la larga
ocasiona problemas. Por ejemplo, en la definición de CMMI for Agile 5.0 que se
incorpora con Team Foundation, existe un elemento de trabajo especial para realizar
actas o resúmenes de reuniones, el Review (http://bit.ly/mSB0oZ). Un equipo, puede
utilizar este WorkItem para documentar los resultados de una revisión del diseño o del
-*
Cla
udio
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a:
78 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
código. En el mismo se puede indicar qué temas se han tratado, relacionando
Requerimientos existentes, creando nuevos requerimientos, etc.
La colaboración es muy importante.
Los requerimientos son elementos que están vivos durante todo el proceso de
desarrollo. Es muy importante que todos los integrantes de un equipo realicen un
consenso de los mismos para asegurar que todos persiguen los mismos objetivos.
Por ejemplo, cuando un cliente aprueba o da por válido un requerimiento, es muy
importante que sea consciente de que a partir de ese momento un desarrollador
comenzará a trabajar con el mismo. De la misma forma, si una vez definidos un
conjunto inicial de requerimientos, estos quedan sin ser aprobados u organizados para
comenzar a trabajar, ocasionará retrasos en el proyecto.
Los requerimientos pueden cambiar, es importante conocer cómo
influirán estos cambios.
Por más control que se tenga sobre un proyecto, los requerimientos pueden cambiar.
Tener una visión completa del trabajo que se está realizando nos permitirá evaluar
el impacto que provocará el cambio en un requerimiento.
Por ejemplo, un requerimiento de negocio exige que todas las acciones que realiza
un usuario en una aplicación queden registradas en un sistema de trazas. Para cumplir
con este requerimiento se ha creado un sistema de trazas a medida que las almacena en
una base de datos de SQL Server. Con el tiempo se incorpora un sistema de análisis de
información a la organización que requiere que se agregue la información de
utilización de la aplicación. Entonces se define un nuevo requerimiento: la integración
con el sistema de análisis de datos. Esto, probablemente, nos obligará a modificar el
alcance y las tareas iniciales ligadas al requerimiento inicial.
La lista de premisas puede ser mucho más amplia, pero una visión general de ellas
nos ayuda a comprender de qué forma debemos trabajar con los requerimientos en un
proyecto.
3.2.- Historias de Usuario en AGILE.
En AGILE, la principal herramienta que se utiliza para la interacción con nuestros
clientes o usuarios finales es la historia de usuario (User Story http://bit.ly/ikxAZL).
Básicamente, una User Story, es una o más frases que representan lo que un usuario
“quiere hacer” o lo que un cliente “necesita”. AGILE promueve que las mismas se
anoten en pequeñas tarjetas para evitar que el detalle de una User Story sea demasiado
amplio.
Cuando se trabaja con User Stories aflora la siguiente duda ¿por qué no se anotan
más detalles y tan solo se escriben dos o tres líneas en una User Story? La respuesta es
muy simple; no se debe malgastar tiempo en entrar en detalle en una recolección de
historias de usuario ya que es muy probable que la misma cambien cuando se comience
a implementar.
-
-
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
l
icen
ciad
o
a:
Gestión del trabajo 79
Cada User Story debe tener sentido en el contexto del cliente y además en un
contexto que no sea técnico para que todos los participantes del proyecto puedan opinar
y evaluar sobre ella.
Por lo general las historias de usuario se representan con el siguiente formato
"As a <role>, I want <some goal > so that <some reason>"
Este formato nos permite definir en una misma frase el QUIÉN (role), el QUÉ
(Some goal) y el POR QUÉ (Some reason) de una necesidad transmitida por un cliente.
Esto no es obligatorio para la descripción completa de una historia de usuario. Por
ejemplo es posible comenzar escribiendo en una tarjeta una simple descripción de la
necesidad
“Agregar clientes en biblioteca virtual”
Y luego completar la historia de usuario con los detalles propios de la plantilla:
“Como un lector deseo tener un usuario en la biblioteca virtual para poder
consultar y alquilar libros”.
Además de las premisas definidas para un requerimiento en la sección anterior, una
User Story debe poseer el mínimo detalle necesario para que un desarrollador pueda
hacer una estimación ideal sobre el trabajo necesario para dar una solución a la User
Story. Las historias de usuario deben poder ser estimadas entre 1 y 3 semanas, en caso
de no ser posible, es aconsejable reacomodarlas juntando varias historias de usuario en
una “superior”, o desagregando una User Story en historias de usuario más simples.
3.2.1.- Frodo, Gandalf y las historias de usuario.
Para hacer más llevadera la lectura haremos una analogía entre una vivencia
personal y la historia de usuario que nos llevará a una interesante conclusión. Esta
historia sucedió hace muchos años. Un buen día mi amiga la flaca dejó caer en mis
manos El Hobbit de J.R.R. Tolkien. Como era un tipo de lectura nueva para mí, en un
par de días me ventilé las 324 páginas del libro; entonces la flaca decidió prestarme la
trilogía de El Señor de los Anillos, pero aquí la cosa no fue tan bien.
En primer lugar, por la cantidad de páginas que tiene cada libro. A ver, yo entiendo
que contar tantas historias paralelas al mismo tiempo requiere espacio, pero tantos kilos
de peso para un anillo que puedes conseguir por 20€ en internet sin gastos de envío ¡me
parece una locura!
En segundo lugar, los bosques. Sé que es un tópico, pero leer más de 40 páginas en
las que únicamente se describe un bosque de arbolitos me resulta cansino. He de
admitir que hasta hace unos meses, tras un viaje a Canadá, mis conocimientos sobre
árboles se reducían a saber diferenciarlos entre: árbol, pino o palmera. En Canadá
intentaron que aprendiese conceptos como sauce llorón, eucalipto, etc.; pero estoy
-*
09/0
8/20
13
Con
teni
do
lic
enci
ado
a
: C
laud
io
V
arga
s
A
lejo
s
cla
udio
cva@
hotm
ail.c
om
80 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
convencido que con árbol, pino y palmera puedo tirar otros 30 años sin ningún
problema.
Finalmente, la mala planificación, especialmente la de Gandalf. Resulta increíble
que un inmortal, con la sabiduría que ha acumulado durante siglos, frente a una de las
campañas más difíciles de todos los tiempos ponga a cuatro hobbits. No me
malinterpretéis, yo no tengo nada contra Frodo, Sam, Merry o Pippin. Es más, me caen
muy bien este tipo de personas; siempre dispuestas a tener una jarra de cerveza en sus
manos y cantando canciones de fiesta, podríamos decir que son unos tipos de lo más
simpáticos. Pero de ahí, a poner en sus manos el destino de la tierra media, el error de
planificación es evidente. Si en lugar de a cuatro hobbits le das el anillo a un Navy
Seal, o a su homólogo en esa época, entonces a Tolkien le hubiese quedado un cuento
de 40 páginas.
Si este hubiese sido un proyecto de informática, Gandalf hubiese creado la
siguiente historia de usuario y ¡listo!:
Yo como un habitante de la tierra media
Deseo destruir el anillo este de aquí
Para no tener miedo al ojo de Sauron
Sin embargo, el mago embauca a cuatro o cinco razas diferentes para llevar un
anillo hasta Mordor, cuando por internet en cuatro o cinco días estaría listo.
A simple vista parece que no había buena comunicación con los integrantes del
equipo, o que los hobbits no eran muy avispados porque ¿qué hubiese pasado si
produjera el siguiente diálogo?:
Frodo: Gandalf, ¿es cierto que eres uno de los magos más poderosos?
Gandalf: Bueno no es para tanto, pero sí, soy un mago de los buenos, buenos. Frodo: Y eso que hiciste el año pasado de montar en un águila gigante, ¿lo puedes
hacer siempre que quieras?
Gandalf: En un águila, un halcón, un buen dragón; depende del día.
Frodo: Tomemos como ejemplo un águila, ¿qué autonomía tiene?, ¿podría llegar
hasta Mordor? y ¿hasta el monte del destino? Gandalf: Las águilas son magníficas, llegan hasta Mordor y más lejos aún.
Frodo: Entonces, ¿no se te ha ocurrido agarrar el anillo, subirte al águila, volar
hasta el monte del destino…? Bueno ya me entiendes.
A continuación encontrarás las conclusiones extraídas de las más de 1200 páginas y
las más de 9 horas de películas y aplicables al tema que nos atañe:
Siempre redacta bien tus historias de usuario.
Es importante que las mismas reflejen objetivos realistas que puedan ser llevados a
cabo en una o dos semanas y que además puedan ser testeados.
-
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a: C
laud
io
Var
gas
A
lejo
s
Gestión del trabajo 81
Habla y comunícate con tu equipo.
No tengas miedo de hacer preguntas difíciles o poco agradables. Por lo general,
estas preguntas hechas al principio de un proyecto son más fáciles de solucionar que al
final.
3.2.2.- Tutorial: Registrar User Stories utilizando Microsoft
Excel e importarlas a Team Foundation.
En este tutorial veremos cómo realizar una toma de requerimientos utilizando
Microsoft Excel y luego importarlos a Team Foundation. Para este ejemplo
utilizaremos un Team Project basado en MSF for Agile, con lo que nuestros
requerimientos serán historias de usuario.
1. Abrir Visual Studio 2010
2. Conectar al Team Project correspondiente. Para este ejemplo utilizaremos
un Team Project llamado “ALMBookAgile”
3. En el panel Team Explorer, acceder al Team Project y dentro del mismo en
la sección de elementos de trabajo (WorkItems), crear una nueva consulta.
4. Cuando aparezca la consulta la guardaremos con los valores por defecto
con el nombre “Manage User Stories from Excel”
5. En este punto es necesario modificar la consulta para que aplique los
siguientes criterios de filtro:
And/Or Field Operator Value
Team Project = @Project
And Work Item Type = User Story
And State = Any
6. Luego es necesario modificar la consulta para que muestre las siguientes
columnas respetando el orden propuesto:
a. ID
b. WorkItem Type
c. Title
d. Description
e. Assigned To
f. State
-
--
Con
teni
do
l
icen
ciad
o
a:
Cla
udio
V
arga
s
Ale
jos
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
82 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
g. Area Path
h. Iteration Path
7. Guardar la consulta.
8. En este punto debemos seleccionar la consulta creada desde el panel Team
Explorer, desplegar el menú contextual y seleccionar la opción “Open in
Microsoft Excel”.
9. Podemos ver como la lista creada en Visual Studio se abre en Microsoft
Excel.
Figura 3- Lista de requerimientos en Excel
10. Para agregar una nueva fila a la lista en Excel, nos situamos en la última
fila y en la última columna y presionamos “TAB”, esto agregará una nueva
fila.
11. En este punto, debemos seleccionar el tipo de WorkItem como “User
Story” y podremos ver como el campo “Title” se marca como obligatorio y
además en el campo descripción tenemos el texto predefinido para crear
una historia de usuario.
-
-
09/0
8/20
13
Con
teni
do
lic
enci
ado
a
: C
laud
io
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om
Gestión del trabajo 83
Figura 4- Alta de historias de usuario en Excel.
12. En este punto ya podemos comenzar a dar de alta masivamente nuestras
historias de usuario, completando solamente los campos “Title” y
“Description”.
13. Una vez que hemos completado la carga de historias de usuario, las
publicamos al servidor Team Foundation utilizando el botón “Publish” de
la Ribbon “Team”.
14. Adicionalmente podemos completar campos como “Assigned To”, “Area
Path” o “Iteration Path”, para darle más valor a nuestra User Story.
15. En cualquier momento podemos guardar y volver a abrir esta hoja de Excel
para seguir trabajando en ella.
3.3.- Proyecto Valmar: Gestionando el inicio de un proyecto
con Visual Studio ALM.
A continuación encontraréis la transcripción de la típica charla entre un cliente y
cualquiera de nosotros.
Nosotros: Bien, después de ver, pero sin profundizar, los requerimientos para la aplicación, no nos olvidemos del entorno de desarrollo.
Cliente: No sé a qué te refieres, entiendo que vosotros contareis con vuestros
ordenadores y vuestras herramientas de desarrollo, ¿no es así?
-
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
licen
ciad
o
a:
Cla
udio
Var
gas
A
lejo
s
84 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Nosotros: Efectivamente, pero además de nuestros ordenadores, necesitaremos
un servidor de colaboración, un entorno de pruebas, un entorno de compilación, etc.
Cliente: Bien, dame los requerimientos de hardware y veremos cómo lo
gestionamos.
Generalmente, lo primero que debemos hacer en un nuevo proyecto es poner a
punto el entorno de desarrollo. Es muy importante hacerlo correctamente en los
comienzos del proyecto, ya que cambiar la dinámica de trabajo e incorporar elementos
en fases de desarrollo, puede ocasionar retrasos o contratiempos. Pero, ¡cuidado!, esto
no significa que luego no tengamos que madurar nuestros procesos de integración
continua, o de despliegue. La idea de montar el entorno de desarrollo es establecer una
buena base para que el equipo pueda trabajar.
Una vez aclarada la necesidad de un entorno de desarrollo, podríamos comenzar a
pensar en la siguiente User Story con la que empezar a trabajar:
As a Developer I want a development environment so that I can collaborate with
the development team, I can perform CI and I can use an integration and test
environments.
Asumiendo que ya poseemos un entorno con Team Foundation server configurado e
instalado, y que estamos trabajando con una plantilla de trabajo basada en MSF for
AGILE 5.0, podríamos crear una User Story y además describir las tareas necesarias
para completarla.
En Team Foundation una User Story si se utiliza MSF for AGILE o un
Requerimiento si se utiliza MSF for CMMI, requiere de una información básica para
poder trabajar con él:
Título: Hace referencia a la denominación del elemento.
Descripción: Contiene los detalles del elemento. Es por ejemplo donde se
completa la información con formato "As a <role>, I want <goal/desire> so
that <benefit>"
Implementación: Describe la tarea o grupo de tareas necesarias para dar
solución al elemento. También permite desagregar el elemento, por ejemplo,
una User Story en otras User Stories más simples.
Testing: Describe los casos de pruebas que se deben llevar a cabo para poder
validar la correcta implementación del elemento.
En las guías de proceso que se distribuyen con Visual Studio ALM las necesidades
de un cliente se traducen como User Stories o Requirements. En ambos casos estos
elementos de trabajo representan una necesidad. Luego es necesario complementarlos
-
-
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
li
cenc
iado
a:
Gestión del trabajo 85
con otros elementos de trabajo para definir la implementación y las pruebas que se
deben ejecutar sobre dicha necesidad para darla por cerrada.
Por ejemplo, si trabajamos con una User Story; para su implementación es posible
asociar una o más tareas que representen el trabajo real a realizar por un equipo. En el
caso de las pruebas, la definición de una User Story nos permite asociarla con uno o
más casos de prueba (Test Cases) los cuales definirán los criterios de aceptación para la
User Story.
Nota: Si en el momento de implementar una User Story tenemos un escenario
donde vemos que es posible asociarla con otras User Stories para su
implementación, podemos crear una jerarquía de User Stories que terminarán en
tareas de implementación y que nos ayudarán a organizar mejor el trabajo a
realizar.
Además de completar las tareas de implementación y los casos de prueba, es
necesario completar valores como la iteración, el área, la prioridad, los puntos de la
User Story, etc.
La siguiente imagen muestra los elementos básicos (WorkItems) que podemos
asociar a una User Story para definir, por un lado su implementación y por otro lado las
pruebas necesarias (Test Cases) para validar la User Story.
Figura 5 - Elementos básicos relacionados con una User Story.
Una vez asociados varios WorkItems a la User Story, la misma puede quedar en un
estado similar al de la siguiente imagen. Aquí, es posible apreciar los elementos que
diferencian la implementación de las pruebas.
-
*-
09/0
8/20
13
C
onte
nido
licen
ciad
o a:
Cla
udio
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om
86 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 6 - Ejemplo de elementos relacionados.
Volviendo al ejemplo anterior, si inicialmente definimos una User Story con el
texto acordado con el cliente, en nuestro proyecto deberíamos tener creada la siguiente
historia de usuario:
Tabla 3- Historia de Usuario inicial
Campo Valor
Title Setup Development Environment
Description As a Developer I want a development environment so that I can
collaborate with the development team, I can perform CI and I can use an
integration and test environments.
Assigned To Developer Lead
Figura 7- Historia de usuario inicial.
-
Cla
udio
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lic
enci
ado
a:
Gestión del trabajo 87
En este punto, esta historia de usuario es más bien un poco “vaga” en su definición.
Así que lo ideal es comenzar a trabajar con nuestros clientes para darle más forma. Este
ejemplo ha sido elegido porque nuestro cliente es el propio equipo de desarrollo y los
conceptos que trabajaremos son muy comunes para todos los proyectos.
Una vez realizada una reunión de planificación con el equipo de trabajo, nos
encontramos con tres frentes que debemos atacar para tener montado el entorno de
desarrollo:
En primer lugar, la configuración de los usuarios y permisos que debemos
poseer en nuestro Team Project. Recordemos que a Team Project no solo
acceden los desarrollares, sino también personas de negocio, gerentes, etc. Es
necesario identificar estas personas, crear los usuarios correspondientes en el
dominio, configurar los permisos asociados, etc. Esto, que parece una tarea de
una mañana, suele llevar varios días.
A continuación, tenemos que montar el entorno de compilación. Esto es
necesario para la integración continua, pero además, para crear un mecanismo
ágil para la distribución de Releases intermedias a los entornos de desarrollo y
pruebas. Como las plantillas de Team Build no poseen estas capacidades, es
necesario personalizarlas para dar soporte a este entorno.
Finalmente, es necesario configurar el entono de pruebas. Como esta tarea
requiere del trabajo de un IT Pro, ya que es necesario crear la maqueta de
despliegue utilizando un entorno de trabajo virtual, también se considera como
un nuevo frente de trabajo.
Una vez definidas estas historias de usuario que dependen de la historia de usuario
principal, la implementación queda como muestra la siguiente imagen.
Figura 8 - Implementación de la historia de usuario principal
*
Cla
udio
Var
gas
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
C
onte
nido
l
icen
ciad
o
a:
88 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
El siguiente paso es comenzar a definir las tareas y casos de prueba necesarios para
cada historia de usuario. La siguiente tabla muestra un ejemplo de la implementación
de la historia de usuario relacionada con la configuración de los usuarios y permisos.
Tabla 4- Implementación de una Historia de Usuario.
WorkItem Type Title Assigned To
User Story Users and permissions Abu Obeida (Dev)
Task Implementation Setup user and permissions
in Team Foundation Server
Abu Obeida (Dev)
Task Implementation Setup user and permissions
in Team SharePoint Server
Abu Obeida (Dev)
Task Implementation Setup user and permissions
in Reporting Server
Abu Obeida (Dev)
Test Case Test Cases Test access to Team
Foundation Server
Christine Koch
(Tester)
Test Case Test Cases Test access to SharePoint
Server
Christine Koch
(Tester)
Test Case Test Cases Test access to Reporting
Server
Christine Koch
(Tester)
Cuando creamos una consulta que nos muestre la relación entre las diferentes
historias de usuario, las tareas creadas para su implementación y los casos de prueba
que se han definido para asegurar la calidad de la misma, podemos encontrarnos con
los siguientes resultados
Tabla 5 - Implementación y pruebas para las historias de usuario
WorkItem Type Title Assigned To
User Story Setup Development Environment April Stewart (Dev
Lead)
User Story Users and permissions Abu Obeida (Dev)
Task Setup user and permissions
in Team Foundation Server
Abu Obeida (Dev)
Task Setup user and permissions
in SharePoint Server
Abu Obeida (Dev)
Task Setup user and permissions
in Reporting Server
Abu Obeida (Dev)
Test Case Test access to Team
Foundation Server
Christine Koch (Tester)
Test Case Test access to SharePoint
Server
Christine Koch (Tester)
Test Case Test access to Reporting
Server
Christine Koch (Tester)
User Story Build Environment Doris Krieger (Dev)
-
*
09/0
8/20
13
Con
teni
do
lic
enci
ado
a:
Cla
udio
V
arga
s
A
lejo
s
clau
dioc
va@
hotm
ail.c
om
Gestión del trabajo 89
Task Setup Team build
environment for Continuous
Integration
Doris Krieger (Dev)
Task Create team build process to
allow the deploy of the
application
Doris Krieger (Dev)
Test Case Test CI team build template Christine Koch (Tester)
Test Case Test Build and Deploy team
build template
Christine Koch (Tester)
User Story Lab Management Adrian Gonzalez (IT)
Task Configure Lab Management
environment
Adrian Gonzalez (IT)
Si realizamos un diagrama con los elementos creados en el paso anterior, basados
en la relación de una User Story con los WorkItems de Implementación y Testing,
obtendríamos:
Figura 9.- Relación entre elementos de Implementación y Testing con una User Story.
Cuando utilizamos el informe de MSF for AGILE, “Stories Progress Report”
(http://bit.ly/o6MjpF), nos muestra las diferentes historias de usuario que se definen
en un Team Project. Sobre ellas es posible ver el grado de avance con las horas
completadas, y las horas restantes a partir de la implementación definida.
*
09/0
8/20
13
C
onte
nido
lic
enci
ado
a:
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
90 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
La siguiente imagen muestra un ejemplo sobre este informe en el momento inicial
de trabajo, cuando las tareas todavía no se han llevado a cabo. Aquí podemos ver en
negrita todas las historias de usuario activas y el subtotal y total de horas para los
diferentes grupos de historias de usuario.
Figura 10 - Progreso de las historias en el punto inicial.
Además, es posible filtrar las historias de usuario por iteración o por área y ver las
horas imputadas recientemente. La siguiente imagen muestra la evolución de las
diferentes historias de usuario cuando ya se han imputado horas a las tareas
relacionadas.
Figura 11.- Progreso de las historias después de unos días.
-*
Cla
udio
Var
gas
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lic
enci
ado
a:
Gestión del trabajo 91
Existe otro informe dentro de MSF for AGILE que nos permite ver los siguientes
elementos para cada historia de usuario:
El trabajo pendiente
El trabajo completado
El estado de las pruebas
La cantidad de errores activos
Este informe se denomina “Stories Overview” (http://bit.ly/oiYjqH) y en el
ejemplo de implantación de Team Foundation, después de unos días de trabajo, puede
presentar el siguiente estado.
Figura 12 - Estado de las historias de usuario
En este informe, el estado de las pruebas se obtiene a partir de los resultados de
ejecución de los Test Cases definidos para cada User Story. Los estados para los Test
Cases pueden ser:
Passed
Failed
Not Run
Y siempre se muestra el último resultado de ejecución de un Test Case asociado a la
User Story correspondiente. En la imagen anterior podemos ver que, para la User Story
principal, hay un porcentaje de Test Cases que han pasado correctamente, otros que
han fallado y otros que no se han ejecutado.
-
-*
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lice
ncia
do
a:
92 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
3.3.1.- Tutorial: Crear elementos iniciales para la gestión de
un proyecto
Este tutorial demuestra cómo crear los elementos iniciales descritos en la sección
anterior, para realizar las primeras tareas de gestión en un entorno de desarrollo que
utilice Team Foundation. Para ello, se utilizará una plantilla de procesos basada en
MSF for AGILE.
1. Abrir Visual Studio 2010.
2. Conectar al Team Project sobre el que se quiere trabajar. En este caso
conectamos a un Team Project llamado “ALMBookAGILE”
3. Desde el panel Team Explorer seleccionar el nodo “WorkItems” y crear un
nuevo WorkItem de tipo User Story. Completar los siguientes campos:
Campo Valor
Title Setup Development Environment
Description As a Developer I want a development environment so that I can
collaborate with the development team, I can perform CI and I
can use an integration and test environments.
4. Guardar el WorkItem.
5. Seleccionar la pestaña “Implementation” y presionar el botón “New”. Esto
nos permitirá crear los elementos que definen la implementación de la
historia de usuario creada en los pasos anteriores.
6. En el formulario “Add New Linked WorkItem to User Story” seleccionar
“User Story” para el tipo WorkItem Type y completar la descripción con
“Users and permissions”.
Figura 13- Agregar User Story para la implementación.
-
**
09/0
8/20
13
Con
teni
do
licen
ciad
o
a
: C
laud
io
V
arga
s A
lejo
s
cla
udio
cva@
hotm
ail.c
om
Gestión del trabajo 93
7. Completar los siguientes campos en la historia de usuario creada en el paso
anterior.
Campo Valor
Title Users and permissions
Description As a developers I want to create and allow access to the
development environment to the business users, the
developers and other groups of users
8. Guardar el WorkItem.
9. Repetir los pasos del 5 al 7 para agregar dos nuevas User Stories
relacionadas con la User Story principal.
10. Las nuevas historias de usuario poseen la siguiente información:
Campo Valor
Title Build Environment
Description As a developer I want a build environment to support the CI
process and to allow automatic deploy to integration and test
environments
Campo Valor
Title Lab Management
Description As a developer I want a lab management environment
integrated in the TFS environment so that I can test my
deploys
11. Una vez creadas y relacionadas los WorkItems en la pestaña
“Implementation” de la User Story Principal deben aparecer las tres nuevas
User Stories creadas. En este caso los IDs de las User Stories serían
similares a las siguientes:
20 – Setup Development Environment
21 – Users and Permissions
22 – Build Environment
23 – Lab Management
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lice
ncia
do
a
: C
laud
io
V
arga
s
Ale
jos
94 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 14 - WorkItems Ids en los elementos creados.
12. A continuación definiremos las tareas y casos de pruebas necesarios para
cada User Story.
13. Editar la User Story “Users and Permissions” y en la sección
“Implementation” agregar los siguientes elementos relacionados de tipo
“Task”.
Campo Valor
Title Setup user and permissions in Team Foundation Server
Original Estimate 18
Remaining 18
Completed 0
Campo Valor
Title Setup user and permissions in SharePoint Server
Original Estimate 8
Remaining 8
Completed 0
Campo Valor
Title Setup user and permissions in Reporting Server
Original Estimate 18
Remaining 18
Completed 0
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do l
icen
ciad
o a
: C
laud
io
Var
gas
Ale
jos
Gestión del trabajo 95
14. Editar la User Story “Users and Permissions” y en la sección “Test Cases”
agregar los siguientes elementos relacionados de tipo “Test Case”.
Campo Valor
Title Test access to Team Foundation Server
Automation Status Not automated
Steps 1. Open an internet browser
2. Navigate to http://<server>:8080/tfs/web
3. Login using a valid set of credentials
4. Confirm access to a valid Team Project
Campo Valor
Title Test access to SharePoint Server
Automation Status Not automated
Steps 1. Open an internet browser
2. Navigate to
http://<server>/sites/<TeamProject>
3. Login using a valid set of credentials
4. Confirm access to the SharePoint site
Campo Valor
Title Test access to Reporting Server
Automation Status Not automated
Steps 1. Open an internet browser
2. Navigate to http://<server>/reports
3. Login using a valid set of credentials
4. Confirm access to the Reporting Services portal
15. Editar la User Story “Build Environment” y en la sección
“Implementation” agregar los siguientes elementos relacionados de tipo
“Task”.
-
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a
: C
laud
io
Var
gas
Ale
jos
96 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Campo Valor
Title Setup Team build environment for Continuous Integration
Original Estimate 16
Remaining 16
Completed 0
Campo Valor
Title Create team build process to allow the deploy of the
application
Original Estimate 36
Remaining 36
Completed 0
16. Editar la User Story “Build Environment” y en la sección “Test Cases”
agregar los siguientes elementos relacionados de tipo “Test Case”
Campo Valor
Title Test CI team build template
Automation Status Not automated
Steps 1. Open Visual Studio 2010
2. Create a sample project using C#
3. CheckIn the project into Source Control
4. Create a new Build Definition using the CI Build
Template
5. Modify the sample project
6. CheckIn the changes
7. Confirm that a new build is launched
Campo Valor
Title Test Build and Deploy team build template
Automation Status Not automated
Steps 1. Open Visual Studio 2010
2. Create a sample Website project using C#
-
*-
Cla
udio
V
arga
s A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a:
Gestión del trabajo 97
3. CheckIn the project into Source Control
4. Create a new Build Definition using the Build
and Deploy Build Template
5. Configure the default values for the deploy
environment for the build
6. Launch a new build
7. Confirm that the Website was deployed to the
deploy environment
17. Editar la User Story “Lab Management” y en la sección “Implementation”
agregar los siguientes elementos relacionados de tipo “Task”.
Campo Valor
Title Configure Lab Management environment
Original Estimate 18
Remaining 18
Completed 0
18. En este punto las User Stories y las Tasks creadas serían similares a las
siguientes:
20 – User Story - Setup Development Environment
21 – User Story - Users and Permissions
24 – Task - Setup user and permissions in Team Foundation
Server
25 – Task - Setup user and permissions in SharePoint
Server
26 – Task - Setup user and permissions in Reporting Server
30 – Test Case - Test access to Team Foundation Server
31 – Test Case - Test access to Team Foundation Server
32 – Test Case - Test access to Team Foundation Server
22 – User Story - Build Environment
27 – Task - Setup Team build environment for Continuous
Integration
28 – Task – Create Team Build Process to allow the deploy
of the application
33 – Test Case - Test CI team build template
34 – Test Case - Test Build and Deploy team build template
-
--
Cla
udio
Var
gas
Ale
jos
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
licen
ciad
o
a
:
98 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
23 – User Story - Lab Management
29 – Task – Configure Lab Management
19. En la imagen siguiente podemos ver un ejemplo de las relaciones que
poseen cada WorkItem para los tipos de relaciones, “Child” y “Tested By”.
Figura 15- Relaciones de tipo “Child” y “Tested By” entre WorkItems
3.3.2.- Tutorial: Crear una consulta para mostrar el avance
de las historias de usuario
Este tutorial demuestra cómo crear una consulta de WorkItems para ver el avance
de las historias de usuario, mostrando los elementos relacionados de tipo User Story,
Task y Test Case. Se utilizará una plantilla de procesos basada en MSF for AGILE y los
elementos de trabajo creados en los pasos anteriores.
1. Abrir Visual Studio 2010.
2. Conectar al Team Project sobre el que se quiere trabajar. En este caso
conectamos a un Team Project llamado “ALMBookAgile”
-
--
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do l
icen
ciad
o
a: C
laud
io
V
arga
s A
lejo
s
Gestión del trabajo 99
3. Crear una nueva consulta. En este ejemplo la llamaremos “All User
Stories, Tasks and Test Cases”.
4. Cambiar el tipo de consulta por “Work Items and Direct Links”.
5. Definir los siguientes criterios de filtro en la consulta:
Group And/Or Field Operator Value
Team Project = @Project
1 And Work Item Type = User Story
1 Or Work Item Type = Test Case
1 Or Work Item Type = Task
And State = “Any”
6. En la sección de los WorkItems relacionados definir los siguientes
criterios:
Group And/Or Field Operator Value
Work Item Type = User Story
Or Work Item Type = Test Case
Or Work Item Type = Task
7. En la sección “Linking Filters” seleccionar:
a. Top Level work items: Only return items that have the specified
links
b. Types of links
i. Child
ii. Tested by
8. Seleccionar los siguientes campos para la consulta, es importante respetar
el orden de los mismos:
a. ID
b. Link Type
c. Work Item Type
d. Title
e. Assigned To
f. State
--
Con
teni
do
licen
ciad
o a
: C
laud
io
Var
gas
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
100 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
g. Original Estimate
h. Completed Work
i. Remaining Work
9. Ejecutar la consulta.
10. Ordenar los resultados por el campo “Link Type” de forma ascendente. De
esta forma es posible ver todas las relaciones del mismo tipo agrupadas
para cada User Story.
11. La siguiente imagen muestra un ejemplo del resultado de la consulta creada
utilizando User Stories, Tasks y Test Cases
Figura 16 - Ejemplo de resultado de ejecución de consulta
3.3.3.- Tutorial: Analizar el avance de las historias de
usuario utilizando Microsoft Excel.
Este tutorial explica cómo utilizar una consulta de WorkItems y trabajar con la
misma desde Excel para analizar la información que muestra. Se utilizará una plantilla
de procesos basada en MSF for AGILE, los elementos de trabajo creados en los pasos
anteriores y la consulta creada en el paso anterior.
1. Abrir Microsoft Excel 2010.
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a:
Cla
udio
Var
gas
Ale
jos
Gestión del trabajo 101
2. Seleccionar la Ribbon “Team”.
3. Presionar el botón “New List”.
4. Conectar al servidor Team Foundation de trabajo donde se han creado los
elementos de los pasos anteriores.
5. En el formulario de selección de consultas, seleccionar la consulta creada
en el tutorial anterior.
6. La acción anterior incluirá los datos de la consulta en una hoja de cálculo
en Excel. Para simular la dependencia entre los diferentes WorkItems, por
ejemplo entre User Stories y Tasks, se crearán diferentes columnas “Title”
con el título de los elementos de trabajo, en las que se mostrarán los
diferentes niveles de WorkItems. La siguiente imagen muestra un ejemplo
de este escenario.
Figura 17 - Lista con jerarquías en Microsoft Excel.
7. A continuación crearemos una regla en la columna de estado para mostrar
gráficamente el estado de los elementos de la consulta. Para esto debemos
seleccionar los elementos de la columna “Active”.
8. En la Ribbon “Home”, seleccionar “Conditional Formatting // New Rule”.
9. En “Rule Type” seleccionar “Format only cells that contains” y completar
los siguientes valores para los elementos activos:
a. Cell Value // Equals to // “Active”
b. Format: Background = Yellow
*-
09/0
8/20
13
Con
teni
do
lic
enci
ado
a:
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
102 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
10. Repetir los pasos anteriores con los siguientes valores:
a. Elementos Resueltos
i. Cell Value // Equals to // “Resolved”
ii. Format: Background = Orange
b. Elementos cerrados
i. Cell Value // Equals to // “Closed”
ii. Format: Background = Green
11. La columna de estado de los WorkItems mostrará una imagen similar a la
siguiente.
Figura 18 - Estados visualizados gráficamente en Microsoft Excel.
12. A continuación crearemos una nueva columna que analizará los datos de
las horas que se imputan en las tareas y si el trabajo restante sumado al
trabajo realizado es superior al trabajo estimado, se mostrará un cambio en
el color del fondo de la celda.
13. Para esto, agregar una columna al final de la tabla a la que llamaremos
“Hours”.
14. En la misma, agregar la siguiente fórmula: “=([@[Completed
Work]]+[@[Remaining Work]])<=[@[Original Estimate]]”, en todas las
celdas de la tabla.
15. En este momento es necesario repetir los pasos de cambio de formato en
las celdas de la columna creada con los siguientes valores:
a. Horas
i. Cell Value // Equals to // “TRUE”
-
09/0
8/20
13
C
onte
nido
lice
ncia
do
a
: C
laud
io
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
Gestión del trabajo 103
ii. Format: Background = GREEN
b. Horas desfasadas
i. Cell Value // Equals to // “FALSE”
ii. Format: Background = Red
16. La columna de horas mostraría un aspecto similar al siguiente:
Figura 19 - Analizando horas desfasadas en Microsoft Excel.
4.- GESTIONANDO PROYECTOS
En la sección anterior vimos cómo utilizar las herramientas que brinda Visual
Studio ALM para crear elementos que nos permitan controlar el avance de un proyecto.
Pero antes de comenzar un proyecto hace falta darle forma, lo que comunmente
conocemos como “estimar”.
Esta palabra, aunque no va de la mano con XP, AGILE y sus derivados, es
necesaria ya que, salvo en ocasiones excepcionales, todos debemos responder frente a
un cliente o un superior con:
Una fecha “estimada” de finalización para un proyecto.
Un coste “estimado” para el proyecto.
Un alcance “estimado” de lo que se desea realizar en el proyecto.
Un nivel de calidad “minimo” que se desea cumplir en el proyecto.
Es casi imposible escapar de una estimación independientemente de la forma de
trabajo que adopte un equipo. Ya sea un gurú de AGILE o un Senior Project Manager
PMP ultra certificado, deberá dar como mínimo una fecha y un coste aproximado.
-
*-
Cla
udio
V
arga
s
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
Con
teni
do
l
icen
ciad
o
a:
104 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Este punto, es uno de los que más conflicto ocasiona con las metodologías
AGILES, ya que según XP el alcance de un proyecto no está completamente cerrado al
comienzo, y como la filosofía de XP es adaptarse a los cambios constantemente, es una
tarea muy difícil realizar un presupuesto previo para un proyecto.
Pero incluso en las formas de trabajo más detalladas, tampoco se pueden prever
todas las variables que intervienen en un proyecto ni los cambios que se darán durante
el mismo. En este epígrafe veremos una pequeña colección de apuntes de varios
autores que nos pueden ayudar a organizar mejor el día a día de un proyecto y además,
las ventajas que nos brinda la utilización de Visual Studio ALM para la gestión.
4.1.- The Inception Deck
Jonathan Rasmusson en su libro “The Agile Samurai” (http://bit.ly/rtO5WQ)
explica diferentes técnicas relacionadas con la gestión de proyectos utilizando
conceptos de AGILE. Entre estos conceptos destaca el llamado “Inception Deck”, que
básicamente consiste en una serie de preguntas que se deben realizar a todos los
participantes del proyecto para dar claridad al mismo. El tiempo estimado de creación
del Inception Deck varía entre un par de días hasta un par de semanas, pero la
información obtenida con este ejercicio debe ser lo suficientemente completa como
para poder planificar hasta seis meses de proyecto.
Durante su libro JR describe en detalle las 10 preguntas que dan pie al Inception Deck, así como también diferentes técnicas para dar una respuesta correcta a cada paso.
Es importante tener presentes las diez preguntas y luego comenzar a trabajar con ellas.
A continuación encontraréis 7 preguntas junto con sus los ejercicios que implican; es
recomendable realizar estos ejercicios en los proyectos.
1. Preguntarse por qué estamos aquí (Ask why we are here)
Esta pregunta debe ser respondida a varios niveles. Debe incluir el objetivo del
proyecto, definir quiénes son los participantes del equipo, quiénes son los clientes con
los que se interactúa. Este ejercicio usualmente se realiza durante la definición del
alcance del proyecto.
2. Crear un “discurso de ascensor” (Create an elevator pitch)
Esta pregunta es un clásico en los resúmenes ejecutivos, consiste explicar de forma
breve (lo que dura un viaje de ascensor) todo sobre un proyecto
(http://bit.ly/pBsdGo). Las premisas para este punto son las siguientes:
Cuál es el objetivo del proyecto.
De forma concisa dar pocas, pero fuertes ideas.
Generar curiosidad y apelar a las emociones.
En qué es diferente su proyecto respecto la competencia.
*
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a: C
laud
io
Var
gas
A
lejo
s
Gestión del trabajo 105
Alternativas para provocar una reunión posterior.
3. Diseñar una caja de producto (Design a product box)
Es importante e interesante pensar en la posibilidad de que el resultado del proyecto
es un producto que se pueda vender a gran escala. Sobre esta base, el equipo debe crear
una caja para el producto. Esto ayuda a identificar, con un título, una imagen y un par
de frases, aspectos tan importantes como el objetivo principal del producto, la visión
gráfica que los integrantes del equipo tienen de él y la definición de las características
principales.
4. Crear una lista de elementos fuera de alcance (Create a NOT list)
Este es un ejercicio que se suele hacer en todos los proyectos. Además de crear un
diseño del alcance se deben definir claramente los elementos que están fuera de él. Lo
importante aquí, es que todos los integrantes del equipo estén informados sobre estos
puntos para no generar sorpresas posteriores.
5. Conocer a los vecinos (Meet your neighbors)
Este ejercicio anima a incorporar, en fases tempranas al proyecto, la opinión de
todas las personas que puedan tener peso en el mismo. Por ejemplo, no sirve de nada
conocer al equipo de seguridad y calidad de código en las fases finales de un proyecto
ya que es muy probable que tengan algo (o bastante) que decir respecto a los aspectos
de seguridad que debe cumplir una aplicación.
6. Mostrar la solución (Show the solution)
Es importante tener en cuenta, que si bien muchas personas pueden estar al tanto de
la solución planteada, el hecho de mostrarla ayuda a esclarecer dudas. Obviamente es
imposible tener una solución para todos los problemas en la primera fase del proyecto,
pero cuestiones comunes, como herramientas, plataforma, arquitectura inicial, etc.,
pueden ser discutidas por los integrantes del equipo y los clientes para tomar decisiones
al respecto.
Veamos un ejemplo relacionado con productos de pago. Muchas veces asumimos
que la mejor solución es utilizar el producto XYZ, y comenzamos a trabajar con él en
su versión gratuita; pero al cabo de 3 meses al área comercial del cliente le saltan los
ojos al ver el cuadro de precios para la versión Enterprise del producto. Este hecho,
apuntado como un riesgo el día inicial, puede ahorrar ese dolor de cabeza (aunque tal
vez no se ahorren esos €uros).
7. Comentar lo que nos mantiene despiertos por las noches (Ask what
keeps us up at night)
Este es otro clásico en la gestión de proyectos, la gestión de riesgos. En muchos
proyectos sucede que muchas personas son conscientes de algunos riesgos que pueden
afectar al desarrollo del proyecto, pero no los comparten con el equipo.
-
--
Cla
udio
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Con
teni
do
l
icen
ciad
o
a:
106 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
4.1.1.- ¿Qué sucede cuando no hablamos?
Abordaremos este punto a través de un ejemplo. Hace unos años, en un proyecto de
tamaño medio, se trajo a un especialista en tecnologías Microsoft para que montase un
escenario de integración continua en el proyecto. Si bien ahora Visual Studio ALM y
Team Foundation nos proporcionan estas capacidades out of the box, hace unos años,
realizar esta tarea era un proceso más bien artesanal. Esta persona, que no era parte del
equipo, tuvo una reunión con el líder de proyecto donde comentó las virtudes de la
integración continua y se comprometió a montar un entorno de este tipo.
Al cabo de un par de semanas de trabajo, después de conseguir el hardware y el
software necesarios, y de montar el entorno; el líder y el experto decidieron realizar una
demonstración al equipo de desarrollo, para evaluar el impacto del cambio de modo de
trabajo. Se reservó una sala con proyector, se preparó una presentación y convocó al
equipo a una reunión de una hora para comentar este cambio.
Durante la presentación el experto mostró un par de “Hello Worlds” muy bonitos
con sus correspondientes pruebas, que compilaban perfectamente en el entorno de CI,
además de las opciones que se podían montar utilizando las diferentes herramientas que
se habían integrado. Cuando llegó el turno de las preguntas alguien dijo: “¿qué versión
de Visual Studio es? Nosotros estamos trabajando con Visual Studio .Net y es evidente
que no esta no es la misma”. Después de debatirlo un poco entre todos, vieron que el
experto había montado todo con Visual Studio 2003 y que las herramientas no
coincidían.
Huelga decir que fue necesario realizar todo el trabajo nuevamente con las
herramientas correctas, retocar algunos detalles, etc. Pero lo importante de este caso, es
que desde el punto de vista del equipo de desarrolladores, el problema se había
originado por el poco conocimiento técnico del líder de proyecto. Por otro lado,
durante las semanas de trabajo del experto de Microsoft los desarrolladores se habían
dado cuenta que el experto estaba trabajando con otra versión. ¿Por qué no hablaron
entonces?
Con este ejemplo no se trata de buscar culpables, si no de evidenciar que si hubiese
habido una comunicación clara y transparente entre los integrantes del equipo, si todos
se hubiesen preocupado por conocer el alcance del proyecto y las tareas que se realizan,
si se hubiesen preocupado por “conocer a sus vecinos”, el resultado podría haber sido
muy diferente.
Una buena comunicación no significa que debamos estar continuamente
convocando reuniones formales. De hecho, en numerosas ocasiones, en las charlas de
café, de forma espontánea, se comentan detalles que tiene una gran influencia sobre el
proyecto y que son desconocidos por parte del equipo implicado.
-
-
Con
teni
do
l
icen
ciad
o a
: C
laud
io
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Gestión del trabajo 107
4.2.- La importancia de la gestión de riesgos
La correcta gestión de riesgos en un proyecto es básicamente un indicador de su
salud. Un ejercicio muy interesante es hacer una lista con todos los riesgos que los
participantes piensen que pueden afectar al proyecto. Una vez definida la lista, se debe
apuntar para cada riesgo las consecuencias del mismo y además, en el caso de que
exista, un plan de acción a aplicar en caso de que el riesgo se materialice.
Otro punto a tener en cuenta es que los riesgos que se definan deben ser riesgos
reales, no riesgos imposibles como por ejemplo “que un terremoto afecte el Data
Center”. Con esto no se pretende minusvalorar dicha posibilidad, pero se supone que
que un buen Data Center tiene un plan de contingencia para estos casos, por lo que
contemplar este tipo de posibilidades no forma parte de un proyecto de desarrollo.
Una vez definidos los riesgos para nuestro proyecto, debemos tener en cuenta dos
cuestiones importantes. En primer lugar, debemos aprender a vivir con ellos. Los
riesgos bien planteados no son más que eso: un riesgo. Si es posible debemos
resolverlos, pero si no tienen solución hay que aprender a convivir con ellos y plantear
planes de acción para mitigarlos. En segundo lugar, no desatender esta lista. Muchas
veces la lista de riesgos creada al principio del proyecto queda escondida como un
documento de referencia y no es revisada más durante el proyecto. Lo ideal es seguir
los riesgos durante la vida del proyecto. Por ejemplo si los riesgos estén relacionados
con requerimientos o User Stories; cuando éstas se dan por cerradas, deberían darse por
cerrados los riesgos.
La siguiente imagen muestra un WorkItem de tipo “Requirement” relacionado con
dos WorkItems de tipo “Risk”.
Figura 20- Requerimiento relacionado con riesgos
Además, basándonos en los tutoriales: “Tutorial: Crear una consulta para mostrar
el avance de las historias de usuario” y “Tutorial: Analizar el avance de las historias de usuario utilizando Microsoft Excel.” es posible crear una consulta y una hoja Excel
para ver los requerimientos y los riesgos asociados a los mismos. La siguiente imagen
muestra una hoja Excel en la que es posible ver una serie de requerimientos, los riesgos
relacionados y los riesgos “huérfanos”, es decir, aquellos que no están asociados a
*
-
Cla
udio
Var
gas
Ale
jos
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
licen
ciad
o
a:
108 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
ningún requerimiento. Además se puede ver gráficamente el estado de cada WorkItem
y la probabilidad asociada a los riesgos.
Figura 21 - Gestión de riesgos en Excel.
Utilizando Microsoft Excel y Visual Studio ALM es posible tener una gestión
inicial de los riesgos que pueden afectar a un proyecto y de muy fácil uso. Sin embargo
insistimos en ello, para la correcta gestión de los mismos, es necesario un trabajo a
conciencia del equipo, evaluando el estado del proyecto día a día.
4.2.1.- Tutorial: Crear una hoja de gestión de riesgos
El siguiente tutorial muestra cómo gestionar riesgos utilizando Visual Studio ALM.
Para este ejemplo utilizaremos el WorkItem de tipo “Risk” que se incluye en la
plantilla de MSF for CMMI 5.0.
1. Abrir Visual Studio 2010.
2. En el panel “Team Explorer” conectar a un Team Project basado en la
plantilla MSF for CMMI 5.0.
3. Crear el siguiente requerimiento:
Campo Valor
Title Load page time must be less than 2 seconds
Requirement Type Quality of Service
4. Seleccionar la pestaña “All Links” y agregar un nuevo link con los
siguientes datos:
a. Link Type: Child
b. Work Item Type: Risk
c. Title: The appropriate hardware must be provided in order to supply
the desired load page time
*
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
licen
ciad
o
a:
Cla
udio
Var
gas
A
lejo
s
Gestión del trabajo 109
Figura 22 - Relacionar un Requerimiento con un Riesgo.
5. Completar los siguientes campos en el “Risk” creado:
Campo Valor
Title The appropriate hardware must be provided in order to
supply the desired load page time
Probability 1
6. Relacionar un nuevo riesgo al requerimiento con la siguiente información:
Campo Valor
Title All pages must load in a single page mode and start to
update logically in order to display information easily to
the user
Probability 1
7. Crear una nueva consulta de WorkItems para analizar los riesgos asociados
a requerimientos. El tipo de la consulta debe ser “Tree of Work Items”.
8. Definir los siguientes criterios de filtro en la consulta:
Group And/Or Field Operator Value
Team Project = @Project
1 And Work Item Type = Requirement
1 Or Work Item Type = Risk
And State = “Any”
-
*-
Cla
udio
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
l
icen
ciad
o
a
:
110 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
9. En la sección de los WorkItems relacionados definir los siguientes
criterios:
Group And/Or Field Operator Value
Work Item Type = Risk
10. Seleccionar los siguientes campos para la consulta respetando el orden de
los mismos:
a. ID
b. Work Item Type
c. Title
d. Assigned To
e. State
f. Probability
11. Guardar la consulta bajo el nombre “Risk Management”.
12. Abrir la consulta en Microsoft Excel y aplicar diferentes filtros de colores
para los posibles estados de los WorkItems.
13. Seleccionar la columna “Probability”.
14. En la Ribbon seleccionar una de las opciones de iconos presentadas en
“Conditional Formatting // Icon Sets // Directional”.
15. La columna de probabilidad mostrará una imagen similar a la siguiente:
Figura 23- Probabilidad del riesgo analizada gráficamente
16. Guardar la hoja Excel.
-
-*
Cla
udio
Var
gas
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
Con
teni
do
lice
ncia
do
a:
Gestión del trabajo 111
4.3.- ¿Estimar o adivinar el futuro?, mejor organizamos el
trabajo.
Hasta ahora hemos visto las diferentes capacidades que posee Team Foundation
para trabajar con User Stories, Riesgos, Requerimientos, Tareas, etc. Sin embargo, los
proyectos de desarrollo requieren una planificación o una organización del trabajo. Este
es uno de los temas más delicados porque muchas veces se asume que dicha
planificación es un contrato cerrado que se cumplirá al pie de la letra y sobre el que se
realizará todo el trabajo siguiente.
La realidad nos muestra que esto no es así, que en los proyectos de desarrollo de
software, pocas veces las planificaciones coinciden con la realidad que se vive día a día
en el proyecto.
Una secuencia simple de pasos para la organización de un proyecto trabajando con
los elementos de AGILE puede ser la siguiente:
1. Preparar el Inception Deck.
2. Crear una lista de User Stories.
3. Definir tareas y de pruebas para implementar las User Stories.
4. Crear una lista de User Stories.
5. Definir qué User Stories entran en las primeras cuatro iteraciones.
Con estos pasos ya tenemos el trabajo planificado para dos meses y podemos ir
ajustando el mismo a medida que avanzamos. Veamos algunas consideraciones a tener
en cuenta sobre estos puntos:
1. Preparar el Inception Deck.
Como comentamos en la sección anterior, el ejercicio del Inception Deck ayuda a
que todos los integrantes del proyecto conozcan los pormenores del mismo. Deben
estar involucrados los clientes y el equipo de desarrollo.
2. Crear una lista de User Stories.
Una vez preparado el Inception Deck llega el momento de comenzar a redactar las
historias de usuario. En este punto es importante utilizar solo la información que sea
imprescindible para empezar a trabajar; ya que si se detalla cada User Story se corre el
peligro de dedicar demasiado esfuerzo a una tarea que luego puede cambiar.
3. Definir tareas y pruebas para implementar las User Stories.
Aquí empezaremos a usar números, datos tangibles, como por ejemplo horas. Una
User Story posee un atributo llamado “Story Points” que básicamente define su peso.
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
li
cenc
iado
a:
Cla
udio
V
arga
s
A
lejo
s
112 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Si bien inicialmente se puede poner un valor a este atributo, es en este momento donde
lo podremos ajustar un poco.
Este paso consiste en comenzar a crear las tareas necesarias para llevar a cabo las
historias de usuario y además, crear las pruebas y los criterios de aceptación que se
deben cumplir para dar como válida una User Story.
Es después de este ejercicio cuando nos encontraremos que a una User Story que
inicialmente habíamos estimado como “simple” resulta ser “compleja” o viceversa.
4. Crear una lista de User Stories.
Una vez que tenemos la lista de User Stories debemos organizarlas de manera que
sigan un criterio lógico para poder sacar adelante el trabajo. En el epígrafe 3.3 se
crearon una serie de User Stories para articular el entorno de desarrollo, para montar el
servidor de integración continua, etc. Aunque esto es lo primero que se suele hacer en
los proyectos, es recomendable comenzar a trabajar con el cliente para ordenar los
elementos propios del proyecto.
Recordad que, si bien las expectativas del cliente son las que guían el proyecto,
nuestras habilidades como consultores deben ayudarlo para definir el camino correcto.
Por ejemplo, si estamos construyendo un portal de control de maquinaria en una
industria, y un punto fuerte del mismo es un tablero de control con vistas generalizadas
de todos los procesos, es muy probable que éste sea uno de los primeros elementos que
nuestro cliente desee ver.
Como para tener el tablero de control en funcionamiento necesitamos primero
implementar muchas User Stories relacionadas, debemos explicarle esto a nuestro
cliente e intentar evaluar y acomodar las User Stories por funcionalidad y por
expectativas.
Si aun así, tenemos que mostrar el tablero de control, podemos crear un prototipo de
tablero que trabaje “de cartón piedra” y explicarle que este prototipo seguramente
sufrirá cambios durante las próximas iteraciones. De esta manera podemos cumplir con
la expectativa del tablero de control, pero también podemos seguir trabajando en las
User Stories de más bajo nivel.
Nota: No es recomendable diseñar las pantallas al principio de un proyecto sino
más bien al final. Pero, esto no quita que utilicemos herramientas como Microsoft
Expression Blend y SketchFlow para validar la funcionalidad y navegación de una
aplicación en las etapas iniciales.
Por lo general cuando comenzamos trabajando en base a diseños de UI
contaminamos el código que escribimos sujeto a esos diseños.
5. Definir qué User Stories entran en las primeras cuatro iteraciones.
Una vez organizada la lista de User Stories, con el tiempo de duración de cada una
de ellas podremos comenzar a definir cuántas se completarán en cada iteración. Para
ello primero debemos concretar la capacidad de trabajo que tenemos para una iteración.
-
--
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a
: C
laud
io
V
arga
s
Ale
jos
Gestión del trabajo 113
Si suponemos que una iteración son dos semanas o lo que es lo mismo diez días
laborables; como cada jornada de trabajo son 8 horas y suponemos que el equipo lo
componen cuatro personas, hacemos un cálculo rápido:
2 semanas: 10 días.
10 días de 8 horas: 80 horas de trabajo por iteración.
4 personas por 80 horas: 320 horas de trabajo de capacidad por iteración.
Una vez acomodadas las User Stories de la lista en las primeras cuatro iteraciones
ya podremos saber, en teoría, el trabajo completado en los próximos dos meses.
Recordemos que cuando creamos las tareas y Tests necesarios para dar solución a una
User Story, en realidad lo que hicimos es una estimación del tiempo que consideramos
necesario para esas tareas y Tests. Pero, tras una iteración y después de haber realizado
realmente el trabajo este tiempo puede haber cambiado.
Es recomendable que al finalizar cada iteración se analicen las User Stories
similares y se ajusten los “Story Points” de las mismas en base a las experiencias reales
del trabajo realizado. Esto nos permitirá después de 3 o 4 iteraciones tener una
estimación real de la velocidad de trabajo de nuestro equipo. Para afinar nuestra
capacidad de estimación debemos comenzar a trabajar con retrospectivas.
Lo que a priori eran unos puntos muy simples, se ha convertido en algo más
complejo. No es objeto de este libro entrar en más detalle, pero aquellos que realmente
quieran mejorar su experiencia en este aspecto es recomendable que lean:
AGILE Coaching (http://bit.ly/n8dCnE)
Effective Project Management: Traditional, Agile, Extreme
(http://amzn.to/q4yf4f)
4.4.- El Product Backlog
A partir de ahora emplearemos con frecuencia en este libro el término “Product
BackLog”. Si bien, no hay gran diferencia con el concepto de una lista de historias de
usuario organizada, es un término que se utiliza principalmente en SCRUM, con lo que
no es 100% puro del mundo AGILE.
Una vez más, no existen “balas de plata” que solucionen todos los problemas. Sin
embargo, la evolución de MSF for AGILE en su versión 5.0 introduciendo muchos
conceptos de SCRUM es un gran paso para agilizar y mejorar la gestión de proyectos
con Team Foundation. Un ejemplo de ello es la inclusión de elementos de tipo Product
BackLog.
20128
-
-
Con
teni
do
li
cenc
iado
a:
Cla
udio
V
arga
s
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
114 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Los siguientes elementos se incluyen en la guía de procesos de MSF for AGILE para
ayudar a trabajar con el concepto de Product BackLog.
Consultas de WorkItems
o Product BackLog: Muestra todas las User Stories que no estén
cerradas ordenadas por el campo “Stack Rank”.
o Product Planning: Muestra todas las User Stories que no estén
cerradas en los últimos 90 días ordenadas por el campo “Stack
Rank”.
Documentos
o Product Planning.xlsm: Permite trabajar con el BackLog y
organizar el trabajo de las diferentes User Stories en las iteraciones
de trabajo. Permite, además, trabajar con la agenda que se
manejará en el proyecto; por ejemplo definir los espacios de
tiempo de las iteraciones, definir la agenda de vacaciones y días no
laborables. A la información completa para trabajar con este
documento se puede acceder desde http://bit.ly/qUJkmz.
Para más información véase la sección de MSDN “Creating a Great Product
BackLog” (http://bit.ly/r3cr4I).
Si abrimos la consulta de WorkItems “Product Backlog”, podremos ver el estado de
las User Stories con las que estamos trabajando. De la misma manera, la hoja de Excel
“Product Planning.xlsm” nos permite organizar nuestro trabajo en iteraciones tomando
como base los datos que devuelve la consulta de WorkItems “Product Planning”.
Tomando como ejemplo el trabajo realizado para el montaje de entorno de trabajo
durante la iteración 1, y para las siguientes iteraciones la creación de una aplicación
llamada Valmar, podremos ver una hoja de planificación similar a la siguiente.
Figura 24 - Product Planning.
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s
Gestión del trabajo 115
4.5.- Trabajando con iteraciones.
El trabajo con iteraciones no es complicado, simplemente se trata de definir
períodos de tiempo donde un equipo de trabajo se compromete a realizar una serie de
tareas completas. Aunque con una pequeña frase se pueda definir el concepto de
iteración, hay algunos matices importantes como por ejemplo el relacionado con el
tiempo.
Cuando se desarrolla utilizando iteraciones es importante realizar entregas rápidas
con dos objetivos claros: ir validando la construcción de nuestro software y no perder
la atención de nuestros clientes. El período ideal para una iteración es de dos semanas,
aunque trabajar con iteraciones de un mes de duración tampoco es descabellado en
determinados escenarios.
Nota: Los libros que tratan el tema de gestión de proyectos o de AGILE,
coinciden en afirmar que debemos trabajar con iteraciones cortas para no perder el
interés del cliente y para poder comprobar rápidamente si el trabajo que estamos
realizando cumple los requisitos del cliente. Ahora bien, un matiz importante en
este punto es que, además, podemos aprovechar estos períodos cortos para
“intentar llevar al cliente por nuestro camino”.
Por ejemplo, es bastante más complicado tener que defender 20 decisiones que
se han tomado durante 4 meses de trabajo en una única reunión, que hacer una
entrega parcial de las mismas e ir demostrando que nuestro criterio es válido para
determinadas situaciones. Por otra parte, estas entregas rápidas y estas discusiones
nos ayudarán a comprender mejor cómo piensa nuestro cliente, de tal manera que
con el tiempo, será más fácil tomar estas decisiones por nuestra cuenta sino
podemos contar con su ayuda.
Para ver cómo trabajar con iteraciones veamos un caso que incluye tareas reales.
Por ejemplo, si trabajamos con los usuarios de la máquina virtual a la que hicimos
referencia el capítulo 1, podremos definir las siguientes acciones a realizar por cada
uno para dar comienzo a una iteración:
Project Manager (Michael Affronti) y Cliente (Robin Wood)
o Comienzan la creación del Inception Deck con los participantes
del proyecto.
Project Manager (Michael Affronti)
o Trabaja con los clientes para obtener los requerimientos del
proyecto. A partir de este punto podremos armar el Product
BackLog o la Master User Story List.
o Trabaja en la priorización de los requerimientos.
-
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
licen
ciad
o
a:
Cla
udio
Var
gas
A
lejo
s
116 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
o Define los criterios de aceptación para cada requerimiento y lo
valida con el equipo de Testing y con los clientes.
o Crea los WorkItems en Team Foundation para representar los User
Stories o los Requirements.
o Define con el equipo la duración de cada iteración, en base a la
carga de trabajo y las expectativas del cliente.
Developers (Abu Obeida, Doris Krieger, Bruno Capuano)
o Definen las tareas necesarias para cada User Story o Requirement.
o Definen los tiempos estimados de implementación para cada tarea.
o Crean las Tasks en Team Foundation.
Testers (Christine Koch)
o Define las tareas de Tests necesarias para dar soporte a los criterios
de aceptación para cada requerimiento.
o Crea los Test Cases necesarios en Team Foundation.
Una vez creados estos elementos comienza la iteración. Esto significa que ya no hay
tantas tareas de planificación, sino que el equipo se pondrá a trabajar en todas las tareas
definidas para en dicha iteración.
Cuando se finaliza la iteración las tareas que se realizan son las siguientes:
Project Manager (Michael Affronti) y Cliente (Robin Wood)
o Analizan con el equipo de trabajo los requerimientos que no
pudieron ser completados en la iteración.
o Agregan nuevos requerimientos a la Master User Story List.
o Definen nuevamente qué requerimientos se deberán incluir en la
próxima iteración.
o Realizan una comunicación formal de los objetivos alcanzados a
los stakeholders del proyecto.
Como hemos podido ver, para cada rol definido hay diferentes acciones a realizar, y
si bien al principio y al final, el peso más grande recae sobre el project manager, esto
no significa que durante la iteración todo el peso recaiga sobre los developers y sobre
los testers. En este punto, la principal tarea del project manager es la de ayudar a llevar
adelante la iteración.
-
-
Cla
udio
V
arga
s
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lic
enci
ado
a
:
Gestión del trabajo 117
Además, es muy común que la persona que lidera un proyecto con el rol de project
manager también se encargue de tareas de desarrollo, diseño o testing. Según esto, en
el periodo de ejecución de la iteración será la persona encargada de cerrar las tareas.
4.6.- Trabajando con iteraciones en Visual Studio ALM.
Visual Studio ALM nos brinda diferentes herramientas que nos ayudan en el trabajo
con iteraciones. Inicialmente, el concepto de iteración que se maneja en Team
Foundation es una simple colección de elementos organizados en formato árbol que
pueden ser asignados a un WorkItem, por ejemplo a una tarea o a una User Story.
La siguiente imagen muestra el editor de iteraciones de Team Foundation. En el
mismo podemos ver el árbol de iteraciones y un ejemplo de agrupación de iteraciones,
con el objetivo de identificar las iteraciones de despliegue.
Figura 25 - Edición de Iteraciones en Team Foundation.
Cuando trabajamos con WorkItems, el campo Iteración es uno de los campos
obligatorios que se deben rellenar a la hora de definir cada WorkItem. La siguiente
imagen muestra la edición de un WorkItem de tipo User Story en Eclipse. En la misma
podremos ver cómo es posible definir el valor del campo Iteration a partir de valores
definidos en el Team Project para las iteraciones.
-*
C
onte
nido
lice
ncia
do
a:
Cla
udio
V
arga
s A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
118 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 26 - Asignar el valor de una iteración a un WorkItem.
En un Team Project podremos ver además que existen diferentes consultas y
documentos que se han creado para que trabajen por defecto con las primeras tres
iteraciones que se hacen en el mismo.
Figura 27 - Hojas Excel y WorkItem Queries por iteración.
-
C
onte
nido
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Gestión del trabajo 119
4.6.1.- MSF for Agile, consultas y documentos por iteración.
En la plantilla de MSF for Agile existe una serie de consultas que nos ayudan a
trabajar organizando el trabajo en iteraciones. No es el objetivo de este libro comentar
el detalle de cada una de ellas, pero sí dejar un apunte sobre las más importantes.
Lo primero que nos llama la atención es que las carpetas de las iteraciones 2 y 3
solo poseen la consulta “Iteration BackLog”, mientras que en la carpeta de la iteración
1, existen más de 10 consultas diferentes. Esto se debe a que las plantillas iniciales de
estas consultas utilizan como criterio de filtro la iteración 1.
Figura 28 - Iteraciones 2 y 3 vacías.
El siguiente tutorial muestra cómo copiar estas consultas a nuevas iteraciones y
como respetar la información que se muestra en las mismas.
Además de las consultas de WorkItems, tenemos una serie de documentos en
SharePoint que también nos ayudan a trabajar con las iteraciones.
-
*
Cla
udio
Var
gas
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
Con
teni
do
l
icen
ciad
o
a:
120 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
4.6.2.- Tutorial: Copiar consultas para una iteración a partir
de las consultas de la iteración 1
Este tutorial muestra cómo copiar las consultas que se incluyen en la plantilla de
procesos MSF for Agile dentro de la iteración 1, y así poder trabajar con las mismas en
otras iteraciones. Para esto utilizaremos Visual Studio 2010.
1. Abrir Visual Studio 2010.
2. Acceder al panel Team Explorer.
3. Conectar con un Team Project creado con la plantilla de MSF for Agile .
4. Acceder al nodo “Team Project \\ Team Queries \\ Iteration 1”.
5. Seleccionar la consulta “Active Bugs”.
6. Desplegar el menú contextual y seleccionar la opción “Copy”.
7. Seleccionar el nodo “Team Project \\ Team Queries \\ Iteration 2”.
8. Desplegar el menú contextual y seleccionar la opción “Paste”.
9. Seleccionar la consulta creada “Active Bugs” en el nodo “Iteration 2”.
10. Desplegar el menú contextual y seleccionar la opción “Edit Query”.
11. En la consulta cambiar el siguiente criterio de filtro:
a. Iteration Path >> Under >> Team Project\Iteration 2
12. Guardar la consulta.
13. Repetir los pasos del 5 al 13 para todas las consultas que se deseen copiar de la
Iteración 1 a la Iteración 2, o a otras iteraciones.
4.6.3.- Tutorial: Copiar documentos para una iteración a
partir de los documentos de la iteración 1.
Este tutorial muestra cómo copiar las consultas que se incluyen en la plantilla de
procesos MSF for Agile dentro de la iteración 1, para poder trabajar con las mismas en
otras iteraciones. Para esto utilizaremos Visual Studio 2010.
1. Abrir Visual Studio 2010.
2. Acceder al panel Team Explorer.
3. Conectar con un Team Project creado con la plantilla de MSF for Agile .
-
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lice
ncia
do
a
: C
laud
io
V
arga
s
A
lejo
s
Gestión del trabajo 121
4. Acceder al nodo “Team Project\\Documents\\ Shared Documents \\ Iteration 1”.
5. Seleccionar y abrir el documento de Excel “Iteration Backlog.xlsm”.
6. Guardar el mismo en una ubicación temporal.
7. Abrir el documento y activar las Macros y la sincronización de datos.
8. Acceder a la Ribbon “Team”.
9. Seleccionar la opción “Configure // List”.
10. Seleccionar la consulta de WorkItems “Team Project // Team Queries //
Iteration 2 //Iteration Backlog”, como muestra la siguiente imagen.
Figura 29 - Selección de consulta para elementos de Iteración 2.
11. Guardar el documento Excel en la carpeta de SharePoint. Esto se puede hacer
desde la interfaz web de SharePoint o arrastrando el documento hasta el nodo
“Team Project \\ Documents \\ Shared Documents \\ Iteration 2”.
La siguiente imagen muestra cómo se ha agregado un documento modificado a la
carpeta de documentos de Iteración 2.
Figura 30 - Almacenar el documento modificado en SharePoint
para la iteración 2.
-
-*
09/0
8/20
13
C
onte
nido
li
cenc
iado
a:
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
122 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
4.7.- Valmar: Comenzando a dar forma a la aplicación
En el epígrafe 3.3 “Proyecto Valmar: Gestionando el inicio de un proyecto con
Visual Studio ALM.”, vimos un ejemplo sobre cómo se podía crear una serie de User
Stories que ayudan a montar el entorno de desarrollo. Si asumimos que esas User
Stories se ejecutaron en la iteración 1 del proyecto, podemos pensar que a partir de la
iteración 2, ya nos podemos dedicar plenamente a la creación de la aplicación.
Después de varias reuniones con nuestro estimado y participativo cliente, armamos
la siguiente lista de User Stories creando una agrupación de User Stories para dar una
mejor visibilidad en Team Foundation.
Chapter 3 - Valmar Wave 1
o Architecture
Logging
Exception Management
Distributed Cache
o Work Schedule Management
Create work schedule
Add users to work schedule
View work Schedule
Print work schedule
Auto assign users to work schedule
o User Management
Add user
Synchronize users with LDAP
4.7.1.- Configurando el Product Backlog
Partiendo de la información que nos presenta la hoja Excel “Product
Planning.xlsm”, podremos comenzar a organizar las User Stories en cada una de las
iteraciones de trabajo correspondientes.
Esta tarea se deberá realizar con el consenso del cliente y del equipo de trabajo, ya
que es la que proporcionará las directrices para las tareas que debemos llevar a cabo.
-
09/0
8/20
13
Con
teni
do
lic
enci
ado
a:
Cla
udio
V
arga
s
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
Gestión del trabajo 123
Esta tarea se realiza en la hoja de trabajo “Product Backlog”, y los criterios para
organizar las User Stories se basarán en los puntos que les demos a las mismas. A
continuación con el campo “Stack Rank” podremos posicionarlas a nuestro gusto en la
hoja Excel. Además, es aquí donde podemos ir definiendo las iteraciones para cada
User Story.
Nota: Si bien la hoja de Excel presenta los campos “Stack Rank”, “Story
Points”, “Title”, “Iteration” y “Area Path” para la edición, si necesitamos
modificar más información de cada User Story, podemos aprovechar este momento
para completar las mismas.
Los campos “Assigned To”, “State”, “Risk” y “Description” pueden ser
agregados a la hoja Excel y de esta forma, también aprovechar la reunión de
planificación para completar esa información.
Una vez definida toda la información correspondiente a cada User Story, podremos
comenzar a validarlas utilizando la información de la hoja de trabajo “Iterations”. En
esta hoja de trabajo definimos las fechas de inicio y fin para cada iteración y el tamaño
del equipo.
En la imagen siguiente podremos ver que la Iteración 2, en la que inicialmente
hemos agregado todos los elementos de trabajo, está un poco sobrecargada: su objetivo
es cerrar 36 puntos asociados a las User Stories. Llegó el momento de ser ágiles y de
comenzar a ajustar nuestra planificación. Si tomamos como referencia la cantidad de
elementos cerrados en la Iteración 1 (8 puntos), podríamos intentar cerrar la misma
cantidad de puntos en esta iteración o algo similar.
Figura 31 - Iteración 2 sobrecargada de trabajo.
-
-
09/0
8/20
13
Con
teni
do
l
icen
ciad
o
a:
Cla
udio
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om
124 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Como el equipo de trabajo ha incorporado la lista completa de integrantes y ya
podemos contar con los mismos, supondremos que 10 puntos es el ideal para entregar
por iteración. Ajuntando las iteraciones a las User Stories correspondientes, podremos
ver una planificación como la que nos muestra la siguiente imagen.
Figura 32 - Balance de trabajo entre iteraciones.
Ahora asignamos además algunas User Stories a la iteración “Iteration 4 –
Deployment Wave 1\Iteration 4.1”. Entonces, ya podremos definir las fechas de
trabajo para esta iteración en la pestaña “Iterations”, y asignar User Stories de manera
más ágil para organizar las User Stories por Iteración.
Finalmente la pestaña “Interruptions” nos permitirá definir días de trabajo no
laborables para que sean tenidos en cuenta en la planificación.
Figura 33 - Definición de Interrupciones
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s
Gestión del trabajo 125
Una vez llegado el punto en el que estemos cómodos con la planificación, podemos
sincronizar los cambios con Team Foundation desde la hoja de trabajo “Product
Backlog”. También podemos utilizar esta hoja Excel para ver el avance de nuestro
proyecto. Por ejemplo, una vez cerradas un par de User Stories, el gráfico de avance
mostrará un estado similar al siguiente, en el que podremos ver que se han cerrado 3
puntos de las User Stories definidas para la Iteración 2, y que todavía quedan
pendientes 7 puntos.
Figura 34 - Controlando el avance de User Stories por iteración.
En AGILE esta hoja Excel es muy práctica para poder medir la velocidad con la que
estamos entregando nuestras User Stories por iteración. Esto es lo que se conoce por
“Velocity” (http://bit.ly/pxaQHU) y nos permite medir la cantidad de trabajo que
entregamos por iteración.
4.7.2.- Gestionando las Iteraciones
Tras crear las hojas Excel correspondientes a cada iteración, basados en “Iteration
Backlog.xlsm”, es momento de comenzar a planificar y realizar el seguimiento de cada
iteración. Esta hoja de trabajo nos permite calcular la capacidad de trabajo y el
“BurnDown” basados en las estimaciones de horas de las tareas que se asocian a las
User Stories.
La primera hoja de trabajo “Iteration Backlog” posee una estructura jerárquica en
la que podremos ver las diferentes User Stories organizadas en modo de árbol y las
tareas asociadas a las mismas. Entre la información relevante que se muestra en esta
hoja, debemos destacar que además de “State” y “Assigned To”, es posible definir el
tiempo estimado de duración para cada tarea utilizando el campo “Remaining Work”.
-
-*
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
l
icen
ciad
o
a:
126 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 35. - Elementos del Iteration Backlog.
A medida que el equipo va adelantando el trabajo y va completando las horas de
trabajo, es posible visualizar el progreso de horas y la cantidad de horas completadas y
pendientes para cada tarea. La siguiente imagen muestra un ejemplo, donde utilizando
los indicadores de tipo “Data Bars” de Microsoft Excel (http://bit.ly/p0SoRa) es
posible tener una representación visual del trabajo realizado y del trabajo pendiente.
Figura 36 - Análisis de horas completas y pendientes por Tarea
A continuación es necesario definir la fecha de inicio y fin de la Iteración, para esto
pasamos a la hoja de trabajo “Settings” en la que seleccionamos la iteración
correspondiente y definimos estas fechas. También es posible filtrar por un área
definida en nuestro Team Project.
-
-
09/0
8/20
13
C
onte
nido
lic
enci
ado
a: C
laud
io
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
Gestión del trabajo 127
Figura 37 - Configuración de la Iteración.
Otro punto importante es indicar los días no laborables o las interrupciones que
puede sufrir la iteración sobre la que estamos trabajando. Para introducir esta
información accedemos a la hoja de trabajo “Interruptions” y definimos los períodos de
ausencias, bien generales para todo el equipo, por ejemplo días festivos, o bien
ausencias específicas para un integrante, durante la iteración.
Figura 38 - Interrupciones para la iteración.
Con toda esta información configurada, podremos ver en la hoja de trabajo
“Capacity” si nuestro equipo es capaz de afrontar el trabajo planificado. Esta hoja
indica el trabajo pendiente, el trabajo realizado a nivel equipo de trabajo y el realizado
por cada integrante del equipo.
La siguiente figura muestra un ejemplo poco saludable donde, según la
planificación actual, el equipo no podrá sacar adelante el trabajo planificado.
Figura 39 - Análisis de la capacidad de trabajo del equipo.
-
**
Cla
udio
V
arga
s
Ale
jos
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a:
128 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Cuando un equipo no puede cumplir con la planificación inicial, es momento de
preguntarse qué punto de la estimación inicial ha fallado.
La siguiente imagen muestra los datos de capacidad individual para cada uno de los
integrantes del equipo. Si analizamos la misma, veremos que por un lado Bruno
Capuano y Abu Obeida están sobrepasados en un 50% de su capacidad actual de
trabajo y que por otro, April Stewart no posee ninguna tarea asignada.
Figura 40 - Análisis de la capacidad de trabajo individual.
Tras una reunión de equipo se evidencia que las tareas asignadas a Bruno y Abu
resultaron ser mucho más complejas de lo que se pensó inicialmente. Es el momento de
redistribuir las tareas entre los recursos para equilibrar de nuevo el trabajo del equipo.
Nota: Salvo que un equipo posea un nivel muy alto de conocimiento sobre el
negocio de la aplicación que se va a desarrollar y que los integrantes del equipo se
conozcan muy bien entre sí, es muy poco probable que las estimaciones iniciales se
cumplan.
Por eso es muy importante no descuidar la información que nos va brindando
Visual Studio ALM para poder conocer mejor los puntos en los que las
estimaciones han fallado y poder estimar mejor en las próximas iteraciones.
Uno de los principios de AGILE nos indica que cada cierto tiempo, el equipo
tiene que analizar su forma de trabajo y proponer mejoras para el mismo. Este tipo
de análisis, conocido como RETROSPECTIVAS, nos ayudan a identificar los
puntos problemáticos y a dedicar más esfuerzos a mejorar los mismos.
Estas reuniones no deben durar más de 10 ó 15 minutos, no deben convertirse
en una caza de brujas o en una búsqueda de culpables, sino que es el momento para
compartir experiencias y aportar ideas para mejorar.
-
Cla
udio
V
arga
s A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
licen
ciad
o
a:
Gestión del trabajo 129
La última hoja de trabajo “Burndown”, muestra un gráfico en el que es posible ver
el trabajo pendiente en un proyecto, además de la tendencia con la que se está
consumiendo las horas del proyecto.
La siguiente imagen nos muestra cómo se consumieron las horas en la primera
iteración.
Figura 41 - Burndown para la iteración 1.
En esta sección hemos visto cómo crear y mantener un Product Backlog además de
cómo planificar y realizar un seguimiento de nuestras iteraciones. Visual Studio ALM
posee más herramientas que nos ayudan al seguimiento del trabajo del equipo, como
por ejemplo los informes comentados al principio del capítulo; siempre es posible crear
reportes personalizados consultando el repositorio de DataWareHouse de Team
Foundation para analizar la información al detalle.
4.7.3.- Relato: La princesa Martina, la caza del dragón y los
planes al garete
El siguiente relato es un pequeño ejemplo sobre malas planificaciones, malas
ejecuciones e incluso un pésimo cierre de proyecto. Si alguna vez has participado en un
proyecto en donde un “Framework” prometía bajar los tiempos de desarrollo a la
mitad, o un equipo de desarrolladores de primer nivel en algún país exótico bajaba los
costes un 30%, seguro que el relato te resulta familiar.
Había una vez, en un reino muy, pero que muy lejano, una princesa llamada Martina. Como casi todas las princesas de los cuentos, Martina era muy bonita
*-
C
onte
nido
licen
ciad
o
a:
Cla
udio
V
arga
s A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
130 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
esperaba conocer a un príncipe azul para casarse, tener principitos y vivir felices como los conejitos de Pascua.
La princesa creció y llegó el momento de pensar en la boda real. Su padre, un rey
muy guapo e inteligente, el rey Bruno, decidió poner a prueba a los pretendientes para ver cuál era el mejorcito. El rey ya sabía cómo se las gastaban los príncipes de esa
época, así que no tenía muchas esperanzas y puso el listón bastante bajo:
El primero que logre dar caza al dragón Andrés podría casarse con la princesa
Martina en menos de 30 días.
El 29 de Marzo se proclamó un bando real según el cual aquellos que desearan
casarse con la princesa tenían dos días para inscribirse, siendo la cuota de inscripción de 500 coronas por casa real. La caza de dragones era algo común en esa época, y el
dragón Andrés se encontraba a solo 100 millas del castillo del rey, era un dragón más bien viejo y en decadencia. Por ello, el rey Bruno estableció que semejante hazaña
debería llevarse a cabo en un máximo de 30 días.
Cuando finalizó el proceso de inscripción, 3 casas reales se habían dado de alta
para la caza del dragón, cada una con una estrategia diferente:
En primer lugar estaba la casa de Lannister, con el príncipe Edu a la
cabeza. Los Lannister, como todo el mundo sabe, son famosos por tener mucho dinero. Así que habían contratado al mejor grupo de caballeros
llamados “Caballeros Incorporated SA” (CISA), que aseguraban dar caza
al dragón de la manera más rápida conocida y con los mejores recursos disponibles. Estos caballeros estuvieron en la taberna jactándose de sus
experiencias pasadas, entre sus filas varios de ellos habían sido instruidos en la Academia Real para la Caza del Dragón (ARCD) obteniendo las
mejores calificaciones que existían.
En segundo lugar estaba la casa de Robles, con el príncipe José a la
cabeza. Los Robles, que eran grandes ingenieros, presentaron el prototipo de un arma de guerra desconocida hasta el momento: la lanza caza-
dragones LCD4000. Los lugareños comentaban que esta lanza permitía
matar a un dragón a 200 pasos de distancia, con lo que el riesgo de morir en el intento era casi nulo. Además, los dibujos de la lanza, eran realmente
espectaculares (¡¡¡era una lanza dorada!!!).
En tercer lugar estaba la casa de Foster, con el príncipe Dani a la cabeza.
La casa de Foster era famosa por tener conexiones por todo el reino
medio, y en este caso en particular, aseguraron tener a un destacamento
mata dragones en la villa de Horseffer. Y como todo el mundo sabe, esta
villa está a sólo 5 millas de la cueva del dragón Andrés. Solo era necesario soltar un cuervo con el mensaje y en pocos días el destacamento sería el
primero dar caza al dragón. De esta forma los Foster lograrían la victoria a pesar de ser los que menos habían trabajado.
*
Con
teni
do
lic
enci
ado
a: C
laud
io
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Gestión del trabajo 131
Así que, con las inscripciones cerradas el 31 de marzo, el rey Bruno dio comienzo a la casa del dragón el 1 de Abril con una gran fiesta en honor a todas las casas. Al
finalizar la fiesta casi 3 días después, volvió a convocar a todas las casas para
comunicarles que el 1 de Mayo todos debían estar de vuelta y narrar sus logros o fracasos.
El 1 de mayo, con todo preparado para rendir homenaje al ganador, el rey Bruno
se encontró con una fiesta sin ningún invitado; ninguna de las tres casas reales se
había presentado. Como estaba un poco intrigado llamó al espía de la corte y éste le contó lo que había sucedido con las casas. Estas son las palabras del espía:
Los Lannister se desentendieron del asunto, habiendo pagado por adelantado a “Caballeros Incorporated SA” pensaron que el tema estaba resuelto. Pero
parece que “Caballeros Incorporated SA” con sus caballeros dorados a la cabeza, se había comprometido a cazar otros dragones en paralelo y algunos
estaban ya de vacaciones con el dinero cobrado. Entonces decidieron
subcontratar a “Malhechores y Bandidos” (MB) para que hicieran el trabajo. Por esos días, el líder de MB tenía pendiente pagar unas deudas con una
salón de juego, con lo que destinó parte del dinero a pagar esa deuda y el
resto lo dilapidó en una gran fiesta con sus compañeros de armas, una de esas
fiestas que hacen historia. Después de esto, el grupo de MB quedó reducido a
muy poca gente, pero el líder de MB que era una persona de honor le pagó 10 coronas al herrero del pueblo para que se encargase del dragón.
El herrero del pueblo era famoso por ser un ex-caballero. Todas las noches
con su copa de cerveza contaba historias pasadas sobre caza de dragones y sobre salvar a princesas en peligro. Pero lo que el pueblo no sabía, era que
todas estas historias no eran más que fantasías. Como ya había aceptado las
10 coronas, la única solución que se le ocurrió fue enviar a su aprendiz a la caza del dragón.
Y poco más se sabe sobre esta historia, algunos campesinos aseguran que
cuando el aprendiz asomó su cabeza en la cueva, el dragón Andrés se lo zampó de un bocado, otros dicen que huyó hacia el mar para convertirse en
marinero.
Mientras tanto, en la casa de Robles, para asegurar la victoria, comenzaron a
crear la lanza caza-dragones LCD4000. Pero el grupo de ingenieros que había diseñado los bocetos de la lanza, nunca habían pasado de ahí, es decir
de los bocetos. Se encontraron con muchos problemas técnicos que todavía no
tenían solución; por ejemplo procesar “eso” que llegó de una tierra lejana llamado pólvora que era muy bueno para reventar muros y puertas, pero poco
fiable para enviar una lanza en la dirección correcta.
Después de procesar esta información con detalle, llegaron a la conclusión de que podrían crear una versión mejorada de la lanza caza-dragones LCD4000.
Se trataba de la lanza caza-dragones LCD5800 Ultimate, pero no estaría lista
**
09/0
8/20
13
Con
teni
do
lic
enci
ado
a: C
laud
io
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
132 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
hasta el año entrante. El príncipe José compró la idea de la LCD5800
Ultimate (si algo se llama Ultimate tiene ser lo mejor de lo mejor) y decidió
esperar hasta el año entrante para conseguir pareja.
Finalmente la casa de Foster, aunque estuvo muy cerca de matar al dragón Andrés no logró su cometido. El problema fue algo muy simple, incluso un poco tonto.
El cuervo con el mensaje para matar al dragón llegó correctamente a la villa
de Horseffer una vez comenzado el torneo. El encargado del destacamento
entendió el mensaje, pero no se imaginó que era al dragón Andrés al que había que matar. Pensó que para demostrar que eran los mejores debían
enfrentarse con el dragón más feroz del lugar. Se dirigió a la cueva del dragón Lucio, un dragón famoso por su mal genio y por el que más de una
casa real ofrecía una recompensa, convencido de que de esta forma ayudaría
al príncipe a casarse y de paso ganaría unas coronas para la villa. Así que después de 15 días asediando al dragón y con sus filas mermadas, el
encargado solicitó más coronas a la casa de Foster. Como el tiempo
apremiaba, con esas coronas el encargado contrató a un caballero para que
diese caza al dragón. Tenía unas increíbles referencias, aseguraba trabajar
en “Caballeros Incorporated SA” e incluso había sido adiestrado en la Academia Real para la Caza del Dragón.
El caballero aceptó el encargo a pesar de que le supuso un conflicto moral,
ya que estaba realizando el mismo trabajo (algo así) para otra casa real. Decidió quedarse con el 80% del dinero y envió a su escudero para que se
encargase del dragón. Aquí también hay teorías encontradas al respecto, unos dicen que sirvió de comida del dragón Andrés, otros comentan que como el
aprendiz de herrero huyó hacia el mar para vivir como un marinero y recorrer
tierras lejanas.
Esto fue lo que le contó el espía de la corte al rey Bruno, asegurando además que
las 3 casas solicitaban su perdón y que siempre estarían en deuda con su reino. Pero “esto no es todo, tome asiento mi rey; queda algo más que debe saber”, le dijo el
espía.
Parece que durante el mes de plazo que dio el rey Bruno, la princesa Martina
se había embolsado 1000 coronas procedentes de las inscripciones por la caza del dragón, se había enamorado de un marinero y huido con él a tierras
lejanas. Dicen que el marinero era muy parecido al aprendiz del herrero o al
escudero del caballero, esto nunca se sabrá puesto que el barco ya había zarpado sin rumbo conocido.
El rey Bruno, que era rey pero no tonto, después de darle vueltas a la situación dijo
al espía:
-
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a
: C
laud
io
V
arga
s
Ale
jos
Gestión del trabajo 133
Esto no ha salido tan mal. Por un lado, tengo a 3 familias reales que me deben
un gran favor y por otro, mi niña ha emprendido un viaje para conocerse a sí misma sin haberle costado ni una corona a las arcas del reino. Martina es
inteligente, seguro que sabrá arreglárselas con sus propios medios. Y además me ha dejado 500 coronas que puedo disponer a mi antojo y concederle algún
capricho a mi reina.
Así pues, todos quedaron felices; algunos con unas coronas más, otros con unas
coronas menos, la princesa con un viaje gratis por el mundo, el rey con más tiempo
para estar con la reina, y el dragón Andrés que hacía años que no se daba un buen
festín, feliz con el buche lleno tras haberse zampado un humano, uno que parecía ser
un escudero o quizás un aprendiz de herrero.
Fin.
5.- KANBAN Y TEAM FOUNDATION
5.1.- Introducción a Kanban
Kanban es una palabra que significa “Tarjeta visual” y se hizo famoso a partir de un
sistema de información para sistemas de producción basado en tarjetas desarrollado por
Toyota para coordinar el trabajo de las líneas de producción en sus empresas. Si bien es
aplicable a sistemas informáticos o de producción como veremos en este capítulo, la
idea de utilizar un sistema de tarjetas visuales para controlar un flujo de trabajo es la
base de Kanban.
Veamos como Starbucks aplica Kanban en la recepción y entrega de pedidos:
Un empleado nos toma el pedido.
Apunta en un vaso de papel nuestro nombre y en las casillas del vaso los
detalles de nuestro pedido.
El vaso pasa a las manos de otro empleado el cual a partir de las indicaciones
visuales que posee el vaso hace el café.
Finalmente con el café listo, se llama al cliente que lo pidió y se cierra el ciclo.
En este caso, el propio vaso de papel hace de Kanban ya que en el mismo se
apuntan los diferentes pasos del proceso.
*-
09/0
8/20
13
Con
teni
do
licen
ciad
o
a:
Cla
udio
V
arga
s
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
134 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 42 - Kanban y Starbucks.
Cuando aplicamos Kanban en proyectos de desarrollo de software, Kanban se
caracteriza por definir un tamaño máximo de capacidad de trabajo, denominado WIP
(work in progress). El WIP se toma como medida de trabajo dentro de Kanban y
además es posible obtener métricas para ver la capacidad y el estado del proyecto.
Kanban es muy amplio como sistema, pero habitualmente para su implementación
en proyectos de desarrollo es muy usual seguir las siguientes premisas:
El trabajo actual se debe poder visualizar fácilmente. Se trabaja con un tablero
en el que existen diferentes columnas que representan los estados de una tarea.
Las tareas se representan con PostIts
Pueden existir diferentes categorías de colores, para definir estados o tipos de
tareas. Por ejemplo, a las tareas que se encuentren bloqueadas se les puede
pegar un PostIt de color rojo, para resaltarlas de las demás.
El WIP se debe respetar siempre (¡fundamental!)
Supongamos que partimos de un escenario donde una tarea puede adoptar uno de
los siguientes estados:
Propuesta
Activa
Lista para Test
Cerrada
*
C
onte
nido
l
icen
ciad
o
a:
Cla
udio
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Gestión del trabajo 135
Bloqueada
Las diferentes zonas en donde se agrupan las tareas de acuerdo a su estado se
representarían en un tablero ficticio tal y como sigue:
Figura 43 - Modelo para un tablero de Kanban.
Cada tarea sólo puede tener un estado, las tareas siempre se dan de alta con el
estado “propuesto”, pero a partir de ahí no hay ninguna regla para las transiciones, es
decir, para moverse entre los distintos estados. Así por ejemplo una tarea podría seguir
el siguiente camino:
Propuesta > Activa > Cerrada
Propuesta > Activa > Lista para Test > Cerrada
Propuesta > Cerrada
Propuesta > Activa > Bloqueada > Activa > Lista para Test > Cerrada
Propuesta > Bloqueada > Activa > …
La siguiente imagen muestra un ejemplo del tablero con varias tareas en diferentes
estados. Para este ejemplo el WIP se calcula en base a la siguiente fórmula:
WIP = Tareas Activas + Tareas Listas para Tests
Con lo que tenemos un WIP de 5 tareas, que es el número máximo de tareas que
puede manejar nuestro equipo.
-*
09/0
8/20
13
Con
teni
do
l
icen
ciad
o
a:
Cla
udio
V
arga
s
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
136 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 44 - Ejemplo de WIP.
Es importante aclarar que las nuevas tareas se van agregando a la sección de
propuestas y no se pasan a activas hasta que se libera un espacio en el WIP. Esto
sucede cuando una tarea se completa, una tarea se bloquea, o una tarea se descarta. Lo
mismo sucede con las tareas que salen del estado bloqueado, éstas solo se podrán
volver a procesar cuando exista un espacio disponible en el WIP.
Veamos un ejemplo práctico:
Una tarea muy importante está bloqueada porque depende de una colaboración
externa para completarla. El equipo de trabajo coloca esta tarea en la sección de
bloqueos y sigue trabajando con las demás. Pero en un determinado momento, la
colaboración externa termina y ya es posible continuar con esta tarea. Entonces surge
un problema porque el equipo de trabajo aún no ha terminado con ninguna de las tareas
del WIP, por lo que no hay lugar para realizar una tarea más.
En estos casos, el equipo o el project manager deberá tomar una decisión, algunas
posibles opciones son las siguientes:
Esperar a que se libere una tarea del WIP para poder completar la tarea
bloqueada
Bloquear una tarea existente para liberar un espacio de trabajo en el WIP.
Aumentar el tamaño del WIP para poder incorporar la tarea que se ha
desbloqueado.
Lo importante en estos casos es que en Kanban no se trabaja con iteraciones ni con
estimaciones de tiempo para las tareas. La unidad de medida de trabajo la determina el
WIP.
-
-
Cla
udio
Var
gas
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
C
onte
nido
licen
ciad
o
a:
Gestión del trabajo 137
Según el tipo de equipo y la forma de trabajo, es posible que exista un modelo más
formal donde un project manager es el encargado de crear y asignar las tareas, o
también puede existir un modelo más flexible, donde las decisiones y asignaciones de
tareas se hacen de común acuerdo entre todo el equipo. En ambos casos, la pizarra
Kanban siempre es un excelente punto de partida para ver con qué tareas se debe seguir
trabajando.
El siguiente ejemplo muestra una pizarra en la que de un simple vistazo se aprecia
que hay un problema con las tareas que están listas para ser testeadas. Si un
desarrollador se encuentra libre de trabajo y se pregunta ¿con qué debo seguir? La
opción natural sería tomar el relevo y ayudar a Testing.
Figura 45 - Ejemplo de acumulación de tareas listas para Testing.
Algunas críticas a Kanban se centran en que al no trabajar con métricas de tiempos
de tarea, no es posible medir la velocidad de un equipo, ni tampoco estimar la
finalización de un grupo de tareas. Estas premisas hacen que muchas personas piensen
que Kanban solo sirve para gestionar equipos de mantenimiento de software, ya que en
los mismos, se trabaja en base a un grupo no definido de errores a solucionar.
Para este ejemplo, el funcionamiento de un equipo de mantenimiento de software
podría ser similar al siguiente:
El equipo de recepción de incidencias recibe y registra una incidencia por
parte de un usuario.
Esta incidencia llega al equipo de mantenimiento.
El equipo de mantenimiento crea una tarea Kanban asociada a la incidencia
y la agrega a la pizarra en el estado “Propuesta”.
-
-*
Con
teni
do
lic
enci
ado
a
: C
laud
io
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
138 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
El equipo realiza una evaluación de las tareas propuestas para evaluar cuál
es la siguiente tarea a incorporar en el flujo de trabajo.
Cuando una incidencia se da por resuelta y validada por el equipo de
Testing, se libera un hueco en la capacidad de trabajo y se “activa” una
incidencia desde el grupo de tareas propuestas.
Trabajando ordenadamente en lo relacionado a la selección de las próximas tareas a
“activar”, Kanban se convierte en un excelente sistema con el que gestionar un equipo
de trabajo.
5.2.- Valmar: Gestionando un equipo de desarrollo con
Kanban
Visual Studio Application Lifecycle Management no posee una plantilla por defecto
para trabajar con un modelo Kanban. Las plantillas que vienen por defecto que libera el
equipo de producto de Microsoft dan soporte para modelos AGILE, CMMI y SCRUM.
Para trabajar con un modelo KANBAN es posible utilizar plantillas de empresas
externas o seguir el ejemplo que se comentará en esta sección.
Modificando una plantilla de las que se incluyen en Team Foundation y trabajando
con herramientas externas es posible simular un entorno de trabajo Kanban. El tutorial
“Tutorial: Cómo agregar un estado a la definición de un WorkItem” muestra un
ejemplo en el que se modifica la definición de un WorkItem.
Para este ejemplo utilizaremos una plantilla MSF for Agile 5.0 en la que se ha
modificado la definición del WorkItem de tipo “Task” para que soporte los siguientes
estados:
Proposed
Active
Resolved (Ready to Test)
Closed
Blocked
El estado inicial es “Proposed” y a partir de ahí existen diferentes caminos para
pasar de un estado a otro, por ejemplo:
Proposed >> Active
Active >> Proposed
Active >> Resolved
-
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a:
Cla
udio
V
arga
s
A
lejo
s
Gestión del trabajo 139
Active >> Blocked
Resolved >> Active
Resolved >> Blocked
Resolved >> Closed
Blocked >> Active
Blocked >> Resolved
Closed >> Resolved
La siguiente figura muestra el Workflow de estados por los que puede pasar este
tipo de WorkItem.
Figura 46 - Transiciones de estado para el tipo “Task”.
Al igual que en la sección “Tutorial: Crear elementos iniciales para la gestión de
un proyecto”, una vez creada una User Story, se definen las tareas necesarias para
implementar la misma, por ejemplo:
User Story - Setup Development Environment
o Task - Setup user and permissions in Team Foundation Server
o Task - Setup user and permissions in SharePoint Server
o Task - Setup user and permissions in Reporting Server
o Task - Setup Team build environment for Continuous Integration
-
**
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do li
cenc
iado
a:
Cla
udio
Var
gas
A
lejo
s
140 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
o Task – Create Team Build Process to allow the deploy of the
application
o Task – Configure Lab Management
En una consulta de WorkItems de tipo TreeView sería posible ver información
similar a la siguiente:
Figura 47 - User Story y tareas asociadas.
A continuación, el equipo debería definir cuál es el WIP con el que va a trabajar,
por ejemplo 3; y activar 3 tareas para comenzar a trabajar con ellas. Una gran ventaja
de Team Foundation es que es posible contabilizar las horas de trabajo imputadas a
cada tarea utilizando los campos “Remaining Work” y “Completed Work”.
Si creamos una consulta que muestre las tareas organizadas por User Story y estado,
sería posible ver el WIP actual y además las tareas en los demás estados. La siguiente
imagen muestra un ejemplo con esta consulta.
Figura 48 - WIP utilizando WorkItem Query
Ahora bien, lo interesante de Kanban es que nos ofrece una representación visual de
nuestro WIP, pero trabajando con WorkItem Queries no tenemos las capacidades
gráficas necesarias. En estos casos podemos utilizar productos de terceras partes para
que nos ayuden a implementar Kanban con Team Foundation.
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a
: C
laud
io
Var
gas
A
lejo
s
Gestión del trabajo 141
Por ejemplo, existe un tablero de trabajo con WorkItems de
ScrumForTeamSystems (http://www.scrumforteamsystem.com) que nos permite
trabajar visualmente con las tareas en Team Foundation, agrupando las mismas por
User Story. Esta herramienta se llama TFS Workbench (http://bit.ly/nzszAv) y si
analizamos los elementos de trabajo de la consulta anterior, veríamos los mismos con
un formato similar al mostrado en la siguiente imagen:
Figura 49 - Tablero de trabajo Kanban con TFS Workbench.
Si definimos nuevamente el WIP como:
WIP = Tareas Activas + Tareas Listas para Tests
Veríamos que nuestro WIP está completo, y que tenemos una tarea cerrada y una
tarea a la que tenemos que prestar especial atención, ya que está bloqueada.
Figura 50 - Analizando el WIP.
-
-
09/0
8/20
13
Con
teni
do
lic
enci
ado
a
: C
laud
io V
arga
s A
lejo
s
cla
udio
cva@
hotm
ail.c
om
142 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Esto es un pequeño ejemplo sobre cómo es posible implementar un modelo de
trabajo Kanban para trabajar con Visual Studio ALM. Como no existe ninguna
herramienta que provea estas funcionalidades “out of the box” es posible aprovechar
las capacidades de Team Foundation y su modelo de extensibilidad para poder
implementar este modelo.
Un ejemplo más detallado es el que ha mostrado Adam Gilmore (@adamgilmore)
en los TechDays y que se puede descargar desde CodePlex (http://bit.ly/qhiA4k). En
este ejemplo se han implantado los siguientes elementos:
Una modificación de los estados de las User Stories para dar soporte al
flujo de estados en el proceso.
Un tablero gráfico para mostrar los estados de las diferentes User Stories
desarrollado en ASP.Net.
Una hoja de trabajo en Excel para mostrar diferentes métricas de proyecto,
por ejemplo:
o La evolución diaria del WIP.
o El tiempo medio de resolución de WorkItems.
Figura 51 - TechDays, evolución diaria de los elementos de trabajo
*
Cla
udio
Var
gas
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lic
enci
ado
a
:
Gestión del trabajo 143
Nota: SCRUMBAN es una tendencia que intenta reunir las ventajas de Kanban
con la forma de trabajo definida por SCRUM. ScrumBan incorpora muchos
conceptos interesantes que pueden ser utilizados para la gestión de un equipo de
desarrollo. Si bien no hay implementaciones formales para Visual Studio ALM,
hay varios links que pueden ayudarnos a comprender este enfoque:
Scrum-ban, http://bit.ly/n4TygA
Scumban, multi proyecto y multi perfil por Carlos Iglesias,
http://bit.ly/nt4ziz.
5.2.1.- Tutorial: Cómo agregar un estado a la definición de
un WorkItem
Este tutorial muestra cómo modificar la definición de un tipo de WorkItem “Task”
en una plantilla de procesos de Team Foundation Server 2010 de tipo MSF for Agile
5.0. Para esto utilizaremos Visual Studio 2010, un Team Project basado en MSF for
Agile 5.0 y la última versión disponible de las Team Foundation Server Power Tools.
1. Abrir Visual Studio 2010.
2. Acceder al menu “Tools // Process Editor // WorkItem Types // Open WIT from
Server”.
3. Seleccionar el Team Project basado en MSF for AGILE en el que se modificará
el tipo de WorkItem “Task”.
4. Seleccionar el WorkItem Type “Task”.
5. En este punto se debe visualizar dentro del IDE de Visual Studio 2010, el
formulario de edición para la definición de un WI. Acceder a la pestaña
“Workflow”, donde podremos ver el proceso actual con los estados por los que
pasa el WorkItem de tipo “Task”. Por defecto, el primer estado es el estado
ACTIVE.
6. Activar la ToolBox de Visual Studio 2010. En este panel se puede acceder a los
elementos de tipo “State” y “Transition” para trabajar sobre la definición del
flujo de estados del WorkItem.
7. Agregar un nuevo estado y modificar el nombre del mismo a “Proposed”
8. Agregar transiciones para poder cambiar de estado de “Proposed” a “Active” y
de “Active” a “Proposed”. Para este ejemplo no se habilitará el cambio de
estado de “Closed” a “Proposed”.
20128
-
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lice
ncia
do
a:
Cla
udio
V
arga
s A
lejo
s
144 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 52 - Nuevo estado “Proposed” agregado y relacionado.
9. Como la primera transición está asociada al estado “Active”, en este paso
cambiaremos la misma para que el primer estado sea “Proposed”.
10. Para esto debemos seleccionar la transición.
11. Desplegar el menú contextual.
12. Seleccionar la opción “Open Details”.
13. En el formulario de edición, seleccionar “Proposed” como el estado destino de
la transición.
14. A continuación debemos validar si el esquema que hemos definido es correcto.
Para esto debemos desplegar el menú contextual sobre el diseñador.
15. Seleccionar la opción “Validate All”. Es posible que para que la definición sea
correcta, sea necesario agregar por lo menos una razón (Reason) a los cambios
de estado del Workflow.
16. Debemos editar la transición [Proposed >> Active]. Para esto seleccionamos la
pestaña “Reasons” y editamos las “Reasons” definiendo una razón por defecto
llamada “Accepted”.
17. En la transición [Active >> Proposed] agregamos dos posibles Reasons:
“Rejected” y “More Information is Required”.
18. Si expandimos el gráfico para ver el detalle de las transiciones, veremos los
cambios que hemos aplicado en la tarea en un Workflow.
-*
Cla
udio
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3 C
onte
nido
l
icen
ciad
o a
:
Gestión del trabajo 145
Figura 53 - Cambios de estado con Reasons.
19. Guardar la definición del WorkItem. Este cambio se aplica en el servidor Team
Foundation, por lo que puede tardar un poco.
20. Para probar la nueva definición de un WorkItem de tipo “Task” debemos
seleccionar el Team Project en el panel del Team Explorer y refrescar el
contenido del mismo.
21. Al momento de crear una nueva Task, es posible ver que el estado inicial es
“Proposed” y que la Reason es “New”.
22. Una vez creada la “Task”, veremos que es posible cambiar el estado a “Active”
y que la Reason propuesta es “Accepted”.
23. Finalmente vemos que si se desea cambiar el estado de “Active” a “Proposed”,
las Reason propuestas son las que hemos definido en los pasos anteriores.
5.2.2.- Tutorial: Cómo agregar condiciones a los cambios de
estado en la definición de un WorkItem
Este tutorial es la continuación del tutorial anterior “Tutorial: Cómo agregar un
estado a la definición de un WorkItem” y en el mismo veremos cómo es posible
agregar una serie de condiciones que se deben cumplir en las acciones de cambio de
estado de un WorkItem. Para este ejemplo, trabajaremos con la siguiente regla de
negocio que se debe aplicar al cambio de estado de una “Task”:
*
-
09/0
8/20
13
C
onte
nido
lice
ncia
do
a:
Cla
udio
V
arga
s
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
146 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Una Task no puede pasar del estado [Proposed] a [Active] si no se ha completado
la información de horas estimadas, completadas y pendientes definida en la misma.
A partir del tutorial anterior, los pasos a seguir son los siguientes:
1. Editar la definición de una “Task”.
2. Acceder a la pestaña “Workflow”.
3. Seleccionar la transición [Proposed >> Active]
4. Desplegar el menú contextual.
5. Seleccionar la opción “Open Details”.
6. Seleccionar la pestaña “Fields” en la que agregaremos los campos sobre los
que queremos trabajar.
7. Agregar un nuevo campo, seleccionando
a. Microsoft.VSTS.Scheduling.OriginalEstimate
8. En la pestaña “Rules”, agregamos una nueva regla de tipo “REQUIRED”
para indicar que el campo es requerido.
9. Agregamos también los siguientes campos como campos requeridos en la
transición.
a. Microsoft.VSTS.Scheduling.RemainingWork
b. Microsoft.VSTS.Scheduling.CompletedWork
10. En el diagrama del Workflow es posible ver como estos campos, se marcan
como campos de trabajo en la transición [Proposed >> Active].
11. Guardar la definición del tipo de WorkItem “Task” en el servidor de Team
Foundation Server.
12. Refrescar el Team Explorer
13. Crear una nueva tarea.
14. En el momento de crear una nueva Task es posible ver que el estado inicial
“Proposed” no presenta ninguna restricción.
15. Se cambia el estado a “Active”: los campos de esfuerzo (horas) se marcan
como activos, con lo que se cumple la regla que definimos para la
transición.
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do l
icen
ciad
o
a:
Cla
udio
Var
gas
Ale
jos
Gestión del trabajo 147
Figura 54 - Campos requeridos en el cambio de estado.
6.- CONCLUSIÓN
A lo largo de este capítulo hemos intentado dar un repaso a algunas de las
tendencias que se utilizan actualmente para el desarrollo del software, centrándonos en
la experiencia adquirida y básicamente, en el trabajo con los productos de Visual
Studio Application Lifecycle Management. Hemos dejado muchos puntos sin tratar, los
cuales constituirían un libro por sí solos, poniendo foco en los siguientes:
Si no conoces AGILE o alguna de sus variantes (SCRUM, KANBAN, etc.)
dedícale un tiempo a conocer los conceptos que se presentan en las
mismas. Tal vez no los puedas aplicar completamente en tu entorno de
trabajo, pero seguramente podrás incorporar algunas prácticas que te
ayudarán a mejorar tu modelo de trabajo
Todos los procesos de trabajo son mejorables: No importa lo maduro y
completo que sea una metodología de trabajo, siempre es posible encontrar
puntos donde mejorar el proceso. Por eso es importante conocer diferentes
opciones para tomar ejemplo de las mismas y, además de corregir errores,
incorporar mejoras.
La gestión no se basa en las herramientas: Si bien este libro se basa en
ejemplos con productos Microsoft, la correcta gestión de un proyecto se
apoya en los productos, pero no es lo fundamental. En cada uno de los
casos comentados, el problema no era el producto si no la mala utilización
del mismo. Antes de comenzar a trabajar de una determinada forma,
asegúrate que todo tu equipo está en la misma sintonía.
Lo importante son las personas: AGILE 100%.
-*
09/0
8/20
13
C
onte
nido
lice
ncia
do a
: C
laud
io
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
149
CAPÍTULO
El auténtico problema no es si las máquinas piensan, sino si lo hacen los hombres.
Frederic Burrhus Skinner
-Nuestro producto es superior.
-No lo entiendes Steve, eso no importa.
Pirates of Silicon Valley
Calidad
4
-
*-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
licen
ciad
o
a
: C
laud
io V
arga
s A
lejo
s
150 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
1.- QUÉ ENTENDEMOS POR CALIDAD
En el segundo capítulo de este libro hemos visto por qué es importante gestionar
correctamente el código fuente de una aplicación para manejar la evolución de la
misma. En el capítulo siguiente se ofrece una visión general sobre por qué es
primordial ayudar al desarrollo del proyecto desde un punto de vista de la gestión del
mismo. Y en este último capítulo hablaremos de la calidad necesaria a la hora de crear
un producto de software.
Generalmente, cuando pensamos en “control de calidad” lo primero que nos viene a
mente es que las pruebas unitarias pasen correctamente y que las pruebas de aceptación
de usuarios sean efectivas. Sin embargo, el concepto de calidad debe aplicarse en todas
las facetas de un proyecto, es decir, con una visión mucho más amplia.
Por ejemplo, la arquitectura de la aplicación tiene que ser robusta y extensible, el
diseño de clases tiene que respetar los principios SOLID, etc. Estos y otros conceptos
definen la calidad de una aplicación desde el punto de vista del software, pero la
calidad también debe ser entendida desde el punto de vista de la gestión de la
aplicación. Dicho de otra forma, tenemos que controlar cómo manejamos la evolución
de una aplicación. Tomemos por ejemplo la definición de Wikipedia (http://bit.ly/q9WBkO), para la
calidad del software. En esta página se define calidad como:
La aptitud de un producto o servicio para satisfacer las necesidades del
usuario.
La cualidad de todos los productos, no solamente de equipos sino también de programas.
Pero para evaluar la aptitud de un producto es necesario tener un punto de
referencia a partir del cual poder calificar un producto como:
Producto bueno.
Producto malo.
Es por eso que la calidad del software está asociada a una o más métricas que
permitan medir la misma. De esta forma podemos identificar desviaciones y trabajar
sobre ellas. Es importante remarcar que las métricas nos ayudan a tomar decisiones. Y
sobre estas decisiones podemos actuar en consecuencia.
Una de las tareas esenciales en la ejecución de un proyecto consiste en identificar
éstas métricas y luego comenzar a definir valores estimados para trabajar con ellas.
Nota: Uno de los padres de la informática, Tom De Marco, dijo “no se puede
controlar lo que no se puede medir” poniendo así de relieve la importancia de
actuar en base a métricas.
**
09/0
8/20
13
Con
teni
do
licen
ciad
o
a:
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
Calidad 151
Veamos un ejemplo más claro. En el capítulo anterior vimos como un
requerimiento podía ser desglosado en tareas y casos de prueba para dar forma al
mismo.
Figura 1 - Implementación y pruebas de una User Story.
Así como el seguimiento de las tareas nos ayuda a ver el progreso de la
implementación de la User Story, el resultado de la ejecución de las pruebas (Test
Cases) nos ayuda a ver si una User Story está completa.
A medida que un equipo avanza en un proyecto, es muy probable que hayan
definido varios elementos que les ayuden a comprender mejor el estado del proyecto.
Por ejemplo, creando una serie de Bugs asociados a los Tests Cases definidos para una
User Story.
Figura 2 - Elementos relacionados a una User Story.
-
**
Cla
udio
V
arga
s
A
lejo
s
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
Con
teni
do
li
cenc
iado
a:
152 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Para ver esta información de forma más efectiva podemos utilizar el informe “Stories Overview” (http://bit.ly/oiYjqH). La información del estado de las Pruebas y
Bugs relacionados con cada User Story es mostrada de la siguiente manera:
Figura 3 - Pruebas y Bugs asociados a una User Story.
Este informe nos brinda una serie de métricas que nos pueden ayudar a ver la
calidad actual de la implementación de nuestro proyecto. Como podemos ver en el
mismo con la primer User Story:
Un 40% de las pruebas definidas han pasado correctamente.
Un 20 % de las prueba definidas han fallado.
Un 40% de las pruebas definidas no se han ejecutado.
Además vemos que existe un bug en estado activo asociado a esta User Story. Tras
este vistazo general de la User Story podemos afirmar que no está completa para ser
liberada.
En este ejemplo estamos interpretando información, que Visual Studio ALM genera
automáticamente a partir de nuestros inputs en el proceso de desarrollo de software,
para poder analizar el estado de una User Story.
Otras métricas como la ejecución de pruebas unitarias, la cobertura de código, el
análisis de código estático, etc.; también son parte de los elementos que provee Visual
Studio ALM para controlar nuestro proyecto.
En este capítulo veremos cómo trabajar con los mismos y además daremos un
repaso a otros factores que ayudan a mejorar la calidad, como por ejemplo las
herramientas de colaboración.
20128
-
-
09/0
8/20
13
Con
teni
do
lic
enci
ado
a
: C
laud
io
Var
gas
Ale
jos
cla
udio
cva@
hotm
ail.c
om
Calidad 153
1.1.- Relato: El piloto que pasa por producción antes de
terminar en la basura
Muchas veces se inicia un proyecto con una premisa simple:
Necesitamos saber si el producto 123 ó la tecnología ABC son válidos para cubrir
la funcionalidad XYZ, ¿podemos hacer una prueba de concepto sobre esto?
Después de un par de semanas la prueba de concepto está completa y como parece
que puede tener buen futuro se organiza un pequeño Workshop para mostrar el mismo.
Aquí suele comenzar un pequeño infierno para los gestores, para los desarrolladores y
finalmente para los usuarios.
Como todo parece tener muy buena pinta, alguien decide que esto que era una
prueba de concepto, está completo para salir a producción. Comienza un proceso de
tira y afloja entre las áreas de Management y Development para ver cuándo se puede
desplegar la aplicación, y ya no se habla más de una prueba de concepto, ahora ya es
una “aplicación”.
En la mayoría de los casos la prueba de concepto suele tener un 10% de código
realmente aprovechable, siendo el restante 90% una base de “cartón-piedra” que da
soporte a la prueba. Entonces, cuando se decide lanzar la aplicación en producción
saltan a la vista estas carencias.
Si en el Workshop se ha involucrado además a un cliente, y no se ha manejado
correctamente las expectativas del mismo; es muy probable que el cliente vea una
“aplicación cerrada” en lugar de una pequeña prueba. Finalmente, las consecuencias de
salir a producción con un producto inmaduro son harto conocidas por todos nosotros.
No debemos deducir, de lo expuesto anteriormente, que debemos evitar hacer
pruebas al inicio. En realidad, el problema ha sido originado por no dejar en claro
desde un primer momento las expectativas sobre las tareas que se están realizando, no
por el hecho de haber realizado una prueba de concepto. Dicho de otra forma, podemos
comenzar un proyecto con una pequeña prueba, es más; animamos a tener un prototipo
de la aplicación lo antes posible para mostrar al cliente. Esto nos permitirá demostrar al
cliente que estamos trabajando y además ver si estamos todos sintonizados y trabajando
en el mismo canal. Así, cuando presentemos el prototipo los apuntes sobre el mismo
irán orientados a mejorarlo no a desplegarlo.
Esto no quita que desde el inicio del proyecto adoptemos las buenas prácticas de
desarrollo, tengamos un buen diseño de arquitectura y refactoricemos constantemente
nuestro código para mejorar el mismo.
La calidad es un factor que debe estar siempre presente en todas las fases de un
proyecto.
-
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s
154 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
2.- CALIDAD DE CÓDIGO Rodrigo Corral (http://bit.ly/pYnCmD) hace tiempo escribió un post titulado “En
el software, la calidad, no es opcional” (http://bit.ly/q9FzL7). Cualquiera que lo lea
se sentirá identificado con varios de los puntos que se comentan en el mismo.
Mientras el relato anterior hacía referencia a la mala gestión de la calidad de un
producto, esta sección versa sobre la calidad de código en el desarrollo de una
aplicación.
Este es un libro orientado a la organización de un equipo, pero así como es
importante la gestión correcta del modelo de branches y la gestión de las historias de
usuarios, también lo es el código.
Cuando hablamos de calidad de código por lo general nos referimos a mejoras de
diseño o de técnicas de programación. Ppero si volvemos al tema de las métricas
comentado al principio del capítulo, pocas imágenes definen la calidad de un software
como la mostrada en el libro de Robert C. Martin:
“Clean Code: A handbook of Agile Software Craftsmanship” (http://amzn.to/pdVuno).
Figura 4 - Métrica WTF de Tom Holwerda (http://bit.ly/nsk3L4).
Nota: En caso de que alguien no conozca el libro Clean Code: A handbook of
Agile Software Craftsmanship, éste es un buen momento para hacerlo. Es un libro
recomendable para todos los niveles de programadores. Si eres una persona que
está comenzando a programar o no sabes mucho sobre el tema, este libro te
ayudará a comprender las bases de un modelo de programación con todas las
mejores prácticas recomendadas.
-
**
09/0
8/20
13
C
onte
nido
licen
ciad
o
a: C
laud
io
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
Calidad 155
Si por el contrario, ya posees una buena base y mucha experiencia, este libro
deberías dejarlo al lado de la cama o a mano en tu oficina y cada tanto abrirlo en
algún capítulo al azar, volver a leer el mismo, y seguro que te llevas alguna
sorpresa al respecto.
En conclusión, si no lo has leído, deberías leerlo. ¡Suelta este libro de tus
manos y consigue Clean Code lo antes posible!
Comencemos por lo básico. Lo mejor es hacernos la siguiente pregunta:
¿Qué herramientas me provee Visual Studio ALM para mejorar mi calidad de
código?
Visual Studio ALM es una gran suite con muchas herramientas incorporadas para
mejorar la calidad. Pero además de las herramientas, se deben tener buenos
conocimientos sobre programación; a mayores se puede mejorar Visual Studio con
herramientas externas obteniendo así más provecho y logrando una mejor calidad.
A continuación veremos un ejemplo concreto donde repasamos un poco algunas
buenas prácticas implementadas con Visual Studio ALM.
2.1.- Unit Testing, Code Coverage, TDD, Refactoring, Code
Analysis, etc.: De 1 a 100 Km/h en 10 páginas
Para ver algunas de las capacidades de Visual Studio ALM haremos un ejemplo
desde cero donde utilizaremos las mismas.
Para este ejemplo supondremos que estamos trabajando en una aplicación para un
Zoológico y que después de un trabajo inicial de diseño de de entidades ya validado
con un cliente, tenemos la siguiente definición de una clase “Animal“, de la que luego
se implementan varios animales diferentes:
Figura 5 - Esquema de animales del zoológico.
-
--
09/0
8/20
13
C
onte
nido
l
icen
ciad
o
a:
Cla
udio
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om
156 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Aclaración: Para dar con la excepcion que cumple la regla, o para demostrar el
“haz lo que yo digo, pero no lo que yo hago”; este ejemplo no cumple con todas las
reglas de diseño. Prometemos dedicar más tiempo al diseño correcto de entidades
en el próximo libro.
Si partimos de la siguiente User Story como base para la implementación de un
sistema de validación de animales en el zoo:
As a <zookeeper> I need to <validate if all the animals in my zoo are sleep before I close the zoo>
Como estamos trabajando con un enfoque Test Driven Development (http://bit.ly/5Df53A), lo primero que haremos es escribir las pruebas que den validez
a las historias de usuario.
Nota: Para conocer la técnica de programación dirigida por pruebas se
recomienda leer el libro de Carlos Blé Jurado, Juan Gutiérrez Plaza, Fran Reyes Perdomo y Gregorio Mena; “Diseño Ágil con TDD” (http://bit.ly/qfxqWW).
Este libro es un excelente punto de partida para comenzar a trabajar utilizando
correctamente esta técnica de programación.
¿Por qué es importante escribir las pruebas unitarias antes? Este es un tema
complejo al cual se le podría dedicar todo un capítulo. Lo importante en este caso
es comprender que al comenzar escribiendo Unit Tests que validen una
funcionalidad específica, comenzamos a crear un diseño incremental de una
aplicación.
Este concepto “Incremental Design” lo explica detalladamente Kent Beck en su libro Extreme Programming Explained (http://amzn.to/oYQjue). Aquellos
que no puedan acceder al libro, el artículo de Martin Fowler, “¿Ha muerto el diseño?” (http://bit.ly/odrqSu) también aclara el porqué de un enfoque TDD.
A lo largo del ejemplo se han intercalado notas y referencias a buenos patrones para
el desarrollo de aplicaciones, pero ahora, volvamos a nuestro ejemplo. En este punto
crearemos una clase “ZooValidatorTest”. En ella agregaremos un código similar al
siguiente:
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Collections.Generic;
namespace ElBruno.CodeQuality.Tests
{
[TestClass()]
public class ZooValidatorTest
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
l
icen
ciad
o a:
Cla
udio
Var
gas
Ale
jos
Calidad 157
{
public TestContext TestContext { get; set; }
[TestMethod()]
public void CanClose_WithAllAnimals_Sleep_ReturnTrue()
{
var target = new ZooValidator();
var animals = new List<Animal>
{
new Lion {Name = "Simba", IsSleep =
true},
new Lion {Name = "Nala", IsSleep =
true},
new Monkey {Name = "Simon", IsSleep
= true},
new Tiger {Name = "Patricio",
IsSleep = true}
};
var actual = target.ValidateBeforeClose(animals);
Assert.IsTrue(actual);
}
}
}
Todavía no hemos implementado la clase “ZooValidator” , pare ello podemos
aprovechar las capacidades que posee Visual Studio e implementarla directamente, sin
ningun tipo de funcionalidad.
Esto nos generará una clase vacía, que tras ser retocada en cuanto a Namespaces y
otras funcionalidades, queda similar a la siguiente:
using System.Collections.Generic;
namespace ElBruno.CodeQuality
{
public class ZooValidator
{
public bool ValidateBeforeClose(List<Animal> animals)
{
throw new System.NotImplementedException();
}
}
}
Como queremos validar además otros escenarios, creamos las siguientes pruebas
unitarias:
CanClose_WithAllAnimals_Sleep_ReturnTrue
CanClose_WithAllAnimals_Awake_ReturnFalse
CanClose_WithAnimals_SleepsAndAwake_ReturnFalse
CanClose_WithEmptyAnimalsList_ReturnTrue
Es importante que los nombres de las pruebas unitarias sean lo más descriptivos
posibles, ya que de esta forma podemos saber que nuestro escenario se cumple para:
*
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Con
teni
do
li
cenc
iado
a
:
158 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Es posible cerrar el zoológico cuando todos los animales están dormidos
retorna TRUE.
Es posible cerrar el zoológico cuando todos los animales están despiertos
retorna FALSE.
Es posible cerrar el zoológico cuando hay animales despiertos y dormidos
retorna FALSE.
Es posible cerrar el zoológico cuando no hay animales retorna TRUE.
Cuando ejecutemos el conjunto de pruebas unitarias, estaremos cumpliendo la
premisa de Red-Green-Refactor, que consiste en crear una prueba que valide la
funcionalidad deseada pero sin implementar la misma. Es por esto que la ejecución de
pruebas unitarias nos dará un conjunto de errores con excepciones del tipo
“NotImplementedException”.
Figura 6 - RED: Unit Tests fallidos.
El siguiente paso, es lograr que nuestro código pueda pasar correctamente las
diferentes pruebas unitarias. Para esto comenzaremos a implementar el código
necesario que pueda ayudarnos a dar por válida cada una de dichas pruebas.
La siguiente porción de código soluciona casi todos los problemas.
using System.Collections.Generic;
namespace ElBruno.CodeQuality
{
public class ZooValidator
{
public bool ValidateBeforeClose(List<Animal> animals)
{
var canClose = true;
foreach (var animal in animals)
{
if(!animal.IsSleep)
{
canClose = false;
break;
}
}
-
*
Con
teni
do
licen
ciad
o
a: C
laud
io
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Calidad 159
return canClose;
}
}
}
Podemos comenzar con un código similar al anterior que nos permitirá pasar el set
de pruebas unitarias correctamente.
Figura 7 - GREEN: prueba unitaria exitosa.
Una vez superados los pasos RED y GREEN, vamos por el REFACTOR. En este
punto tenemos que refactorizar nuestro código, es decir, tenemos que modificar el
código, si es necesario, para poder seguir trabajando.
En este caso, y por más que las pruebas unitarias pasen correctamente, las líneas de
código del ejemplo anterior “huelen mal”.
Algo tan simple como controlar un true/false en una lista de animales no puede ser
tan complicado de escribir. Además, aprovechando las virtudes que nos ofrece LINQ,
seguro se puede simplificar la funcion de validación.
Es posible simplificar el código de la función de la siguiente manera:
using System.Collections.Generic;
using System.Linq;
namespace ElBruno.CodeQuality
{
public class ZooValidator
{
public bool ValidateBeforeClose(List<Animal> animals)
{
return animals.All(animal => animal.IsSleep);
}
}
}
La simplificación del código nos ayuda a que el mismo sea más fácil de leer y
además evita utilizar estructuras complejas como un bucle foreach.
Como el conjunto de pruebas unitarias sigue corroborando que la funcionalidad no
se ha corrompido en la clase, podemos continuar trabajando.
-
-
09/0
8/20
13
Con
teni
do
l
icen
ciad
o a
: C
laud
io
Var
gas
Ale
jos
clau
dioc
va@
hotm
ail.c
om
160 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Refactorización con Visual Studio ALM
Desde hace un par de versiones Visual Studio incluye opciones para
refactorizar código. Martin Fowler define la acción de Refactoring como
Code refactoring is "disciplined technique for restructuring an existing
body of code, altering its internal structure without changing its external
behavior", undertaken in order to improve some of the nonfunctional
attributes of the software.
Esto significa que “refactorización” es una acción en la que modificamos una
porción de código sin modificar su comportamiento. Esto lo solemos hacer por
cuestiones de organización, de limpieza o incluso para mejorar la forma en la que
se plantea nuestro código para que sea más legible.
Usualmente un desarrollador cuando escribe código se dedica a solucionar un
problema puntual. Pero una vez finalizado el código, es muy probable que en el
momento de releer el mismo, el desarrollador vea una forma mejor de implementar
la misma funcionalidad sin cambiar el comportamiento de las funcionalidades ya
creadas.
Este tipo de cambios sobre el código ya creado es lo que conocemos como
Refactoring, que aunque es una palabra que no existe está muy extendida.
Existen varios casos de Refactoring identificados, como por ejemplo extraer
una porción de código en una función externa, o realizar un renombrado de una
función de manera inteligente en el código, que vienen cubiertos por defecto con
Visual Studio ALM.
Es muy importante conocer estas capacidades y utilizarlas, ya que nos brindan
la ventaja de poder trabajar siempre con un código limpio y bien declarado.
Ahora que hemos cumplido con Red – Green - Refactor, veamos otra cuestión
interesante:
Analicemos el porcentaje de cobertura de código que posee actualmente la
solución.
La cobertura de código, usualmente conocida como Code Coverage, permite
conocer qué porcentaje de código de una clase es utilizado en la ejecución de pruebas
unitarias. En nuestro ejemplo, todo el código ejecutable de la clase “ZooValidator” está
siendo utilizado en nuestras pruebas unitarias, por lo que poseemos una cobertura de
código de un 100%.
La siguiente imagen muestra el análisis de código sobre la clase “ZooValidator”
desde Visual Studio. Se aprecia como los 8 bloques que componen el 100% de la
aplicación están cubiertos por la ejecución de las pruebas unitarias.
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a
: C
laud
io
Var
gas
A
lejo
s
Calidad 161
Figura 8 - Code Coverage al 100%.
En este momento hay una versión estable para la implementación del Zoo y se
decide validar la misma con el cliente. La siguiente imagen muestra como la
organización de User Stories y Tasks nos da una vista para conocer el estado del
proyecto.
Figura 9 - Estado de la implementación del Zoo
En este punto podemos seguir adelante con la implementación de las User Stories
definidas para la gestión del Zoo. Las siguientes User Stories en el Product Backlog
son:
As a <zookeeper> I want <to validate the open and close times for the zoo
based on the zoo schedule>
As a <zookeeper> I want <to validate that the total count of animals is
four before I can close the zoo>
La primera User Story implica crear una agenda para gestionar los horarios de
apertura y de cierre del Zoo. Además afecta al proceso de validación que ya tenemos
creado para ver si es posible cerrar el Zoo.
Para validar la agenda del Zoo creamos la siguiente clase “ZooTimes”; que además
permite definir como horario de apertura por defecto las 09:00 horas y horario de cierre
por defecto las 20:00 horas.
using System;
namespace ElBruno.CodeQuality
{
public class ZooTimes
{
public DateTime OpenTime { get; set; }
-
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
162 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
public DateTime CloseTime { get; set; }
public ZooTimes()
{
OpenTime = GetDefaultOpenTime();
CloseTime = GetDefaultCloseTime();
}
public static DateTime GetDefaultOpenTime()
{
return new DateTime(1900, 1, 1, 9, 0, 0);
}
public static DateTime GetDefaultCloseTime()
{
return new DateTime(1900, 1, 1, 20, 0, 0);
}
}
}
Una vez implementada esta funcionalidad y modificadas las pruebas unitarias
correspondientes, nos encontramos con el siguiente porcentaje de cobertura de código,
en el que vemos que hay un 3,33% de código que no está cubierto por las pruebas
unitarias.
Figura 10 - Code Coverage a la baja.
Cuando navegamos al código que no está cubierto desde el IDE de Visual Studio
ALM, en este caso la función “ValidateBeforeClose”, podemos ver lo siguiente en la
definición de la función:
Se encuentra resaltado en color azul el path de ejecución que se ha
ejecutado en una o varias pruebas unitairas.
Se encuentra resaltado en rojo el path que no se ha ejecutado en las pruebas
unitarias.
-
-
09/0
8/20
13
Con
teni
do
lice
ncia
do
a
: C
laud
io
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om
Calidad 163
Figura 11 - Paths de ejecución durante la evaluación de Code Coverage.
Tras revisar los paths de ejecución vemos que es necesario una nueva prueba
unitaria que valide una hora de cierre menor que las 20:00 horas para que retorne un
FALSE como resultado de la prueba.
La siguiente prueba unitaria simula ese escenario.
//[TestMethod]
public void
CanClose_WithAnimals_SleepsAndAwake_AndCloseTimeEighteen_ReturnFalse()
{
var target = new ZooValidator();
var animals = new List<Animal>
{
new Lion {Name = "Simba",
IsSleep = true},
new Lion {Name = "Nala",
IsSleep = false},
new Monkey {Name =
"Simon", IsSleep = true},
new Tiger {Name =
"Patricio", IsSleep = false}
};
var zooTimes = new ZooTimes {CloseTime = new DateTime(1900, 1,
1, 18, 0, 0)};
var actual = target.ValidateBeforeClose(animals, zooTimes);
Assert.IsFalse(actual);
}
Una vez incluida esta prueba nuestra cobertura de código ya llega nuevamente al
100% en todos los bloques de la aplicación.
-
*
Cla
udio
Var
gas
Ale
jos
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
164 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 12 - Code Coverage nuevamente en 100%.
En esta situación podríamos pensar que ya tenemos una aplicación completa.
Tenemos nuestro código bien refactorizado y nada “nos huele mal”. Por otra parte las
pruebas unitarias nos han dado un resultado correcto y además tenemos el visto bueno
del cliente.
Figura 13 - Estado de las User Stories.
Antes de considerar que la aplicación está completa, demos un paso más y
verifiquemos la calidad de nuestro código utilizando las reglas de análisis de código
estático. Esta validación ya no se realiza sobre el en código en ejecución (como por
ejemplo cuando ejecutamos una prueba unitaria), sino directamente sobre el código
fuente de la aplicación.
Desde la versión 2010 de Visual Studio es posible definir un conjunto de reglas a
utilizar en el análisis y luego tomar decisiones en función del resultado obtenido. Por
ejemplo si analizamos el proyecto utilizando el conjunto de reglas “Microsoft
Minimun Recommended Rules” veremos que no hay ninguna advertencia que
debamos tener en cuenta.
Si en cambio realizamos el anáalisis utilizando el set “Microsoft All Rules”,
veremos que aparecen varios puntos a tener en cuenta. Por ejemplo:
La regla CA2210 nos recomienda firmar el ensamblado.
La regla CA1709 nos recomienda cambiar la palabra “El” por “EL” en el
ensamblado “ElBruno.CodeQuality.dll”.
-
-
Cla
udio
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Con
teni
do
lice
ncia
do
a
:
Calidad 165
La CA1014 nos recomienda marcar al ensamblado
“ElBruno.CodeQuality.dll” como CLSCompliant.
Y varias más.
Figura 14 - Análisis de código estático.
Si queremos que nuestro código realmente tenga una calidad aceptable, deberíamos
elegir un set de reglas y trabajar con ellas durante todo el proceso de desarrollo. De esta
forma, aseguramos cumplir con los estándares que vienen incuidos de fábrica en Visual
Studio ALM.
Nota: Por lo general no es recomendable dejar activas las reglas de análisis de
código estático para los procesos de compilación mientras estamos desarrollando,
ya que afectan un poco al rendimiento del proceso de compilacion. Debemos
recordar siempre que cuanto más rápido sea el proceso de compilación, más
rápido será nuestro flujo de trabajo.
Es por esto, que el análisis de código es una tarea se recomienda realizar en
cada una de las compilaciones por el servidor de integración contínua. En la
proxima sección veremos qué ventajas aporta el tener un servidor de compilación
continua en un equipo de desarrollo.
-
*
Con
teni
do
licen
ciad
o
a
: C
laud
io
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
166 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
2.2.- Team Build: Automatizando la evaluación de
parámetros de calidad
Realicemos un repaso de las acciones descritas en la sección anterior mientras
participábamos en la creación de la aplicación para el Zoo.
Design and Code: Diseñar, pensar y programar una aplicación debería
suponer el 90% de nuestro trabajo.
Test Driven Development: Antes de comenzar a crear la implantación de
nuestra aplicación de Zoo, debemos escribir las pruebas que permitrán
probar las User Stories. Trabajamos con un enfoque guíado por pruebas.
Refactoring: Una vez escritas las pruebas y el código de implantación de la
aplicación, a medida que agregamos funcionalidades, maduramos el código
sin cambiar su funcionalidad para que el mismo tenga una estructura más
sólida.
Code Coverage: En base a la cobertura de código devuelta por la ejecución
de las pruebas unitarias, analizamos los paths de ejecución que se excluyen
y creamos nuevas pruebas unitarias para los mismos.
Code Analysis: Verificamos el resultado del análisis utilizando las reglas
de análisis de código estático para ver puntos a mejorar en nuestra
aplicación.
Estos son algunos de los puntos en los que Visual Studio ALM como herramienta
nos ayuda para que nuestras aplicaciones tengan unas métricas de calidad aceptables.
Pero qué pasa si nos hacemos las siguientes preguntas:
¿Es posible automatizar el proceso de análisis de estas métricas de manera
que no tenga que ver las mismas mientras trabajo en mi desarrollo local?
¿Es posible generar un sistema automático de alertas para que cuando una de estas métricas no se cumpla, pueda enterarme lo antes posible?
¿Es posible automatizar el proceso de integración y pruebas de las
funcionalidades que generamos como equipo para una aplicación?
La palabra clave es automatización, y esto mismo es lo que buscamos cuando
decidimos utilizar Team Build. Team Build es el servidor de compilación de Visual
Studio ALM que nos permite definir nuestras agendas y políticas de compilación para tener escenarios de Continuous Integration (http://bit.ly/4FcdAP), escenarios de
despliegue automatizado, gestión de la configuración, etc.
*
Con
teni
do
licen
ciad
o a:
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Calidad 167
Volviendo al ejemplo del Zoo, pensemos en un escenario en el que cada vez que un
programador modifica código y lo sube al repositorio de código fuente, se realizan
además estas acciones automatizadas por el servidor Team Build:
1. Se le requiere al desarrollador que asocie el cambio de código con un
WorkItem, por ejemplo con una Tarea.
2. Se genera un identificador único para esta instancia de ejecución del
proceso. Este id se conoce como BuildId.
3. Una vez protegido el código en el repositorio de código, se crea una
etiqueta con el nombre del BuildId para tener un SnapShot con los
elementos de código actuales.
4. Se descarga el contenido completo de la etiqueta a un servidor de
compilación en un directorio temporal de trabajo.
5. En el servidor de compilación, se compila la solución con los cambios
subidos por el programador.
6. Se ejecuta un análisis de código estático para detectar defectos asociados a
grupos de reglas para cada proyecto.
7. Se ejecutan además las pruebas unitarias definidas en la solución.
8. Se comprueba la cobertura de código a partir de la ejecución de las pruebas
unitarias.
9. Se copia el resultado de la ejecución de este proceso a un directorio
compartido con el nombre del BuildId. En este directorio se copian los
ensamblados resultantes del proceso de compilación, los resultados de
ejecución de las pruebas unitarias, los Logs de compilación, etc.
10. Se almacena la información de resultado de la compilación para su análisis
posterior.
11. Si se han detectado errores en alguno de los pasos, por ejemplo en la
compilación o en la ejecución de pruebas unitarias, se notifica al
responsable.
Esto lo hace por nosotros Team Build, y además podemos configurarlo para que
realice estas acciones en diferentes escenarios.
Cuando lo deseemos y lo lanzamos manualmente.
Basado en una agenda.
Cada vez que un usuario haga un CheckIn de código.
-
--
C
onte
nido
lic
enci
ado
a:
Cla
udio
V
arga
s
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
168 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Volviendo al escenario del Zoo, en cada una de las acciones realizadas para el
ejemplo de este capítulo, cuando el programador protegía el código en Team
Foundation se lanzaba una nueva build llamada “4.2.1 Zoo DEV CI”.
Si analizamos el histórico de ejecución de la misma desde Visual Studio podremos
ver los siguientes datos:
Nombre asignado a la Build.
Usuario que lo solicitó.
Calidad de la build.
La fecha en que se completó la ejecución de la build.
Tipo de Trigger que disparó la build. Por ejemplo, manual o por una acción
de CheckIn.
Figura 15 - Histórico de Builds en Visual Studio.
Esto nos sirve para descubrir, de un solo vistazo, qué Builds se han completado y
cuáles no. Una ejecución de una build en Visual Studio ALM puede terminar con los
siguientes estados:
Fallida. Esto significa que ha habido un error durante la ejecución de una
build. Por lo general suele ser un error de compilación o de configuración
de la Build.
Parcialmente Correcta. Esto significa que durante el proceso de ejecución
de la Build se ha podido compilar el código, pero en la ejecución de las
pruebas unitarias las mismas una o más han fallado.
*-
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
Calidad 169
Correcta. Esto significa que durante el proceso de ejecución de la Build, se
ha podido compilar el código y han pasado correctamente todas las pruebas
unitarias.
Para ver además la información relacionada con la calidad de código de la ejecución
de una build, podemos utilizar los diferentes informes que se incluyen en las guías de
proceso de MSF for Agile y MSF for CMMI. El informe “Build Summary” (http://bit.ly/qSTmcz) muestra información
detallada sobre la ejecución de las Builds en Team Foundation. En este informe es
posible ver, además del resultado de la ejecución de la build, información relacionada
con el resultado de la ejecución de las pruebas unitarias que se han realizado en el
build, la cobertura de código de las mismas y el código adicionado en cada ejecución.
Figura 16 - Ejemplo del informe “Build Summary”
Más allá de los valores que se muestran en este informe; se recomienda utilizarlo
para estudiar la evolución de nuestro código. Por ejemplo, la siguiente imagen
significa:
En las dos primeras ejecuciones no estaba habilitada la Cobertura de
Código. Vemos que hay un cero de CC.
En la tercera ejecución solo se pasó correctamente un tercio en la ejecución
de las pruebas unitarias.
En la quinta ejecución se bajó el porcentaje de Cobertura de Código a un
97%. También vemos que hay bastante código “nuevo” y “modificado” en
la aplicación, esto seguramente ha afectado a la Cobertura de Código.
20128
*-
Cla
udio
V
arga
s
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
170 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
En las últimas ejecuciones hay muy “poco código nuevo”, es probable que
estas acciones sean de estabilización.
Figura 17 - Evolución de la calidad de código en “Build Summary”
Otra forma de analizar y mostrar la información sobre el progreso de nuestra aplicación es utilizar el informe “Build Quality Indicators” (http://bit.ly/nEkPuO).
Este informe nos presenta la misma información que el informe anterior, pero en una
línea de tiempo donde podemos ver cómo evolucionan los párametros de calidad
durante el avance de nuestra aplicación.
Figura 18 - Build Quality Indicators.
*
-
09/0
8/20
13
Con
teni
do
lic
enci
ado
a:
Cla
udio
Var
gas
A
lejo
s c
laud
iocv
a@ho
tmai
l.com
Calidad 171
La imagen anterior muestra las ejecuciones de la definición de build “4.2.1 Zoo
DEV CI” para el día 21 de septiembre del 2011, desde la build número 1 hasta la build
número 7. Si analizamos cada uno de estos pasos con el ejemplo del Zoo veremos lo
siguiente.
1. Diseño inicial de la aplicación. Cuatro Unit Tests ejecutados
correctamente. No hay Cobertura de código configurada.
2. Se ha agregado un código, Code Churn = 21. Los demás parámetros siguen
igual.
3. Se han incorporado ocho nuevas pruebas unitarias que fallan en la
ejecución. Estamos en el paso RED de TDD, creando pruebas pero sin
implementar las mismas. La CC está al 100%. El Code Churn indica que ha
habido mucho movimiento en el mismo.
4. Se ha implementado el código necesario para pasar las pruebas. Con poco
código (Code Churn) en los SUT (Subject Under Test) se han
implementado estas pruebas.
5. Se ha implementado la validación de horarios para el cierre del Zoo. Se han
agregados nuevas pruebas que pasan correctamente, pero la CC baja al
97%. Es necesario ver qué punto de la aplicación no se prueba
correctamente.
6. Se han agregado dos pruebas unitarias para llegar al 100% de CC.
7. Se ha habilitado el análisis de código estático con lo que no varían los
porcentajes de la calidad.
Si se conoce el contexto de trabajo y las diferentes acciones que se realizan en el
mismo, este tipo de informes nos pueden ayudar a analizar el progreso de la calidad de
nuestra aplicación.
Los siguientes escenarios pueden servir de ejemplo para analizar este gráfico.
Ha crecido el número de nuevas pruebas unitarias y las mismas fallan.
Este caso es similar al ejemplo anterior. Si el equipo hace TDD, es probable que se
hayan definido una serie de pruebas unitarias pero que no se hayan implantado las
mismas. Esto se convertiría en un problema si, con el tiempo, la cantidad de pruebas
unitarias que fallan no disminuye.
El número de pruebas unitarias es el mismo y ha crecido el número de
pruebas unitarias que fallan.
20128
-
Cla
udio
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
licen
ciad
o
a:
172 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Si en una build hay 20 pruebas unitarias que pasan correctamente y en la siguiente
ejecución hay 12 pruebas unitarias que pasan correctamente y 8 que fallan, es momento
de ver qué código se ha cambiado entre ambos estados para averiguar qué ha
ocasionado el fallo. Este punto lo veremos en detalle en “Team Build: Analizando el
detalle de la ejecución de un Build.”.
Entre 2 Builds ha subido mucho el Code Churn y no ha cambiado la
Cobertura de código.
El sentido común nos dice que si agregamos código nuevo sin sus pruebas unitarias
correspondientes, la cobertura de código total de una solución debería bajar. Existen
ocasiones donde esto no es así, por ejemplo cuando trabajamos con herramientas de
tipo DSL que generan código automáticamente. Estas herramientas, por lo general,
para evitar que el código generado sea procesado por el análisis de cobertura de código,
decoran a los miembros generados con el atributo [ExcludeFromCodeCoverage] (http://bit.ly/pDFn7N).
No es posible visualizar la barra de ejecución de pruebas unitarias en
una build.
Esto sucede cuando una compilación no es exitosa. Al no poder compilar la
solución o el proyecto, tampoco es posible ejecutar las pruebas unitarias definidas en el
mismo.
En las siguientes páginas veremos un poco más de detalle sobre cómo interpretar y
extender la información que se genera durante la ejecución de Team Build.
2.3.- Opinión: ¿Realmente de qué sirve la cobertura de
código?
El porcentaje de Cobertura de Código (CC) puede ser un dato engañoso. Tener un
100% de CC solo asegura que nuestro código está siendo ejecutado por una o más
pruebas unitarias, pero no asegura que las pruebas unitarias sean correctas. Es muy
fácil dejarse engañar o caer en la trampa de buscar un 100% de CC para pensar “mi
aplicación tiene una calidad excelente”.
Se recomienda intentar mantener un porcentaje de CC por encima del 60%. Sin
embargo, lo más importante es estar atento a las variaciones de la misma.
Por ejemplo, supongamos que durante el desarrollo de una aplicación, nuestras
pruebas unitarias nos dan un CC entre 70% y 75%. Pero en un determinado momento,
vemos que la cobertura de código cae al 40%, esto es un indicador que algo raro ha
pasado.
Si analizamos la ejecución de la build con el 40% de CC, vemos que, además, el
Code Churn ha subido bastante. Entramos más en detalle y descubrimos que como
parte de esta build se ha compilado el código fuente de un set de controles gráficos que
hemos comprado para el desarrollo de la aplicación.
Si nos basamos en la premisa de que el soporte y mantenimiento de esos controles
son de la empresa a la que se los hemos comprado, no tiene sentido tener el Source
*
Cla
udio
V
arga
s
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
licen
ciad
o
a:
Calidad 173
Code de los mismos en nuestro repositorio. Pero por otro lado, tenemos que cumplir
con una serie de reglas de auditoría que así lo requieren.
En este momento hay que tomar una decisión, o decoramos todo el código de esta
suite de controles con el atributo [ExcludeFromCodeCoverage] o tal vez, lo mejor sea
agregar el SC de esta suite, pero en una rama diferente de nuestra aplicación (ver en el
capítulo 2 sobre referencias y controles externos).
Lo importante en este caso, no obsesionarse con un por un porcentaje muy alto de
CC, sino más bien analizar los cambios en el mismo para detectar factores externos que
puedan afectar a nuestro desarrollo.
2.4.- Team Build: Analizando el detalle de la ejecución de
un Build.
Hemos visto cómo analizar el progreso de una aplicación en base al histórico de las
Builds de la misma. En esta sección veremos qué información ofrece el detalle de una
build. La siguiente imagen muestra el formulario con los detalles de ejecución de una
build. En la misma podemos encontrar las siguientes secciones:
Información de la Build. Este apartado contiene:
o El nombre de la Build.
o La calidad de la misma.
o El tiempo total de ejecución.
o Accesos directos para acceder al log de ejecución y al directorio
donde se almacenan los ensamblados generados como resultados
de la build.
o Un gráfico comparativo con los tiempos de ejecución de las Builds
anteriores.
Usuario y fecha en que se lanzó la Build.
Un resumen con:
o Warnings y Errores de compilación.
o La cantidad de proyectos compilados.
o La cantidad de Unit Tests ejecutados y el porcentaje de éxito de
los mismos.
o El porcentaje de Cobertura de Código.
-
Cla
udio
V
arga
s
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lice
ncia
do
a:
174 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Los ChangeSets que se han acumulado desde la ejecución de la build
anterior.
Los WorkItems que se han acumulado desde la ejecución de la build
anterior.
Figura 19 - Formulario de detalle de ejecución de una build.
En este caso en particular, como además hemos activado la opción para que se
analice el proyecto con las reglas de análisis de código estático, si se expande la
sección “Summary”, es posible ver el detalle de los “Warnings” que se generan como
resultado del análisis de código estático.
En el caso de que se registren más de 5 Warnings, se mostrarán los 5 primeros y se
habilitará un link para acceder al log de ejecución.
Figura 20 - Warnings de compilación con la información de Code Analysis.
-*
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
licen
ciad
o
a
:
Calidad 175
En la sección siguiente podemos ver los accesos al log de compilación, la
información de las ejecucion de Unit Tests y el porcentaje de Code Coverage.
Figura 21 - Acceso a los resultados de ejecución de los Unit Tests y el porcentaje de
cobertura de código.
Otra opción que viene incluida en Visual Studio ALM es la capacidad de realizar
validaciones de arquitectura aprovechando una definición de Team Build. Cuando
utilizamos un proyecto de tipo Modeling en Visual Studio y dentro del mismo
empleamos un elemento de tipo Layer Diagram, es posible verificar que no existan
relaciones inválidas entre los diferentes elementos. Por ejemplo validar referencias
circulares o llamadas entre capas que no estén validadas.
La siguiente imagen muestra un ejemplo de un Layer Diagram con una serie de
capas asociadas a proyectos de una solución. (Este ejemplo se puede descargar y visualizar completo en mi libro titulado Visual Studio 2010, .NET 4.0 y ALM).
Figura 22 - Ejemplo de Layer Diagram.
Cuando realizamos una validación de capas, si todo va correctamente, en el panel
de Output de Visual Studio ALM tendremos un mensaje como el siguiente:
-
-
C
onte
nido
licen
ciad
o
a: C
laud
io
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
176 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
1/11/2010 5:24:44 PM: Architecture validation is starting. 1/11/2010 5:24:52 PM: Architecture validation succeeded (0 suppressed).
Pero si la validación de arquitectura encuentra una relación no definida en el
diagrama, por ejemplo que desde la capa de presentación se invoque directamente a la
capa de datos, en la ventana de output podremos ver que el proceso de validación no ha
terminado correctamente. El Output de Visual Studio muestra este mensaje:
1/11/2010 5:52:09 PM: Architecture validation is starting. 1/11/2010 5:52:15 PM: Architecture validation failed with 3 violation(s) (0 suppressed).
Además en el panel [Error List] podremos ver el listado completo de errores con la
descripción de los mismos. La siguiente figura muestra un ejemplo donde los dos
primeros errores describen una llamada inválida entre capas y el tercer error indica la
existencia de una referencia entre las capas que no debería estar definida de acuerdo
con lo que dicta la definición del Layer Diagram.
Figura 23 - Errores de validación de Layer Diagram.
Ahora bien, si modificamos una definición de Team Build para que incorpore
validaciones de arquitectura, en el resultado de ejecución de una Build podremos ver el
detalle de los errores que se han registrado.
Truco: Para habilitar las validaciones de arquitectura por defecto en una
definición de Team Build, hay que editar la definición de la Build y en la sección
Process, modificar el valor de la propiedad
[3. Advanced / MSBuild Arguments]
con el valor
[/p:ValidateArchitecture=true].
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
licen
ciad
o
a: C
laud
io
Var
gas
A
lejo
s
Calidad 177
Figura 24 - Validación de arquitectura en Team Build.
En las siguientes páginas veremos cómo es posible extender las capacidades que
posee la ejecución de Team Build para realizar tareas adicionales durante la ejecución
de una Build y mostrar información en el log de ejecución.
Durante la ejecución de una build, no solo puede realizar tareas de comprobación de
calidad, sino que también es posible realizar tareas de despliegue, como copia de
archivos, despliegue de bases de datos, etc.
Para cubrir estos escenarios de despliegue y validación, que no cubre OOTB Visual
Studio ALM, existen diferentes opciones:
Recurrir a elementos que crea y compila la comunidad, como por ejemplo TFS Build Extensions (http://bit.ly/mRUQL7).
Crear actividades personalizadas (Custom Activities) para Team Build y
editar plantillas de Team Build. Para esto recomiendo los tutoriales de
MSDN y los Posts de tipo Tutorial y HowTo que escribo frecuentemente (http://bit.ly/qVsjGd).
-
*
09/0
8/20
13
C
onte
nido
l
icen
ciad
o
a:
Cla
udio
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om
178 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
2.4.1.- Tutorial: Crear una Custom Activity para Team
Build
El siguiente tutorial muestra cómo crear una actividad personalizada para Workflow
Foundation para ser utilizada en una definición de Build de Team Build 2010.
1. Abrir Visual Studio 2010.
2. Crear un nuevo proyecto del tipo Class Library. Para este ejemplo lo
llamaremos “ElBruno.TeamBuild”.
3. Agregar las siguientes referencias al proyecto:
a. System.Activities
b. Microsoft.TeamFoundation.Build.Workflow.dll
c. %Program Files%\Microsoft Visual Studio10.0 \Common7 \IDE\
ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Build.Clien
t.dll
d. %Program Files%\Microsoft Visual Studio 10.0 \Common7 \IDE\
ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Client.dll
e. %Program Files%\Microsoft Visual Studio 10.0 \Common7 \IDE
\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.VersionCo
ntrol.Client.dll
4. Eliminar la clase “Class1.cs”.
5. Agregar un directorio llamado “Activities”
6. Agregar un nuevo elemento del tipo “Code Activity”, llamado
“DisplayInformation”.
7. En la clase definir dos parámetros para la actividad:
a. Message, el mensaje a mostrar en el Log.
b. MessageImportance, el nivel de importancia del mensaje.
8. Sobrescribir la función Execute() y utilizar la función
TrackBuildMessage() para mostrar esta información.
-
-*
Con
teni
do
lic
enci
ado
a
: C
laud
io
Var
gas
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Calidad 179
using System.Activities;
using Microsoft.TeamFoundation.Build.Client;
using Microsoft.TeamFoundation.Build.Workflow.Activities;
namespace ElBruno.TeamBuild.Activities
{
[BuildActivity(HostEnvironmentOption.All)]
public sealed class DisplayInformation : CodeActivity
{
[RequiredArgument]
public InArgument<string> Message { get; set; }
[RequiredArgument]
public BuildMessageImportance MessageImportance { get; set; }
protected override void Execute(CodeActivityContext context)
{
var textIn = context.GetValue(Message);
context.TrackBuildMessage(textIn, MessageImportance);
}
}
}
9. Compilar el proyecto. En este punto ya tenemos creada la actividad
personalizada para utilizar desde Team Build.
10. Para tener acceso a esta actividad desde el editor de Visual Studio 2010,
debemos copiar el ensamblado en el directorio de ensamblados de Visual
Studio 2010.
%Program files%\Microsoft Visual Studio 10.0\Common7\IDE
Aclaración: Esta es una forma de disponer de acceso al ensamblado desde Visual Studio, en el siguiente tutorial veremos una forma “más elegante”.
11. Una vez copiado el ensamblado ya podemos utilizar esta actividad desde
una definición de Build en Team Foundation Server 2010. Antes de
modificar la plantilla de ejecución de Builds, creamos una copia del
mismo y agregamos el ensamblado a una ubicación específica del Source
Control de TFS2010.
12. En este caso trabajaremos en las siguientes ubicaciones:
a. $/<Team Project>/BuildProcessTemplates, para almacenar las
plantillas de build.
b. $/<Team Project>/BuildProcessTemplates/CustomAssemblies,
para almacenar los ensamblados con las Custom Activities. En esta
ubicación subimos los ensamblados compilados del proyecto:
i. ElBruno.TeamBuild.dll
ii. ElBruno.TeamBuild.pdb
*-
09/0
8/20
13
C
onte
nido
li
cenc
iado
a
: C
laud
io
V
arga
s
A
lejo
s
clau
dioc
va@
hotm
ail.c
om
180 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 25 - Ubicación y ensamblados para Team Build.
13. Desde la ubicación de los templates de Team Foundation Server 2010,
usualmente en “$/<Team Project>/BuildProcessTemplates”, debemos
copiar el archivo “DefaultTemplate.xaml” al directorio
“BuildProcessTemplates”, renombrando el mismo con el nombre
“SampleTemplate.xaml”.
14. Una vez subidos todos los archivos, debería quedar similar a la siguiente
imagen:
Figura 26 - Plantillas de Build.
15. Creamos una definición de Build, en este caso que compila el proyecto de
Zoo.
16. A continuación modificaremos la plantilla de build que utiliza esta
definición. Para este ejemplo, hemos creado una build llamada “4.2.4.1
Custom Activity Dev MB”.
-*
C
onte
nido
li
cenc
iado
a
: C
laud
io
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Calidad 181
17. Editamos la definición de la build y en la sección “Process” modificaremos
el Build Template con el que trabaja la build.
18. Seleccionamos “New” y en el formulario de configuración seleccionamos
el archivo “SampleTemplate.xaml”.
19. Lanzamos una build para ver que la misma funcione correctamente.
Figura 27- Build Complete.
20. En este punto debemos editar la plantilla de ejecución de la Build para
utilizar la actividad que hemos creado en los primeros pasos.
21. Editamos la plantilla “SampleTemplate.xaml”.
22. Dentro de la ToolBox de Visual Studio agregamos una nueva sección
llamada “Custom Build Activities”.
23. Escogemos la opción de agregar nueva actividad, seleccionamos el
ensamblado compilado de nuestra actividad y la añadimos a la barra de
herramientas.
24. Agregamos una actividad de este tipo al inicio del proceso de la Build y
como tiene una propiedad pública requerida veremos que el editor marca
un error de diseño:
Figura 28 - Agregar Custom Activity.
-
-*
Cla
udio
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
li
cenc
iado
a:
182 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
25. Debemos completar la propiedad “Message”. Por ejemplo cambiamos la
importancia por el valor “High”. El mensaje posee el siguiente valor:
“Start Build con Valentino”.
26. Protegemos la plantilla “SampleTemplate.xaml” en el Source Control.
27. A continuación modificamos el Build Controller que orquesta la ejecución
de las builds.
28. Seleccionamos el nodo “Builds” desde el Team Explorer, desplegamos el
menú contextual y seleccionamos la opción “Manage Build Controllers”.
29. Desplegamos las propiedades del mismo y configuramos la opción
“Version control path to custom assemblie” indicando el path donde
hemos subido los ensamblados de la Custom Activity.
Aclaración: esta acción reinicia el Build Controller, con lo que éste no
estará disponible inmediatamente.
30. Lanzamos una nueva build del mismo tipo y podremos ver el mensaje
personalizado en el log de ejecución de dicha build.
Figura 29 - BuildLog con el mensaje personalizado.
2.4.2.- Tutorial: Incluir el análisis de estilo de código
StyleCop en Team Build
El siguiente tutorial explica cómo modificar una definición de Team Build 2010
para que la misma incluya el análisis de estilo de código con StyleCop. StyleCop es una extensión disponible (http://bit.ly/niG5Y4) que analiza la estructura de los archivos de
código fuente de una aplicación y alerta sobre los errores en ella. Además usaremos la
última versión de TFS Build Extensions.
*-
C
onte
nido
lic
enci
ado
a
: C
laud
io
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Calidad 183
Para este ejemplo emplearemos el código del proyecto de Zoo que hemos creado a
lo largo del capítulo.
1. Lo primero es organizar la estructura de directorios con el fin de poder
tener los ensamblados requeridos para la definición personalizada de Team
Build. Esta definición será la que se encargue de aplicar las reglas de
análisis de código con StyleCop.
2. Creamos dentro del SCC una estructura con varias carpetas:
a. Build: En este folder se almacenarán los ensamblados propios que se
utilizan durante el proceso de build. Por ejemplo, las dlls que se
distribuyen con TFS Build Extensions.
b. Src: En este folder se almacena el código fuente de la solución
Figura 30 - Directorios en el Source Control
para la definición de Team Build.
3. En la carpeta “build” debemos copiar una Template de Team Build desde
la ruta “$/BuildProcessTemplates/DefaultTemplate.xaml”.
4. Renombramos la misma como “BuildTemplateWithStyleCop.xaml”.
5. A continuación debemos modificar la definición del Build Controller para
que use el directorio configurado en el paso anterior como repositorio de
custom assemblies para la ejecución de la Build.
6. Seleccionamos el nodo “Builds” en el Team Explorer.
7. Desplegamos el menú contextual y seleccionamos la opción “Manage
Build Controllers”.
8. Seleccionamos el Build Controller con el que trabajaremos y editamos las
propiedades del mismo.
*
Con
teni
do l
icen
ciad
o
a: C
laud
io
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
184 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
9. Modificamos la propiedad “Version custom control path to custom
assemblies” para que apunte al directorio “build” que creamos en el paso 2.
Figura 31 - Modificación de Build Controller.
Nota: Encontrarás un ejemplo completo de extensibilidad y personalización de Team Build aquí (http://bit.ly/qhhdax).
10. A continuación debemos crear un nuevo proyecto de tipo Class Library en
Visual Studio 2010 en el directorio “builds”. Este proyecto será utilizado
para poder editar la definición de build.
11. Dentro del proyecto que hemos creado debemos eliminar la clase
“Class1.cs”. A continuación agregamos una referencia al fichero
“BuildTemplateWithStyleCop.xaml” utilizando la opción “Add As Link”
al proyecto.
El proyecto se crea en su propia carpeta dentro del SCC, con lo que
tendremos que subir un par de niveles hasta llegar al fichero
BuildTemplateWithStyleCop.xaml.
12. Luego debemos agregar las referencias a todos los ensamblados que están
en el folder Build, los que hemos descargado desde Tfs Build Extensions (http://bit.ly/mRUQL7).
13. A continuación editamos el archivo BuildTemplateWithStyleCop.xaml.
Esta acción abre el editor de Workflow Foundation.
-
Con
teni
do
lic
enci
ado
a
: C
laud
io
Var
gas
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
09/
08/2
013
Calidad 185
14. En la ToolBox de herramientas agregamos una nueva sección llamada
“TFS Build Extensions”. Dentro de ella añadimos los ensamblados que
hemos almacenado en el directorio build; esta acción agrega nuevas
actividades de WF. La sección quedará:
Figura 32 - ToolBox con actividades para Team Build.
15. Editamos el proceso de WF y accedemos hasta la compilación de cada
proyecto. Para esto debemos seguir la siguiente ruta de edición:
a. Secuence >
b. Run on Agent >
c. Try Compile, Test, and Associate ChangeSets and Work Items >
d. Secuence >
e. Compile, Test, and Associate ChangeSets and Work Items >
f. Try Compile and Test >
g. Compile and Test >
h. For Each Configuration in BuildSettings.PlatformConfigurations >
i. Compile and Test for Configuration >
j. If BuildSettings.HasProjectsToBuild >
k. For Each Project in BuildSettings.ProjectsToBuild >
-
-
Con
teni
do
l
icen
ciad
o
a
: C
laud
io
V
arga
s
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
186 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
l. Try to Compile the Project >
m. Compile the Project
16. Tras la actividad “Run MSBuild for Project” debemos agregar una nueva
secuencia a la que llamaremos “Run StyleCop Analysis”.
17. En la secuencia añadimos las siguientes variables, con los tipos de cada
una, con el Scope propio de la secuencia
a. StyleCopFiles – iEnumerable<string>
b. StyleCopSettingsFile – string
c. StyleCopResults – bool
d. StyleCopViolations - int32
18. Dentro de la secuencia incluimos dos actividades del tipo
“WriteBuildMessage” para indicar el inicio y el fin del proceso de análisis
con StyleCop.
19. Debemos cambiar el nombre de las mismas por
a. “Start StyleCop Analysis”
b. “Finish StyleCop Analysis”
20. En cada una de ellas se mostrará un mensaje con el mismo nombre que la
actividad correspondiente.
21. Después del primer mensaje agregamos una actividad del tipo
“FindMatchingFile” para identificar los archivos de C# (con extensión .cs)
sobre los que se realizará el análisis.
22. En esta actividad debemos configurar las siguientes propiedades
a. Display Name = Find CS files for source analysis
b. Result = StyleCopFiles
c. MatchPattern = String.Format("{0}\**\*.cs", BuildDirectory)
23. A continuación debemos agregar una actividad del tipo “Assign” para
ubicar el archivo de Settings de StyleCop.
24. En esta actividad debemos configurar las siguientes propiedades
a. Display Name > Assign StyleCop Settings File
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lice
ncia
do
a: C
laud
io
V
arga
s
Ale
jos
Calidad 187
b. To > StyleCopSettingsFile
c. Value>String.Format("{0}\Settings.StyleCop",
localProject.Substring (0, localProject.LastIndexOf("\")))
25. En este momento agregamos una actividad del tipo “WriteBuildMessage”.
26. En la misma configuramos las siguientes propiedades:
a. Display Name > Start StyleCop Analysis using settings file
b. Importance>Microsoft.TeamFoundation.Build.Client.Build
MessageImportance.High
c. Message > String.Format("About to run StyleCop with [{0}]",
StyleCopSettingsFile)
27. Agregamos una actividad del tipo “StyleCop” que es la que realiza el
análisis de código.
28. En la misma configuramos las siguientes propiedades:
a. Display Name > Run StyleCop Analysis
b. SettingsFile > StyleCopSettingsFile
c. SourceFiles > StyleCopFiles.ToArray()
d. Succeeded > StyleCopResults
e. TreatViolationsErrorASWarnings > True
f. ViolationCount > StyleCopViolations
Un detalle importante es poner en “True” la propiedad
“TreatViolationsErrorASWarnings” para que los errores que se
encuentren en el proceso de análisis de código se muestren en el log como
Warnings.
29. A continuación agregamos una actividad del tipo “WriteBuildMessage”.
30. En la misma configuramos las siguientes propiedades:
a. Display Name > Display StyleCop Analysis Results
b. Importance>Microsoft.TeamFoundation.Build.Client.BuildMessag
eImportance.High
-
*-
09/0
8/20
13
Con
teni
do
licen
ciad
o
a: C
laud
io
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
188 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
c. Message > String.Format("StyleCop Successed:{0} with {1}
violations", StyleCopResults, StyleCopViolations)
31. Protegemos los archivos modificados en TFS. El proceso se muestra en la
siguiente figura:
Figura 33 - StyleCop en WF
32. A continuación crearemos una nueva definición de Team Build para el
proceso modificado en los pasos anteriores.
33. Creamos una nueva build y configuramos el Workspace para que procese
una solución. Para este ejemplo trabajaremos con una build llamada “4.2.1
Zoo Dev StyleCop CI”.
34. Accedemos a la sección “Process” y desplegamos la sección “Build
Process Template”.
-
*
Cla
udio
V
arga
s
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
Calidad 189
35. Presionamos el botón “New” y seleccionamos el template que hemos
modificado en los pasos anteriores, “BuildTemplateWithStyleCop.xaml”.
La siguiente imagen muestra la definición:
Figura 34 - Definición de Team Build con el nuevo Template.
36. Guardar la definición de Team Build.
37. Lanzar una nueva compilación con esta build y esperar a que termine la
ejecución de la misma.
38. Una vez finalizada, si el código se ha compilado correctamente, en el log
de ejecución de la build es posible ver información relacionada con el
análisis de StyleCop.
Figura 35 - BuildLog con información de StyleCop.
-
--
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3 C
onte
nido
lic
enci
ado
a:
190 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
2.5.- Opinión: ¿Qué tipos de definiciones de Build debo
crear para mi aplicación?
La respuesta a esta pregunta es casi siempre otra pregunta:
¿Qué es necesario validar para que un equipo funcione correctamente?
Sin conocer mucho la forma de trabajo y el entorno de trabajo de un equipo
concreto, podemos afirmar que se necesita una build de integración continua (http://bit.ly/qv76ED) que asegure que el código de la aplicación compila
correctamente, pasa las pruebas unitarias, mide la cobertura de código, etc. Esta es la
primera recomendación, pero existen situaciones donde hay que tener como mínimo
una definición de build más.
Por ejemplo, supongamos que estamos trabajando en un proyecto donde el tiempo
de compilación completo de una build es de 30 minutos aproximadamente, y no
tenemos mucha capacidad de hardware para un servidor de build. En este caso, en lugar
de utilizar una configuración con integración continua, podemos utilizar la
configuración de integración frecuente que posee Team Build. La misma nos permite
emular un escenario de CI, pero con un tiempo mínimo de ejecución entre cada build.
La siguiente imagen muestra un ejemplo de FI cada 35 minutos.
Figura 36 - Integración frecuente cada 35 minutos.
Para este caso nos aseguramos que el servidor de compilación tendrá “un respiro”
entre cada ejecución de build. Pero es posible que si se da la siguiente casuística no
tengamos una prueba de todo el código del equipo:
17:50, Adrián protege código y se lanza una ejecución de build.
17:55, Bruno protege código, no se lanza una build al ya estar en ejecución
una anterior desde hace 5 minutos.
17:58, Valentino protege código, no se lanza una build al ya estar en
ejecución una anterior desde hace 8 minutos.
-
C
onte
nido
lic
enci
ado
a:
Cla
udio
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
Calidad 191
Este equipo de trabajo no puede garantizar que todo su código está integrado en
todo momento, ya que los cambios de Bruno y Valentino, quedan fuera de la
compilación.
Una solución para este caso, es crear una nueva definición de build basada en una
agenda que compile todo el código por la noche, por ejemplo a las 03:00 AM. De esta
forma, siempre al llegar por la mañana, el equipo se asegura que todo el código ha sido
compilado por la noche.
Otra duda que puede surgir en el escenario anterior es la siguiente:
¿Cuántas definiciones de build se deben tener, una para toda la solución, una por
branch, etc.?
En el ejemplo anterior y asumienod que el equipo de trabajo está definiendo como
mínimo dos ramas para trabajar; MAIN y DEV, lo aconsejable sería tener cuatro
definiciones de build. A saber:
Zoo DEV CI
Zoo DEV NB
Zoo MAIN CI
Zoo MAIN NB
Cada una de estas definiciones de build cumple con un objetivo específico. En este
caso, asegurar que todo el código que se modifique en las ramas DEV y MAIN sea
procesado por una build.
Ahora bien, para no tener que descargar todo el ramal de código fuente desde el
repositorio de código fuente, cada Build solo descarga la rama correspondiente, o DEV
o MAIN.
Además cada build compila la solución que está dentro de la rama. La siguiente
imagen muestra este esquema.
Figura 37 - Definiciones de Build por Branches.
*-
C
onte
nido
li
cenc
iado
a
: C
laud
io
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
192 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Lamentablemente para esto no hay reglas escritas. Pueden existir tantas definiciones
de build como se nos ocurran. Lo importante en todo momento es intentar organizar las
mismas de manera tal que sirvan a un propósito para el equipo de desarrollo, como por
ejemplo “compilar y validar la calidad”, o “compilar y desplegar en el entorno de
integración”.
2.6.- Sugerencia: Formato nombres para las definiciones de
Builds
A priori, el tema de los nombres de las Builds es algo se podría obviar en este libro.
Sinn embargo, tras encontrarnos con numerosos nombres de Builds que no aportan
nada, creemos que es necesario dar un par de pincelas sobre este tema.
Por ejemplo, si definimos el nombre de una build como “BUILD ZOO”, es evidente
que el proceso de Team Build compilará algo relacionado con un Zoológico. Pero no
nos permite saber si es una definición de Integración Continua, o si compila y
despliega la aplicación, por poner un ejemplo. Tampoco debemos caer en el otro
extremo, por ejemplo asignándole el siguiente nombre:
“Build que compila la capa de servicios de Zoo sin Tests todos los días a las 04:00
AM”
Lo mejor es tener un nombre descriptivo que nos ayuda a asociar rápidamente el
resultado de la build (success/fail) con el proceso que se ha ejecutado. Por lo general el
siguiente formato es suficiente:
[$Aplicación].[$Branch].[$Detalle de Build].[$Tipo de compilación]
El uso de un punto “.” como el separador de las secciones del nombre de la Build es
una cuestión de gusto personal. Cada sección tiene el siguiente significado:
Aplicación. Define la aplicación que se está compilando. Puede ser un
acrónimo de tres letras. Por lo general no debería ser una palabra de más de
seis letras.
Branch. Define la rama que se está compilando.
Detalle de la Build. Define qué tipo de solución o de proyectos se están
compilando.
Tipo de Compilacion. Define el tipo de compilación con los siguientes
valores:
o CI. Compilación para integración continua.
*
-
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lic
enci
ado
a
:
Calidad 193
o FI. Compilación para integración frecuente.
o NB. Compilación nocturna.
o MB. Compilación manual.
Con estos valores ya podemos tener una guía mínima para identificar nuestras
builds. Veamos algunos ejemplos.
Zoo.Dev.Complete.CI. Esta build compila la aplicación Zoo en la rama
DEV lanzando las builds con cada CheckIn.
Zoo.Dev.Complete.NB. Esta build compila la aplicación Zoo en la rama
DEV lanzando la build cada noche.
Zoo.Dev.Services Deploy Test.MB. Esta build compila y despliegua la
capa de servicios de la aplicación Zoo en la rama DEV en un entorno de
Test. La build se lanza manualmente.
Zoo.Main.Complete.CI. Esta build compila la aplicación Zoo en la rama
MAIN lanzando las builds con cada CheckIn.
Zoo.Main.Complete.NB. Esta build compila la aplicación Zoo en la rama
MAIN lanzando la build cada noche.
La sección de las builds del Team Explorer quedaría:
Figura 38 - Definición de Builds en Team Explorer.
*
09/0
8/20
13
Con
teni
do
lic
enci
ado
a:
Cla
udio
Var
gas
Ale
jos
cl
audi
ocva
@ho
tmai
l.com
194 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Nota: En la versión 2010 de Team Foundation, una de las grandes carencias es
la falta de algún mecanismo que permita agrupar las builds por algún criterio
lógico. Cuando tienes 20 o más definiciones de build, el árbol del Team Explorer
puede quedar poco organizado.
Existe una extensión para Visual Studio llamada Inmeta Build Explorer (http://bit.ly/roTvY2), que agrega una nueva rama al Team Explorer donde
agrupa las definiciones de build realizando un Split por el carácter punto “.”.
El ejemplo anterior quedaría como sigue:
Figura 39 - Definición de Builds en Team Explorer.
2.7.- Team Build: ¿Dónde almacenar los ensamblados
comunes de las Builds?
En los tutoriales de este capítulo hemos visto que para que una definición de Team
Build funcione hay que tener un par de cosas en cuenta.
Por un lado, la ubicación de las plantillas de Team Build que pueden estar
distribuidas por nuestras ramas del repositorio de Source Control.
Por otro lado, una ubicación para los ensamblados comunes que se
configura a nivel de Build Controller.
Como una definición de Team Build puede utilizar cualquier plantilla con la
primera variante, el problema viene dado con la ubicación de los ensamblados comunes
que puede necesitar una build.
-
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
licen
ciad
o a
: C
laud
io
V
arga
s
Ale
jos
Calidad 195
El escenario ideal, mostrado en la siguiente figura, presenta una relación 1 a 1 entre
un Team Project y un Build Controller. Como cada Build Controller está configurado
para que utilice los ensamblados comunes de cada Team Project, entonces no supone
ningún problema.
Figura 40 - Ejemplo de un Build Controller por Team Project.
En numerosas ocasiones, varios Team Projects tenían que compartir un único Build
Controller tal y como se aprecia en la siguiente imagen.
Figura 41 - Build Controller compartido por varios Team Projects.
20128
-
*-
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
li
cenc
iado
a:
196 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
En este caso es muy importante definir qué ruta de almacenamiento de ensamblados
comunes para la compilación se utilizará además de coordinar los esfuerzos entre
ambos Team Projects de forma que, cuando se necesite crear definiciones de Build las
cuales requieran ensamblados especiales, no se generen problemas.
¿Qué problemas nos podríamos encontrar? Pues, por ejemplo, que ambos equipos
incorporen métricas de StyleCop en sus builds, pero que el Team A esté trabajando con
StyleCop 1.3.1.1 y el Team B con StyleCop 1.3.1.2. Si este es el caso, uno de los dos
equipos tendrá que cambiar de versión de StyleCop.
Por último, una sugerencia para la ubicación de plantillas y ensamblados.
$\<Team Project>\BuildProcessTemplates. En esta ubicación almacenar
todas las plantillas de Team Build que se utilicen.
$\<Team Project>\BuildProcessTemplates\CustomAssemblies. En esta
ubicación almacenar todos los ensamblados comunes que se utilicen para la
ejecución de Team Build.
3.- TESTING FUNCIONAL
Tras haber visto algunos elementos que nos ayudan a mejorar la calidad de nuestro
código, volvamos a una de las figuras iniciales de este capítulo. En ella se indicaba que
para llevar adelante un requerimiento, en este caso una User Story, era necesario definir
la implementación utilizando Tareas y definir los criterios de prueba que se tienen que
cumplir para dar como válida la User Story.
Figura 42 - Implementación y pruebas de una User Story.
-
-*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a: C
laud
io
Var
gas
Ale
jos
Calidad 197
Esta segunda rama es la que Visual Studio ALM cubre con Microsoft Test
Manager: la capacidad de definir qué criterios de prueba se deben seguir para dar como
válido un Requerimiento o una User Story.
Esta sección se tiende a subestimar en los desarrollos de software cuando en
realidad es uno de los pilares para asegurar la calidad en un proyecto. Uno de los
problemas, es que a medida que la aplicación avanza, los requerimientos comienzan a
madurar y con esto, se hace necesario actualizarlos en cada nueva iteración para que
reflejen realmente el estado de nuestra aplicación.
Desde el punto de vista de control de calidad, los escenarios se pueden complicar un
poco. En la siguiente imagen vemos cómo en la iteración 1 la User Story A, se probaba
con los Test Cases 1, 2 y 3, y los mismos pasaban al 100%. Pero luego al llegar a la
iteración 2, hubo que cambiar la User Story A y se generó la versión A1, con
modificaciones sobre los Test Cases existentes y con un nuevo Test Case. Después de
la ejecución del primer set de pruebas, vemos que sólo el 50% de los Test Cases pasan
correctamente.
Figura 43 - Errores en nueva iteración.
*
-
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
Cla
udio
V
arga
s
Ale
jos
198 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Uno de los peores errores que podemos cometer en este momento es pensar que
hemos bajado la calidad de nuestro producto. Si analizamos los cambios y el progreso
veremos que en realidad estamos trabajando con una nueva User Story (A1) y que para
dar el OK a la misma, hay un nuevo Test Case y una serie de Tests que hemos
aprovechado de la iteración anterior.
Esto es muy similar a lo que hacemos cuando refactorizamos una porción de código
o una porción de un Unit Test. En este caso, necesitamos volver a asegurar la calidad
de nuestro código, pero esto no significa que la calidad del mismo haya bajado.
Como hemos advertido en varias ocasiones en el capítulo 3, es necesario comunicar
rápidamente al cliente o analista funcional este cambio para que sea consciente del
impacto del mismo.
3.1.- Opinión: ¿Cómo gestionar los errores funcionales en
mi equipo de desarrollo?
Antes de responder, pongamos un par de premisas:
El cliente o los analistas funcionales son los encargados de crear o de
validar los Tests Funcionales. Es ideal que esta figura trabaje codo a codo
con el equipo de desarrollo para agilizar la solución de problemas.
Antes de dar por válida una iteración se deben ejecutar todos los Tests
funcionales asociados a las User Stories cerradas en la misma.
Y ahora volvamos a la pregunta en su modo simplificado;
¿Qué @@#$@ hago con los errores?
Una opción es crear WorkItems de tipo Bug para que sean parte de la iteración y
que el equipo de desarrollo los pueda procesar antes de finalizar la misma. Pero, por lo
general, más del 50% de los bugs no son bugs propiamente dichos, sino más bien una
mala interpretación de una User Story. Esto no es código mal escrito, sino algo más
peligroso, ya que debido a una mala comunicación, estamos realizando un “re-trabajo”
que no gusta a nadie.
En estos casos, simplemente comentando el error durante la reunión diaria, es
posible que nos ahorremos la burocracia de la gestión de un WorkItem y además,
seguramente nos sirva para aclarar esa parte de funcionalidad de la aplicación que no
estaba bien definida para todos los integrantes.
¡Cuidado!, aquí comienza nuevamente el ciclo iterativo. Ya que si una User Story
no estaba clara para el equipo, es necesario volver a detallar la misma y seguramente
será necesario volver a definir los Test Cases que aseguren que está completa, volver a
definir los ciclos de prueba, etc.
*-
Cla
udio
Var
gas
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
C
onte
nido
lice
ncia
do
a:
Calidad 199
Nota: Cuando trabajamos con Bugs en Team Foundation, una de las razones
para cerrar un Bug es que el problema reportado no es Bug, sino que se debe al
diseño original de la aplicación.
Si el Bug ha sido reportado por un cliente final, es muy probable que los
diseños con los que estamos trabajando no se correspondan con la realidad de la
funcionalidad que requiere nuestro cliente. Es momento de sentarse con el cliente
para afinar las User Stories.
Si por el contrario el Bug ha sido reportado por el mismo analista funcional que
hizo el diseño original, es muy probable que este analista sufra un trastorno de
personalidad que no le permita conciliar su perfil de analista y de Tester en su
cabecita. Es momento de buscar un buen psicólogo para nuestro querido analista.
3.2.- Microsoft Test Manager
Microsoft Test Manager (MTM) es el producto de la familia de Visual Studio ALM
que nos permite completar el abanico de pruebas con todos los elementos que no se
cubren en Visual Studio. Pensemos que MTM es una herramienta pensada para Testers,
y esa gran diferencia hizo que no se incluyeran las capacidades de Testing dentro del
IDE de Visual Studio.
Con MTM podremos realizar un ciclo de completo de pruebas, desde el diseño
hasta la ejecución las mismas. También podremos definir diferentes entornos de
pruebas, definir qué tipo de información queremos automatizar para recolectar durante
la ejecución de una prueba y muchas otras funcionalidades.
Un detalle interesante sobre MTM es que además de las pruebas manuales,
incorpora la novedad de la ejecución de pruebas automatizadas, es decir sin
intervención de un usuario o Tester.
La siguiente figura muestra cómo, en la sección superior de MTM, es posible
seleccionar las diferentes fases de ejecución de las pruebas:
Plan. Permite definir la planificación del plan de pruebas y las
configuraciones que se utilizarán durante el mismo.
Test. Facilita ejecutar el plan de pruebas utilizando cada una de las
configuraciones definidas. Permite además grabar el resultado de la
ejecución de las pruebas.
Track. Permite realizar un seguimiento del plan de pruebas y medir el
progreso de las mismas. En esta sección es en la que podremos ver la
calidad del software que estamos probando.
Organize. Permite definir parámetros generales de configuración y de
seguimiento.
*
-
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
200 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Figura 44 - Microsoft Test Manager.
A partir de los Tests Cases definidos para un Requisito o User Story es posible crear
un plan de pruebas. También es posible definir diferentes configuraciones de pruebas
donde se ejecutará una aplicación.
Por ejemplo, cuando se trabaja con una aplicación web, es recomendable realizar las
pruebas en diferentes navegadores. Sobre esta base sería posible crear configuraciones
como las que muestra la siguiente tabla.
Tabla 1 - Configuraciones para un plan de pruebas
Sistema Operativo Navegador
Windows 7 Internet Explorer
Windows 7 Firefox
Windows 7 Chrome
Windows 8 Developer Preview Internet Explorer 10 Beta Windows Mode
Windows 8 Developer Preview Internet Explorer 10 Beta Metro Mode
Una vez definido el plan de prueba y las configuraciones con las que trabajaremos,
es posible comenzar a ejecutar dicho plan. Cuando MTM cambia al modo de ejecución
de pruebas, se convierte en una aplicación de tipo barra lateral dentro de Windows que
nos permite ejecutar aplicaciones en el escritorio restante.
De acuerdo a las configuraciones que se hayan definido para la ejecución, también
es posible grabar un video con el paso a paso de ejecución de las pruebas, adjuntar el
proceso de pruebas a una aplicación para guardar datos de depuración histórica
(IntelliTrace) de la misma, guardar valores del sistema, etc.
Figura 45 - MTM en modo de ejecución de pruebas.
*
-
09/0
8/20
13
Con
teni
do
l
icen
ciad
o
a
: C
laud
io
V
arga
s
A
lejo
s
cla
udio
cva@
hotm
ail.c
om
Calidad 201
Tras la ejecución de un plan de pruebas es posible analizar los resultados que se han
almacenado en el mismo. En la siguiente figura vemos como para el Requerimiento 21,
se han ejecutado tres Tests Cases de los cuales dos han pasado correctamente y uno ha
fallado.
Figura 46 - Resultado de la ejecución de un plan de pruebas.
Al acceder al detalle del Test Case fallido encontramos la información para analizar
el problema que hizo fallar el test:
Usuario y fecha en la que se ejecutó el Test Case.
Entorno en el que se ejecutó el Test Case.
Detalle de cada uno de los pasos del Test Case y su resultado.
Archivos adjuntos al test case. En estos archivos pueden estar:
o El log de ejecución del test.
o El video con una grabación de las acciones del Test.
o Un archivo con la información del sistema.
o Un archivo con los datos de la depuración histórica.
o Etc.
WorkItems relacionados.
Histórico de ejecución del Test Case.
La siguiente imagen muestra el detalle de un Bug creado a partir de la ejecución de
un Test Plan. En el campo Steps to Reproduce se añade la información de los pasos del
Test Case y el resultado de ejecución de los mismos. Además en el Bug, toda la
*
Cla
udio
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a:
202 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
información relacionada del Test Case se agrega para, así, dotar de más valor a la
información que se deberá analizar después por el equipo de desarrollo.
Figura 47 - Bug creado a partir de la ejecución de un Test Case.
Microsoft Test Manager es un producto que abarca muchos aspectos relacionados
con el Testing en el desarrollo del software, por ejemplo:
Planificación de pruebas
Creación y ejecución de pruebas manuales y automáticas
Automatización de pruebas de interfaz de usuario (pruebas automáticas)
Cuando MTM se combina con la potencia de Lab Management el concepto de
Testing adopta una nueva dimensión. Lab Management utiliza Microsoft Hyper-V para
administrar y usar máquinas virtuales para la ejecución de pruebas. Visual Studio Lab
Management se integra con System Center Virtual Machine Manager (SCVMM) para:
Permitir la administración de los diferentes entornos virtuales.
Permitir la administración del almacenamiento de las máquinas virtuales,
de las plantillas de las máquinas virtuales y de otros archivos de
configuración.
-
--
Cla
udio
V
arga
s A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
lic
enci
ado
a:
Calidad 203
Los entornos virtuales son grupos de máquinas virtuales que están administradas
por Lab Management y desde los cuales es posible lanzar automatizaciones de pruebas
a partir de definiciones de planes de pruebas de MTM.
Con estas herramientas, es posible crear dinámicamente un entorno de pruebas,
lanzar una prueba automatizada a partir de una compilación y finalmente guardar toda
esta información para su posterior análisis.
Este proceso puede repetirse n-veces gracias a las capacidades de MTM de
definición de pruebas y de Lab Management de gestión de entornos de pruebas,
respectivamente.
*
Con
teni
do
li
cenc
iado
a: C
laud
io
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
205
APÉNDICE
Pensar es el trabajo más difícil que existe. Quizá esa sea la razón por la que haya tan pocas personas que lo practiquen.
Henry Ford
Las siguientes páginas son puntos que creímos que no encajaban dentro de
la estructura del libro, pero que pueden ayudar a mejorar el trabajo en equipo.
Técnicas varias
A
-
**
Con
teni
do
licen
ciad
o
a:
Cla
udio
Var
gas
Ale
jos
c
laud
iocv
a@ho
tmai
l.com
09/
08/2
013
206 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
1.- COLABORACIÓN
Todos sabemos lo importante que es la comunicación en un equipo de desarrollo.
Después de leer mucha literatura sobre AGILE, y de trabajar en muchos entornos
diferentes terminas por darte cuenta que el mejor mecanismo de comunicación es el
“cara a cara” con tus compañeros.
Pero esto no siempre es posible ya que cuando trabajas desde ubicaciones externas,
o con equipos distribuidos, es muy probable que resulte imposible este “cara a cara”.
Lo importante en estos casos es encontrar un mecanismo que permita que la
comunicación sea fluida. Skype, Lync o Live Messenger pueden ser una excelente
herramienta para lograr tener una comunicación “cara a cara virtual” con otros
integrantes de un equipo.
Además estas herramientas no solo mejoran la comunicación, sino que sirven como
un mecanismo de colaboración entre integrantes de un equipo.
Si utilizamos las Team Foundation Server Power Tools podremos ver cómo estas
herramientas nos permiten acceder a las capacidades propias de los sistemas de
mensajería para interactuar éstos.
Figura 1 - Integración con sistemas de mensajería.
La imagen anterior muestra a los participantes del Team Project “ALMBookAgile”
en el panel del Team Explorer y además las diferentes acciones que tenemos para
realizar con los mismos relacionados con el equipo de trabajo:
*
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a:
Cla
udio
V
arga
s
Ale
jos
Técnicas varias 207
Visualizar el histórico de CheckIns de este usuario.
Visualizar los Shelvesets de este usuario.
Visualizar los cambios pendientes que posee este usuario.
Cuando hemos configurado las opciones de la mensajería instantánea, podremos ver
no solo las acciones propias del trabajo en equipo con Visual Studio ALM, sino
también las propias del sistema de mensajería.
Figura 2 - Interacción completa.
¿Qué ventajas posee esto? El ver en todo momento si un usuario está disponible
para preguntarle algo o comentarle algo sobre el proyecto, referenciar acciones
realizadas en Team Foundation para aclarar dudas sobre funcionalidades de una
aplicación, etc.
La colaboración va mucho más allá de la comunicación, es además compartir
información con los integrantes de un equipo y tener los medios para poder analizar y
discutir sobre la misma.
*
-
09/0
8/20
13
C
onte
nido
lic
enci
ado
a: C
laud
io
V
arga
s
A
lejo
s
c
laud
iocv
a@ho
tmai
l.com
208 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
Nota: Wave-vs.net (http://www.wave-vs.net) es una extensión para Visual
Studio que permite trabajar en un escritorio compartido directamente sobre el IDE
de Visual Studio entre dos o más personas. Es un producto realmente potente y que
para equipos distribuidos con muchas casuísticas de Code Reviews, brinda una
alternativa muy ágil.
2.- REUNIONES
Cuando estudiaba informática, hace ya bastante tiempo, leí un artículo sobre “La correcta gestión del tiempo en las reuniones de trabajo”. En ese momento me pareció
una estupidez, ya que pensé que si dos personas o más van a dedicar parte de su tiempo
a debatir un tema, pues lo más natural es que este tiempo sea productivo para todos.
Con esa inocencia terminé la carrera y no fue hasta que comencé a trabajar, cuando me
di cuenta del gran problema que representa la mala gestión del tiempo en las reuniones.
Existen ambientes, altamente contaminados, en los que se organizan reuniones
“para todo”. Para que una reunión resulte productiva debe cumplir las siguientes
premisas:
Definir SIEMPRE un tema y una serie de puntos a tratar en una reunión.
Cada vez que Exchange procesa una cita de Outlook con un simple
“reunión de seguimiento de 10:00 a 11:00”, alguien mata un gatito en
internet.
Organizar las reuniones de manera tal que todas las personas estén
enteradas de los temas que se tratarán en la misma. Es recomendable “dar
tarea” a los asistentes de manera tal, que los que se presenten tengan algo
que aportar.
Invitar solo a la gente que deba participar en la misma. No importa si es el
subjefe de la sección y opina que “tal vez tenga algo que decir al
respecto”; si su participación no es necesaria, entonces ¡no viene!
Intentar que las reuniones no superen los 30 minutos de duración. Para esto
una persona tiene que tomar las riendas de la reunión e intentar dar por
cerrados los temas que se tratan en la misma.
Finalmente y tal vez lo más importante. Siempre cerrar las reuniones con
las conclusiones de la misma. Redactar un acta si es necesario, pero, en
cualquier caso, dejar constancia de los temas que se han tocado y las tareas
que han surgido de la reunión.
-
Cla
udio
Var
gas
A
lejo
s
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
lic
enci
ado
a:
Técnicas varias 209
Para organizar este tipo de reuniones MSF for CMMI incorpora un tipo de WorkItem llamado “Review” (http://bit.ly/nxhvn4). Este WorkItem te permite
almacenar en Team Foundation un “acta de reunión”, en el que podrás incorporar
información de los asistentes, tipo de reunión, relacionarla con Requerimientos o
Tareas que se hayan tocado en la misma, etc. Es llevar la potencia de Team Foundation
a un tema tan delicado como es el de las reuniones.
*-
09/0
8/20
13
Con
teni
do
li
cenc
iado
a: C
laud
io
V
arga
s
Ale
jos
cla
udio
cva@
hotm
ail.c
om
211
Índice analítico
A
Agile, 64, 66, 67, 77, 78, 81, 84, 89,
91, 92, 98, 100, 111, 113, 114, 120
AGILE, 70, 71, 78, 103, 104, 113, 115,
125, 128, 138, 147, 206
ALM Rangers, 21, 40, 52
ALMBookAgile, 81, 92, 98
análisis de código estático, 152, 164,
165, 166, 167, 171, 174
Assigned To, 81, 83, 86, 88, 99, 110,
123, 125
B
Branch, 22, 23, 24, 29, 37, 38, 59, 61
Branching, 21, 22, 23, 24, 25, 26, 40,
41, 42, 49, 52
Build Quality Indicators, 170
Build Summary, 169
BurnDown, 125
C
calidad de código, 154, 155, 169
Changeset, 60, 61
ChangeSets, 174, 185
CheckIn Notes, 57
checkin policies, 54
CMMI, 64, 67, 69, 77, 84, 108, 138
Code Analysis, 166
Code Churn, 171, 172
Code Coverage, 160, 166, 175
Code Reviews, 208
colaboración, 68, 71, 78, 84, 136, 206,
207
comunicación, 206, 207
control de calidad, 150, 197
Convert to Branch, 23
D
desarrollos correctivos, 32, 35, 38
**
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do
licen
ciad
o
a: C
laud
io
V
arga
s
Ale
jos
212 Trabajando en equipo con Visual Studio ALM - Experiencias reales en desarrollo de proyectos de software
desarrollos evolutivos, 32, 35, 38, 39,
52
E
elevator pitch, 104
Extreme Programming Explained, 71,
75
F
Frodo, 80
G
Gandalf, 80
gestión de riesgos, 105, 107
I
Inception Deck, 104, 111, 115
integración continua, 190, 192
integración frecuente, 190, 193
iteraciones, 77, 111, 112, 113, 114,
115, 117, 118, 119, 120, 122, 123,
124, 128, 129, 136
Iteration BackLog, 119
K
Kanban, 65, 73, 74, 133, 134, 136,
137, 138, 140, 142, 143
KANBAN, 138, 147
Kent Beck, 70, 71, 75
L
Labels, 29
Layer Diagram, 175, 176
Lean Development, 71
Live Messenger, 206
M
Merge, 22, 23, 26, 27, 28, 33, 34, 36,
37, 38, 39, 42
Merging, 21, 22, 23, 24, 25, 26, 40, 41,
52
Microsoft Excel, 81, 82, 100, 108, 110,
126
Microsoft Test Manager, 197, 199, 202
MSF, 81, 84, 89, 91, 92, 98, 100, 108,
113, 114, 120, 138, 143
MSF for Agile, 119, 120
MSF for AGILE 5.0, 138, 143
MSF for CMMI, 169, 209
MSMQ, 50
N
NASA, 71
P
políticas de CheckIn, 54
PostIt, 74, 134
Process Editor, 58
Product BackLog, 113, 114, 115
Product Planning, 114, 122
R
Red-Green-Refactor, 158
REFACTOR, 159
Refactoring, 160, 166
Refactorización, 160
Remaining Work, 100, 102, 125, 140
Requerimiento, 75, 84
requerimientos, 66, 69, 74, 75, 76, 77,
78, 81, 83, 84, 107, 109, 115, 116
requisito, 70
requisitos, 68, 70
Requisitos, 70
-
-
Cla
udio
Var
gas
Ale
jos
cla
udio
cva@
hotm
ail.c
om 0
9/08
/201
3
Con
teni
do li
cenc
iado
a
:
Índice analítico 213
RETROSPECTIVAS, 128
S
SCRUM, 65, 71, 113, 138, 143, 147
ScrumBan, 143
Shelvesets, 207
Skype, 206
SOLID, 150
Source Control Explorer, 23
Sprints, 77
Starbucks, 133
Stories Overview, 91, 152
Stories Progress Report, 89
SubVersion, 21, 52, 60
T
TDD, 156, 171
Team Build, 166, 167, 172, 175, 176,
177, 178, 179, 182, 183, 184, 188,
189, 190, 192, 194, 196
Team Explorer, 81, 82, 92, 108, 120,
145, 146
Team Foundation Server BackUps, 58
Team Foundation Server MSSCCI
Provider, 58
Team Foundation Server Power Tools,
54, 56, 58, 206
Test Cases, 85, 88, 91, 95, 96, 99, 100,
116
Test Driven Development, 156, 166
TFPT, 58
TFS Build Extensions, 177, 182, 183,
185
The Agile Samurai, 104
U
User Stories, 78, 81, 84, 85, 93, 97, 99,
100, 101, 107, 111, 112, 113, 114,
116, 122, 123, 124, 125, 142
User Story, 75, 78, 79, 81, 82, 83, 84,
85, 86, 88, 89, 91, 92, 93, 94, 95, 96,
97, 98, 99, 100, 111, 112, 113, 115,
116, 117, 123, 139, 140, 141, 151,
152, 156, 161, 196, 197, 198, 200
V
vampiro, 22
View Hierarchy, 25
Visual Studio ALM, 67, 71, 72, 74, 84,
103, 104, 106, 108, 117, 128, 129,
142, 143
W
waterfall, 64
Windows Shell Extensions, 58
WinMerge, 28
WIP, 73, 134, 135, 136, 140, 141, 142
Workspace, 31, 32, 59, 60
X
XP, 70, 71, 103, 104
Z
Zombie, 29
-
-
Con
teni
do
licen
ciad
o
a
: C
laud
io
Var
gas
A
lejo
s
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
clau
dioc
va@
hotm
ail.c
om 0
9/08
/201
3
C
onte
nido
l
icen
ciad
o
a
: C
laud
io
V
arga
s
Ale
jos