Exprimiendo Scrum: Scrum y la gestión de la configuración (I)

Toda implantación de una metodología tiene un aspecto clave que muchas veces se olvida: diseñar una adecuada política de gestión de la configuración que de soporte a las actividades de desarrollo concurrente que el equipo realiza y las verificaciones de calidad que llevan a cabo los testers.

 

Además otra cuestión relacionada con la gestión de la configuración, que resulta imprescindible, es la necesidad de poder trazar nuestros binarios . Esta es una cuestión que a menudo se olvida y que se hace especialmente importante en los momento de dificultad, cuando nuestro software está sufriendo problemas: es sumamente difícil depurar un problema con garantías de éxito si no contamos con la certeza de que en el entorno de depuración contamos con el código fuente, la información de depuración (generalmente en forma de PDBs) y los binarios que se corresponden con una determinada entrega.

 

Otro aspecto vital, sobre todo en las metodologías ágiles, pero cada vez más en cualquier proceso de desarrollo, es la integración continua: construir nuestro software y ejecutar las pruebas automatizadas del mismo cada vez que se realiza un check-in.

 

En este post voy a cubrir la primera parte: describir la política de ramas que permite a un equipo de desarrollo que utiliza Scrum desarrollar de manera concurrente, estabilizar el software desarrollado y habilitar los mecanismos que permitan que los testers reciban software de calidad suficiente para su validación y de manera aislada de los continuos cambios realizados por el equipo de desarrollo para evolucionar la solución. En próximos post abordaré otras cuestiones relacionadas con las construcciones automatizadas y diarias, la integración continua y la trazabilidad.

 

Evidentemente, no pretendo dar una solución global, de universal aplicación en todo proyecto. La política de gestión de fuentes se ve condicionada por una infinidad de aspectos: el número de equipos, el número de versiones a mantener en producción, la existencia de adaptaciones para clientes determinados, el número de plataformas en las que se desplegará el proyecto, la necesidad de asegurar formalmente la calidad, rendimiento o seguridad del código antes de su integración en líneas privilegiadas (golden lines) y así un largo etcétera. Cada caso, según su complejidad y necesidades exige la utilización de unos patrones de SCM u otros. Lo que pretendo mostrar es el mínimo común denominador que todo equipo Scrum y en general todo equipo ágil necesita en su política de gestión de fuentes.

 

Cuando se plantea una política de gestión de fuentes, es una buena idea es enumerar los objetivos que persigue. Los objetivos que persigo, en esta ocasión, por considerarles comunes a todo equipo ágil son:

 

  • Permitir que los desarrolladores trabajen de manera concurrente y en equipo.
  • Permitir que los testers puedan estabilizar el software sin sufrir interferencias por parte de los desarrolladores.
  • Permitir el objetivo de Scrum de conseguir tras cada Sprint ‘un incremento de funcionalidad potencialmente entregable’.
  • Permitir la corrección de errores encontrados con el mínimo impacto.
  • Establecer una nomenclatura para las diferentes ramas.

 

Permitir que los desarrolladores trabajen de manera concurrente y en equipo

 

Uno de los valores claves en Scrum es que los desarrolladores trabajen en equipo, evitando el código con propietario y fomentando la colaboración. Lógicamente cualquier herramienta de gestión del código fuente habilita escenarios de compartición de fuentes entre desarrolladores y el trabajo compartido. Luego aquí podríamos decir que para cubrir este objetivo necesitamos poco más que instalar una herramienta de gestión de código, crear una línea de código, y utilizar la herramienta. Pero esto es cierto hasta cierto punto. Cuando los equipos crecen y hay un número relevante de desarrolladores tocando la misma línea de código compartida se producen continuos cuellos de botella (si utilizamos bloqueos exclusivos, práctica nada recomendada) o continuos conflictos a la hora de integrar las fuentes (si no utilizamos bloqueos).

 

