Áreas en Team Foundation Server

Hace unos días escribía sobre las iteraciones en Team Foundation Server, pues bien tal y como prometía en ese post, hoy le toca el turno a las áreas.


Si bien las iteraciones del proyecto representan la jerarquía de eventos en el ciclo de vida del proyecto, la áreas representan, típicamente, la jerarquía de componentes y características del proyecto. Digo típicamente porque las areas pueden representar cualquier tipo de agrupación de workitems que se nos ocurra que puede ser de nuestro interés. Supongamos, por ejemplo, un equipo de desarrollo geográficamente distribuido: en este caso puede que nos interese que las areas de primer nivel representen los diferentes lugares donde se realiza el desarrollo. O supongamos que nuestro proyecto utiliza diferentes tecnologías, p.e. Java y .Net: en este caso nuestras areas de primer nivel podrían ser estas.


La importancia de definir adecuadamente las áreas de nuestro proyecto radica en que los work items pueden ser asignados a areas y los informes pueden ser filtrados por área. Las áreas son jerarquicas, de manera que pueden contener subáreas. Cuando filtramos un informe por area, los datos que muestra incluyen los datos relativos a los workitems del área y de las subáreas de ese área. Otro punto a tener en cuenta es que podemos establecer permisos a nivel de cada área de nuestro proyecto.



Las áreas son uno de los puntos que más atención necesitan a la hora de modelizar nuestro Team Foundation Server. La cuestión origen de la confusión es dilucidar cuando crear un nuevo proyecto o cuando crear áreas dentro de un proyecto. Necesitamos tomar una decisión adecuada de que áreas son adecuadas para nuestra organización o proyecto pues estas tienden a ser muy estables en el tiempo, de modo que cuando decidimos nuestras áreas (sobre todo las de más alta jerarquía) estamos tomando una decisión a largo plazo.


Tenemos dos enfoques a la hora de modelar como nuestros proyectos se trasladan a nuestro Team Foundation Server: que nuestros proyectos se correspondan con areas o que se correspondan con Team Projects. La recomendación es utilizar áreas siempre que sea posible.


Los Team Projects deben representar la mayor unidad de trabajo posible en nuestra organización, por lo tanto en principio deberiamos tener un solo Team Project por producto o línea de productos o incluso organización, y utilizar areas para obtener la granularidad necesaria a la hora de explotar los informes. Este enfoque además nos permite obtener informes agregados que incluyan información de alto nivel de nuestra organización. Cuantos más Team Projects tengamos dentro de nuestra organización más estamos fragmentando la posibilidad de obtener informes.


Dicho esto, y dejando claro que debemos tender a tener el menor número de Team Projects posible, la pregunta es ¿cuándo debemos crear un nuevo Team Project?. Los motivos pueden ser tan diversos como las organizaciones y proyectos que usen Team Foundation Server, pero las causas habituales desde un punto de vista organizativo, son:



  • La necesidad de tener portales de proyecto separados

  • La necesidad de tener diferentes permisos para las mismas personas

  • La necesidad de establecer diferentes políticas de check-in

  • La necesidad de utilizar diferentes metodologías de desarrollo

  • La necesidad de utilizar diferentes workitems o adaptarlos

Para obtener más información sobre este tema: Planear un proyecto de equipo y este post en el que Eric Lee habla del tema.

Hablar es fácil… otra cosa es tener razón o a veces los locos son los galos

Leía hace unos días en el blog de Rafael Ontivero sus airadas quejas contra los terminos de licencia de usuario de Windows Vista. La verdad es que según iba leyendo, a mi tambien me estaba empezando a hervir la sangre como al amigo Rafael. No podía creer que Microsoft pudiese haber puesto tantas restricciones en la licencia de Windows Vista… al fin y al cabo estabamos pagando por un producto con muchas limitaciones de uso…

Pero mis ardores llegaban a su fin, cuando tras leer los cometarios, sana construmbre que no todo el mundo practica, veía que mi amigo y compañero Unai decía que lo expuesto en el post era falso. A mi lo que dice Unai siempre me merece credito siempre, pero en cualquier caso, lo duro del tono de los comentarios de Rafael, me obligaba a tomar la postura de San Agustín: «ver para creer». Asi que armado con Google, me dispuse a desentrañar el misterio: ¿Está equivocado el amigo Rafael? ¿Se sostienen sus airadas críticas?.

Bueno como se que algunos (os tengo fichados ¿eh?) no se leen mis post hasta el final, voy a desentrañar la cuestión y luego pondré mis conclusiones y mis fuentes:

