La masa, el ladrillo, la bota, el bocadillo...

Estuve en: ALM’09 Sessions

Rodrigo Corral — Mon, 30 Nov 2009 05:58:00 GMT

El pasado martes estuve participando como ponente en las ALM’09 Sessions. Un exitazo de evento que reunión a más de 800 profesionales interesados en mejorar la gestión del ciclo de desarrollo de sus aplicaciones. La agenda que propuso Microsoft y la calidad de los ponentes tubo una clara respuesta. Plain Concepts era uno de los patrocinadores del evento y colaboramos con tres charlas. Yo hablé en el track de procesos, mi compañero Jose Luis Soria hablo de ecosistemas heterogéneos de desarrollo y Team System, y mis compañeros Pablo Peláez y Ricardo Acosta, hablaron de como integrar a los diseñadores en el ciclo de vida.

Como no podía ser de otro modo hablé de Scrum, aderezándolo esta vez, con un poco de buenas prácticas y con un tema que cada vez me preocupa más, la gestión de la configuración en equipos ágiles. El motivo es que veo cada vez más aberraciones de arquitectura, complejidad innecesaria y disfunciones en el ciclo de vida que se pueden solucionar con una política de gestión de la configuración. La gestión de la configuración es una de las ramas más desconocidas, más infrautilizadas y peor utilizadas cuando se usa, de la ingeniería del software.

Os dejo la presentación que realice:

Como siempre, lo mejor en este tipo de eventos fue la oportunidad de charlar con compañeros de la comunidad, amigos, clientes y gente interesada en la gestión de sus proyectos y las tecnologías de Microsoft.

¡Un saludo!

Estuve en: Foro de arquitectos sobre VSTS 2010 en Santander

Rodrigo Corral — Sat, 28 Nov 2009 18:50:45 GMT

Gracias a la amable invitación de Juan Carlos, MVP y miembro del CIIN fui invitado junto a Ibon Landa y Juan Irigoyen, a participar en un evento en Santander. El evento consistió en una reedición del Foro de Arquitectos (podéis seguir el link si queréis la ppt) en el que había participado en Madrid y Barcelona.

El evento reunión a tres decenas de profesionales del mundo informático cántabro, entre los que quiero resaltar al compañero de Geeks.ms Miguel Sierra, más que nada por que en la comida posterior al evento hubo mucho debate muy interesante sobre CMMI vs. Scrum y la idea de realizar ese debate en forma de evento… ¡algo que seguro que haremos!, estad atentos.

Sodercan TV siguió el evento y publicó una pequeña reseña sobre el evento. Desde luego no se quien eligió los cortes, pero en lo que a mi respecta… no me parece que me quisiese bien ;).

¡Un saludo!

Exprimiedo Scrum: Scrum y el triangulo de la gestión de proyectos: la calidad

Rodrigo Corral — Mon, 09 Nov 2009 06:18:00 GMT

Escribía hace un tiempo sobre el triangulo de gestión de proyectos y la férrea dictadura que impone sobre la gestión de proyectos. En esencia, uses la metodología que uses para la gestión de proyectos o incluso si no usas ninguna hay cuatro factores sobre los que, como gestor de proyectos, puedes llevar a cabo tu gestión: la calidad, el alcance, el coste y el tiempo. De todos estos factores, el cliente puede controlar como máximo, tres. El cuarto será el que nos permite gestionar. Si el cliente o alguien externo a la gestión del proyecto controla la totalidad de los aspectos ¿que papel nos queda como gestores del proyecto?.

Dado que el dichoso tirano triángulo nos impone su realidad, cabe plantearse una serie de cuestiones sobre el mismo y su relación con Scrum: ¿Cuál es la relación de Scrum con estos factores? ¿Cómo se actúa sobre ellos en Scrum? ¿Cómo condicionan esta metodología? ¿Qué decisiones explicitas han tomado los diseñadores de Scrum sobre ellos? Estas son las preguntas que quiero responder, en la medida de mis conocimientos, con esta serie de post.

Hoy hablaremos de la calidad, desde la perspectiva de Scrum.

La calidad no es opcional, no es un factor sobre el que podamos especular. Ni siquiera lo podemos gestionar explícitamente: cualquier decisión que tomemos puede ser dañina, vaya esta en el sentido de incrementarla como en el sentido de reducirla. Es un aspecto que siempre decide el cliente no quien gestiona el proyecto. Si decidimos recortar calidad para ganar velocidad, por ejemplo, tarde o temprano lo pagaremos si la calidad que logramos no es la que el cliente está dispuesto a aceptar.

El riesgo, ocurre a menudo, es sobrereaccionar. Para asegurarnos de que cumplimos las expectativas ponemos más calidad de la necesaria en el proyecto. El problema es que la calidad adicional tiene un coste, pero sin embargo, no es percibida por el cliente. Suelo poner siempre el mismo ejemplo, que explica muy bien este asunto, solo es un ejemplo, que nadie se quede con los valores absolutos. A mi me gusta el vino, el buen vino, estoy dispuesto a pagar por un vino de cierta calidad. Si alguien me quiere regalar vino, que no se gaste más de 25 euros, ni menos de 10. Por debajo de 10 euros, es probable que el regalo no cumpla su cometido de agradarme, por encima de 25, estará tirando el dinero, ¡mi paladar no es capaz de distinguir un vino de 25 euros, de uno de 35!. A partir de 25 euros todos los vinos me parecen excelentes. Descubrir el nivel de calidad que satisface al cliente al menor coste, es nuestra principal labor a la hora de gestionar la calidad.

El otro aspecto clave la gestión de la calidad es mantenerla a lo largo del proyecto. Es sumamente difícil medir el nivel de calidad de una manera objetiva, precisamente, por que es algo que depende de los usuarios, de los clientes y de su percepción subjetiva. Pero siempre tenemos una idea más o menos intuitiva o analítica (será más analítica si tenemos métricas claras, un proceso de aseguramiento y validación y sobre todo si tenemos testers) sbore cual es nuestro nivel de calidad que nuestro cliente requiere. Y sobre todo de cuan lejos estamos del nivel de calidad que nuestro cliente esta dispuesto a aceptar: ¿se beberá nuestro cliente un Don Simón o un Castillo de Vulpi (dignísimos vinos en brick para calimotxo, pero capaces de corroer una copa de cristal) sin negarse a pagar la cuenta?. Supongamos que no, ¿cómo podemos descubrir que nuestro cliente no se conformará con nuestro Don Simón, sino que quiere mínimo un rioja joven un poco decente y en botella?. Y sobre todo, una vez que lo descubrimos, que sabemos el nivel mínimo de calidad que satisface a nuestro cliente, ¿cómo aseguramos que no estamos elaborando Don Simón?. Por que estaremos de acuerdo en que si estamos elaborando Don Simón es muy muy difícil que al final, hagamos lo que hagamos, logremos que nos salga un Vega Sicilia (¡hay clientes muy exigentes!). Debemos evitar a toda costa darnos cuenta al final de que no hemos alcanzado el nivel de calidad que nuestro cliente requiere, es un riesgo que no podemos asumir.

El único enfoque que funciona, es, sin duda el mantener de manera constante, durante toda la vida del proyecto, un nivel de calidad que sea aceptable al cliente. Si no averiguamos el nivel de calidad que el cliente esta dispuesto a aceptar y no lo mantenemos a lo largo del ciclo del vida del proyecto, a final, cuando los recursos y el tiempo que nos queden sean más bien justos, tendremos que, aunque la funcionalidad este completa, el proyecto se alargará para alcanzar el nivel de calidad necesario.

Las claves son claras: descubrir el nivel mínimo de calidad que el cliente esta dispuesto a aceptar y mantenerse alrededor del mismo durante todo el proyecto. La pregunta es ¿qué mecanismos establece Scrum para que esto ocurra?: El sprint review y los incrementos de funcionalidad potencialmente entregables.

El sprint review, actúa como regulador de la calidad. Por un lado nos va a permitir detectar, mediante el feedback que los asistentes aporten, si estamos lejos o no del nivel de calidad requerido. Además, que el equipo presente las nuevas funcionalidades, es un catalizador clave de la calidad: asegurando una calidad mínima (da mucha vergüenza que te ‘casque’ una demo) y asegurando que el equipo percibe cual es el nivel de calidad mínimo aceptable.

Los incrementos de funcionalidad potencialmente entregables son otro aspecto clave de Scrum. Si algo es ‘potencialmente entregable’, como debe ser el resultado de todo sprint en Scrum, debe cumplir las expectativas de calidad de nuestro clientes (o de su proxy, el Product Owner). Si algo no cumple las expectativas del cliente, no está completado y no se sigue avanzando. Esta es la única manera de asegurar que el equipo no toma atajos sacrificando funcionalidad o no cae en el preciosismo, añadiendo calidad que el cliente no está dispuesto a apreciar y mucho menos a pagar.

Un error habitual es recortar el sprint review o saltárselo, de tal manera que el equipo nunca llega a descubrir cual es el nivel de calidad mínimo aceptable por el cliente o no se asegura que no estamos lejos de este.

En la próxima entrega, Scrum y el triangulo de la gestión de proyectos: El alcance.

Agile Open Spain 2009: ¡impresionante!

Rodrigo Corral — Mon, 26 Oct 2009 06:46:00 GMT

Aun estoy que no me lo creo. Pedazo de evento nos ha salido, y cuando digo nos ha salido me refiero a los 160, si 160, asistentes. Aunque los patrocinadores y la organización también hemos tenido algo que ver seguro. No cito a nadie de la organzación para no dejarme a nadie: compromiso compartido y responsabilidad compartida, para lo bueno y lo malo.

No esperaba yo tanto de este evento, sobre todo era bastante escéptico en lo que al formato de open space se refiere. Eso de no tener una lista de sesiones de antemano me ponía un poco nervioso ¿cómo podía saber que las sesiones merecían un viaje desde Bilbao? ¡Nada me garantizaba tener un hueco a pesar de que mi empresa patrocinaba el evento! ¿y si no había temas suficientes? ¿y si había mucho? ¿y si construir la agenda era un proceso eterno?… El resultado a tener de la retrospectiva que entre todos los asistentes realizamos al final del evento no puede ser más satisfactorio. En lo personal decir que a sido uno de los eventos en los que más he disfrutado… y mira que he participado en eventos ¿eh?…

La primera jornada del evento, viernes por la tarde, se dedicó a montar la rejilla. Básicamente el proceso es escribir el título de tu propuesta (sesión, debate, charla magistral o lo que sea) y tu nombre en una tarjeta, comentar en un minuto de que va el tema y luego poner tu tarjeta en un panel con una chincheta. Luego todos los asistentes cogen tres pegatinas rojas que representan votos y las reparten por aquellas sesiones de su interés. Se recogen las sesiones más votadas y de manera colaborativa se distribuyen por la rejilla de sesiones. Entre mi compañero Jose Luis y yo propusimos cinco sesiones (tampoco hay que abusar) y salieron las cinco. Una pena que una de J se solapo con una mía y no pude asistir. El que salgan todas tus propuestas tiene una pega, no puedes ir a las sesiones de los demás… es el único pero que puedo poner. A continuación podéis ver la rejilla. Repasando la rejilla he visto que hay una sesión mía a la que no asistí, ¿Ya tengo Scrum y ahora qué?, se fusiono con otras y no me di cuenta. Pensé, erróneamente que se había quedado fuera, lamento el error y pido disculpas.

Las sesiones a la que acudí fueron:

Artesanía del software, propuesta por Xavi Gost