La solución habitual en este tipo de escenarios es utilizar una rama por desarrollador, pero esta no es una buena solución. De hecho se trata de un antipatrón conocido como ‘Berlin Wall’, ya que si bien es cierto que aísla a los desarrolladores de los cambios de otros desarrolladores, también impide que varios desarrolladores trabajen en equipo para desarrollar un misma característica.

 

Una aproximación que funciona mejor es usar ‘ramas por característica’. En la aproximación de rama por característica se crea una rama de desarrollo partiendo de la rama de desarrollo principal, generalmente llamada DEV, con el fin de desarrollar sobre ella una determinada característica. La rama de característica incluye todo el código de la rama principal de desarrollo (DEV) Una vez completada esta característica la línea creada converge de nuevo con la línea principal de desarrollo (DEV). Varios desarrolladores trabajan de manera concurrente sobre cada rama de característica, pero el número de desarrolladores que en un equipo trabajan sobre una característica determinada en un momento del tiempo, no debe ser muy elevado, con lo que evitamos cuellos de botella que se producen cuando solo contamos con una única rama de desarrollo.

 

A la hora de nombrar las ramas de característica se suele elegir entre dos esquemas: dar a la rama el nombre de la característica (p.e.: DEV-TransferenciaAlmacenes, DEV-ConversionAlbaranFactura) o usar el número de ticket o workitem que define la caracteristica como nombre de la rama (DEV-401, DEV-402, siendo el número el identificar del Producto Backlog Item que describe la característica o historia de usuario que se implementará en esa rama). Es una cuestión, más que nada, de gustos.

 

Con lo descrito hasta ahora, nuestra política de gestión de fuentes tendría un aspecto similar al siguiente: Desarrollo concurrente y en equipo

Permitir que los testers puedan estabilizar el software sin sufrir interferencias por parte de los desarrolladores

 

Scrum es una metodología que no prescribe el rol de tester. Sin embargo, sí tiene la calidad continua como uno  de sus valores y como ya he comentado en alguna ocasión la calidad no es algo de lo que se pueda prescindir. Para mantener la calidad de manera continua en nuestros proyectos, no podemos hacer nada mejor que poner un tester en el proyecto.

 

Siguiendo la máxima de que un bug nos cuesta más dinero cuanto más tarde lo detectamos, debemos poner a nuestros testers (o al menos una parte significativa de los mismos) lo más cerca posible de nuestro equipo de desarrolla e idealmente los testers deben ser parte integrante del equipo de desarrollo.

 

En cualquier caso se hace evidente la necesidad de que nuestros testers prueben software con un mínimo de estabilidad, que presente características concretas y que no se vea continuamente bajo impactos provenientes de los  desarrollos que están en curso.

 

La conclusión es evidente. Aparece la necesidad de una nueva rama a la que promocionaremos código con ciertas garantías, de manera que el trabajo de los testers comience sobre una base de código de cierta calidad. Esta rama, sobre la que no se realiza desarrollo, sino sobre la que se promociona código maduro, se suele llamar MAIN.  Esta rama contendrá el código, correspondiente a características completas, que los testers estarán probando para lograr su estabilización.

 

Las garantías que se deben cumplir para promocionar código desde la rama DEV a esta cambian de equipo a equipo en función de las situaciones concretas. Se suele exigir, para promocionar código a esta rama, que el código a promocionar se haya compilado correctamente,  pasado todas la pruebas automáticas, y probablemente que haya pasado satisfactoriamente al menos un test de humo realizado por los desarrolladores o por los propios testers.

 

Con la aparición de esta rama, nuestra política de gestión de fuentes tendría un aspecto similar al siguiente:  Aislar el entorno de pruebas

Permitir el objetivo de Scrum de conseguir tras cada Sprint ‘un incremento de funcionalidad potencialmente entregable’

 

Uno de los apectos claves de Scrum es que tras cada Sprint (periodo de desarrollo de 20 días hábiles como máximo) debemos lograr un ‘incremento de funcionalidad potencialmente entregable’. Para ello es vital lograr que la línea principal de desarrollo nunca contenga características a medio desarrollar. Hemos visto como la necesidad de lograr un desarrollo altamente colaborativo y concurrente nos ha llevado a usar ramas por característica.

 