Cuando Rafael dice en su post que:

  • Windows no se puede reinstalar, debes comprar una licencia nueva. ES FALSO!!!
  • Si una actualización te pide reactivar, tienes que comprar una licencia nueva. ES FALSO!!!
  • Windows no se puede reinstalar, ni siquiera si se ha estropeado a causa de un driver defectuoso o por programas de terceros (incluída la propia Microsoft). ES FALSO!!!
  • No se puede tener instalada en el mismo equipo más de una copia de Windows con la misma licencia, ni siquiera para evitar el punto anterior. PARECE QUE ES FALSO!!
  • No puedes tener replicados en máquinas virtuales diferentes Windows con una misma licencia, ni siquiera si no los tienes cargados simultaneamente, aunque la propia Microsoft te suministra una utilidad para hacerlo. ES FALSO!!

Se que todas estas falsedades tienen su origen en la desinformación y el desconocimiento, y no en la mala fe, así que no dudo que veremos un desmentido, disculpa o fe de erratas (llamemosle como queramos) en el blog de Rafael a no mucho tardar.

Las conclusiones de mi ‘investigación’ son:

  • Puedes reinstalar Windows Vista la veces que quieras, eso si, la licencia esta ligada al dispositivo. Solo puedes instalar un Windows Vista legalmente en un dispositivo. Por mucho que tu seas el propietario la licencia va ligada a un único dispositivo.
  • Nada te impide cambiar en una única ocasión el dispositivo al que va ligada la licencia si es una OEM. Por ejemplo si se te estropea el PC completamente, que practicamente es el único caso en que tiene sentido. Si la licencia es Retail, puedes pasarla de dispositivo en dispositivo sin más condición que quitarla del anterior. Podrás activarla por telefono las veces que necesites.
  • El acuerdo de licencia dice claramente que se puede hacer una copia de seguridad del cd de instalación y usarlo para reinstalar. Luego queda patente que puedes reinstalar cuantas veces necesites.
  • Las únicas versiones de Vista que legalmente puedes usar con Virtual PC (u otro software de virtualización) son la Bussiness y la Ultimate.
  • No me queda claro si puedes instalar en el mismo PC dos copias de Vista en particiones diferentes sin violar licencia. El acuerdo de licencia dice: «Before you use the software under a license, you must assign that license to one device (physical hardware system). That device is the “licensed device.” A hardware partition or blade is considered to be a separate device.». Parece que si la partición es lógica no te estas saltando el acuerdo de licencia. Quiza alguien pueda hechar luz sobre esto.

Sobre el malestar de Rafael por no poder leer la licencia ante de comprar, está totalmente injustificado, puedes encontrar cualquier licencia de Microsoft aquí: Retail Software License Terms. Además, si no aceptas los terminos de la licencia puedes devolver tu copia de Windows Vista.

Las fuentes que me han llevado a estas conclusiones son:

http://windowsvistablog.com/blogs/windowsvista/archive/2006/11/02/news-revision-to-windows-vista-retail-licensing-terms.aspx

http://www.winsupersite.com/showcase/winvista_licensing.asp

http://blogs.zdnet.com/Bott/?p=166

http://www.microsoft.com/about/legal/useterms/default.aspx

y algunas otras, pero con las anteriores es suficiente.

Eso si, al Cesar lo que es del Cesar, las licencias de Microsoft son de todo menos claras. No aplican el principio KISS a la licencias y es una pena, porque una licencia que es dificil de entender es dificil de cumplir. Como MVP me he quejado siempre que he tenido oportunidad de la complejidad de las licencias de Microsoft y lo seguiré haciendo. La respuesta que he recibido siempre que me he quejado a sido siempre la misma, eso es cierto: ‘las licencias son complejas para cubrir el mayor abanico posible de necesidades de nuestros clientes a la vez que aseguramos nuestros derechos sobre nuestra propiedad intelectual’ y la verdad es que la respuesta puede tener su sentido.

He leído: Software Engineering with Microsoft Visual Studio Team System de Sam Guckenheimer

Cómpralo en Amazon Software Engineering with Microsoft Visual Studio Team System, de Sam Guckenheimer, me parece un libro clave para entender que se esconde debajo de Visual Studio Team System desde el punto de vista de la ingeniería del software y las prácticas modernas de desarrollo de software.


Solo alguien que ha estado tan implicado en el desarrollo de herrmientas de gestión de proyectos como Sam Guckenheimer (trabajaba en Rational como Product Line Stategic Director) y que ha estado implicado tambien en el desarrollo de Visual Studio Team System (como Group Product Planner) podía aportar la información ‘desde dentro’ que destila este libro.