Esta sesión molo de verdad, la más friki, de todas la que asistí, sin duda. Pura diversión. La radical propuesta de Xavi (al que le ‘da vergüenza ser tan frki’ jajajaj…) era dejar fuera de la sala todo lo que oliese a negocio y centrarnos en la parte más artesanal, lúdica y motivadora del desarrollo de software. A final la sesión se centro en la belleza del código. Xavi defendía que el código debe ser bello, que el código bello en un valor en si mismo y yo, en otra línea más utilitarista comentaba que para mí el código bello es el código bueno. No todo el mundo compartía mi opinión. Se habló de analizadores estáticos, que garantizan un mínimo de calidad pero nunca belleza y todos concluimos por unanimidad que el camello de Perl es tan bello como mal ejemplo de código mantenible. También se hablo de las escuelas de programación y su relación con las escuelas de Kung Fu. La idea de Xavi que comparto plenamente es que a programar se aprende principalmente con maestros, con gente que te ayuda, es paciente contigo, te corrige el código con cariño (o tobas, en esto no nos pusimos de acuerdo), y leyendo buenos libros. Podéis ver otro resumen de esta sesión (y de otras) y la lista completa de libros propuestos en el post que ha publicado Jose Manuel Prieto sobre el evento.

Control en proyectos ágiles, propuesta por mi

Mi idea para esta sesión era debatir y compartir con los asistentes las métricas y técnicas de control y seguimiento de proyectos que utilizan las metodologías ágiles. Utilice la siguiente ppt para romper el hielo:

Luego a base de preguntas a la audiencia y su participación llegamos a las siguientes conclusiones, que fuimos poniendo en una pizarra durante la sesión:

La base del seguimiento del avance de un proyecto de un proyecto es utilizar tareas pequeñas y binarias.
Es necesario visibilizar y medir el avance.
La métrica clave es la velocidad, pero hacia fuera del equipo interesa más el grado de cumplimiento de lo comprometido en el sprint.
Para cumplir hace falta compromiso, sin equipos dedicados no se logra compromiso. Definir tus equipos es vital.
Solo con estimaciones colegiadas y consensuadas, logramos compromiso por parte del equipo.
Es vital la priorización. Cuando las métricas cantan que estamos retrasados, no tenemos más opción que recortar funcionalidad.
Sin priorización ese recorte deja fuera características importantes y daña el resultado del proyecto irreversiblemente.

Tres años de proyecto con Scrum, propuesta por mi

En esta sesión, ya un clásico, pues la he presentado en una u otra forma en varios foros diferentes trate de comentar mis experiencias de tres años en un proyecto gestionado con Scrum y Team System como herramienta de gestión. Una vez más use una ppt para romper el hielo:

En esta sesión hable de las dificultades, las acciones tomadas ante ellas y los resultados que nos ha dado la adopción de Scrum y Team System en el desarrollo de Captor 3 en Sisteplant. Angel Agueda tiene un excelente resumen sobre esta sesión en su blog, así que os remito a el.

Oficina de proyectos ágil, propuesta por Xavier Albaladejo.

Lo mejor de la sesión sin duda, escuchar las experiencias de Xavier en Indra y ver como está cambiando el panorama de la gestión de proyectos en empresas de esa envergadura gracias a tipos como él. La otra gran cosa fue coincidir con mi viejo conocido Angel Medinilla. Angel es uno de los grandes del agilísmo en España, coincidí con él en el curso de CSM y desde entonces, de un modo u otro hemos estado en contacto. Poder debatir con él la visión de una oficina de proyectos ágil fue toda una experiencia. La principal conclusión de la sesión para mí fue que una oficina de proyectos (PMO) que de una visión global de todos los proyectos de la empresa y que de soporte en ingeniería ágil a todos los proyectos es posible y deseable. También fue muy interesante la aportación de gente que ya está en PMOs, como Juan Mari Huarte de Orona.

Documentación ágil e historias de usuario propuesta por Jose Luis Soria, también de Plain Concepts y por otra persona cuyo nombre no recuerdo (disculpas):

Excelente sesión en la que se trataron temas como:

¿Cúal es la utilidad de la documentación?
¿Cómo de útiles son las historias?
¿Cómo es una buena historia?
La importancia de las condiciones de aceptación
Documentar frente a refactorizar

Las principales conclusiones:

La documentación es un subproducto del software que funciona. Debemos evitarla.
Los wikis pueden ser de gran ayuda, pero también tienen problemas relacionados con la organización, la responsabilidad sobre el contenido etc…. Ninguno de estos problemas anulan su utilidad.
Debemos tender a generar toda la documentación.
La única documentación única es aquella que evoluciona a la vez que el código.

Seguro que Jose Luis nos contará más cosas sobre esta sesión y sobre la otra sesión que propuso sobre gestión de la configuración en proyectos ágiles.

Destacar la aportación de Joao Gama en esta sesión. No todos los días se encuentra uno con un Product Owner profesional y que se dedica a ello ‘full time’. Esto es algo que me encanto del formato open space, ¡cualquiera puede aportar en una sesión!.

Mi conclusión sobre el evento: excelente, no he estado nunca en un evento más participativo. Todo el mundo tuvo voz y todo el mundo tenía cosas interesantes que decir. Pensé que no tenía mucho que aprender sobre agilidad, que era un campo ya muy arado, ¡como me equivocaba!.

Y sabéis lo mejor ¡este era el primer evento de Agile Spain!… en próximas ocasiones no se que va a ser esto…

Por último decir que también aprovechamos para constituir oficialmente como asociación Agile Spain. Puedo presumir de ser uno de los que han firmado los estatutos aun a costa de casi perder el avión… menos mal que lo cogí, sino me cuesta el matrimonio y con razón.

Podéis encontrar una recapitulación de post, fotos y twits sobre el evento en esta página.

¡Un saludo!

Luchando contra los interbloqueos en Sql Server (II): Read Commited y el modo snapshot

Rodrigo Corral — Tue, 20 Oct 2009 15:09:00 GMT

Hace ya un tiempo escribía sobre cómo evitar los interbloqueos en Sql Server y como diagnosticar que les está causando cuando se producen. Hoy quiero contar un pequeño ‘truco’ que nos puede ayudar a, sin cambio alguno en el código de nuestra aplicación, reducir las probabilidades de sufrir un bloqueo. Este pequeño truco es un ‘antídoto’ que nos permite solucionar a menudo problemas de interbloqueos con un mínimo impacto sobre la aplicación. Además, esta técnica también puede mejorar el rendimiento de aquellas aplicaciones que estén sufriendo problemas de esperas en bloqueos entre lectores (selects) y escritores (updates e inserts).

El nivel de aislamiento por defecto de Sql Server es Read Commited. Esto quiere decir que este nivel es el más utilizado y que si no tienes ni idea de qué es el nivel de aislamiento este es el que estás utilizando. En este nivel de aislamiento, con el fin de evitar las lecturas sucias, cuando una consulta esta actualizando una fila, establece un bloqueo sobre la misma. Este bloqueo hace que quien quiere leer esta fila, se encuentre con que debe esperar. Este bloqueo en principio inocuo, puede se origen de interbloqueos en aplicaciones altamente concurrentes que no se hayan diseñado adecuadamente. Cuantos mas bloqueos, menos rendimiento, y más posibilidades de interbloqueos Tengo que decir, antes de que mi compañero Pablo Alvarez Doval, gurú de estos temas, me saque los colores, que he simplificado mucho la película, para no liar el asunto.

A partir de Sql Server 2005 se introdujo un nuevo modo de funcionamiento para el nivel de aislamiento Read Commited, que sigue evitando las lecturas sucias y que también evita ese posible bloque dañino del que hablábamos. Este modo es el modo Snapshot del nivel de aislamiento Read Commited, en el que, simplificando de nuevo el asunto, en lugar de establecer un bloqueo que para las lecturas, hace una copia en la sombra (snapshot) de las filas que se están modificando y si alguien intenta leer no lo bloquea sino que devuelve el valor copiado en la sombra. Resumiendo, no hay lecturas sucias como exige el nivel Read Commited y además no hay bloqueo.

Una ventaja adicional de este modo, es que es así y solo así como Oracle se comporta, luego si tu aplicación soporta Oracle y Sql Server, con este modo consigues el mismo comportamiento en ambas bases de datos en lo que a las transacciones Read Commited se refiere.

Evidentemente nada es gratis en la vida, y a cambio de no tener bloqueos, vamos a tener más trasiego en la base de datos temporal (TempDb) donde se almacenan los Snapshot y esta va a crecer en tamaño. En la mayoría de las ocasiones este es un mal menor.

Corolario: Si tienes una aplicación que está sufriendo bloqueos o interbloqueos, donde hay tablas que se escriben y leen concurrentemente, activar el modo Snapshot puede ayudarte a solucionar el problema.

Os dejo un script que establece el modo Snapshot para el nivel de aislamiento Read Commited para un base de datos:

-- Script que cambia en comportamiento del nivel de aislamiento -- READ_COMMITED para que use snapshots (READ_COMMITTED_SNAPSHOT ON) -- ¡OJO!: Ejecutar este script establece la base de datos a modo -- de usuario único y por tanto termina las conexiones actuales a la -- base de datos -- Establecer la base de datos sobre la que haremos el cambio USE <nombreDeBaseDeDatos> -- Comprobar que la versión es SQL Server 2005 o superior IF ((SELECT @@microsoftversion / 0x01000000) >= 9) BEGIN DECLARE @sql VARCHAR(8000) SELECT @sql = 'ALTER DATABASE ' + DB_NAME() + ' SET SINGLE_USER WITH ROLLBACK IMMEDIATE ; ALTER DATABASE ' + DB_NAME() + ' SET READ_COMMITTED_SNAPSHOT ON; ALTER DATABASE ' + DB_NAME() + ' SET MULTI_USER; ' EXEC(@sql) END ELSE PRINT 'La versión de su SQL Server no soporta READ_COMMITTED_SNAPSHOT' GO

¡Suerte en la batalla contra los bloqueos y los interbloqueos!

Estuve, subido a la nube con Windows Azure, en el CodeCamp de Tarragona

Rodrigo Corral — Mon, 19 Oct 2009 13:41:00 GMT

Este pasado fin de semana tuve el enorme placer de ser uno de los ponentes del CodeCamp, evento que mi empresa Plain Concepts patrocinaba siguiendo con su línea de continuo apoyo a la comunidad de desarrolladores en .Net. Tuve la oportunidad de exponer en dos sesiones una sobre la plataforma Windows Azure y otra, compartida con dos titanes del tema Luis Fraile y Bruno Capuano, sobre las novedades de VSTS 2010.

Sobre la sesión de Azure puedo decir que me sorprendió gratamente la asistencia que hubo, no esperaba tanto interés sobre el tema, la verdad, y sin embargo la sala se llenó. A continuación os dejo la PPT que use, no tiene mucho contenido, puesto que al ser el evento un CodeCamp traté de mostrar código, pero quizás veáis en ella información que os interese. Si tenéis algún feedback sobre la charla, no dudéis en dejarlo en los comentarios de este post.

En la charla sobre las novedades de VSTS 2010, que puedo decir, que disfruté como un enano compartiendo sesión con Bruno y Luis. La verdad es que da gusto ver como cuando hay comunidad de por medio, podemos dejar a parte la lógica competencia entre empresas y pasar un rato charlando sobre los temas que nos apasionan.

