Yo y la calidad del software en la web de la UPNA

Como parte de mi participación en los Cursos de Verano de la Unversidad de Navarra, para hablar de Team System y la calidad en el desarrollo de Software, tuvo lugar una rueda de prensa. Aprovecho para agradecer desde aquí la opotunidad de ‘evangelizar’ sobre la importancia de la calidad en el desarrollo de software.


Tenaís que verme, jajajaj… ni el mismísimo Beckam o mejor aún por poner alguien a quien admiro, Martinez de Irujo. No sabia que hacer ante las hordas de periodistas (dos), que querian oir lo que yo tenia que decir. 


Podeís leer lo que comenté en la misma aquí, en la Web de la Universidad Pública de Navarra.


La agencia EFE tambien se hace eco, de manera más breve, de la rueda de prensa: Experto destaca que en software “nunca la calidad para final”


Destarcar tambien que tuve el placer de conocer al profesor emérito de la Universidad Carnegie Mellon, Ángel G. Jordán, uno de los ‘padres’ de CMMI.

‘Insourcing’ mejor que ‘outsourcing’

El viernes estuve en los Cursos de Verano de la Universidad Pública de Navarra, hablando sobre Team System y como puede influir en la calidad de software que desarrollamos. Tuve el placer de comer con Jesús Villadangos Alonso, profesor de la Universidad, y entre los numerosos temas de conversación que tratamos, durante la amena comida, salió el outsourcing. Luego, al llegar a casa y leer Geeks.ms vi que mi vecino de blog, Gustavo Vélez, había escrito sobre éste tema  y ya no pude resistirlo, tengo que dar mi opinión, para que quede constancia por escrito, pues intuyo que es un tema que cada vez se va a comentar más y más. Y es que en éste tema, como en otros relacionados con el mundo del software, Europa se mueve a rebufo de los Estados Unidos y hay olas que surgen en el otro lado del charco, se toman su tiempo en cruzarlo, y llegan a Europa, sin que aquí hayamos aprendido nada. Una de las grandes preocupaciones de la industria del software en Estados Unidos en los últimos años ha sido el outsourcing. Hay blogs llenos de consideraciones de programadores llamando al proteccionismo, de consultores prometiendo mejoras económicas fabulosas. Conste que los argumentos en contra del outsourcing basados en la ética de las empresas o en sus obligaciones morales, en el proteccionismo y en otras consideraciones de esa índole no me valen. Tenemos que aceptar que somos jugadores (o quizás peones) de la economía global y que lo mismo merece un puesto de trabajo un indio, que un europeo, que un africano.


Hemos de reconocer que la idea en si es atractiva. Llevemos nuestra producción a lugares donde la mano de obra sea más barata, y así conseguiremos ahorros de costes. La industria del automóvil, espejo por excelencia de otras industrias, lo está haciendo con éxito, no con tanto como se esperaba pero si con un balance global positivo. Es fácil, en teoría, el producto se diseña en nuestros cuarteles generales de Europa y luego un grupo de bien entrenados y educados programadores indios lleva a cabo la implementación. El problema que se obvia, es que construir software no es como construir coches, o confeccionar zapatillas. Cuando hablamos de software, el diseño no es una fase que termine en un momento del proyecto y no se retome. Cada vez más y más profesionales y más metodologías están comprendiendo que el proceso de diseño en el software es continuo. Por eso, cada vez se pone más hincapié en involucrar al cliente, en mostrarle continuamente lo que ya tenemos implementado para poder llegar conocer, mediante el ‘feedback’ que proporciona éste proceso, qué diseño de la solución cubre sus necesidades. Al contrario que cuando diseñamos coches o zapatillas, en los proyectos de software es el cliente quien tiene toda la información sobre sus necesidades y, el problema, es que a veces no es capaz de expresarlas hasta que tiene un sistema ejecutable delante. Se puede ‘imponer’ una moda en camisetas o zapatillas, pero no se pueden imponer necesidades a nuestros clientes. Es falso que podamos, con éxito, especificar completamente un proyecto de software, que nuestros analistas lo diseñen y que un equipo de fuera lo implemente. Sin duda vamos a obtener ahorros de coste, pero a costa de perder totalmente la posibilidad de involucrar al cliente en el proyecto. Y las estadísticas dicen, que después de tener un ‘sponsor’ claro del proyecto, involucrar al cliente es el principal factor para que los proyectos triunfen. El problema principal es, que quienes toman la decisión de seguir el camino del outsourcing no conocen que cada línea de código que se escribe en un programa supone tomar una decisión de diseño. Suelen ser economistas o gestores, que entienden de dinero, no de software.