Las ramas por característica también nos ayudan a evitar que la línea principal de desarrollo pueda contener en algún momento del tiempo características incompletas. Puesto que establecemos la política de integrar en la rama de desarrollo principal (DEV) características completas, provenientes de las rama de características, nunca tendremos, en la rama MAIN, código de características a medias. Esto nos garantiza que al final de cada Sprint y a partir de la rama MAIN, podremos construir la solución con la garantía de poder presentar características completas. Esto es vital, pues en Scrum seguún las reglas del Sprint Review, el equipo solo puede presentar durante el mismo funcionalidad completa.

 

Según lo comentado, el modelo que tenemos hasta ahora, nos sirve perfectamente y, en consecuencia, para cubrir el objetivo que nos ocupa, no necesitamos añadir modificación ninguna al mismo:

Incrementos de funcionalidad potencialmente entregables

Permitir la corrección de errores encontrados con el mínimo impacto

 

Una necesidad que surge en todo proceso de desarrollo, relacionada con la gestión de la configuración y del código fuente, es la de habilitar un mecanismo que permita liberar versiones que solo corrigen errores y no añaden nueva funcionalidad.

 

Una situación habitual en equipos de desarrollo que utilizan esquemas de gestión de fuentes demasiado simplistas es la imposibilidad de liberar releases que solo incluyen correcciones de errores. Esto es importante pues muchas veces los clientes o usuarios están dispuestos a cambiar de versión en producción si saben que los impactos a los que se exponen sus sistemas están acotados. Esto se consigue con versiones menores, que solo corrigen errores y que no añaden nueva funcionalidad.

 

Otra situación habitual, en estos esquemas simplistas,  es que para recibir una corrección de un error, el cliente debe esperar a que los desarrolladores completen ciertas características, a que los testers estabilicen el software, que no solo incluye correcciones de errores, y a que en general toda la organización esté en condiciones de liberar una nueva versión. Este es un proceso, que a menudo, se prolonga más en el tiempo que el tiempo que los clientes están dispuestos a esperar nuestros parches.

 

Para permitir la corrección de errores de una manera ágil y operativa necesitamos dos cosas: una rama por cada versión soportada en la que podamos hacer correcciones de emergencia para una determinada release minimizando el impacto sobre el desarrollo en curso. Y un proceso claro de promoción de las correcciones de los errores que encontremos durante el desarrollo y la validación de software por parte de los testers.

 

Aparece así una nueva línea, habitualmente llamada RELEASE, que contiene el código desde el que liberaremos cada release. Habrá tantas ramas RELEASE como versiones a las que tengamos que dar mantenimiento. Sobre esta línea se puede hacer correcciones puntuales de errores si solo afectan a esta versión, pero la práctica recomendada a la hora de corregir errores es buscar la línea de código más antigua en la que el error se reproduce,  corregirlo en esa línea y luego propagar la corrección hacía líneas superiores en el proceso de desarrollo. Típicamente y salvo parches de urgencia o cuando la complejidad del proceso lo desaconseje, debemos corregir el bug sobre la línea principal de desarrollo o sobre la línea de característica si es que esta aun sigue viva. Luego escalar esta corrección, mediante la integración del changeset relacionado con el error, a la línea MAIN y de hay seguir el proceso de estabilización de la línea MAIN que dará lugar a la creación de una nueva línea RELEASE correspondiente con una determinada versión.

 

Con esto nuestro modelo, incluido el mecanismo de corrección de errores como sigue, quedaría definitivamente como sigue: Corrección de errores

Espero que este post os resulte útil a la hora de establecer una política de gestión de fuentes. Espero vuestros comentarios, preguntas y sugerencias sobre el tema.

Requisitos de usar y tirar