No puedo cerrar este post sin un agradecimiento explicito a la organización de evento. El esfuerzo realizado por los grupos de usuario implicados y por las personas que ha llevado adelante la organización a sido espectacular. Un diez señores, podéis sacar pecho de comunidad .Net. Además hay que destacar que en esta ocasión también Mono estuvo presente, más comunidad aun, incorporando otras plataformas. Jose Miguel Torres, Viçens Masanas, Toni Recio, Marc Rubiño (y seguro que algunos otros que me dejo), se han lucido con la organización. No es fácil montar un evento para trescientas personas y que no haya fricciones y todo vaya como la seda.

Decir, por último que la sesiones fueron grabadas, así que supongo que, tras maquetarlas un poco, en un tiempo estarán disponibles para que las podáis disfrutar aquellos que no pudisteis asistir al evento, ¡estad atentos!.

¿Hasta donde podemos llegar?

Rodrigo Corral — Mon, 28 Sep 2009 20:33:00 GMT

Un anuncio de Microsoft decia: ‘hasta donde quieres llegar hoy’ o algo así, pero la pregunta es más bien ¿hasta donde puede llegar la ingeniería del software?. Comenta Gustavo, vecino de blog y uno de los grandes de Sharepoint (y no solo de Sharepoint) que cada vez la complejidad de los proyectos de Sharepoint es mayor, tanto como para que en muchas ocasiones lo mejor sea esconder la cabeza como un avestruz. Yo lo se bien, pase de conocer a fondo la versión 2003 a caer en la sima de la transición a 2007. Hace tiempo que deje de ser un experto en Sharepoint, si es que alguna vez lo fui del todo, el salto a la versión 2007 me supero, demasiada complejidad para un humano mortal.

En mi opinión lo que Gustavo comenta no solo está ocurriendo en Sharepoint. Es un problema generalizado, cada vez más voces importantes del mundo de la ingeniería de software se preguntan si no hemos alcanzado un punto de singularidad en el que la complejidad de los problemas a resolver se ha incrementado más allá de lo manejable.

Hace poco veía un proyecto que han hecho una compañeros de Plain Concepts. La interfaz es realmente acojonante, lo que antes serían aburridas cajitas de texto y etiquetas ahora son preciosos controles de WPF que informan visualmente del estado de los aparatos que la aplicación monitoriza. Se cae la baba viendo la interfaz. Pero eso tiene un precio. Hay miles de líneas de WPF y XAML. ¡Miles de líneas en la interfaz de usuario!. Se que muchas son generadas, pero me da igual, generadas o no son fuente de complejidad. La herramienta las genera, pero tu las mantienes y cuando la herramienta falla o la abstracción fuga, el problema es tuyo. Más código más problemas.

Los sistemas son cada vez más complejos, exponencialmente más complejos, pero las herramientas han cambiado solo sutilmente. Ya nos sabemos eso de KISS, si, pero no es suficiente. En esencia, desde que Grace Murray, almirante de la marina estadounidense y probablemente la mujer más influyente en la historia de la ingeniería de software, invento el compilador, no se ha producido un cambio cualitativo importante en la forma en que se hace software. Codificar, compilar, depurar. Solo se han añadido billones de horas hombre al desarrollo de software. Fuerza bruta. El problema es hasta donde escala esta aproximación... cada vez parece más que hemos tocado techo. Hay quien incluso ha puesto nombre a este problema: el dilema de la divergencia del software. Ahí es nada…

Para que os hagáis una idea. Un avión de caza de los años 60, tenía típicamente unas cincuenta mil líneas de código, un caza moderno unos cinco millones de líneas de código. Cada vez me da más por los aviones para hablar de software :). En este periodo, pese a la evolución de las herramientas, los estudios más optimistas sostiene que se ha doblado la productividad de los desarrolladores. Y mucha de esa productividad se ha ido en actividades de coordinación entre los miembros el equipo.

Barry Boehm, padre del modelo COCOMO y padre del ciclo de vida en espiral, comentaba en 2004, en un conferencia auspiciada por el DoD (Department of Defence, el mayor contratista de software del mundo por mucho), que ‘la cantidad de software que el DoD necesita crece exponencialmente, por lo tanto nunca podremos completarlo en un tiempo finito de tiempo’, para echarse a llorar... o no, también se puede hacer la lectura positiva: los informáticos tenemos una cantidad de trabajo infinita por hacer.

Yo personalmente soy pesimista. Todos los intentos de atajar la complejidad que hemos realizado han sido en vano. Los patrones parecían prometedores, pero aunque útiles no han supuesto una revolución. Las herramientas 4GL se postularon como una especie de bálsamo de Saxafrax, que se quedo en nada ¿alguien usa 4GL?. Las herramientas de modelado… en fin… esperemos a Oslo, pero mucho me temo que tampoco será mágico… y necesitamos mucha magia. Las herramientas no van a ser la solución al problema. Fijaros, llevo programando desde VB3.0. En la caja de todas la herramientas de programación que he usado desde entonces ponía algo parecido a ‘mejora tu productividad un X%, siendo X > 20’. He conocido VB4, VB5, VS6, VS2001 (productividad con esteroides gracias a .NET), VS2003… hasta VS2010. Si cada versión hubiese mejorado mi productividad lo que su marketing prometía ahora yo sería capaz de programar con la mente.

En el lado de los procesos de desarrollo, me conformo no ya con ganar productividad, sino simplemente con poner orden en el caos que se contempla en la gran mayoría de los equipos de desarrollo. Mejoras lo que se dice mejoras, se ven, pero no radicales no nos engañemos.

Ahora todos los proyectos dan miedo, mucho miedo, no hay proyectos sencillos. No los hay. Aun recuerdo cuando, en mi época de freelance, yo, con veinte añitos recién cumplidos era el rey del mambo: ¡sabia que existían los módulos de clase, sabía que existía DCOM y como hablar con SQL Server!, estaba a años luz del programador medio. Ahora todos los proyectos dan miedo. Hay unas frase de Linus Tordvals que son esclarecedoras: ‘No esperes hace nada grande en poco tiempo’ dijo, ‘he estado trabajado en Linux trece años, y creo que lo hare durante bastante tiempo más. Si hubiese pensando que me estaba metiendo en algo tan grande, nunca hubiese empezado’. Esclarecedor. Hay que tener un punto de incauto para meternos en los proyectos que nos metemos.

El tema se resume en dos frases, una de Donal Knuth: ‘hacer software es difícil’ y otra de Fred Brooks: ‘no hay balas de plata’ que da título a uno de los grandes ensayos de la historia de la ingeniería del software. Brooks es también el padre de la ley que lleva su nombre y que dice que ‘añadir desarrolladores a un proyecto retasado solo lo retrasa más’, luego extrapolando esta ley, añadir más fuerza de desarrollo no va a arreglar el problema como ya he comentado.

La paradoja es que dificultad es tal que necesitamos unas balas de plata que no tenemos en nuestra arsenal. Unamos a esto que la ley de Moore ya no está ahí para salvarnos el culo permitiéndonos cambiar complejidad por ciclos de reloj. Tenemos una tormenta perfecta. ¡Hemos llegado al límite!.

¿Sois vosotros igual de pesimistas que yo? Gustavo creo que sí.

Curso de Scrum con Team System en Bilbao (2º edición)

Rodrigo Corral — Mon, 21 Sep 2009 13:37:00 GMT

Entre Plain Concepts y Sarein hemos preparado un interesante curso sobre Scrum y Team System: Gestión ágil de proyectos con Metodología Scrum y Visual Studio Team System que tendré el placer de impartir los días 30 de Septiembre y 1, 2 de Octubre en Bilbao.

El contenido del curso, que tiene una duración de 24 horas es:

Scrum

Introducción a Scrum y las metodologías ágiles
Roles en Scrum
Definición de Sprint
Artefactos en Scrum
Gráficos de progreso y control del proyecto
Comunicación en Scrum
Escalando Scrum
¿Precio y fecha cerrados con Scrum?
Madurez y Scrum
Las reglas de Scrum

Visual Studio Team System

Team Foundation Server y el ciclo de desarrollo
Gestión del proyecto utilizando elementos de trabajo y Scrum
Gestión de fuentes
Herramientas para calidad

El precio del curso, es de 900 euros e incluye el almuerzo de los tres días.

¡Espero que os animéis!

Plain Concepts patrocinador del Agile Open Spain 2009

Rodrigo Corral — Sun, 20 Sep 2009 17:26:47 GMT

Siguiendo la tradición de Plain Concepts y sus profesionales de colaborar con la comunidad en todas las ocasiones que se presente, tenemos el gusto de comunicar que seremos co-organizadores y co-patrocinadores de la próxima edición de Agile Open Spain 2009, a celebrar en Madrid los días 23 y 24 de Octubre (el viernes por la tarde y el sábado).

Agile Open Spain es un evento de comunidad centrado en compartir entre los asistentes experiencias, ideas, dificultades, inquietudes y éxitos sobre metodologías ágiles de desarrollo de software. Este evento tendrá el formato de Open Space con el afán de promover la participación y sobre todo que emerja la conferencia que los asistentes diseñen. No contamos por tanto con una agenda preestablecida, sino que entre todos diseñaremos la conferencia, participando en la selección de las ponencias según su interés.

Desde Plain Concepts, entre un servidor y mi compañero Jose Luis Soria propondremos los siguientes temas:

Gestión de la configuración orientada a la agilidad (charla + demos + ronda preguntas / debate)
Control de proyectos con metodologías ágiles (charla breve + debate)
Dificultades frecuentes y posibles soluciones en la implantación de Scrum (introducción + debate)
Gestión ágil con Team Foundation Server (charla + demos + ronda preguntas)
Behavior driven development (charla + demos + ronda preguntas)
Historias de usuario: ¿son suficiente? (charla + debate)

Aprovecho que todo aquel asistente que lo desee puede proponer una sesión. También me gustaría pediros, que si queréis que plantee alguno de los temas que sobre metodologías ágiles o Scrum he tratado en el blog, no tenéis más que pedirlo.

Las inscripciones han sido un gran éxito y el aforo está completo desde hace tiempo, me gustaría comentar que en Plain Concepts tenemos algunas invitaciones para nuestros clientes, por lo que si tienes interés en asistir, por favor ponte en contacto conmigo.

¡Espero veros en el Agile Open Spain 2009!

Software e innovación… innovación y software: ¿existe un proceso?

Rodrigo Corral — Tue, 08 Sep 2009 22:37:00 GMT

Me encuentro en la Oulanka Research Station de la Universidad de Oulu en Kuusamo, un lugar perdido de Finlandia, a 25 km del círculo polar. Donde Cristo perdió el gorro, vamos. El sitio es precioso: cientos de lagos, miles de arboles, renos en medio de la carretera y una paz que invita a pensar.

En el marco del proyecto ITEI, subvencionado por la Unión Europea, un puñado de ingenieros, académicos y gente de la empresa estamos buscando desarrollar una metodología y un soporte informático abierto para la gestión de la innovación en el desarrollo de sistemas de software. Hay es nada. De este proyecto deben salir una especie de libro blanco de la innovación en el marco del desarrollo de software (SinnoBok) y el diseño de un ecosistema de software que soporte esta proceso de innovación (CyberRoom).

Mi participación, en representación de Sisteplant, es como empresa que está innovando en el desarrollo de software usando metodologías ágiles. Debo aportar que requisitos tenemos en nuestro proceso de desarrollo e innovación para que sean incorporados como parte del proyecto y actuar como caso de uso de la puesta en marcha de lo que sea que salga del proyecto.