Otro factor por el que el outsourcing no es interesante desde mi punto de vista, es que los que aprenden son otros. Cada vez que trabajas en la implementación de un sistema, por trivial que sea, aprendes algo, y ese conocimiento adquirido es algo que te va a ayudar en proyectos futuros. A las empresas siempre se nos llena la boca cuando hablamos de know how, pero se nos olvida que el know how, sólo nace de la experiencia, de la formación y de la capacidad para retener a nuestro personal. Llevar a cabo proyectos de software no es sólo una manera de ganarse la vida, sino también una excelente manera de aprender para poder abarcar proyectos futuros y poder seguir en el juego de ganarnos la vida. Sin ese proceso de aprendizaje de las empresas, es también muy difícil que se den las condiciones necesarias para que se produzca la innovación. Y todos los proyectos de desarrollo de software que triunfan son innovadores, en uno u otro sentido. A las empresas se les paga por el valor que añaden a los productos o servicios, las empresas que desarrollan software tienen muy difícil añadir valor sin ser innovadoras, éste es, a mi modo de ver, el principal motivo por el que las herramientas 4GL no han triunfado, no dejan campo a la innovación. Por eso, seguimos usando compiladores de propósito general, porque nos permiten hacer cosas que otros no han hecho antes, usar nuestro know how para innovar y añadir valor a nuestros desarrollos. Si quereís ahondar en la importancia de el aprendizaje de las empresas y la importancia de retener al personal, Peopleware, de Tom de Marco y Timothy Lister es una excelente lectura.


La industria del software debe cambiar. Es claro que esta corriente es imparable. Debemos aceptar que aunque es una ingeniería, no es una ingeniería como las demás, como bien explica Edsger W. Dijkstra, puesto tiene una componente de creatividad y diseño continuo que otras no tienen. Debemos empezar a preocuparnos por incorporar capacidad de aprendizaje a nuestras empresas. Debemos empezar a pensar en el ‘insourcing’, en lograr que empresas que tienen mayor conocimiento que nosotros vengan a trabajar a nuestras instalaciones, para que nuestros empleados tenga la posibilidad de aprender. En lugar de preocuparnos por ahorrar costes, la preocupación principal debe ser aportar valor a nuestros clientes y que nuestra empresa aprenda. Si dejamos que actividades claves para nuestro negocio las realicen segundas empresas, vamos a describir que las empresas que hacían ‘nuestro trabajo’ han aprendido y ahora son nuestros competidores.


También tendemos a obviar que un factor vital en el desarrollo de software, la comunicación. La comunicación fluida es una precondición necesaria para que los proyectos de desarrollo de software lleguen a buen puerto. Y sin duda no es un factor que facilite la comunicación, que mientras nuestros ingenieros duermen los de la otra empresa estén trabajando y viceversa. Gustavo ya ha descubierto que sin buena comunicación las cosas no se hacen como a uno le gusta, y esto es especialmente preocupante para empresas con estandares de excelencia altos. Ahora Gustavo está viviendo con un modelos de objetos que no cumple con sus estandares, seguro que exigentes, de calidad. Esto no hubiese pasado con una buena comunicación. Otra faceta relacionada con esto que tendemos a pasar por alto, es que el outsourcing, rebaja unos costes, pero introduce otros nuevos relacionados en gran medida con estas dificultades de comunicación y de gestión del proyecto, puesto que aunque no tengamos que desarrollar aún tenemos que gestionar muchos aspectos del proyecto y esta gestión además va a ser más compleja y por lo tanto más costosa en terminos economicos. Tampoco que dos empresas con agendas e intereses, en una relación cliente proveedor y que quizás vayan a competir en otros proyectos, es algo que favorece el clima de comunicación y colaboración necesario para llevar a cabo un proyecto. Una vez más creo que introducir en nuestra empresa conocimiento y personal que pueda colaborar con el proyecto y no simplemente actuar como un proveedor, es una postura que a medio plazo da mejores resultados. Una vez más el camino que veo es el ‘insourcing’.