Garrotazos Que nadie piense que voy a hablar de una aproximación hacia la captura de requisitos que tenga similitud alguna con los prototipos de usar y tirar. Ni siquiera es post va de cómo manejamos los requisitos en las metodologías ágiles y Scrum. De lo que voy a hablar hoy es de una situación que me estoy encontrando a menudo, sobre todo en equipos con cierto nivel de madurez, que escriben elaborados documentos de requisitos. No se porque algunos tienen la extraña idea de que madurez y documentos de requisitos infumables deben ir de la mano.

Cada vez más y más equipos que ‘oficialmente’ se encuentra en organizaciones CMMI, se interesan por la agilidad. En estos equipo, y según mi experiencia, que no es una muestra muy amplia de momento, todo hay que decirlo, encuentro un problema habitual en la gestión de los requisitos.

Las manifestación más claras de este problema es tener diferentes documentos, elaborados por diferentes grupos del equipo de proyecto, que dicen ser la fuente última de verdad sobre los requisitos.

La situación suele ser parecida a la siguiente:

Un grupo, bien ubicado en el departamento de Marketing o en el de Product Management escribe una especificación de requisitos. Esta especificación de requisitos es un documento con un buen puñado de páginas. Generalmente estos requisitos están expresados siguiendo una plantilla de documento, con una serie de campos. Luego este documento se pasa a los desarrolladores, para que lo asuman como fuente de verdad y validen su contenido desde diferentes puntos de vista.

Aquí están los desarrolladores, enfrentándose a un documento formado por cientos de páginas que deben leerse, que básicamente consisten en un motón de aburridísimos formularios. ¿Alguien cree a estas alturas que los desarrolladores se van a leer ese tocho? Ni por asomo. Yo he tenido que leerme ese tipo de documentos y sinceramente, tengo que reconocer que nunca lo hice con el más mínimo interés. Es que leer formularios es muy aburrido.

¿Qué hacemos los desarrolladores en lugar de leernos decenas de aburridos formularios? Defendernos para no tenerlo que hacer. La defensa suele ocurrir de dos maneras: o nos escudamos en las carencias que todo documento tiene para evitar tenerlo que leer y proponemos continuas mejoras o proponemos crear un nuevo documento. Tenemos un nuevo documento, que expresa los mismos requisitos desde el punto de vista de los desarrolladores.

Aquí están los Product Managers o analistas funcionales o lo que quiera que ponga en su tarjeta, enfrentándose a un documento formado por cientos de páginas de incomprensible jerga técnica alejada totalmente de las necesidades del negocio. Y que hacen… protegerse como lo hicieron los desarrolladores.

En cualquier de los casos, nos vemos en la situación que yo llamo requisitos de usar y tirar… de tirar contra otros implicados en el proyecto. Requisitos que se acaban convirtiendo en un arma arrojadiza entre dos grupos de implicados en el proyecto. He puesto aquí el ejemplo de desarrolladores y Product Managers, pero esta situación también se da entre organizaciones, entre proveedores y clientes.

Lo peor, es el tiempo de proyecto que se pierde en este baile de requisitos arrojadizos… y que se podría estar empleando en un motón de cosas útiles.

¿Cuál es el antídoto para esta situación? Usar un lenguaje común, el lenguaje natural para expresar los requisitos, lenguaje simple y llano que todos los implicados entiendan. Y hacer los requisitos divertidos… vale, vale, ya se que los requisitos nunca pueden ser divertidos… pero no tienen por que ser una colección de aburridísimos formularios que se rellenan solo por sistema. Otra aproximación fallida, es la visión de los requisitos como algo jerarquico. ¿Alguien es capaz de leerse una jerarquía de lo que sea? ¿Es posible conocer la historia de una familia viendo su árbol genealógico?.

Evidentemente, lo anteriormente dicho excluye a UML y los casos de uso como herramientas ágiles a la hora de especificar un sistema. Las metodologías ágiles proponen usar historias de usuario o escenarios como alternativa. No es que sea lo más divertido del mundo leer requisitos escritos como historias o escenarios, sigo prefiriendo una buena novela, pero sin duda es infinitamente más divertido que leer casos de uso o jerarquías de requisitos.