El motivo de este mail, es comentar la esencia del proyecto. ¿Es posible definir un proceso de innovación? ¿Es la innovación algo que se puede materializar en un proceso? ¿Hay una serie de pasos que se pueden dar que faciliten la aparición de productos, servicios o vías de comercialización innovadoras en el marco del desarrollo de software? ¿Existe al menos un conjunto de patrones que podamos detectar y describir?. Yo creo que no. Pero también creo que es un camino que es interesante explorar, sobre todo por que hay mucha gente que cree que si y lógicamente yo puedo estar equivocado (es altamente probable).

Lo que quiero comentar es por que creo que no existe un proceso de innovación definible y repetible (¡como les gustaría a la gente de CMMi esto!). Mis argumentos son los siguientes:

1) No hay dos productos de software iguales, no hay dos proyectos iguales, no hay dos equipos iguales, no hay dos empresas iguales. Si tenemos en cuenta que el marco del desarrollo de software es tan diferente y cambiante, es sumamente difícil encontrar un marco que funcione en todas. Esto ocurre con las metodologías, que para funcionar necesitan un fuerte proceso de ajuste e implantación. Si añadimos a esto, que por su propia naturaleza, una innovación es radicalmente diferente de cualquier otra cosa existente, la cosa se complica aun más.

2) Viendo la historia de las innovaciones recientes: el procesador, el ratón, el compilador, las redes, el ordenador personal, la web, las listas de correo, el chat, las redes sociales, las metodologías ágiles… no hay dos que hayan surgido de una manera similar. Es imposible trazar un patrón. En cada situación se partía de unas condiciones iniciales diferentes, se siguió un proceso diferente, se llegó al final del proceso y se comercializo la idea de manera diferente. Pensad en como surge el concepto de Wiki, por poner un ejemplo, base de algo tan rompedor en la cultura moderna como Wikipedia: Ward Cunningham uno de los padres de los patrones, arto de recibir mails pidiéndole que corrija tal o cual detalle en su catálogo de patrones, decide añadir un simple botón que permita a cualquiera editar el html de la página. Una innovación radical, algo nuevo, que nadie ha hecho antes, que no era especialmente ambicioso, que podría haber concluido en un desastre de gente haciendo el vándalo en su sitio y que acaba cambiando el modelo de enciclopedia que se conocía desde la ilustración francesa. Impresionante. ¿Pero como catalogarlo? ¿Cómo sistematizar los ocurrido para facilitar que surjan nuevas innovaciones?. Imposible.

3) No hay una receta para desarrollar software, menos para desarrollar software innovador. Aunque Joel Spolsky incluso tiene un receta para hacer que tu software sea el número 1 ;). El desarrollo de software es un arte. Generalmente detrás de cada gran innovación en este campo hay una persona que actual como un gran catalizador, un artista o un grupo de ellos: La WWW y Tim Berners-Lee, Linux y Linnus Torwalds, GNU y Stallman, C++ y Stroustroup, C# y Gunnerson, los patrones y la Gang of Four, Google y Larry Page y Sergei Brin... Ningún proceso garantiza que ese catalizador va a aparecer, más bien al contrario. Parece que la sensación general es que los procesos definidos tienden a encorsetar la creatividad necesaria para innovar. Muchos creen que Microsoft a perdido su capacidad de innovar y que Google la está perdiendo precisamente por esto.

Tom Simpson, ingeniero de IBM y uno de los padres del OS/360 escribió una algo que aplica perfectamente a lo que comento, en un excelente ensayo breve suyo, escrito en 1968, Masterpiece Engineering. Tom escribe la siguiente sátira, que he traducido muy libremente, sobre como un grupo de ingenieros de software estaba buscando los criterios a establecer para diseñar un sistema operativo:

“Estudiando el problema de como lograr establecer el diseño para producir ‘Mona Lisas’ …la Conferencia decidió que se debía establecer un Instituto para trabajar con más detalle sobre los problemas en el campo de la producción de obras maestras. Así que salieron a las calles de Roma y seleccionó unos cuantos conductores de carros, algunos luchadores y otros artesanos y los sometieron durante un período de cinco semanas (a media jornada) a un Curso de creación de obras maestras, y luego todos fueron puestos en una gran habitación y se les solicito que comenzaran con la creación de obras maestras.

Pronto se dieron cuenta de que no estaban consiguiendo los resultados esperados del Instituto, por lo que se trato de equipar a los trabajadores en la producción de obras maestras con algunas herramientas más eficaces para ayudarles a crearlas. Se inventaron cinceles a motor, pistolas de pintura y así sucesivamente, pero todo esto se limito a provocar una protesta ruidosa de los maestros: "Todas estas técnicas se dan en los pintores de técnica descuidada", dijeron.

La producción aún no estaba llegando a niveles satisfactorios por lo que se amplió la gama de técnicas de producción de obras maestras con algunas medidas adicionales. Una idea fue tener un lienzo y que pasase rápidamente de pintor a pintor. Mientras uno estaba aplicando el pincel los demás tenían tiempo para pensar.

El siguiente paso natural a tomar fue, por supuesto, duplicar el número de pintores, pero antes de tomarlo, adoptaron un mecanismo más interesante. Se decidió establecer alguna métrica adecuada de la productividad. Se emplearon dos semanas en el Instituto contando el número de pinceladas por día producidas por un grupo de pintores, y este criterio fue inmediatamente aplicado para calcular valor aportado a la empresa por el resto. Si un pintor fracasaba en lograr sus veinte pinceladas por día sería claro que se trataba de alguien claramente improductivo.

Lamentablemente ninguno de estos avances en el conocimiento parecía tener un impacto real sobre la producción de obras maestras y así, al fin, el grupo decidió que la dificultad básica era claramente un problema de gestión. Uno de los más brillantes estudiantes (con el nombre de Leonardo da Vinci) fue inmediatamente promovido a gerente del proyecto, poniéndolo a cargo de la adquisición de pinturas, lienzos y pinceles para el resto de la organización.”

Evidentemente no lograron producir una obra maestra.

Entiendo que el mensaje puede ser poco esperanzador, que sueno muy pesimista, pero si que es cierto que hay cosas que podemos hacer para mejorar la innovación. Muy generales, pero hay están. Y son precondiciones. Sin estas precondiciones, no surge la innovación. Quizás facilitar la eliminación de estas barreras de entrada a la innovación sea la innovación que debemos esperar de este proyecto. La gente del VTT y de Sirris ha propuesto unas áreas clave de la innovación que ellos han llamado, en un claro reconocimiento de la naturaleza artística del problema, El Arte de…:

… mantenerse enfocado.
… experimentar.
… optimizar el impacto de tus recursos de alto impacto (tus artistitas vamos…).
… abrirse al mundo (openness tiene una traducción difícil…).
… estimular la innovación.
… de mejorar la innovación.
… de la incubación de ideas.
… de la recolección de ideas.
… de la evaluación de ideas.

A mi me suena que Scrum puede dar una respuesta a algunas de estas preguntas ;) ¿pero realmente si conseguimos responder estas respuesta, estamos consiguiente ser innovadores? No en vano uno de los objetivos de Scrum y de las metodologías en general es ser capaz de incorporar el cambio y la innovaciones que surgen al proceso de desarrollo. Al fin y al cabo: ¿no es toda innovación un proceso de cambio radical?.

Espero que os animéis a dar vuestra opinión, ya que todos los que estáis en el mundo del software sois innovadores por naturaleza. Con cada línea de código que escribís, estáis haciendo algo nuevo. Esto nos diferencia claramente de otras industrias.

¡Un saludo!

Instalando Ubuntu en un PowerMac G4

Rodrigo Corral — Wed, 02 Sep 2009 08:43:41 GMT

Algunos no somos tan afortunados como el amigo Rafael, poseedor de un flamante y nuevecito Mac. Yo me tengo que conformar con un PowerMac G4, con 512Mb de RAM, un procesador PowerPC a 400MHz un disco duro de 10Gb y una tarjeta ATI Rage de 128Mb, un equipo que tiene más de una década y que aun tiene un aspecto realmente acojonante. Es un placer abrir la caja, sin soltar un solo tornillo, simplemente accionando una palanquita de diseño perfectamente integrada en la caja, y echar un vistazo dentro. Que acabados tiene este hardware, impresionante. Antes de hacer nada tuve que limpiar las babas que se me cayeron en la placa base. Es una máquina increíble: cuando salió la mercado se catalogo como material sensible para la exportación por su potencia.

Se ve, nada más abrirlo, que el equipo es una gran máquina, con un sistema operativo muy antiguo, Mac OS 9.2, una reliquia de los tiempos de Windows 3.1. La pega es que no he podido instalar Windows 7, que no soporta procesadores PowerPC. Aunque la máquina soporta perfectamente Mac OS X 10.4 ‘Tiger’, no tengo los CDs de instalación. Así que me he tenido que decantar por Ubuntu 9.04. Será suficiente pues el único cometido del equipo en cuestión será pinchar MP3 en el Pub Jonh Lennon que mi amigo Javier aka Paisano tiene en Belorado.

La instalación de Ubuntu ha ido rodada. Simplemente bajarme la ISO de la versión para PowerPC, tostarla en un CD y arrancar el Open Firmware del Mac (no arranca directamente el CD) hay que hacerlo a manopla. En este equipo, no funciona arrancar pulsando C. Hay que arrancar el Open Firmware (pulsando alt + manzana + o + f) y luego ejecutar el siguiente comando:

boot cd:;\install\yaboot

A partir de aquí la instalación de Ubuntu va como la seda.

Una vez instalado Ubuntu he tenido algunos pequeños problemas:

1) Configurar los drivers de la tarjeta gráfica (sino solo se soportan 800x600 y Xorg consume un montón de procesador haciendo la máquina muy lenta).

La solución es simple, basta editar el archivo /etc/X11/xorg.conf:

sudo gedit /etc/X11/xorg.conf

El contenido del archivo es el siguiente (tened en cuenta que mi monitor es un Philips 107S, pero lo relativo a la tarjeta gráfica serviría para cualquier PowerMac G4 con tarjeta ATI Rage 128 AGP):

Section "Device"
        Identifier         "ATI"
        Boardname       "Ati Rage 128 M3"
        Driver               "r128"
        Screen              0
        Vendorname     "ATI"
        Option              "MergeFB"   "off"
EndSection

Section "Monitor"
        Identifier          "Configured Monitor"
        HorizSync         30.0 - 71.0
        VertRefresh      50 - 160
        Option              "DMPS"
EndSection

Section "Screen"
        Identifier          "Default Screen"
        Monitor            "Configured Monitor"
        Device              "ATI"
        DefaultDepth    24
                Subsection "Display"
                        Depth     24
                        Modes    "1024x768" "800x600" "640x480"
                EndSubsection
EndSection

2) No ~~puedo~~ podía escribir arrobas (@), ni pipes (|), ni sostenidos (#)…

Vamos a Sistema->Preferencias->Teclado y seleccionamos como modelo de teclado PC genérico 105 teclas (intl), en distribución seleccionamos España Macintosh. Luego pulsamos el botón Opciones de distribución… en Key to choose 3rd level, marcamos Rigth Win y listo, la manzana de la derecha pasa a ser nuestro amado Alt Gr.

3) La hibernación no funciona, aunque el equipo hiberna, luego no se despierta. Así que la he desactivado y listo.

Otro tema interesante es que, lógicamente el equipo no tiene una tarjeta Wireless, solo una conexión Ethernet. Yo en el pueblo solo tengo acceso a internet por wireless (cortesía de un vecino). Así que conecté el Mac a mi portátil mediante un cable de red cruzado, active la conexión compartida a internet en el portátil, y listo, conexión a internet en el Mac.