Sin duda, no todo han sido fracasos con el outsourcing en el software. Pero, que empresas como Oracle, muevan sus proyectos a la India, no es un espejo en el que la pequeña o mediana empresa se pueda mirar. Oracle ha movido proyectos completos, incluso divisiones completas, eso no es outsourcing. Al menos no en el sentido en el que estoy comentando en éste post.

Liberada la Release Candidate de Iron Python

Ya tenemos Release Candidate de Iron Python, la implementación sobre .net del lenguaje de moda, Python.


Esta implementación es GPL y podeís descargarla desde Codeplex, el nuevo sitio de alojamiento de proyectos de Microsoft construido sobre Team Foundation Server del que ya hablé anteriormente.


Aquí teneís el hello world en Python, por si os animaís a empezar 😉

print “Hello world!”
Si os animaís, leed Why’s (poignant) guide to ruby, es uno de los más curiosos tutoriales que he leido jamas, su tercer capítulo, es uno de los seleccionados en el libro The best software writing I, de Joel Spolsky. Por cierto este libro es espectacular. Y además podeís encontrar los articulos seleccionados en este libro, online, pues casi todos provienen de blogs.

Selección de proyectos con Motion

Uno de los problemas a los que recurrentemente se enfrentan las grandes empresas, que no son ISV y que cuentan con departamentos de desarrollo propios es priorizar los proyectos a abordar.


Es evidente que este tipo de departamentos a menudo eligen los proyectos que abordan por motivos que no están directamente relacionados con las necesidades inmediatas de la empresa o con maximizar el retorno de la inversión, en el sentido de seleccionar aquellos proyectos de desarrollo que más ayuden más a la empresa en su negocio. Muchas veces ocurre que lo que guía la priorización y selección de proyectos es ‘lo pesado que sea el jefe de área’, ‘lo persistente que sea el comercial que vende la tecnología’, ‘el deber  un favor’ etc… Evidentemente, aunque esto es humano, no es la manera más útil de actuar para la empresa. Es necesario que los departamentos de desarrollo que manejan un conjunto amplio de proyectos y de expectativas por parte de otros departamentos más centrados en el negocio puro de la empresa, seleccionen y prioricen los proyectos de una manera objetiva.


Aquí es donde entran en juego metodologías como Motion, o mejor aun la menos burocrática Motion Lite, propuesta por Microsoft para la gestión de ‘portafolios’ de proyectos, que podríamos considerar como la versión ágil de Motion. Motion Lite reduce el tiempo que empleamos en los proyectos que siguen Motion, de ocho semanas a dos. Motion se centra en averiguar cual es el modelo de negocio de la empresa desde el punto de vista del software y utiliza esta información para priorizar y seleccionar aquellos proyectos que más valor aportan. Es importante tener claro que Motion no es una metodología de gestión de proyectos, sino una metodología de selección de proyectos.


Utilizando Motion Lite durante el primer día, construiremos un mapa de las capacidades de nuestro negocio, durante el segundo día, trataremos de averiguar el valor para le negocio, la madurez y la interconexión de cada una de esas capacidades y utilizaremos la información para priorizar y seleccionar los proyectos.


Con este post solo pretendo que sepáis de la existencia de Motion, que yo conocí gracias a un mail de José M. Alarcón. Podéis encontrar más información en este articulo de MSDN, Motion Lite: A Rapid Application of the Business Architecture Techniques Used by Microsoft Motion


De todos modos conste que el valor no le veo en en Motion Lite en si mismo, que sin duda lo tiene, sino en establecer una metodología clara, sea Motion u otra, para establecer que proyectos aborda y con que prioridad nuestro departamento de desarrollo interno.

Los servicios del modelo de objetos de Team Foundation Server

La arquitectura de Team Foundation esta orientada a servicios, no en el sentido que utiliza servicios Web, sino en el sentido amplio de arquitectura orientada a servicios. Los diferentes componentes de Team System ofrecen servicios a través de interfaces bien conocidas para cada uno de los servicios.