Solo si logramos que leer nuestros requisitos no sea una tarea titánica lograremos que los clientes, los desarrolladores y los Product Managers dejen de usarlos como un arma arrojadiza y lo empiecen a utilizar como un artefacto útil que facilite la construcción del sistema que se necesita.

¿Vamos a poner esfuerzo en hacer de los requisitos algo manejable o vamos a seguir a garrotazos?

Control de proyectos con metodologías ágiles en el Foro de Tecnología y Negocio

Foro Tecnología y Negocio Este jueves tuve el placer de hablar sobre control de proyectos utilizando metodologías ágiles en el 2º Foro de Tecnología y Negocio, celebrado en Santander. La ponencia fue la misma que hice en las ALM Sessions y que podéis ver en video. Después se plantearon algunas cuestiones interesantes sobre las metodologías ágiles en el debate posterior.

El Foro de Tecnología y Negocio esta formado por  un grupo de profesionales de las tecnologías de la información, responsables de los departamentos de IT de las Empresas más importantes de Cantabria. Su objetivo es crear un FORO, sin intereses comerciales ni políticos de ningún tipo, en el que estén agrupados los Responsables de IT que lo deseen, con el objetivo de compartir experiencias profesionales, problemáticas de nuestro trabajo, soluciones a las mismas y todos aquellos temas qué sean de interés común.

Leído lo anterior podría parece una asociación más del mundo de las IT, pero no es así, por ciertas particularidades. Conozco varias asociaciones profesionales pero pocas cuentan con representantes del mundo de las tecnologías, del mundo de la gestión del negocio y del mundo de la universidad. Además también había representantes de entidades públicas. Resumiendo el caldo de cultivo ideal para que el mundo de las IT y el desarrollo de software, las necesidades de la empresas y la universidad avancen de una vez persiguiendo objetivos comunes y comparta experiencias, expectativas, conocimientos y necesidades.

Dicho lo anterior puede parecer todo muy formal, pero no se trata de eso. No es un organismo formal. Es un foro de reunión, discusión con el fin de compartir conocimiento y experiencias. Además el evento culminó con una amena cena durante la cual tuve la oportunidad de charlar con un montón de gente muy interesante sobre temas tan diversos como: el desarrollo de software ágil, la programación concurrente, los dispositivos remotos de captura de datos, la crisis, el mundo de la unversidad…

Una gozada vamos, si estás en Cantabria, estás en el mundo de las IT y de los negocios y no participas en este foro: ¡No tienes perdón!.

Más eventos: Agilidad y Team System en Bilbao, Santiago, Valencia y Zaragoza

El més de Febrero viene fuerte en lo que a eventos ser refiere. No es la guira del amigo Guille pero casi. Estaremos en Bilbao, Santiago de Compostela, Valencia y Zaragoza. Hemos hecho bastantes eventos en Madrid, pero no solo la capital del reino está deseosa de enterarse de lo que Team System y las metodologías ágiles pueden hacer por el desarrollo de software :).

La agenda prevista (que deseo varíe por la participación de los asistentes):

Metodologías ágiles, ¿qué son? ¿ cómo nos ayudan?
Introducción a MSF Agile
Introducción a Scrum

Descanso. Café

Scrum y Team system en el mundo real
Team System : la herramienta perfecta para el desarrollo ágil

Os invito a que seleccionéis vuestra ciudad o la que más cerca os pille y os apuntéis a pasar una mañana aprendiendo, debatiendo y compartiendo expericias de ingenieria del software. Apuntaros pronto, que luego siempre hay problemas de plazas.

hero_alm_events

Bilbao

4 de Febrero de 2009

Plain Concepts

Metodologías ágiles y Visual Studio Team System

Más información y Registro

Coruña(Santiago de Compostela)

11 de Febrero de 2009

Plain Concepts

Metodologías ágiles y Visual Studio Team System

Más información y Registro

Valencia

25 de Febrero de 2009