Una fuente espectacular de información, sin la que me hubiese costado mucho hacer andar este equipo, es la FAQ de PowerPC de Ubuntu también me ha servido enormemente un artículo sobre como hacer que Ubuntu sea más amigable en un Mac. Aquí podéis ver como el G4 arranca Ubuntu 9.04.

No es que la máquina vuele, la verdad, pero es usable para su cometido, navegar por internet, ripear CDs y reproducir MP3.

La siguiente misión es instalar OS X Tiger en este equipo, estoy removiendo Roma con Santiago para encontrar el DVD de instalación. A ver si logro dar con el.

P.D.: Como me mola lo de trastear con hardware viejuno… tengo una flamante estación SGI Indigo Impact a la que llevo metiendo mano meses y aun no he conseguido actualizar el Irix que trae. No tengo la password del root, no tiene lector de CD, y no he logrado instalar Irix por red desde Ubuntu, por mucho que lo intento… pero la historia va a cambiar, junto con el G4 han caído en mis manos dos CD externos SCSI, justo lo que necesito para revivir la Impact… :)… ya os contaré.

Lo quiero todo, todo y todo… o la triste realidad del triángulo de la gestión de proyectos

Rodrigo Corral — Sun, 23 Aug 2009 19:53:00 GMT

Resulta que esta mañana me he levantado graciosito y no se si como resultado del aburrimiento, de la pila de días de descanso vacacional que llevo, o de los cubatas del Cebolla Rock, me he propuesto hacer un experimento. Me he ido al concesionario de BMW más cercano, he buscado a uno de esos aseados y sonrientes y le he dicho…

Buenos días, me gustaría comprar un 750i, blanco, que le gusta a mi mujer de eso color, aunque a mi me parece un poco taxi. Taxi, un 750i, ni aunque le ponga lucecita verde hombre, ha dicho el comercial. Ya que estamos, no lo vamos a mirar, he seguido yo… póngamelo con llantas de 20’’, como no y todos los extras, lo quiero todo, todo y todo… si si el paquete M también, como no, yo soy un joven, dinámico y profesional, no puedo ir por el mundo sin el paquete M, faltarías más.

¿No sería interesante añadir también la garantía extendida? Por su tranquilidad, ya sabe. Ha dicho el comercial. Y claro, pues yo he pensado… como no se me habrá ocurrido, póngalo, póngalo. Quizás no lo use pero que le vamos a hacer, nunca se sabe lo que puede pasar.

Y la bola de caravana, ¿no la necesitará usted?… Hombre, yo no tengo caravana, pero ya que lo comentas, y como nunca se sabe, a lo peor me da por cambiar el pueblo por un camping… venga vale, total, molestar tampoco molesta.

Y claro, seguro que un profesional, joven, dinámico, con paquete M y toda la zarandaja es una avezado ciclista, de los de mountain bike molona, de esos de los de gafas Oakley, maillot, culotte, zapatillas y pedales automáticos ¿no? Seguro que necesita el exclusivo portabicicletas de BMW para pasear, digo transportar sus bicis. Pues no, he dicho yo, eso si que no, que yo hace mucho que deje la bici y soy de pelota mano y tal y cual. Hombre, recuerde que nunca se sabe, ha dicho el comercial, y se lo dejo a precio de risa, a añadido. Así que he pensado, por si acaso, con portabicis, ¿voy a saber yo más que el comercial?.

Ya solo nos quedan dos detalles menores. Empecemos por el plazo de entrega. El comercial a empezado a farfullar no se que de disponibilidad, que si las opciones retrasan no se que y no se cual. Yo he pensado, coño, aquí el cliente soy yo ¿no? y le he dicho… a ver si yo lo entiendo todo, pero me lo tienes para dentro de dos semanas, son fiestas del pueblo y tengo que fardar. El comercial no ha dicho ni mu, es más me ha dicho, que quizás lo tenga un poco antes.

El segundo tema menor, el precio. Aquí yo he tomado la iniciativa que para algo soy el cliente ¿no?. Para esto tengo treinta mil euritos, entiendo que tengo que poner otros dos cientos, por la llantas, pero esto es lo que hay. Me han dicho que en la india hay unos concesionarios que lo hacen más barato y mejor, eso sí, por evitarme el papeleo que sino te iba a comprar al ti el BMW Rita… la cantadora.

Entonces me he despertado. Claro. ¿Por qué estas cosas solo nos pasan en el mundo del software? La historia no se sostiene, claro está, pero cambiad BMW por aplicación de software, y dar sudores fríos el pensar realismo que se añade. ¿Alguno de vosotros le suena? ;)

Hace mucho, mucho tiempo, que se describió el famoso triangulo o tetraedro de hierro de la gestión de proyectos (hay gente que cree que la calidad también es un factor sobre el que podemos gestionar, yo soy de los que piensan que la calidad no es algo con lo que se pueda especular, la calidad no es opcional, y la marca el cliente, no nosotros).

La idea es que de los tres aspectos: alcance, coste, y plazo, el cliente puede manejar dos grados de libertad. El otro, lo maneja la gestión del proyecto. Esta es en esencia una idea de equilibrio básico entre las partes de un proyecto. Es problema es que a menudo este equilibro se rompe. Incluso hay un antipatrón que describe esta situación. Diferentes metodologías dan diferentes respuestas a este problema, en un próximo post, comentaré la solución que propone Scrum. De hecho el propósito de este post, es comentar el dichoso triangulo de una manera un poco amena, como prolegómeno a dicho post.

Por cierto, ya tengo mi BMW, ha llegado seis meses tardes, no es blanco, y le faltan algunos detalles menores. Eso si, cuatro ruedas y volante tiene. Os dejo una fotito, para daros envidia. No es lo que esperaba, pero esa es otra historia…

¿Qué es lo que hace que cuando se habla de software la realidad se torne tan anómala? ¿Por qué creéis vosotros que es tan difícil mantener el equilibrio descrito en el triangulo de la gestión de proyectos en la realidad? ¿Que factores hacen que salte por los aires tan a menudo en los proyectos? Y no, no vale el argumento fácil: ¡es que los comerciales…! ;)

Emitiendo para toda la galaxia, ¿hay alguien ahí?: Lo que todo desarrollador debe saber sobre los eventos en .Net

Rodrigo Corral — Tue, 18 Aug 2009 23:02:00 GMT

La manera que las clases tiene de alertar a otras clases en los lenguajes orientados a objetos modernos es lanzar eventos. Una clase que no expone eventos, hace mucho más ardua la tarea de los desarrolladores que la consumen a la hora de detectar cambios en su estado. Una clase sin eventos es un clase incomunicada, que dirían los O’funk’illo.

En en sentido amplio, se podría decir que toda clase que diseñemos y que mantenga un estado, debería tener eventos. Si una clase mantiene estado, es evidente que ese estado va a cambiar a lo largo del ciclo de vida de los objetos que instanciemos. Es evidente también que si no exponemos eventos quien quiera enterarse de los cambios en el estado, no tendrá más opción que preguntar activamente a nuestro objeto, en lugar de esperar plácidamente a recibir notificaciones. Nada nuevo bajo el sol, el viejo conocido patrón Observer.

Los eventos son imprescindibles y en .Net son ciudadanos de primera categoría (no ocurre así en otros lenguajes como C++). Aun así, no es extraño ver malas implementaciones de eventos. Es un tema que muchos desarrolladores creen conocer bien y sin embargo se ven a menudo errores relacionados con la mala implementación de eventos. Y es que implementar bien un evento tiene más arte del que podría parecer y se pueden cometer más errores de los que uno puede pensar que varían en gravedad desde complicar la vida a las clases que deriven de nuestra clase que expone eventos hasta introducir condiciones de carrera difíciles de diagnosticar, pasando por simples incorrecciones de estilo. Lo peor de caso, es que al contrario que en otras ocasiones, por la propia naturaleza de estos errores, FxCop no es capaz de avisarnos de ellos.

Vamos al grano. Veamos la implementación más simple posible de un evento en .Net 2.0, los que hemos vivido los tiempos de .Net 1.0 y 1.1 sabemos que la palabra clave event solo es azúcar sintáctico que provoca que el compilador emita por nosotros un delegado. En los tiempos de 1.0 y 1.1 nosotros teníamos que declarar el tipo de delegado ‘a manopla’. Se trata de un evento que ni siquiera implementa su propia clase de argumento del evento. Sería algo como sigue:

    class Publisher
    {
        public event EventHandler SampleEvent;
 
        public void FunctionThatProducesTheEvent()
        {
            SampleEvent(this, EventArgs.Empty);
        }
    }

¿Cuántos errores puede ver en esta implementación? Uno, dos, tres… si no les ves sigue leyendo.

¿Qué pasa si no hay nadie escuchando?

Generalmente, en una conversación, para que se produzca una comunicación correcta debe haber una parte emitiendo y otra recibiendo. Evidentemente esto no aplica si se trata de un grupo de mujeres. Pueden estar todas emitiendo, ninguna escuchando y aun así todas enterarse… misterios de la naturaleza.

En .Net un clase que quiera escuchar los eventos de otra simplemente tiene que subscribirse a ellos:

    class Subscriber
    {
        private Publisher _publiser = new Publisher();
 
        public Subscriber()
        {
            _publiser.SampleEvent += new EventHandler(_publiser_SampleEvent);
        }
 
        void _publiser_SampleEvent(object sender, EventArgs e)
        {
            Console.Write("Habemus evento");
        }
    }

Como la hemos comentado lo eventos se implementan, simplificando el asunto, como delegados. Simplificando otro poco, podemos decir que los delegados son la versión orientada a objetos de los punteros a función. Básicamente la clase que declara el evento es declarando un tipo de puntero a función y un lugar en el que almacenar ese puntero. La clase que se subscribe proporciona la función que realmente se ejecutará, proporcionando el puntero a la función mediante la subscripción. Cuando la clase que lanza el evento hace la llamada al evento (SampleEvent en el ejemplo), simplificando, esta llamando a una función a través de un puntero. Es de lógica que si nadie se a subscrito dicho puntero será nulo, por lo tanto invalido, y en consecuencia recibiremos una fea excepción de tipo System.NullReferenceException. La moraleja: siempre debemos comprobar que alguien se ha subscrito a nuestro evento antes de lanzarlo. Más simple no puede ser:

    class Publisher
    {
        public event EventHandler OnEvent;
 
        public void FunctionThatProducesTheEvent()
        {
            //Comprobar que tenemos subcriptores
            if (SampleEvent != null)
                SampleEvent(this, EventArgs.Empty);
        }
    }

¿Que pasa si hay varios hilos?

El código anterior es más correcto. Pero aun tiene un error, además un bastante sutil, que solo se manifestaría en situaciones en las que haya varios hilos de ejecución. Es una típica condición de carrera. Estamos comprobando que tenemos alguien subscrito, en la siguiente instrucción de código estamos lanzando el evento. ¿Qué impide que la clase que estaba subscrita se haya desuscrito entre medias? Nada. La moraleja: debemos asegurar que si alguien estaba escuchando, siga escuchando cuando nosotros digamos algo.

La solución pasa por manejar nuestra propia copia local de la lista de subscriptores. La implementación de esta solución es:

        public void FunctionThatProducesTheEvent()
        {
            //Copia local de las subcripciones al evento para
            //evitar la condición de carrera entre la comprobación de
            //que hay subscriptores y el lanzamiento del evento.
            //Aunque que todos se desuscriban, nosotros tenemos la referencia.
            EventHandler handler = SampleEvent;
 
            //Comprobar que tenemos subcriptores
            if (handler != null)
                handler(this, EventArgs.Empty);
        }