Como consecuencia cuando queremos utilizar uno de estos servicios, sea cual sea, el patrón siempre es el mismo.


Primero debemos autenticarnos en el servidor de Team Foundation Server. Y luego debemos obtener el servicio que necesitamos, generalmente llamando al método GetService de la clase Team Foundation server, pasándole el tipo de servicio que queremos obtener. Si bien esta no es una tarea muy compleja, como podéis observar aquí , si implica conocer cual es el servicio adecuado para la tarea que queremos realizar.


El propósito de este post es dar a conocer cuales son los diferentes servicios que expone Team Foundation Server a través de su modelo de objetos, para que tipo de trabajos se puede utilizar cada uno y ofrecer una recopilación de ejemplos de terceros del uso de cada uno de estos servicios:


El servicio de registro (IRegistracion), permite a la herramientas que se integran en la infraestructura de Team Foundation Server, registrar que artefactos utilizan, como se establecen relaciones entre ellos y que base de datos utilizan para almacenar su información. También permite obtener esa información.


The IRegistration Service Type


El servicio de clasificación (ICommonStructureService), permite enumerar los proyectos, trabaja con propiedades de los mismos, trabajar con las ramificaciones de los proyectos (branch) y enumerar areas e iteraciones.


Enumerate TFS Areas using ICommonStructureService


Listing the team projects on a server


El servicio de enlaces (ILinking) permite que las diferentes herramientas integradas en Team Foundation Server, puedan establecer relaciones entre sus artefactos. Además proporciona la infraestructura necesaria para poder acceder a artefactos mediante URIs. No he encontrado ejemplos de este servicio, más allá de los que aparecen en el SDK y en esta ppt, en la parte que habla de “artifact and links”.


El servicio de eventos (IEventService) permite subscribirse a eventos que ocurren en TFS y tambien registrar nuestros propios eventos. Os remito a un post anterior en el que hay extensa información y recursos sobre este servicio.


El servicios de grupos y seguridad (IGroupSecurityService) y el servicio de autorización (IAuthorizationService) , nos permiten trabajar con los grupos, usuario y permisos.


How to list the users/groups the server knows about?


Programmatically Assign Security Descriptors for the Iterations and Area


El servicio de estado del servidor (IServerStatusService), que solo presenta dos métodos, nos permite obtener informacion sobre en que estado se encuentra el servidor de Team Foundation Server y la versión de los contratos de servicio del mismo.


El servicio de plantillas de proceso (IProcessTemplates), nos permite realizar operaciones sobre las plantillas de proceso, listar las que tenemos, asi como importar y exportar plantillas de proceso desde nuestro programas.


Listing the process templates on a TFS server


Installing Process Templates


El servicio de elementos de trabajo (WorkItemStore) permite realizar todas la operaciones relativas a work items que se nos ocurran. Crearlos, eliminarlos, cambiar su estado, sus campos etc…


Programmatically adding new Work Items to a Team System Project


Web Forms for Submitting Issues to Team Foundation Server


El servicio de control de fuentes (VersionControlServer) nos permite realizar todas la operaciones relativas a gestión de fuentes.


Enumerar contenido en el gestor de fuentes de Team Foundation


Working with the Version Control Object Model


Espero que os animéis a entrar en el mundo de la extensibilidad de Team Foundation Server!!!

Ya soy MCT!!!

Pues eso, que ya soy Microsoft Certified Trainer, tanto para desarrollo web como Windows.



He tenido que, aparte de sacar las cerficiaciones pertinentes de Microsoft, asistir a un curso, sobre presentaciones efectivas, de un día, en las instalaciones de Microsoft en España. El curso fue interesante, pero un día no da para mucho como podreís imaginar. Después de esto, solicitar a través de la web de Microsoft para MCPs mi reconocimiento como MCT, enviar la documentación que acreditaba que habia realizado el curso, llamar un par de veces, porque parece que no la recibian por mail, volver a enviarla por fax, confirmar de nuevo por teléfono que habian recibido el fax y esperar unos dos días. No es que el tema haya sido ágil precisamente, pero ya está. Y además abonar 350€ claro.


Seguro que los que “sufrís” mis cursos tanto a través de [CMVP] como presencialmente, vais a notar la diferencia ;), al menos, pienso poner el logo, que es muy mono, en la primera PPT.