El libro me ha encantado porque describe con gran claridad la relación existente entre prácticas de desarrollo modernas y como estas han sido implementadas en Visual Studio Team System. Es más un libro sobre gestión de proyectos y buenas prácticas de desarrollo que sobre como utilizar Visual Studio Team System.


Especialmente interesante me ha parecido el capítulo dedicado a la captura de requisitos, que describe de manera clara y concisa conceptos como escenarios y personas y como se han llevado a Visual Studio Team System. Tambien es de extraordinario valor el capitulo dedicado a la gestión de proyectos con Visual Studio Team System, en especial la parte que describe el uso de métricas. La visión que transmite esa parte del libro es muy similar a la que comenté en Métricas mal entendidas.


Tambien es de gran interés la parte del libro que describe el paradigma ‘value up’, que es la base de la visión que ha guiado el desarrollo de Visual Studio Team System y las metodologías de la familia MSF. Comprender esta visión es de gran utilidad para comprender como se concibe el desarrollo de software en las metodologías de la familia MSF.


Otra parte del libro que me ha parecido de gran valor es la parte dedicada a la calidad y el manejo de bugs. Dedica un capítulo a cada uno de estos aspectos, lo que nos da una idea clara de que la calidad del software es un aspecto central en Visual Studio Team System, con independencia de la metodología que elijas.


Por ponerle un pero al libro, decir que se sesga más hacia MSF Agile, que hacia MSF for CMMI Process Improvement. De todos modos en las partes que es necesario apunta las diferencias entre ambas metodologías.


En definitiva un libro que es totalmente imprescindible leer para evitar, lo que a mi modo de ver son,  los principales motivos por los que puede fallar una implantación de Visual Studio Team System: los relacionados con la carencia de conocimiento del porque de las prácticas de ingeniería del software que Visual Studio Team System nos facilita llevar a cabo.

Jefe de Proyecto: ¿técnico o gestor?

A menudo imparto formación sobre gestión de proyectos. Los perfiles que me encuentro en estos cursos son de lo más variado: programadores que quieren ampliar sus conocimientos, gestores de proyectos que llevan años gestionando proyectos pero que nunca han recibido formación sobre gestión de proyectos informáticos, analistas que pronto abordaran su primer proyecto como jefes de proyecto, gestores y comerciales que quieren entender lo que ocurre en los proyectos en los que participan.

Una cuestión que a menudo surge es ¿Debe ser el jefe de proyecto un gestor o un técnico? Es una pregunta que siempre se presta a la polémica, y si la traigo a este blog es precisamente por eso, porque quiero saber que opina la gente. Evidentemente si voy a pedir una opinión, antes voy a empezar dando la mía. Sin duda la respuesta correcta a esta pregunta debe abordar que aspecto de los dos debe dominar, pues todo jefe de proyecto debe aunar las dos facetas, ¿pero cual debe primar? .

Lo primero que quiero es comentar qué es lo que yo entiendo por jefe de proyecto. Esto es importante, porque bajo esta denominación podemos encontrar un montón perfiles diferentes. Para mí, el jefe de proyecto, es la persona encargada del día a día del proyecto, alguien completamente involucrado en el mismo, que se encarga de construir el entorno que permita al equipo de desarrollo trabajar de manera productiva y saludable y que es quien establece las pautas generales que guían el proceso de desarrollo.

Bueno y ahora viene cuando me mojo… YO prefiero un jefe de proyecto técnico. Es en mi opinión evidente que los proyectos necesitan de un líder técnico, que sea este el jefe de proyecto es para mi una situación optima. Los desarrolladores tendemos a valorar más las dotes técnicas que las relacionadas con la gestión y guiar un grupo humano es muchas veces una cuestión de respeto. Los desarrolladores tendemos a respetar a los líderes técnicos del proyecto y a ver como simples entes ‘políticos’ a los gestores. Es mucho más fácil que los desarrolladores nos valoren como jefes de proyecto si somos capaces de guiarles con garantías cuando tienen problemas técnicos.

Esto no quiere decir que no sean importantes los aspectos relacionados con la gestión, pero creo que la credibilidad que ganamos a ojos de los desarrolladores cuando somos buenos técnicos, nos facilita mucho las labores de gestión que muchas veces los desarrolladores comprenden menos. La idea subyacente es: el crédito que ganas por ser un buen técnico, lo puedes administrar para tomar decisiones de gestión, a menudo menos visibles y más difícilmente entendibles para los desarrolladores.