Aunque todos se desuscriban nosotros seguimos teniendo una referencia. Las consecuencias de esta solución (que es la implementación correcta si seguimos el patrón de eventos de .Net) son varias:

1) Una clase que se haya desuscrito de un evento, en un entorno multihilo, puede aun así recibirlo temporalmente. Si este comportamiento no es aceptable, tendremos que utilizar algún mecanismo de sincronización.

2) Si una clase está subscrito a un evento, no podrá ser recolectada por el recolector de basura, pues aun quedarán referencias a ella. Esta es una forma muy sutil de fugar objetos en .Net: olvidar desuscribir la clase de los eventos a los que está subscrita. Si esto no fuese así, no habría manera de garantizar que siempre hay alguien escuchando. La moraleja: si no desuscribes tus objetos de los eventos a los que estén suscritos de objetos con mayor tiempo de vida, el recolector de basura no puede llevárselos al otro mundo. Un patrón que funciona bastante bien es implementar IDisposable y desuscribirnos de todos los eventos a lo que la clase se a subscrito en el método Dispose.

¿Qué pasa si derivo de un clase que expone eventos?

Supongamos que derivamos una clase de la clase base que expone eventos. Todos sabemos que el motivo para derivar una clase de otra es modificar o extender su comportamiento. Lógicamente uno de los aspectos que no puede interesar modificar del comportamiento de una clase es como se comportan sus eventos, que ocurre cuando se lanzan, que información acompaña al evento, etc… Cuando se trata de una modificar el comportamiento de un método de una clase base, podemos sobreescribir dicha función, el problema es que no podemos sobreescribir un evento. La solución al problema es simple, lanzar todos los eventos desde una función protegida y virtual, en lugar de directamente, de tal manera que una clase derivada pueda redefinir el comportamiento del evento a su gusto o incluso anular su lanzamiento reescribiendo esta función. La moraleja: Debemos dar a las clases derivadas la oportunidad de modificar el comportamiento del lanzamiento del evento.

Además, con esa función damos a las clases derivadas la posibilidad de lanzar el evento si lo necesitan, simplemente invocando a la función que lanza el evento.

Con lo comentado anteriormente la implementación de nuestro evento quedaría como sigue:

    class Publisher
    {
        public event EventHandler SampleEvent;
 
        public void FunctionThatProducesTheEvent()
        {
            //Hacer algo aquí...
 
            //Lanzar el evento
            OnSampleEvent();
        }
 
        protected virtual void OnSampleEvent()
        {
            //Copia local de las subcripciones al evento para
            //evitar la condición de carrera entre la comprobación de
            //que hay subscriptores y el lanzamiento del evento.
            //Aunque que todos se desuscriban, nosotros tenemos la referencia.
            EventHandler handler = SampleEvent;
 
            //Comprobar que tenemos subcriptores
            if (SampleEvent != null)
                SampleEvent(this, EventArgs.Empty);
        }
    }

De esta manera, cualquier clase que derivase de la nuestra podría modificar el comportamiento del evento a su gusto simplemente sobreescribiendo la función OnSampleEvent. La moraleja: si nuestro evento se llama XYZ la función virtual asociada debe llamarse OnXYX.

¿Qué pasa si además tengo algo que contar asociado al evento?

La firma de un evento declarado con EventHandler es

public delegate void EventHandler(object sender, EventArgs e);

Con esta firma, podemos detectar en la función que maneja el evento, cual es el objeto que origino el evento, en el parámetro sender e información asociada al evento, en el parámetro e, de tipo EventArgs. Si vemos la definición de la clase EventArgs, veremos que es de nula utilidad, ya que no tiene campos que contengan información. El propósito de esta clase es servir como clase base para nuestras propios argumentos de evento.

Supongamos que quisiésemos que cuando salte nuestro evento, quien lo reciba, reciba además cierta información. Por ejemplo nos podría interesar saber a que hora se produjo el evento. En esta situación lo primero es derivar una clase de la clase EventArgs que incluya la información que nos interesa:

    class SampleEventArgs : EventArgs
    {
        readonly private DateTime _eventDateTime = DateTime.Now;
 
        public DateTime EventDateTime
        {
            get { return _eventDateTime; }
        }
    }

Ahora lógicamente necesitamos cambiar la firma del delegado que manejará el evento. Para eso, desde .Net 2.0 tenemos una implementación genérica de la clase EventHandler que nos permite especificar el tipo de nuestro EventArgs. Basta por tanto cambiar la declaración del evento adecuadamente y corregir los errores de compilación. Con lo que la implementación de nuestra clase que expone eventos, quedaría definitivamente, como sigue:

    class Publisher
    {
        public event EventHandler<SampleEventArgs> SampleEvent;
 
        public void FunctionThatProducesTheEvent()
        {
            //Hacer algo aquí...
 
            //Lanzar el evento
            OnSampleEvent();
        }
 
        protected virtual void OnSampleEvent()
        {
            //Copia local de las subcripciones al evento para
            //evitar la condición de carrera entre la comprobación de
            //que hay subscriptores y el lanzamiento del evento.
            //Aunque que todos se desuscriban, nosotros tenemos la referencia.
            EventHandler<SampleEventArgs> handler = SampleEvent;
 
            //Comprobar que tenemos subcriptores
            if (SampleEvent != null)
                SampleEvent(this, new SampleEventArgs());
        }
    }

La moraleja: Si necesitamos transmitir información junto con el evento debemos derivar una clase de EventArgs contenedora de la información y usar la implementación genérica de EventHandler.

Una clase subscrita podría extraer fácilmente la información adicional asociada al evento:

    class Subscriber
    {
        private Publisher _publiser = new Publisher();
 
        public Subscriber()
        {
            _publiser.SampleEvent += new EventHandler<SampleEventArgs>(_publiser_SampleEvent);
        }
 
        void _publiser_SampleEvent(object sender, SampleEventArgs e)
        {
            Console.Write("Se lanzo el evento a las {0}", e.EventDateTime);
        }
    }

Corolario:

No es extraño ver malas implementaciones de eventos.
Siempre debemos comprobar que alguien se ha subscrito a nuestro evento antes de lanzarlo y esta comprobación debe ser ‘thread safe’.
Una clase que se haya desuscrito de un evento, en un entorno multihilo, puede aun así recibirlo momentáneamente.
Si nuestro evento se llama XYZ la función virtual asociada debe llamarse OnXYX.
Si no desuscribes tus objetos de los eventos a los que estén suscritos, de objetos con mayor tiempo de vida, el recolector de basura no puede llevárselos al otro mundo.
Debemos dar a las clases derivadas la oportunidad de modificar el comportamiento del lanzamiento de los eventos y de lanzarlos si lo necesitan.
Si necesitamos transmitir información junto con el evento debemos derivar una clase de EventArgs contenedora de la información y usar la implementación genérica de EventHandler.

A que no pensabais que los eventos daban para tanto… ;).

He leído: The old new thing de Raymon Chen

Rodrigo Corral — Tue, 11 Aug 2009 19:58:22 GMT

Una de las liturgias de mi familia y mía en particular es almorzar donde mi abuela Basi. La liturgia es muy simple, siempre que llego a mi pueblo, Belorado, a eso de media mañana, pongo el culo en una de las sillas de la cocina de mi abuela y degusto alguno de los manjares que prepara: unos huevos fritos o en salsa, una morcillita asada, un trocito de queso, chorizo, pancetita, asadurilla, bacalao… vamos el típico almuerzo castellano. Supongo que muchos ya estaréis salivando pero el tema no es la gastronomía. Ahora me explico, paciencia.

Mientras mi abuela concina y nosotros almorzamos, mi abuela no calla. No para de hablar ni un segundo. Generalmente sobre los pequeños asuntos familiares. Pero, en las grandes ocasiones en las que tengo el placer de ser el único comensal mi abuela me cuenta un motón de historias. Historias sobre mi pueblo, sobre su gente, sobre lo que ha pasado esa semana, sobre lo que paso en la guerra, sobre mi abuelo en Alemania, sobre la vida en el campo, sobre la infancia de mi padre y mi tío, sobre cuando vivían en San Nicolas … Historias inconexas, historias que a veces no tiene sentido para mi, , que divierten o que aburren soberamente (las menos de las ocasiones) y a veces autenticas perlas de sabiduría, historias que enseñan un motón casi siempre, sobre la vida, sobre mi pueblo, sobre mi familia. Muchas veces no conozco a la mayoría de los personajes: Si hombre, la hija de tal, que fue a vivir no se donde, que es prima de ese que es padre de aquella que es de tu cuadrilla que salía con el primo de tu amigo aquel de Galdakano, dice mi abuela y yo digo, si si ya se, no por que sepa sino por no liar más la madeja. Seguro que los que tenéis abuela sabéis lo que digo.

Pues bien, de eso va este libro de Raymon Chen, de historias sobre su pueblo, que da la casualidad que es Windows y su API, en el que lleva viviendo desde la versión 1.0. Las historias que recoge, son como las de mi abuela: entretenidas, aburridas, unas se entienden y otras no, todas tiene algo en común, aunque muchas veces sea difícil ver la línea argumental y en otras no exista.

Resumiendo, y aquí es donde vamos al grano del asunto, que Raymon Chen se ha puesto a contar todas sus historias de abuelo cebolleta. Se trata de un abuelo que lo sabe todo todo todo sobre Windows, su desarrollo, su historia y su interioridades.

El libro es de un valor inapreciable para entender la dificultad que entraña el tomar decisiones que pueden afectar a millones de usuarios y desarrolladores. Además explica un montón de interioridades de Windows y justifica por que muchas cosas son como son en nuestro sistema operativo favorito. Hay artículos sobre como se pintan las ventanas, como se manejan los mensajes (¡por fin lo he entendido! solo por esto ha merecido la pena leer el libro), chascarrillos sobre el equipo de desarrollo de Windows, interioridades de COM, trucos de depuración, etc... Hay artículos muy técnicos y artículos que podría entender cualquiera. Eso sí, si has peleado con el API de Windows desde C, te vas a sentir como en tu pueblo, sino el libro puede ser un poco árido, es la única pega que tiene. Hay que tener claro que el pueblo de Chen es Windows, su shell, el API, COM y C, nada de .Net. Vamos Windows de verdad de la buena.

Un libro bastante recomendable y que merece bastante la pena comprar. Si bien tiene pasajes difíciles de digerir (si si abuelo, ya se de que me hablas, sigue hacia adelante no te enrolles), es lo suficientemente ameno como para recomendar su lectura a cualquier desarrollador que disfrute desarrollando en Windows.

Por último, si queréis saber de antemano el tipo de historias que encontraréis, podéis revisar el blog de Raymon Chen, que lleva el mismo título que el libro.

Truco: Liberar espacio tras la actualización a Windows 7

Rodrigo Corral — Mon, 10 Aug 2009 09:01:14 GMT

He realizado dos actualizaciones a Windows 7, una desde Windows Vista a la RC y otra desde la RC de Windows 7 a la RTM. Las dos han sido un éxito absoluto, a pesar que el segundo camino de actualización, de RC a RTM, no esta oficialmente soportado.

En el caso de la primera, de Vista a RC, lo que más me sorprendió en su momento fue la gran cantidad de espacio de disco duro que recuperé. No tengo muy claro el por que pero el actualizar de Vista a Windows 7 me liberó 8 Gb de disco duro de manera inmediata. Evidentemente esto no ocurrió de la RC a la RTM.

Esto no es todo, el truco que os voy a contar no va a permitir liberar más espacio aun tras una actualización a Windows 7. El hecho es que una actualización a Windows 7 deja mucha ‘morralla’ tras de sí. Principalmente copias de seguridad de archivos descartados durante la migración y una gran cantidad de información de logeo de las operaciones realizadas durante la actualización.