Charla en los cursos de verano de la Universidad de Navarra

El viernes 28 de Julio, sustituiré a David Carmona, vaya reponsabilidad estar a su altura, en el curso “CALIDAD DEL SOFTWARE: Gestión eficaz de los procesos de desarrollo de software para satisfacer la calidad” de los Cursos de Verano de la Universidad Pública de Navarra. La verdad es que tienen una excelente pinta, tanto este curso en particular, como el resto.


Hablaré sobre [TS] y gestión de proyectos, como no, durante cuatro horas. La conferencia se titula “Gestión del ciclo de vida de un desarrollo software: Microsoft Visual Studio Team System”, charla que se esta convirtiendo en un clásico, cosechando exitos de crítica y público 😉


Si alguno de los seguidores de mi blog (las estadísticas de Google Analytics dicen que los hay, pero yo tengo mis dudas) asiste a este curso, me encantaría saber que espera de mi intervención.

Confieso: he estado probando Buildix

¿Que es Buildix?
Pues es una distribución Linux, basada en Knoppix, a la que se han eliminado un motón de cosas y se le ha configurado una serie de software relacionado con la gestión de proyectos, en entornos de desarrollo ágiles.
Y la verdad es que no esta mal del todo. Eso si no es comparable ni de lejos a un sistem Team Foundation Server. Más que nada en cuanto a nivel de integración de las herramientas. Tambien carece de todo el soporte metodológico que aporta Team System y de las excelentes capacidades relativas a informes y métricas de Team System. Además no soporta múltiples metodologías como Team System, sino que esta toltalmente orientado a metodologías ágiles e integración continua.



Buildix cuenta con Trac para la gestión de proyectos, este software pone juntos un Wiki (que actua como repositorio de la documentación de nuestro proyecto), una timeline (donde vemos eventos importantes para el proyecto), un roadmap (que muestra los hitos de nuestro proyecto y el grado de avance), un repositorio de elementos de trabajos, llamados tickets (que permiten definir requisitos, bugs, tareas etc…) y una interfaz web sobre subversión, además de un sistema de busqueda sobre todos estos elementos.



Trac es el componente que más me ha llamado la atención, quiza por resultarme el más desconocido, aunque eso si, aun subre muchas carencias, como la escasa personalización de los diferentes tipos de tickets, que presentan los mismos campos para cualquier tipo y la ausencia total de un motor de workflow que asegure una correcta transición entre los estados. Podeís probar Trac online.

Además Buildix tambien cuenta con un gestor de fuentes Subversion, un con Cruise Control para realizar las tareas de integración continua y con una interfaz web para la gestión unificada de los usuarios de Subversion y Trac.


Hay que reconoce que tener todo un servidor de gestión de proyectos, por limitado que sea, listo para usarlo es una opción golosa y si duda puede ser un gran facilitador para que pequeñas y medianas empresas comiencen a utilizar este tipo de herramientas. De hecho si estas solucíón corriese en Windows y se integrase con Active Directory, ya la estaría usando en algún proyecto, porque en proyectos medianos el coste de licencia de Team System es un problema.


Todos los que tengaís curiosidad podeís bajar un Live CD o incluso una WMWare de la distribución.


Yo he instalado el Live CD en un Virtual PC



Luego basta con apuntar el navegador a la ip de la maquina virtual y listo, podemos empezar a trastear.



Si el sistema nos gusta, solo tenemos que hacer loguin como root (usando root tambien como password) y ejecutar el comando knoppix-installer

Pon una pizarra en tus proyectos

Leía hace poco que hay cuatro cosas que todos los proyectos de software, con total seguridad, necesitan:


 Un editor de texto
 Un compilador
 Un gestor de fuentes
 Un gestor de bugs


Los dos primeros elementos de esta lista, sin duda siempre aparecen, puesto que es imposible crear software sin ellos. El tercero y el cuarto, hay veces que no aparecen. Y aquí sin duda el primer trabajo que debemos hacer cuando llegamos a un proyecto que carece de estos elementos es ponerlos en marcha.