Plain Concepts

Metodologías ágiles y Visual Studio Team System

Más información y Registro

Zaragoza

18 de Febrero de2009

Plain Concepts

Metodologías ágiles y Visual Studio Team System

Más información y Registro

¡Espero veros en los diferentes eventos!

Exprimiendo Scrum: Scrum y el control del proyecto (II): la visibilidad

Avance visible de la construcción de la Torre Eiffel

Hablaba en mi anterior post sobre el control de proyectos con Scrum sobre el avance, uno de los aspectos claves del control de un proyecto de software. Hoy toca hablar de otro aspecto relevante en el control de proyectos: la visibilidad . ¿Qué entendemos por visibilidad? Yo lo definiría como la capacidad del equipo de desarrollo de hacer evidentes los avances realizados durante el tiempo transcurrido de desarrollo.

 

Todo Paris, podía ver como progresaban las obras de la Torre Eiffel. Solo tenían que mirar al horizonte para cuantificar el avance. Eso es visibilidad en un proyecto. ¿Cómo podemos lograr esto en los proyectos de software? ¿Por qué es tan importante?.

 

La visibilidad es un aspecto fundamental en el desarrollo de software. Nuestros clientes, sean externos o internos a nuestra organización, tiene derecho a tener evidencia de que el dinero que aportan al proceso de desarrollo se está convirtiendo en valor. Esto se llama más ponposamente ‘asegurar el retorno de la inversión’. Otro aspecto relevante es que otros departamentos, ajenos al desarrolla de software, pero dependientes o relacionados con este, tienen la necesidad de conocer lo que pueden esperar del software estamos desarrollando y tienen que tener la posibilidad de ir acomodando sus acciones al progreso que perciben en el desarrollo de software.

 

Surge un proyecto, y el equipo de desarrollo se abre al mundo y sale a capturar requisitos, habla con los clientes, con diferentes departamentos, captura sus necesidades y luego… luego ese mismo equipo se retira a su ‘ratonera’ y no se vuelve a saber de él… durante meses. Frecuentemente se ve a los equipos de desarrollo como un conjunto de hechiceros que tras saber el conjuro que el cliente necesita, y tras un largo tiempo de ‘vete tu a saber que andan haciendo’… presentan un software… que no sirve a nadie. A menudo esta presentación se pospone hasta que todo el mundo se pone nervioso, y otras partes de la empresa o los clientes empiezan a demandar visibilidad. Pero ya es tarde. Cuando la visibilidad surge de una demanda externa en lugar de surgir de las prácticas habituales del equipo aparece un problema claro: la confianza está dañada. Además, sin visibilidad no hay feedback y sin feedback no acertaremos a liberar valor. Andaremos camino pero quizás en la dirección equivocada . Pero esta es otra historia que en otra ocasión abordaré. Los equipos de desarrollo tenemos que salir de la ratonera y mostrar que estamos construyendo. Mi experiencia es que hacer ese esfuerzo cambia de manera radical la relación de los equipos de desarrollo con el resto de los componentes de la empresa y el cliente, y lógicamente, para bien.

 

Los equipos de desarrollo hemos actuado a menudo con opacidad. Muchos equipos de desarrollo fallan a la hora de comunicar su progresos. Muchos equipos olvidan que la única medida de su progreso es el valor que liberan y entregan a sus clientes en forma de funcionalidad. Y muchos más equipos de desarrollo obligan que el software al contrario que otros productos tiene valor aunque no esté completamente desarrollado.

 

Pero los proyecto no solo fallan por como se comportan los equipos de desarrollo, en una cuestión cultural de la gestión clásica de proyectos. Se tiende a ver el avance los proyectos como una cuestión objetiva, pero no es así. El avance de un proyecto es una cuestión de percepción. Es evidente  que a menudo hay divergencias entre el avance que el cliente percibe y el avance que el equipo de desarrollo proclama. Solo el avance percibido por el cliente es relevante. De nada sirve que nosotros, los desarrolladores, digamos que hemos hecho ‘arcos de iglesia’ si el cliente no lo percibe así. Un cliente que no percibe avance será, más tarde o más temprano, un cliente cabreado. No hay proyecto exitoso posible sin la colaboración del cliente, y no hay cliente cabreado que sea colaborado.

 