Para recuperar ese espacio debemos ejecutar el asistente para la liberación de espacio en disco.

El detalle más importante es pulsar en el botón Clean up system files, sino no podremos seleccionar la opciones que vemos en la siguiente imagen:

Seleccionando Files discarded by Windows upgrade y Windows upgrade log files liberaremos, en mi caso, 1,96 Gb, un cifra nada despreciable. Decir que esta cifra, según mi varia de máquina a máquina y es aun mayor cuando la actualización es desde Vista a Windows 7.

¡Espero que os sirva!

Truco: Actualizando Windows 7 RC a la versión final (RTM)

Rodrigo Corral — Sun, 09 Aug 2009 18:34:13 GMT

En teoría, no es una situación soportada el actualizar una instalación de Windows 7 Release Candidate (RC) a la versión final o RTM (Release To Manufacturing). Si lo intentamos encontraremos una pantalla, que impide continuar con la instalación, como esta:

Gracias a dios, hay un simple truco del almendruco, lógicamente no soportado, que nos permitirá hacer la actualización. Debemos copiar el contenido del DVD de Windows 7 al nuestro disco duro. En la ubicación que hayamos copiado los contenidos del DVD, dentro de la carpeta sources encontraremos un archivo llamado cversion.ini, con el contenido que podéis ver en la siguiente imagen:

Podéis ver que en la entrada MinClient tenemos el valor 7233.0. Si ponemos en esta entrada 7000.0 y guardamos el archivo, podremos actualizar desde la RC a la versión RTM definitiva ‘sin problema alguno’. Pongo entre comillas, ‘sin problema alguno’ porque si bien es cierto que en mi caso todo ha ido de maravilla, insisto: este procedimiento no esta soportado, podéis usarlo a vuestro propio riesgo y lógicamente siempre tras haber hecho una copia de seguridad de todos vuestros datos valiosos.

¡Espero que os sirva y que os funcione tan bien como a mi!

He leído: The art of Unix programming de Eric S. Raymon

Rodrigo Corral — Tue, 04 Aug 2009 08:48:47 GMT

Supongo que lo primero que se preguntan los lectores de este blog al ver el título de este post es ¿qué hace un MVP leyendo cosas sobre Unix? o formulando la pregunta de una manera menos torticera ¿por qué un experto en entornos Microsoft está interesado en Unix?. La respuesta es compleja, pero las motivaciones que me han llevado a leer este libro son:

Unix es un gran sistema operativo, estaba seguro que aprendiendo más sobre Unix me iba a convertir en un desarrollador y arquitecto más valioso. Internet es Unix, Internet es omnipresente. Quieras o no a diario todos usamos sistemas Unix. Me gusta conocer lo que uso.

Conocer los puntos fuertes y débiles de otras plataformas de desarrollo y sistemas operativos te ayuda a detectar, prevenir y minimizar las debilidades de tus soluciones y del entorno en que te mueves, Windows y .Net en mi casos.

Es un libro enormemente citado. Casi todo el mundo que lo ha leído coincide en que es un gran libro que todo amante del desarrollo de software, por encima de afinidades a tal o cual sistema operativo, disfruta leyendo.

A pesar de lo que pueda parece por el título el libro no es un libro sobre programación. No te enseña a programar en Unix. Es un libro sobre historia, arquitectura y cultura informática en general. Es una lectura amena y llevadera, sobre todo si ya has tenido contacto con entornos Unix y te apetece saber por que las cosas son como son en esa plataforma.

La primera parte del libro, de aplicación universal, desgrana las grandes decisiones de arquitectura y circunstancias históricas que han llevado a los entornos Unix a ser como son. Muchísimas de estas decisiones de diseño, tomadas por gente de extraordinaria valía, pioneros de la computación e Internet, esconden extraordinarias lecciones prácticas de arquitectura y diseño de sistemas informáticos. Además se incluye una ‘comparativa’ entre sistemas operativos y las grandes decisiones de diseño que han marcado cada una de ellos que sin duda aporta una interesantísima cultura general sobre el tema que todo arquitecto debería tener. Lo que menos me ha gustado del libro, sin duda, es que no es del todo objetivo en su tratamiento de los sistemas operativos de Microsoft y que se nota que lleva un lustro escrito y no ha sido actualizado con los avances habidos en esta plataforma. Por poner un simple ejemplo se critica la ausencia de una interfaz de línea de comandos potente, algo paliado ampliamente desde la aparición de PowerShell. En esta parte del libro me parecen especialmente destacables e interesantes las reglas que el autor desgrana sobre la filosofía de Unix, ¡son reglas aplicables a cualquier arquitectura!. No se puede discutir que si algo a demostrado Unix es su capacidad para adaptarse a las circunstancias, evolucionando durante cincuenta años para amoldarse y ser una plataforma puntera en todo cambio habido en la informática durante su historia. Sin duda esta capacidad de adaptación y permanencia se deriva de una excelente arquitectura, por eso conocer las reglas que han guiado esa arquitectura es sumamente valioso.

En la segunda parte del libro, se baja de nivel y pasamos de la arquitectura de Unix a su diseño, a detalles concretos de soluciones que se han tomado en el diseño de este sistema operativo y de aplicaciones significativas del mismo. Esta parte del libro es, para mí, la más interesante. Podemos extraer de los casos estudiados en el libro una gran cantidad de conocimiento práctico sobre el diseño de sistemas informáticos. Se tratan todos los temas clásicos del diseño arquitectónico: Encapsulación, ortogonalidad, capas, diseño de protocolos, transparencia, multiprocesamiento, lenguajes embebidos, generación de código, optimización, complejidad… Resumiendo, todo un tratado sobre los grandes temas del diseño de software, vistos no solo desde un punto de vista teórico sino repasando como se han aplicado en esta plataforma y en sus aplicaciones más relevantes.

El libro presenta además un repaso sumamente interesante, en su tercera parte, de las herramientas y lenguajes de programación que permiten llevar a la práctica la lecciones aprendidas sobre arquitectura y diseño. Aquí el libro se convierte en algo mucho más especifico de la plataforma Unix, y por lo tanto las lecciones que aprendemos en esta parte, aunque interesantes y valiosas, no son de universal aplicación.

La cuarta parte del libro está dedicada a la comunidad. No cabe duda que la cultura de comunidad ha sido mucho más rica y tiene una tradición mucho mayor en entornos Unix que en entornos Windows. Esto ha cambiado radicalmente en los últimos años, pero aun así hay lecciones importantes que podemos aprender y otras que aun estamos aprendiendo en el mundo Windows sobre como compartir código, trabajar en proyectos de manera abierta, documentar los proyectos que compartimos, etc... Conocer como el mundo ‘open source’ Unix lleva años haciendo esto, puede enriquecer el mundo ‘open source’ Windows, cada vez más potente y rico y sobre todo nos puede ayudar a evitar reinventar la rueda.

En resumen un libro excelente, más que recomendable, que merece la pena leer y comprar. Sin duda va a ocupar un lugar preeminente en mi biblioteca y con seguridad va a inspirar post en este blog.

¡Un saludo!

Serías capaz de… ¡por supuesto! o Scrum también da respuestas

Rodrigo Corral — Tue, 30 Jun 2009 06:17:00 GMT

Escribía un interesante post de Miguel Sierra, vecino de blog en Geeks.ms, sobre la implantación de CMMI que ha llevado a cabo su empresa. El post es interesante, y agradezco a Miguel que comparta su experiencias. Por mucho que para mi CMMI sea rara vez la elección metodológica adecuada, creo que es un marco metodológico que debemos conocer, aunque solo sea por la influencia que ha ejercido en el desarrollo de software en los últimos años. Además a mi ‘me va en el sueldo’, pues me toca apoyar técnicamente la implantación de TFS en organizaciones que han elegido CMMI como marco de trabajo.

Lo que motiva este post es el ‘reto’ que lanzaba Miguel preguntando si seríamos capaces de responder a una serie de preguntas relacionadas con el ciclo de vida de nuestros proyectos. Yo que llevo ya un tiempo viviendo en Bilbao, y se me ha pegado un poco la vena Vasca, no he podido remediar el recoger el guante y decir ‘que te apuestas a que sí"’. Es un poco como el chiste de meter cien vascos en un seiscientos… diciéndoles que no caben. Es un poco como las luchas fictícias entre superheroes tipo Lobezno contra Spiderman.

Aquí van las preguntas de Miguel y la respuesta que Scrum en particular y las metodologías ágiles en general darían, de la mano de TFS:

¿Serías capaz de ...?

Identificar las tareas y pruebas funcionales relacionadas con un requisito concreto

Tras el Sprint Planning Meeting y antes de que cualquier trabajo de desarrollo se realice, el equipo de desarrollo desglosa las historias de usuario (requisitos) en tareas. Toda historia de usuario lleva explícitamente en su definición las condiciones de aceptación (versión ágil de las pruebas de aceptación). Luego la respuesta es si.

Identificar las partes de código fuente a las que afecta un cambio de requisito

Por supuesto. Todo cambio tendrá su historia de usuario asociada. En Scrum no se hace ningún desarrollo sin que pase por el backlog y por lo tanto sin que ese trabajo este definido. Apoyándonos en TFS podemos enlazar los cambios en el código con tareas o requisitos en el momento de hacer checkin… ¿a alguien se le ocurre algo más productivo, menos intrusivo para el desarrollador?. Además para que nadie se olvido lo podemos ‘imponer’ mediante políticas de código

Decir cuando se realizó una tarea en concreto y la cantidad de esfuerzo que supuso

Lo lleva el TFS. Sin salir del su entorno natural, el IDE de desarrollo (sea VS o Eclipse) el desarrollador puede actualizar el estado de sus tareas o bug en el mismo instante en el que comienza su trabajo o lo termina. Y sin cambio de contexto alguno. Evidentemente, aunque en Scrum no nos importa demasiado, es posible responder con facilidad el tiempo que te llevo implementar una determinada tarea, bug o requisito. Otra vez, gracias a TFS con burocracia cero para el desarrollador.

Realizar una estimación precisa de una tarea que ya realizaste en algún proyecto anterior

El Product Backlog se debe estimar, las tareas que forman parte de un Sprint se estiman. Scrum no dice nada sobre como debes estimar, pero la comparación con experiencias anteriores es la técnica que explicita o implícitamente todos usamos. Los equipos ágiles suelen preferir métodos más ligeros y más llevaderos de estimación, basados en mejorar el conocimiento, la responsabilidad compartida y el consenso.

Listar las tareas que tienes pendientes en un determinado módulo de tu proyecto

En Scrum el concepto de ‘hecho’ y ‘no hecho’ es clave para gestionar el avance del proyecto. Sabemos en todo momento que elementos del Product Backlog han sido completado y cuales no. Exactamente el mismo aplica a nivel de Sprint Backlog. No solo eso, además visualizamos este estado mediante los gráficos de burndown.

Decir el tiempo restante para terminar un módulo de tu proyecto

En Scrum evitamos construir por módulos. Un módulo por si mismo no suele se capaz de hacer algo de valor para le cliente. No se trata de completar módulos, sino de liberar en cada momento lo que más valor tiene para el cliente. Tratamos de construir el software en ‘tiras verticales’ que implementan toda la funcionalidad de una determinada historia de usuario. Logramos así un continuo flujo de valor. Mirando el Burdown Chart es muy simple decir cuanto queda para completar el proyecto. Evidentemente podemos filtrar este Burdown Chart para las historias de un area (módulo) concreto.