Otro problema con los jefes de proyecto no técnicos es su tendencia a tomar decisiones técnicas en el proyecto. No es fácil que alguien en un entorno técnico y siendo ‘el jefe’ asuma que no tienen el conocimiento necesario para tomar decisiones técnicas. Es lo que yo llama Antipatrón Jefe de Proyecto de Café Tecnológico, que toma sus decisiones en base a artículos técnicos, case studies y cafés tecnológicos y no en base a un profundo conocimiento de las tecnologías involucradas. Esta viñeta de Dilbert describe la situación a la perfección…

En mi opinión los jefes de proyecto no técnicos solo pueden triunfar si son capaces de identificar un buen líder técnico para el proyecto, dejar que todas las decisiones técnicas del proyecto las tome este, y centrarse en la labor de eliminar impedimentos, al estilo del ScrumMaster en Scrum. Eliminar impedimentos no es un trabajo menor, es algo de suma importancia. Ya lo dicen en Peopleware «el trabajo el jefe de proyecto no es hacer que la gente trabaje, sino construir el entorno que haga posible que la gente trabaje» y una manera excelente de hacer es eliminar los impedimentos y los problemas que el equipo de desarrollo encuentra, analizando su origen y asegurándose que se eliminan sus causas para evitar que se repitan.

No deja de ser sorpendente que según una encuesta de la Universidad de Carolina el 49% de los jefes de proyecto consultados admite que no tiene formación ni conocimientos técnicos. ¿Dejaríamos que alguien que no sabe nada de los aspectos técnicos dirijiese la construcción de un oleoducto, un coche, una batidora…?.

Seria sumamente interesante saber que relación hay entre motivación de los desarrolladores (principal factor de productividad en todo proyecto) y el tipo de jefe de proyecto.

¿Qué opinaís vosotros?

Beneficios y caraterísticas de un buen test unitario y de TDD

He leído un pequeño artículo sobre recomendaciones sobre Test-Driven Development: Guidelines for Test-Driven Development de Jeffrey Palermo. Me han llamado la atención sus apuntes sobre los beneficios de TDD y su descripción de un buen test unitario, así que las he traducido. Yo no soy muy partidario de TDD, pues me parece demasiado complejo el poder escribir los test antes, pero si soy muy partidario del testeo unitario.


Benefícios de Test-Driven Development



  • El conjunto de test unitarios proporciona contante retroalimentación de que cada uno de los componentes sigue funcionando.
  • Los test unitarios actuan como documentación que no se queda obsolet, al contrarío que otros tipos de documentación.
  • Cuando el test pasa y el código de producción es refactorizado para eliminar duplicidades, es claro que el código está terminado, y el desarrollador se puede mover a la siguiente tarea.
  • TDD fuerza un análisis y diseño crito porque el desarrollador no puede crear código de producción sin entender realmente cuales deberían ser los resultado deseados y como probarlos.
  • El software tiende a estar mejor diseñado, esto es, menos acoplado y más facilmente mantenible, porque el desarrollador es libre de hacer decisiones de diseño y refactorizar en cualquier momento con la confianza de que el software todavia funciona.
  • El conjunto de tests actua como una red de seguridad contra regresiones en los bugs: Si se encuentra un bug, el desarrollador debe crear un test que ponga de manifiesto el bug y despues modificar el código de producción para eliminar el bug. En sucesivas ejecuciones de los test, todas las correcciones de bugs son verificadas.
  • El tiempo de depuración se reduce.

Características de un buen unit test



  • Se ejecuta rápido, se ejecuta rápido, se ejecuta rápido. Si los test son lentos, no se ejecutaran a menudo.
  • Separa o simula dependencias ambientales como bases de datos, sistemas de archivos, redes, colas y demás. Los test que ejercitan estos no serán rápidos y los fallos no dan información significativa sobre cual es el problema realmente.
  • Es muy limitado en su alcance. Si el test falla, es obvio donde bucar el problema.  Realiza pocas llamadas a la clase Assert de manera que el código que falla sea obvio. Es importante probar una única cosa en cada test. 
  • Se ejecuta y pasa de manera independiente. Si los tests requieren establecer entorno especial o fallan inexperadamente, no son buenos tests unitarios. Cambialos por simplicidad y fiabilidad. Los teste deben ejecutarse y pasarse en cualquier máquina. La excusa «funciona en mi máquina» no sirve.
  • Usa a menudo stubs y mock objects. Si el código que está siendo probado llama a un base de datos o al sistema de archivos, estas dependencias deben ser simuladas. Esta dependencias habitualmente serán abstraidas usando interfaces.
  • Revela claramente su intención. Otro desarrollador puede ver el test y comprender que se espera que haga el código de producción.