Otro error habitual es mostrar el avance del proyecto mediante artefactos que no son software ejecutable. Uno de estos típicos artefactos son ‘los Project’, pero la experiencia nos ha enseñado a los desarrolladores y los clientes que un diagrama de Gantt lo aguanta todo. ¿Quién no ha vivido la paradoja de un diagrama de Gantt que muestra un progresos del 90% en un proyecto que todo el mundo conoce que está a años luz de sus objetivos?… Las métricas se pueden sesgar con facilidad, la de progreso no es una excepción.

 

Además tendemos a pensar que el progreso es una función de los hitos alcanzados o del tiempo transcurrido, pero la realidad es que el avance del proyecto es una función del valor liberado para el cliente.  Da igual el empeño que pongamos en un proyecto, o el tiempo de desarrollo que dedique el equipo, si no logramos liberar valor para el cliente, el progreso del proyecto es nulo.

 

Los clientes, cada vez más, necesitan ver para creer y lo equipos de desarrollo necesitamos que los clientes vean el resultado de nuestro trabajo para saber que estamos en el buen camino, que vamos en la dirección correcta, que nuestros esfuerzos están proporcionando algo útil al cliente. Evidentemente es necesario cambiar la relación con el cliente para que esto funcione.

 

Scrum habilita mecanismos explícitos para lograr hacer visible el avance del proyecto. Este mecanismo es el Sprint Review, una reunión en la que el equipo muestra los avances logrados por el equipo de desarrollo mostrando software que funciona. Además todos los involucrados en el proyecto y especialmente los representantes del cliente o el propio cliente debe proporcionar feedback sobre lo que ve. Esta sencilla liturgia de Scrum, vital en esta metodología, es un poderosísimo mecanismo para introducir la necesaria  visibilidad en el equipo de desarrollo.

En la UAL hablando sobre Team System y Scrum, a pesar del Sepla

A persar de los intentos del SEPLA por evitarlo, hoy he tenido el placer de hablar para un buen puñado de alumnos de la Universidad de Almeria sobre Scrum y Team System. Esto ha sido posible gracias a la iniciativa de los profesores Joaquin Cañadas y Jose Antonio Alvarez de la falcultad de Informática y el dotNetClub de esta universidad y el apoyo de Microsoft.

La unversidad ha publicado una nota de prensa sobre el evento.

Quiero agradecera Joaquin y Carlos y Antonio, del dotNetClub, la copañia, la conversación y el excelente pescado que nos hemos comido con vistas al mediterrano.

Espero que los alumnos hayan disfrutado tanto del evento como yo.

También espero, cambiando de tercio, tener en mi vida profesional la oportunidad de hacerle la vida un poco más dificil a algún piloto del Sepla, que se le borre alguna reserva de entradas o que su cuentas se bloqueen o que su correo se caiga durante horas (aunque se que mi etica profesional me lo impediría, ganas no me faltarían). Se que puede sonar mal generalizar mis sentimientos de fustración en un colectivo tan amplio, pero creo que son unos sinverguenzas, como colectivo Todo el mundo tiene derecho a la huelga, pero las huelgas de celo de estos personajes son como mímino mafiosas. Tomar a los usuarios que te dan de comer como rehenes de tus peticiones laborales no es el camino. Quizás este justificado el tema por lo mal que viven, los pocos privilegios de que gozán y lo poco que cobran los pilotos… como todo el mundo sabe. He visto situaciones dantescas en Barajas, que rozaban lo inhumano.

¡Un saludo!

Luchando contra los interbloqueos en Sql Server

La bases de datos utilizan los bloqueos para asegurar las propiedades ACID de las transacciones. Son un mecanismo imprescindible que tienen una cara oculta, un peaje necesario que muchas veces nos complica la vida: los interbloqueos.