Sacar un listado de las incidencias de un proyecto y la desviación en esfuerzo, tiempo y coste

Una vez más la respuesta es el Burdown Chart que visualiza cualquier desviación en tiempo real. El Burdown Chart refleja las desviaciones en tiempo, pero todos sabemos que tiempo y coste son magnitudes convertibles en gestión de proyectos. Por ejemplo en este Burdown Chart se aprecia claramente una desviación de 60 puntos en un proyecto de 20 unidades de tiempo.

Sacar un listado de las peticiones de cambio de un cliente

El Product Backlog recoge continuamente todas las peticiones del cliente. Todo lo solicitado por el cliente es gestionado por el Producto Owner utilzando el Product Backlog que permanece vivo a lo largo del proyecto. TFS nos proporciona informes sobre la tasa de cambio que ocurre en el Product Backlog.

Certificar que los requisitos del proyecto han sido entendidos y comprometidos por el equipo de trabajo

Evidentemente. Durante el Sprint Planning Meeting, los desarrolladores entienden los requisitos, hacen preguntas y mejoran su conocimiento. La primera parte del Sprint Planning Meeting se dedica a esto. El Sprint Planning Meeting termina con el compromiso de los desarrolladores de hacer todo lo humanamente posible para lograr implementar los requisitos comprometidos para el Sprint durante el mismo.

Identificar, si una prueba falla, que requisitos se ven afectados

TFS permite asociar pruebas de aceptación y sus resultados con cualquier tipo de work item. Si haces esto, es simple responder esta pregunta. Yo he trabajado con equipos que hacen esto y equipos que no lo hacen. Si hay un tester en el equipo, es muy recomendable.

Entregar una versión del producto, mas o menos estable, al cliente, ahora mismo

Lógicamente. Esto es un problema clásico de SCM. En cierto modo no está ligado a la metodología, sino que es una práctica de ingeniería del software más que recomendable. En Scrum todo Sprint debe terminar con un ‘incremento de funcionalidad potencialmente entregable’. Las políticas de SCM de un proyecto que use Scrum deben adecuarse a este objetivo. Una vez más, aperece aquí, el objetivo de Scrum y de las metodologías ágiles en general de ‘crear un flujo continuo del valor para le cliente’.

Decir el porcentaje de construcción del producto o proyecto y certificar el coste actual, "on the fly", del producto

Una vez más me remito al Product Backlog y a su primo visual, el Burndown Chart.

Decir los riesgos activos que hay en tu proyecto

Claro que gestionamos el riesgo, lo llamamos impedimentos y lo hacemos de una manera un poco diferente. No ponemos tanto énfasis pero todo proyecto Scrum tiene un backlog de impedimentos, que es ‘equivalente’ a la lista de riesgos. Otras metodologías ágiles, sobre todo MSF Agile, hace un gestión del riesgo mucho más explicita.

Enumerar las personas dedicadas al proyecto y el porcentaje de ocupación

Ufff… porcentaje de ocupación… es que alguien en alguna empresa no está ocupado al 100% :). Bromas a parte. En Scrum no nos importa tanto la ocupación del individuo como la del equipo. El concepto de equipo es vital. Pero lógicamente, en todo momento tratamos de ajustar la carga del equipo a su capacidad.

Decirme cuando queda liberado un recurso en concreto

Ummm… si por recursos te refieres a máquinas, servidores, fuentes de agua, y máquinas de café y refrescos… simplemente tratamos de tener los suficiente ;).

Decir las medidas correctivas que has tomado cuando has tenido desviaciones

Todo Sprint termina con una Sprint Retrospective. Se trata de saber que ha ido bien, que ha ido mal y plantear las acciones correctoras. Todas las conclusiones quedan reflejadas en TFS y las acciones correctores necesarias que impliquen un esfuerzo explicito se meten en Product Backlog para su gestión dentro de el marco de un Sprint.

Contar lo que se habló en la ante última reunión de seguimiento con el cliente

En Scrum las reuniones de seguimiento son obligatorias. Ocurren puntualmente con periodicidad predeterminada. En esta reuniones de seguimiento, Sprint Reviews en la jerga de Scrum, se muestra software que funciona mediante ‘demos’. Ocurre, sin excepción, al final de cada Sprint. El cliente puede ver el progreso, no imaginárselo en base a diagramas de Gantt o sesudos informes de seguimiento. Además puede y debe dar feedback sobre lo visto durante el Sprint Review.

Enumerar las tareas y esfuerzo que te va a suponer la puesta en producción

Los equipos ágiles tratamos de hacer de la puesta en producción una hábito. La idea es minimizar el esfuerzo de puesta en producción hasta limites tales que sea inapreciable. Para ello nos apoyamos en técnicas como la integración continua o frecuente y el testeo automatizado. Dicho esto, cualquier tarea que se realice, sea del tipo que sea, se debe meter en el marco de un Sprint.

Como podéis ver Scrum responde las mismas cuestiones que CMMI de una manera diferente, pero las responde. No podía se de otra manera, pues muchas de las cuestiones planteadas por Miguel, son cuestiones universales en la gestión de proyectos de software.

Esto me lleva a pensar… es posible usar Scrum + TFS, para cubrir CMMI Nivel 2… la respuesta es que sí. Precisamente de esto habló mi compañero Jose Luis Soria hace poco en un evento sobre CMMI, a ver si se anima y publica las ppts en Slideshare.

¡Un saludo!

Pregunta a la comunidad: ¿Queréis un wiki en Geeks·ms?

Rodrigo Corral — Sun, 28 Jun 2009 19:16:27 GMT

Una de las posibilidades que tiene Community Server, la plataforma sobre la que corre Geeks·ms es contar con un Wiki. Esta posibilidad lleva ‘dormida’ mucho tiempo. No se si activar está posibilidad o no. De aquí las preguntas que hoy lanzo.

¿Os gustaría contar con una Wiki en Geeks·ms?
Los editores serían todos aquellos que tengan un blog en Geeks·ms ¿qué contenidos adicionales a vuestro blog pondríais en ese Wiki?
¿Qué sugerencias tenéis, como autores o lectores de Geeks·ms sobre este asunto?

Podemos contar con más de un Wiki, pero tal y como yo lo veo, creo que debería haber solo uno que aglutinase todo el conocimiento que pudiésemos almacenar sobre los temas que habitualmente tratamos en Geeks·ms.

Lo que quiero es valorar si la comunidad cree que un Wiki aportaría valor a Geeks·ms. La duda se me plantea por que al contrario que los blogs, los foros que tenemos disponibles desde hace mucho tiempo, no parecen tener mucho movimiento.

Esta vez, más que nunca, espero vuestros comentarios. Si no hay comentarios, supondré que la idea no despierta interés.

¡Un saludo!

Exprimiendo Scrum: ¿Cuál es tu definición de equipo?

Rodrigo Corral — Thu, 25 Jun 2009 21:34:00 GMT

La problemática de la gestión de proyectos en las organizaciones que desarrollan software se deriva, simplificando el asunto, de dos situaciones: gestionar proyectos muy grandes o gestionar muchos proyectos pequeños. Todos estaremos de acuerdo en que cualquiera de estas dos situaciones es más compleja que la situación, más equilibrada, en la que tenemos un número limitado de proyectos con unas dimensiones limitadas.

De estas tres posibilidades, sin duda la más compleja es muchos proyectos pequeños. Los grandes problemas siempre se pueden dividir en problemas de tamaño medio y reducir así la complejidad, llevarlos a la categoría de ‘un numero pequeños de proyectos medianos’.

El por qué la situación más compleja se da cuando tenemos muchos pequeños proyectos es simple: tendemos a tener más cambios de contexto. Los cambios de contexto se dan al ‘pasar’ de un proyecto a otro y son tiempos perdidos. Si a un número grande de proyectos pequeños, unimos que no hay concepto de equipo, los cambios de contexto son continuos y la caída de productividad acusada. Cuando un proyecto está en manos de una persona y no de un equipo, esta persona inevitablemente es un cuello de botella. No voy ha hablar hoy de los cambios de contexto, en otra ocasión volveré sobre el tema, que ya he tratado, someramente, en alguna otra ocasión.

Cuando tratamos de implantar Scrum en una organización este problema de la gestión de proyectos también nos afecta de manera decisiva. Como hemos comentado se trata de un problema de cambios del contexto y el antídoto de Scrum para los cambios de contexto es el concepto de equipo autoorganizado y autogestionado. La idea clave es que un equipo autoorganizado y autogestionado puede elegir en que momentos introducir los cambios de contexto, y por simple sentido común elegirá los momentos idóneos. Siguiendo con esta argumentación se hace patente que es precisamente en entornos que presentan muchos pequeños proyectos en los que más dificultoso es implantar Scrum y en los que más atención se debe prestar a un tema clave: definir que es un equipo en tu organización.

En empresas con ‘muchos pequeños proyectos’, como la gran mayoría de las pequeñas y medianas consultoras, la gran dificultad pasa por encontrar que es un equipo para esa organización, en primer lugar, y en segundo lugar definir cuantos product backlogs se van manejar.

Para hacer esto, no hay una receta universal. Depende mucho de la cultura y organización actual de la empresa. Pero es la clave. Pensad que ahora solo existen individuos y tenemos que pasar de esa situación a una en la que el trabajo de reparta entre equipos, no entre individuos. Esa es la gran dificultad.

El principal problema que tenemos en la situación actual es el tiempo que se os va en cambios de contexto, insisto. Probablemente estemos en la típica situación de prioridades difusas, de atender a los fuegos, al cliente que más grita... el antídoto para eso es Scrum y su modelo de equipos. Por ahí empezaría yo, por ahí empiezo yo toda implantación de Scrum en este tipo de situaciones, definir los equipos.

Esa definición de equipos se puede hacer atendiendo a numerosos factores y es particular de cada caso, muchas veces no resulta evidente, pero es vital hacerlo bien. Podemos particionar los equipos por numerosos criterios: tecnología, cliente al que se dedican, proyecto (la más evidente)... Lo vital, en mi opinión, es que esas particiones sean verdaderas particiones, que no existan individuos que están en n equipos a la vez.

Yo suelo analizar las particiones que me salen según las leyes de las particiones de Roger S. Sessions, y da buen resultado:

1ª Ley: Las particiones deben ser verdaderas particiones.
2ª Ley: Las particiones deben ser adecuadas al problema.
3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.

Si lográis hacer bien eso, habréis dado un gran paso. Luego, a la hora de determinar el número de backlogs, el enfoque más simple es un equipo, un backlog, un product owner. Aunque no siempre es posible, es el enfoque más simple y el que siempre se debe perseguir.

Hay una manera muy simple de saber si hemos hecho esto bien: elegimos un desarrollador al azar y le preguntamos:

¿Tu a qué equipo perteneces?
¿Dónde está vuestro product backlog?
¿Quién son vuestro Producto Owner y Scrum Master?
¿Cuáles son los objetivos de tu equipo para este sprint?

Si recibimos respuestas ambiguas, es que no tenemos un modelo de equipos. Sin un modelo claro de equipos no es posible una correcta implantación de Scrum.

El enfoque más simplista de Scrum persigue un proyecto, un backlog, un equipo. Pero esto no siempre es posible en consultoras donde lo que hay son muchos proyectos pequeños que gestionar como un todo en lugar de algunos proyectos grandes que respondan al modelo simple de Scrum.

Este post, se inspira en una interesante conversación mantenida sobre este tema en la lista de Agile Spain, quizás queráis leer los pensamientos allí expuestos.

¡Espero vuestros comentarios!