Una de mis labores habituales es impartir cursos y dar consultaría sobre gestión de proyectos. Me encanta cuando me encuentro algún proyecto que carece de gestor de fuentes o de bugs, porque se que, si pongo uno en marcha, y los involucrados en el proyecto comienzan a usarlo, me consideraran un guru. En adelante recordaran mi nombre como el tipo que más mejoró su vida como desarrolladores. Si quieres que un desarrollador te declare amor eterno, no tienes más que enseñarle a usar un gestor de fuentes, especialmente si lleva un largo tiempo trabajando sin el, puesto que con seguridad habrá sufrido los problemas que siempre surgen si no hay gesto de fuentes.


Sin embargo, si quien quieres que te declare amor eterno es el responsable del proyecto, lo que tienes que montar es un gestor de bugs. Ninguna herramienta proporciona tanta información sobre un proyecto de software como un gestor de bugs, solo hay que ver Team System y la gran cantidad de métricas que se derivan de la información sobre bugs. Siempre, claro está, que alguien este testeando el software que estamos escribiendo. Pero sobre la necesidad de tener especialistas en realizar pruebas en el equipo de desarrollo hablaré otro día.


Además, la buena noticia es que existe un autentico arsenal de estas herramientas y que las hay gratuitas bastante aceptables. La mala noticia para mí es que cada vez más proyectos conocen las bondades de estas herramientas, así que ya no tengo el éxito asegurado sin trabajar duro ;).


Pero vamos a lo que realmente quiero tratar en este post. En mi opinión hay otro elemento que añadir a esa lista, de la que hablaba al principio, uno que además es muy barato: UNA PIZARRA.


Una pizarra (o mejor aun, muchas pizarras), es un elemento de un valor inestimable en todo proyecto, especialmente en todo proyecto de software. Los proyectos de software, al contrario que los de otras ramas de la ingeniería, rara vez parten de una especificación totalmente formal. Necesitan de una continua valoración de alternativas, de una continua toma de decisiones de diseño, que a menudo deben ser comprendidas, evaluadas y discutidas antes de que ni siquiera se puedan plasmar en un documento formal (si es que es necesario ese documento, lo imprescindible es el proceso necesario para encontrar el problema, porque en informática al contrario que en otras ingenieras tenemos que buscar el problema, y la solución). Y mi experiencia me dice que una pizarra es un catalizador de ese proceso. Los motivos son varios:


Cualquiera puede pintar en una pizarra. Es la única herramienta de diseño que todos sabemos utilizar con destreza. Es realmente difícil colaborar alrededor de Visio. Mucho mejor hacerlo alrededor de una pizarra, aunque luego plasmes el resultado en un documento de Visio.


Durante una reunión la persona que tiene el control de la pizarra, tiene la atención de todos los asistentes. No se crean mini reuniones paralelas o al menos no con tanta frecuencia. No hay necesidad de decir “déjame hablar”, te levantas, cojes el rotulador que la otra persona cede cuando ha terminado y ya tienes el testigo de la atención de los demás. Puedes seguir aportando.


La pizarra soporta que borres solo aquellas partes del problema debatido que no están fijadas, el resto no es necesario tocarlo, puedes ir refinando tu solución y tienes a la vista las decisiones que ya has tomado, lo que evita que se reabran temas continuamente. Este proceso iterativo no se soporta sobre papel. La pizarra te aporta un proceso continuo de revisión.


Todo el mundo puede ver el resultado de una reunión o discusión simplemente levantado la cabeza. Y si la pizarra no esta visible siempre puedes sacarla una foto.


Las pizarras no “desaparecen”, las libretas, los papeles, si. Cada uno se lleva la suya. Basta un “no borrar” y un poco de disciplina para que el contenido este disponible durante el tiempo necesario.


La clave sin duda es que las pizarras facilitan la comunicación, o al menos la comunicación inmediata, que es de la que surgen las ideas y conclusiones que, a la postre, guían un proyecto.


¿Me pregunto, realmente alguien puede diseñar software sin tener una pizarra? Espero respuestas. Porque veo muchos proyectos que no usan pizarras, o al menos no pizarras de tamaño adecuado.


Lo bueno es que las pizarras, al igual que los gestores de fuentes y los de bugs, son muy baratas, cómpralas, cuélgalas quizás alguien descubra que son realmente útiles.