Los interbloqueos son una situación a la que todo desarrollador de aplicaciones que manejan un volumen elevado de datos o de peticiones concurrentes se enfrenta en alguna ocasión. Desde el punto de vista de proceso de desarrollo, el antidotó es simple: hacer pruebas de carga y tener en cuenta las prácticas remendadas para evitar los interbloqueos.


Las recomendaciones para evitar los interbloqueos, que deben ser conocidas por todo desarrollador son:



  • Acceder a los objetos en el mismo orden en los diferentes procesos de nuestra aplicación.
  • Evitar que los usuarios tengan que intervenir durante el proceso de una transacción.
  • Mantener las transacciones lo más cortas y eficientes posible.
  • Elegir índices adecuados.
  • Utilizar el mínimo nivel de aislamiento posible (recordad que Sql Server por defecto utiliza Read Commited como nivel de aislamiento, sin embargo muchas veces será sufiente usar Read Uncommited como nivel de aislamiento).

Pero la tozuda realidad, según mi experiencia, es que por muchas pruebas de carga que hagas y por mucho que sigas las recomendaciones es dificil no sufrir interbloqueos la primera vez que pones tu aplicación en producción. Es muy dificil reproducir en un entorno de laboratorio las condiciones reales a las que se enfrentará nuestra aplicación. El problema es que los interbloqueos afectan seriamente al rendimiento de la aplicación y además se manifiestan a menudo como errores funcionales en la aplicación.


La pregunta que debemos contestar y el mótivo de escribir este post es: una vez que sabemos que estamos sufriendo interbloqueos ¿cómo sabemos en que situación concreta se están producciendo?. Dilucidar que consultas están es vital para deshacer el entuerto. Es aquí donde una característica muy poco conocida del profiler de Sql Server no es de tremenda ayuda.


Entre los numerosísimos eventos que podemos recolectar hay uno especialmente útil a la hora de diagnosticar interbloqueos, el evento Deadlock graph (gráfico de interbloqueo):


Evento deadlock graph


Si creamos una traza del profiler de Sql Server en la que incluyamos este evento, cada vez que se produzca un interbloqueo el profiler capturará toda la información relativa al evento, incluidas las consultas que causaron el interbloqueo y nos la mostrará gráficamente:


Deadlock Graph


En la imagen de encima de estas líneas podéis ver el resultado de probocar un interbloqueo intencionado en la base de datos AdventureWorks.


Otra caracterísca interesante es que el profiler nos permite exportar este evento a un archivo XDL (Deadlock XML file) para, por ejemplo, poder enviarlo por correo.


Extraer datos del evento


¡Espero que estas características del Profiler de Sql Server os sean útiles a la hora de luchar contra los interbloqueos!

MVP una ocasión más

Excelente manera de comenzar el año. Microsoft ha tenido a bien distinguirme en una ocasión más como MVP en la categoría de Team System. Es la sexta vez, tres veces en la categoria de C++ y tres más en la de Team System, y no por ser la sexta vez la ilusión es menor. Ilusión que nace de poder compartir un año más de eventos y buenos ratos con el resto de MVPs y la comunidad, que es lo que realmente hace importante este reconocimiento.

Quiero aprovechar para agrader a la comunidad la excelente acogida que han dado a todos mis eventos, artículos, participaciones en grupos de usuarios, a mi blog y a Geeks.ms. Sin esta excelente acogida, el reconocimiento, el apoyo y el ánimo que la comunidad me brinda, yo no sería MVP. En especial quiero mencionar a la gente de Artalde, dotNetMania y mis compañeros de Plain Concepts y de Sisteplant.

También quiero agradecer todo lo que de la comunidad aprendo que es mucho más valioso que el reconocimiento como MVP, a pesar del valor que le doy.

Espero estar a la altura del reconocimiento que Microsoft me ha otorgado.

Pido disculpas por el autobombo, pero ¡la ocasión lo merece!