Estaré en: Team Foundation Server: la navaja suiza de los proyectos en Pamplona

El próximo día 4 de Octubre de 10:00 a 13:00 de la mañana en el Salón de Actos del Centro de Excelencia Software

Edificio de Formación CEIN, S.A.
Polígono Industrial Elorz-Mocholí
Pza. CEIN nº 1. 31110 Noain

Microsoft, Plain Concepts y Tracasa hablaremos de nuestras experiencias en la implantación de Team Foundation Server, evento en el que podéis inscribiros de manera gratuita si la agenda (ver más abajo) resulta de vuestro interés.

MicrosoftMicrosoft DPE

logo_plain

Tracasa

 

En esta jornada te presentaremos de la mano de la División de Desarrolladores y Plataforma (DPE – Developer & Platform Evangelism) de Microsoft, PlainConcepts y Tracasa todo lo que debes conocer de la herramienta perfecta de Application Lifecycle Management (ALM) Microsoft Team Foundation Server:

  • En qué consiste y qué módulos la componen y qué utilidad tiene cada uno de ellos
  • Cómo puede ayudar en el trabajo diario en un proyecto, dentro de múltiples áreas
  • Ejemplos de uso y soluciones de los diversos componentes de este avanzado sistema
  • Un caso de éxito 100% real y cercano, presentado por la empresa Tracasa que nos contará cómo y para qué lo usan ellos, y cuál es su experiencia.

Si quieres conocer con todo detalle esta auténtica “navaja suiza” del desarrollo, calidad, arquitectura, test y seguridad de las soluciones software, anímate a acompañarnos en esta charla.

AGENDA

Microsoft/DPE – Javier Gómez Lozano

  • ¿Por qué necesitamos ALM?
    • Visual Studio 2010
    • ALM con Visual Studio 2010
    • Componentes y Características
  • Soporte para Desarrollo Heterogéneo
  • La Suite de productos Visual Studio 2010
    • Novedades
    • Gestión de proyectos
    • Arquitectura y Modelado
    • Control de Versiones
    • Desarrollo
    • Construcción automatizada
    • Instalación y administración
  • Microsoft Test Manager 2010
  • Microsoft Lab Management 2010

Plain Concepts – Rodrigo Corral

En esta sesión veremos, en base a escenarios reales, como TFS facilita la adopción de una metodología ágil de desarrollo de software y lleva a los equipos de desarrollo buenas prácticas de ingeniería del software que proporcionan un claro retorno de la inversión y una ventaja competitiva basada en el control explícito de los proyectos y la detección temprana de las fugas de rendimiento por problemas de calidad, evitando la burocracia y facilitando las tareas que el desarrollador realiza.

Tracasa – Carlos Aranda

En esta última parte de la jornada conoceremos un caso de éxito real y próximo a través de la experiencia de Tracasa: por qué y para qué usan Team Foundation y cómo les ha permitido mejorar su calidad y productividad.

  • Tracasa
  • Historia
  • Visión de la compañía
  • Proyectos
  • Recorrido y adaptación
  • Situación inicial
  • Iniciativa y plan de mejora
  • Compromiso con la calidad. Frentes abiertos. (Casos de éxito)
  • Gestión de procesos y metodología. Plantillas de procesos
  • Dinamizar el trabajo, respuesta rápida. Construcciones automatizadas
  • Asegurar una calidad mínima. Testeo funcional

Un saludo.

Detectar cambios en los datos en SQL Server

Saber si los datos almacenados en una base de datos han cambiado es un problema al que nos enfrentamos frecuentemente. Son varios los escenarios en los que tenemos esta necesidad:

  • Enviar solo a un cliente desconectado los datos que han cambiado mientras no tenía conexión.
  • Actualizar datos cacheados solo si los datos subyacentes a la caché han cambiado.
  • Refrescar la representación de los datos en una interfaz de usuario compleja solo si estos han cambiado.

Los niveles a los que nos puede interesar detectar cambios en los datos son varios: detectar que los datos de una fila concreta han cambiado, detectar si los datos en una columna determinada de una columna han cambiado o detectar si alguno de los campos de un conjunto de filas (o una tabla completa) han cambiado. Existe una manera muy simple de conseguir esto en SQL Server que no es muy conocida: apoyarse en las funciones de checksum.

El mecanismo es bien simple: si un solo bit de un conjunto de datos cambia, su checksum cambia. Evidentemente es mucho más simple almacenar y comprobar cambios en el checksum de un conjunto de datos que comprobar si alguno de los campos del conjunto de datos ha cambiado.

¿Cómo detectar cambios en una fila?

SELECT BINARY_CHECKSUM(*) FROM [AdventureWorks].[HumanResources].[Department]
WHERE DepartmentID = @DeparmentID

Si nos interesa podemos calcular el checksum de algunos campos.

SELECT BINARY_CHECKSUM(Name, GroupName) FROM [AdventureWorks].[HumanResources].[Department]
WHERE DepartmentID = @DeparmentID

¿Cómo detectar cambios en un conjunto de filas o una tabla completa?

Aquí el truco es saber que en SQL Server contamos con una función de agregación que nos permite calcular el checksum. Así que primero calculamos el checksum de la fila y luego el checksum agregado del checksum de cada

SELECT CHECKSUM_AGG(BINARY_CHECKSUM(*)) FROM [AdventureWorks].[HumanResources].[Department]

Evidentemente podemos filtrar los datos que nos interesa con una clausula WHERE para limitar el conjunto de filas.

¿Cómo detectar cambios en una columna concreta?

La técnica es similar a la anterior.

SELECT CHECKSUM_AGG(BINARY_CHECKSUM(Name)) FROM [AdventureWorks].[HumanResources].[Department]

¿Y el rendimiento?

Pues en el caso más desfavorable tendremos un ‘full scan’, pero este caso solo se da si calculamos el checksum de una tabla completa que no cuente con un índice clustered. En caso de contar con un indicé clustered, tendremos un ‘index scan’. Es importante desde el punto de vista del rendimiento, en el caso de detectar cambios en una columna concreta, es importante que está cuente con un índice.

Podéis ver los planes de ejecución en la siguiente imagen:

Planes de ejecución

La conclusión es que con índices adecuados el rendimiento de esta solución es al menos tan buena como con cualquier otra. Al final si quieres saber si los datos han cambiado nadie te va a librar de leerlos.

¡Espero que os sea útil!

Primer postgrado mundial en métodos ágiles

En noviembre de 2011 se iniciará el Barcelona el primer postgrado mundial en métodos ágiles y en español. Será una oportunidad única para aprender de la experiencia de profesionales de primer nivel con varios años aplicando principios y métodos ágiles en diferentes contextos e investigando sobre nuevas técnicas.

postgrado-metodos-agiles

A continuación figura el profesorado del postgrado y el temario que impartirán:

  • Xavier Albaladejo – Agile Coach y experto en Gobierno TI, actualmente desplegando el uso de métodos ágiles en everis, consultora tecnológica internacional de 8000 personas, mediante la creación de su Agile Excellence Center. Es fundador de proyectosagiles.org.
    • Qué es la agilidad, su origen, el Agile Manifesto, fundamentos; facilitadores e impedimentos; introducción a Scrum, Lean, Kanban y XP; simulación de estimación de Product Backlog; simulación de Scrum (8 horas).
    • Agile Product Portfolio Management, empresas ágiles, contratos ágiles (8 horas).
  • Agustín Yagüe – Profesor de la Universidad Politécnica de Madrid, especialista en la investigación de técnicas para la gestión ágil de producto, proyecto y pruebas.
    • Product Ownership y gestión de producto; historias de usuario; documentación ágil y usabilidad / experiencia de usuario; elaboración de Product Backlog (24 horas).
  • Xavier Quesada – Certified Scrum coach y Certified Scrum Trainer, ha trabajado en el despliegue de métodos ágiles en Belgacom (la mayor empresa de telecomunicaciones belga con más de 2000 desarrolladores distribuidos entre Bélgica e India), De Post (Correos Belga) y Fédération Royale du Notariat Belge. Ha sido orador en conferencias internacionales y es autor de Visual Management blog.
    • Estimación y planificación ágiles; métricas; herramientas ágiles físicas; radiadores de información (16 horas).
    • Lean thinking y lean tools (8 horas).
  • José Ramón Díaz – Impulsor del uso de métodos ágiles en Biko2 hasta transformarla en una consultora tecnológica ágil, es responsable del área de desarrollo Java. Programador vocacional y apasionado, es un estudioso de todas las disciplinas que rodean a la construcción de software. Constructor de equipos altamente productivos, invierte el tiempo y esfuerzos necesarios en ayudar a que cada miembro de un equipo alcance la mejor versión de si mismo. Siempre coloca a las personas en el centro de atención. Es autor del blog Najabaraja.
    • Gestión de personas, trabajo en equipos altamente productivos e innovadores, facilitación de reuniones (8 horas).
  • Jorge Uriarte – Director de Gailen Tecnologías, donde ha conjugado la visión de emprendedor con el coaching de equipos a nivel de gestión y técnico para crear una empresa y unos clientes ágiles. Es autor del blog Omelas.
    • Herramientas ágiles electrónicas; revisiones de producto y retrospectivas ágiles (8 horas)
    • Agile Coaching, gestión de conflictos, motivación e incentivos, contratación (16 horas).
    • Agile Knowledge Sharing and Management (8 horas).
  • Rodrigo Corral – Mentor, trainer y consultor en ALM y arquitectura, especializado en resolver problemas de estabilidad y rendimiento de sistemas, varias veces MVP y copropietario de Plain Concepts, consultora de referencia por Microsoft en España. Ha sido orador en diferentes eventos ágiles, es administrador de geeks.ms y autor del blog La masa, el ladrillo, la bota, el bocadillo.
    • ALM ágil, eXtreme Programing, testing ágil, arquitectura ágil (12 horas).
  • Alberto Pizarro – Gerente de arquitectura en everis, experto en el desarrollo de arquitectura empresarial bajo planteamientos ágiles en sectores como banca, seguros y administración pública y creador de la suite ALM corporativa de everis, con soporte a métodos ágiles como Scrum y eXtreme Programming.
    • Arquitectura empresarial ágil (4 horas).
  • Carlos Ble – Desarrollador vocacional y arquitecto, eXtreme Programming Coach, es co-propietario de iExpertos y autor de “Diseño Agil con TDD”, el primer libro en castellano sobre Test Driven Development. Ha sido orador en diferentes eventos ágiles y es autor de El blog de Carlos Ble.
    • TDD y BDD (24 horas).
  • Jordi Salvat – Como programador y analista en el sector espacio tuvo ocasión de conocer (o sufrir) las metodologías tradicionales de gestión de proyectos. Como director de tecnología de dos exitosas start-ups y CTO de Salir.com, ha tenido ocasión de vivir en primera persona la aparición y evolución de las metodologías ágiles y el impacto que han tenido en la productividad de los equipos de desarrollo. Es especialista en luchar contra la acumulación de “deuda técnica” heredada y en medir la mejora conseguida. Es autor del blog Jordi on Software Development.
    • Trabajo con código “legacy” (8 horas).
  • Beatriz Martín – 14 años en Publicidad y TIC. Experiencia en gestión de proyectos, gestión y dirección de personas, y liderando equipos profesionales. En su trabajo conjuga la necesidad de resultados y procesos de trabajo con la atención a las personas; y Joao Gama, propietario y product owner de agileScorecard.com, herramienta de valoración de equipos ágiles y de desarrollo continuo de talento empresarial.
    • Gestión del cambio organizativo y desarrollo de la cultura a través del Management. (8 horas).
  • Juan Gutierrez – Manager y Agile Coach en F-Secure, empresa internacional de seguridad informática, donde ha estado involucrado en el despliegue global y multi-sede de métodos ágiles y donde actualmente está realizando el depliegue de su sede francesa. Trabajó en Nokia donde vivió la transición de la compañía a los métodos ágiles. Es autor del blog Agilizar.
    • Despliegue de Agile en organizaciones, escalado, equipos distribuidos (8 horas).

El postgrado tendrá una duración de 6 meses y se realizará viernes tarde y sábado por la mañana. Estará dividido en 3 módulos: conceptos ágiles, ingeniería y empresa, siendo obligatorio cursar el primero y uno de los dos siguientes para obtener el postgrado. Para más detalles, consultar la página oficial del postgrado

¡Un saludo!

Estuve en: Agile Open Spain 2011

Este fin de semana pasado se ha celebrado la tercera edición del Agile Open Spain que reunió unos 150 asistentes interesados en las metodologías ágiles. El desembarco de la armada de Plain Concepts fué notable, Vicenç Garcia, Ibon Landa, Gerard Lopez, Alfredo Fernandez y Jose Luis Soria (podéis ver la presentación de su sesión sobre estimación), hay es nada. Propusimos un total de cinco sesiones de los temas más variopintos… y sobre todo creo que disfrutamos un montón. Empezamos cepillandonos un chuletón para comer el viernes y acabamos con una cervecitas en el Puerto Viejo de Algorta ¿alguna manera mejor de hacer equipo?.

Si alguien duda de la calidad del evento y la diversidad de temas tratados no tiene más que echarle un vistazo al panel de sesiones. No tenéis que ver más que los twits sobre le evento.

El panel de la CAS 2011

Os dejo mis impresiones sobre las sesiones a la que acudí aunque lo más interesante en un open space pasa en los pasillos.

Test doubles: stubs, spies y mock de Rubén Bernárdez

¿Por qué usamos dobles? Para evitar dependencias externas, para que los test no sean lentos…

Interesante conversación y debate sobre los diferentes tipos de dobles de test que podemos usar, los diferentes estilos a la hora de usar test, las señales que nuestros test lanzan cuando se rompen…

Especialmente interesante para mi fue la conversación Alberto Peña en la que constaté que tenemos aproximaciones muy diferentes al testeo unitario pero que aun así los dos disfrutamos de la ventaja que tiene escribir test, los escribas antes, durante o después, los uses como herramienta de diseño o como herramienta de calidad.

Os recomiendo una artículo muy interesante que va en la línea de lo hablado en esta sesión: Exploring The Continuum Of Test Doubles.

 

Seducir a las empresas, Raquel Laina y Amalia Hernandez

¿Nos disfrazamos para seducir a las empresas? ¿Se disfrazan las empresas? ¿Es posible no disfrazarse?… Yo defendía que todos estamos sometidos queramos o no, de manera incosciente a la tiranía de la apariencia, de la pose cuando estamos en un proceso de selección, seamos empresa o candidato. Es como ligar, propuse, nadie es la persona que se ver cuando está ligando.

¿Como presentamos el modelo alternativo que supone el agilísimo a las empresas? ¿Comó lograr que este modelo llegue a los procesos de selección? En Plain Concepts algo hacemos, por lo menos no son entrevistas convencionales, hablamos por skype, los traemos a nuestra oficina, comemos con ellos, todo el equipo está en todo el proceso…

¿Está obsoleto el modelo del currículo? Todos tenemos un currículo, es necesario diferenciarse: escribe un blog,… el papel a muerto.

Surgio una idea interesante: Desacreditar la entrevista de trabajo convencional,

Excelente resumen de Xavier Verges sobre esta sesión, en general las notas de su cuaderno sobre la AOS son una caña.

Talento de Israel Alcazar y Raquel Laina

La pizarra lo dice todo…

La pizarra de la sesión sobre el talento

La sesión que yo propuse: Déjame hacer las cosas bien, sobre la deuda técnica

Os dejo la presentación que utilicé, os servirá para situaros sobre los temas que debatimos.

Las notas sobre mi sesión de Frank son el complemento perfecto (también tiene notas muy interesantes sobre otras sesiones).

También en el podcast de Carlos Ble, hablo de la sesión.

El podcast de Carlos Ble

Si bien Carlos Ble, uno de los habituales en estos eventos, no acudió en esta ocasión, ni aun así ha dejado de aportar. El domingo tras el evento se tomo la molestia de preparar un podcast con entrevistas a algunos de los asistentes, entre los que me encuentro. No te lo pierdas, tanto si estuviste como si no, es muy interesante. En las grabaciones podeis escuchar a Vicenç García (@vgaltes), Rubén Bernárdez (@rubenbpv), Jorge Uriarte (@jorgeuriarte), Israel Alcázar (@ialcazar), José Ramón Díaz (@joserra_biko), José Manuel Beas (@jmbeas) y yo mismo.

Un saludo.

Proxy cache con IIS Application Request Routing

Introducción

IIS Application Request Routing (ARR) es una extensión que permite aumentar la escalabilidad y la fiabilidad de las aplicaciones Web desplegadas sobre IIS mediante el enrutamiento de peticiones basado en reglas, permitiéndonos añadir balanceo de carga  o cache de contenidos de manera muy simple.

En concreto nos vamos a centrar en implementar un proxy que actuará como cache aliviando en número de peticiones que recibirá nuestro servidor Web. El proxy cache se sitúa entre el servidor Web y los clientes y cachea a a disco contenidos que de otra manera tendrían que ser descargados desde el servidor Web.

Un uso típico de un proxy cache es actuar con ‘edge server’. Un ‘edge server’ es un servidor más cercano a los clientes que consume el contenido. Supongamos una empresa que tiene una aplicación Web desplegada en La Coruña y que tiene delegaciones en Madrid, Bilbao y Seattle. Supongamos que esa aplicación Web por ejemplo utiliza Smooth Streaming para servir videos. Se hace evidente que contar con un proxy cache en las delegaciones que se encargue de cachear los videos servidos (o cualquier otro contenido pesado) de manera trasparente tendrá un efecto muy beneficioso en varios aspectos: mejorar la experiencia de usuario que tendrá que esperar menos para tener los contenidos disponibles, aliviar la carga soportada por el servidor web y minimizar el consumo de ancho de banda ya que si un contenido está en la cache no tendrá que pedirlo hasta el servidor Web lejano.

Veamos a continuación los pasos necesarios para montar un proxy cache con IIS Application Request Routing.

Instalar IIS Application Request Routing en nuestro IIS

Sin duda la manera más cómoda de instalar ARR es utilizar el Microsoft Web Platform Installer, basta con descargarlo, ejecutarlo y seleccionar Application Request Routing y pulsar el botón Install.

image

Una vez terminada la instalación en Internet Information Server (IIS) Manager, si seleccionamos el nodo raíz de nuestro servidor, veremos un nuevo icono en la sección IIS llamado Application Request Routing Cache.

image

Configurar la caché de disco

Para configurar el lugar donde nuestro proxy almacenara los archivos cacheados pinchamos en el icono de Application Request Routing Cache y veremos la siguiente pantalla.

image

Tras pinchar en Add Drive… podremos configurar la ruta en la que se almacenarán los archivos cacheados.
Precaución: esta carpeta debe existir de antemano, sino no recibiremos ningún error pero la carpeta no se creara y nada se cacheará.

image

Activar el proxy y configurar sus propiedades

Para configurar las propiedades del proxy pinchamos en Server Proxy Settings…

image

En la pantalla Application Request Routing que aparece, para activar el proxy marcamos la casilla Enable proxy

image

El siguiente paso es habilitar la cache en disco y para optimizar la cache para eventos de video online marcar el check Enable request consolidation (más información sobre esta característica).

image

Para lograr que se cacheen peticiones con respuestas de tamaño considerable como por ejemplo porciones de video es necesario incrementar el valor de Response buffer threshold a 2048 KB.

image

Por último en Proxy Type debemos asegurarnos de que están marcados Use URL Rewrite to inspect incoming request y Enable SSL offloading (este último check hará que la comunicación entre el servidor Web y el proxy no se haga por SSL aunque la petición sea SSL si confiamos en la red por la que se realizarán las comunicaciones ahorraremos la carga adicional que supone SSL).

El paso final es introducir en Reverse Proxy la dirección del servidor Web para el que estamos configurando el proxy (p.e.: www.koalink.tv).

image

Ahora solo queda un último paso: que todos los clientes que queramos que usen este proxy resuelvan la dirección del servidor Web a la dirección del proxy, mediante la configuración adecuada del DNS de los clientes o de su archivo HOSTS (c:windowssystem32driversetchosts

Comprobar el funcionamiento del proxy

La primera comprobación que debemos hacer es que el proxy está respondiendo. Para ello simplemente apuntaremos el navegador a http://localhost y debemos recibir exactamente la misma respuesta que si navegásemos directamente al servidor Web directamente.

La segunda es ver que tras un numero significativo de peticiones existen ficheros en el directorio de disco que hemos configurado para la cache (c:cache en este caso).

La tercera es ver que los contadores de estado de la cache, en la pantalla principal de Application Request Routing Caching, empiezan a mostrar actividad:

image

Referencias adicionales

Application Request Routing

Configure Request Consolidation Feature in Application Request Routing

Configure and Enable Disk Cache in Application Request Routing

Estuve en: ALM Sessions 2011: Caminado hacia la agilidad con Visual Studio 2010

El pasado 9 de Marzo en el marco del Cloud Day de Microsoft tuve el placer de participar en las ALM Sessions. No es que no me guste la nube, pero como el público me tiene más encasillado que a Micheal Landon, me toco hablar una vez más de las excelentes capacidades de Visual Studio para implementar metodologías ágiles. Mis compañeros Unai Zorrilla y Ibon Landa participaron también en tan magno evento. Ibon, con dos ponencias Nubes híbridas con Azure Connect y Gestión efectiva con Project Server y Team Foundation Server (le toco sustituir a Jose Luis Soria, que estaba de ponente en el TechEd de Oriente Medio) y Unai con una ponencia sobre Seguridad basada en Claims.

En mi sesión titulada Caminando hacia la agilidad con Visual Studio 2010 vimos, en base a escenarios reales, como TFS facilita la adopción de una metodología ágil de desarrollo de software y lleva a los equipos de desarrollo buenas prácticas de ingeniería del software que proporcionan un claro retorno de la inversión y una ventaja competitiva basada en el control explícito de los proyectos y la detección temprana de las fugas de rendimiento por problemas de calidad, evitando la burocracia y facilitando las tareas que el desarrollador realiza.

Para aquellos que os perdisteis el evento o que no pudisteis asistir a mi sesión os dejo la presentación que utilicé y el video de la misma:

Video: Caminando hacia la agilidad con Visual Studio 2010

Si queréis ahondar en los conceptos que se presentan en esta sesión, tenéis una excelente oportunidad en la Scrum Week.

Espero que os resulte interesante.

Cacheitis: Lo mínimo que todo desarrollador debe saber sobre las cachés

Creo que, después de tanto artículo sobre Scrum, los lectores de mi blog agradecerán una entrada que no tenga nada que ver con las metodologías ágiles. Sí, sí, yo también estoy un poco saturado del tema, pero de todos modos, no dudéis que vamos a seguir hablando de ello en este blog. Pero antes de meterme en harina, permitidme que os presente www.scrumweek.com, una semana enterita de formación sobre metodologías ágiles.

Pero como decía hoy no vamos a hablar de metodologías, sino de arquitectura y diseño de software. De hecho vamos a hablar de uno de los elementos claves de toda arquitectura: la caché.

Seguro que ninguno de los lectores ignora los beneficios que una caché bien diseñada proporciona a casi cualquier aplicación. Se puede asegurar que sea cual sea el dominio de nuestra aplicación el rendimiento de la misma se verá beneficiado por el principio general de almacenar datos en lugares donde su acceso sea más rápido (memoria frente a disco, memoria frente a base de datos, capas más cercanas de la aplicación frente a capas más lejanas…).

Este principio general se cumple casi siempre, pero no es el motivo de este post hablar de los ya conocidos efectos beneficiosos del cacheo, sino de los usos aberrantes que a menudo he visto de la cache. Y es que, si bien una cache bien utilizada es un catalizar claro del buen rendimiento, una mal uso de la cache es más a menudo de lo que muchos desarrolladores sospechan fuente de serios problemas de rendimiento. Es la tan temida cacheitis. La cacheitis es una enfermedad que sufren muchísimas aplicaciones, consiste en hacer una mal uso de la cache que provoca una dolorosa inflamación de la misma que la hace totalmente inservible. La cacheitis se manifiestas con muchos síntomas diferentes siendo los más significativos un altísimo consumo de memoria y un mal rendimiento de la aplicación.

La cacheitis tiene sus orígenes en diversos malos usos de la caché casi siempre relacionados con olvidar alguna de las siguiente buenas prácticas:

Asume que no puedes cachearlo todo: Como arquitecto, cuando te enfrentas a la difícil decisión de diseñar tu modelo de caché debes tener en cuenta que no puedes cachear todo. La cache por definición es finita. Si puedes contar con una caché infinita, simplemente no necesitas una caché. El lugar en el que suelen acabar todo los datos es la memoria, si todos los datos que va a manejar tu aplicación caben en memoria por definición y tienes la seguridad de que esto siempre va a ser así, simplemente almacénalos directamente en memoria (ignoro aquí la necesidad de persistencia). Por ejemplo supongamos una aplicación que utiliza una tablas de cálculo, cargar directamente esas tablas en memoria puede ser una opción interesante. De todos modos, hemos de reconocer, que a menudo las aplicaciones no puede asumir está premisa. En ese caso es una labor sumamente difícil decidir cual es el balance justo entre consumo de memoria y uso de recursos más lentos como acceso a disco y petición de datos por la red, pero ese no es le punto ahora. El punto ahora es que la memoria es finita y además un recurso compartido y por tanto tu cache tiene que estar explícitamente limitada. Diseñar si tener en cuenta que la cache es finita y cachearlo todo es un error de base, una cache que cachea todo nunca va a ser efectiva. Una frase que en el Debugging and Optmization Team de Plain Concepts hemos oído a menudo es: ‘Cómo puede ser lenta la aplicación si lo cacheamos todo’… cachear todo es dañino por que la cache es finita. Si en una cache finita, cacheas todo el resultado será que algo tendrá que salir de la caché para que entre lo último que has cacheado y que tu cache por lo tanto siempre contendrá lo último cacheado, pero no lo que más importante sea cachear. La cache debe almacenar lo recursos costosos que se acceden con más frecuencia, no los últimos accedidos.

El cacheo temprano es el origen de todos los males: Parafraseando la mítica frase de Donald Knuth , ‘la optimización temprana es el origen de todos los males’, tomar decisiones de cacheo demasiado temprano es dañino en la mayoría de las ocasiones. A menudo cuando diseñamos una arquitectura establecemos mecanismos de cacheo que luego son utilizados hasta el abuso. El peligro subyacente al cacheo temprano es que comencemos a cachear sistemáticamente elementos que nos parecen costosos sin tener evidencia de que realmente son los mejores candidatos para su cacheo. Por ejemplo, llegamos a una historia de usuario que requiere cargar datos de provincias y como suponemos que van a cambiar poco decidimos cachearlos ignorando que el factor más importante a la hora de cachear es el coste de obtener la información multiplicado por el número de accesos que esa información va a ser accedida. Cachear toda la información que cambia poco simplemente por que es fácil de cachear es un error habitual. Además los patrones de acceso a la información en aplicaciones complejas son difícilmente predecibles, es muy difícil sin analizar el rendimiento de tu aplicación mediante unas adecuadas pruebas de carga que modelen el uso que va a tener, tomar las decisiones correctas sobre que cachear. Diseña para hacer el cacheo posible, pero no decidas que cachear hasta que no te quede más remedio.

No solo existe una caché: Otro error habitual es olvidar que no solo existe una cache en el sistema. El gestor de bases de datos que utilizamos implementa mecanismos de cache, el servidor web que utilizamos implementa mecanismos de cache, nuestra aplicación implementa mecanismos de caché… ¡y todos usan la memoria!. Hace un tiempo nos llamaron para ver que estaba ocurriendo en una aplicación que hacia un buen uso de la caché, de hecho el comportamiento de la aplicación era adecuado la gran mayoría de las ocasiones… excepto cuando el ‘servidor’ tenía menos de dos bigas de memoria situación en la que todo se volvía escandalosamente lento. Lo más sorprendente es que en la última versión de la aplicación habían añadido una caché que mejoraba mucho el rendimiento en la mayoría de los casos. Sin embargo la versión anterior sin caché se comportaba aceptablemente en servidores con poca memoria. Tras estudiar el comportamiento de la aplicación, sorprendentemente, en situaciones con poca memoria, elementos costosos que habitualmente debían estar en la caché sistemáticamente tenían que ser recuperados desde la base de datos. Y lo que es peor, cuando observábamos el comportamiento de la base de datos ¡también veíamos tiempos de respuesta muy elevados!. Tras tirar del hilo nos dimos cuenta de lo que estaba ocurriendo: SQL Server y ASP.Net/IIS se estaban pegando por la memoria para colocar sus respectivas cachés. Vaya, nos habíamos olvidado de que ¡la memoria es finita!. La solución, sencilla, limitar la memoria máxima a utilizar por parte de SQL Server y de ASP.Net y listo… problema solucionado.

Una colección estática o global no es una caché: Aunque parezca sorprendente, no es extraño encontrar desarrolladores que implementa su propio sistema de caché. Esto siempre es una aberración. Hoy por hoy todas las tecnologías que podemos usar en una arquitectura .Net en las que el cacheo puede jugar un papel tiene un mecanismo de caché. ¡He visto cachés implementadas como colecciones estáticas! Una mecanismo de caché que no cuenta con un mecanismo de invalidación no es un mecanismo de caché. Tan importante es mantener en caché los elementos que se acceden con más frecuencia como liberar la memoria utilizada por aquellos elementos en cache que no son accedidos. Igualmente es importante, siempre que se decide cachear un elemento establecer la política de invalidación de dicho elemento.

La cacheítis, como cualquier enfermedad tiene síntomas que nos pueden poner sobre su pista. Casi todos estos síntomas se manifiestan con contadores de rendimiento fuera de control. El el Performance Monitor (Perfmon.exe) el termómetro que nos indicará que podemos estar sufriendo de cacheitis. Hay un parámetro que todo mecanismo de caché suele publicar en sus contadores rendimiento y que es fundamental a la hora de diagnosticar una cacheítis:

Cache Hit Ratio:

Cuando el cliente de un sistema de caché pide el acceso a un dato que es susceptible de encontrarse en la caché y lo encuentra se produce un ‘hit’ de la cache. La relación entre las veces que se hacen peticiones a la cache y las veces que el dato buscado en la caché se encuentra en esta es el Cache Hit Ratio. Un porcentaje bajo en este indicador es un síntoma claro de un mal uso de la caché. Se suele considerar un valor adecuado un ratio de alrededor del 90%.

En la siguiente imagen se pueden ver diferentes contadores de rendimiento de componentes típicos de una aplicación .net:

image

¡Ojo con la cacheitis!

¡ScrumWeek y el primer curso de certificación Professional Scrum Developer en España!

Scrumweek2011_r2_c1

En el marco de la primera edición de la ScrumWeek organizada por Plain Concepts y Proyectalis, desde Plain Concepts hemos preparado el primer curso de certificación Professiona Scrum Developer en España. Pero no solo podrás aprender y certificarte sobre Scrum y TFS a fondo, además hay formación sobre: Pruebas unitarias, Arquitectura ágil, Coaching de equipos ágiles, Scrum (de manera agnóstica a la tecnología) y sesiones gratuitas.

Regístrate ahora con un descuento del 50% sobre el valor del curso.

El programa Professional Scrum Developer .NET (PSD.NET) capacita, evalúa y certifica a los desarrolladores de Scrum que trabajan en tecnologías .NET. Durante Scrumweek se llevará a cabo un curso PSD.NET durante el cual se mostrará cómo utilizar prácticas de ingeniería de software modernas para desarrollar un incremento de funcionalidad potencialmente entregable, en el marco de Scrum, Visual Studio y Team Foundation Server 2010, y trabajando como parte de un equipo autoorganizado y multifuncional que practica un desarrollo iterativo e incremental. Las clases son guiadas por ejercicios prácticos, en los que los estudiantes trabajan en equipo para desarrollar incrementos completados de elementos del Backlog de producto.

Lugar y fecha

La ScrumWeek Madrid 2011 tendrá lugar del 4 al 8 de Abril (lugar pendiente de determinar).

PROGRAMA

El programa de esta semana Ágil incluye:

Cursos

  • Curso de Scrum (iniciación a intermedio), por Rodrigo Corral y José Luis Soria (lunes-martes, 9 a 18)
  • Coaching de equipos Ágiles, por Ángel Medinilla (lunes-miércoles, 9 a 15)
  • Arquitectura Ágil, por Unai Zorrilla (miércoles-jueves, 9 a 15)

Seminarios y talleres en profundidad

  • Gerencia Ágil, por Ángel Medinilla (jueves, 9 a 18)
  • Taller de pruebas unitarias, por Ibón Landa (viernes, 9 a 15)

Sesiones divulgativas gratuitas

  • Visual Studio Ágil, por Ibón Landa (jueves-viernes, 16 a 18)
  • Cultura Corporativa Ágil (lunes-martes, de 16 a 18)

Scrum Clinic

Por Ángel Medinilla y Rodrigo Corral (viernes, 9 a 15)

Curso oficial Professional Scrum Developer .NET

Por Rodrigo Corral y José Luis Soria (lunes-viernes, día completo)

Adicionalmente, el programa incluirá la celebración de una serie de sesiones divulgativas, talleres, coloquios, reuniones de grupos locales y networking, además de un Coding Dojo, las tardes de lunes a miércoles, así como un barcamp-cena el jueves. Permaneced atentos a esta página y a nuestras noticias para más información.

Scrumweek2011_r6_c2

Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil

Tras unos cuantos años participando en la gestión de proyectos de desarrollo de software y ayudando a diversas organizaciones a mejorar como gestionan sus proyectos, he llegado a una conclusión muy curiosa: gestionar proyectos de software es una actividad extremadamente difícil. Continuamente veo aberraciones, errores abismales, errores que llevan descritos décadas en los libros sobre gestión de proyectos, errores que todos los que participamos en la gestión de proyectos cometemos muy a menudo. Observando estos errores, buscando su causa última, lo que nos lleva caer una y otra vez en el mismo error he llegado a una conclusión: la intuición no sirve para gestionar proyectos. La intuición de proyectos esta llena de ideas contra intuitivas, de anti patrones, de soluciones que parecen atractivas y simples y que no funcionan. Un buen gestor de proyectos tiene que luchar continuamente contra su intuición. Solo los conocimientos, las convicciones firmes en principios y fundamentos universales de la gestión de proyectos nos sirve. Y evidentemente la voluntad de defender esos principios, muchos de ellos, insisto, contra intuitivos contra la gente que trata de meter su nariz en la gestión de nuestros proyectos basándose en su intuición, en el siempre se ha hecho así, o en el aquí mando yo…

La lista de trampas que nos encontramos en la gestión de proyectos es inmensa, no me ha costado más de quince minutos pensar en una serie de ejemplos. Esta lista de cosas que parecen funcionar y no lo hacen no pretende ser completa o exhaustiva, simplemente pretende soportar mi tesis de que la gestión de proyectos está llena de trampas, que disfrazadas como soluciones interesantes o verdades absolutas, a menudo se rebelan como errores. Errores que se repiten con demasiada frecuencia. Esta es la gran dificultad de la gestión de proyectos: tener los conocimientos suficientes, el arsenal de respuestas preparado para que cuando algún gestor de proyectos de postal, uno de los miembros de nuestro equipo, un consultor externo u otro que viene con una genial idea, plantea de nuevo una de estas soluciones que llevan una trampa dentro, podamos contrarrestarla con contundencia, con datos y demostraciones que dejen claro que lo que es intuitivo no siempre funciona en lo que se refiere a la gestión de proyectos.

El modelo en cascada. No hay nada más intuitivo que el modelo en cascada, es fácil de explicar, fácil de entender, fácil de implementar, describe perfectamente las actividades claves del desarrollo de software… solo tiene un problema, no funciona.  Aun así es una trampa golosa en la que miles de proyectos mueren atrapados cual moscas ignorantes del peligro. Nunca falta quien defiende este modelo, y es normal, la intuición no dice que si dedicamos suficiente esfuerzo al principio del proyecto para eliminar la incertidumbre todo fluirá después por nuestra cascada de manera limpia y ordenada. Con suficiente planificación y diseño todo fluirá. Pero hay un motivo por el que este modelo nunca a funcionado y nunca va a funcionar: Siempre hay incertidumbre, nunca vas a se capaz de eliminarla toda y en el momento en que esa incertidumbre aparezca por pequeña que sea, el modelo en cascada mostrará sus flaquezas de manera irreversible: la retroalimentación es casi imposible. ¿Que pasa si en tu fase de test descubres que tu arquitectura no da el rendimiento adecuado?. Pues te pasará lo que ha un salmón que remonta una cascada: morirás exhausto sin remedio. Steve McConnell tiene una ilustración en su libro Rapid Application Development que yo procuro traer a mi cabeza cada vez que la tentación de acercarme a un modelo en cascada me ronda la cabeza:

image

Las estimaciones son certezas. Convertir las estimaciones en compromisos o certezas es otra de esas trampas que nos hacemos a nosotros mismos cada poco. Bien cuando damos estimaciones, bien cuando las recibimos. Pensar que somos capaces de estimar con el grado de certeza suficiente, olvidar el cono de incertidumbre es otra de esas trampas habituales. Es imposible acertar sistemáticamente en tus estimaciones, no por que yo lo diga, sino por que así lo demuestra el cono de incertidumbre.

El cono de incertidumbre nos dice, que en el momento en que habitualmente estimamos un proyecto o una tarea, al principio del mismo, es altísimamente probable que nos desviemos. Boehm intuyo esta realidad en 1981 y formuló el cono de incertidumbre que luego fue validado por el Laboratorio de Ingeniería del Software de la NASA. La próxima vez que alguien quiera ignorar el difícil problema de la estimación y convertir tus estimaciones en adivinaciones, dale con el cono en los morros… y dale fuerte.

Estimar con búferes. Como todos nos hemos visto atrapados por las dificultades de la estimación en un momento u otro y todos hemos sido flagelados por no cumplir nuestras estimaciones en alguna ocasión (pese a que el cono de incertidumbre demuestra que lo normal es no acertar), todos hemos sido victimas alguna vez de otra de esas ideas, que si bien la intuición nos dice que son correctas, la realidad y la ciencia han demostrado como erróneas: estimar con búferes. La intuición nos dice que si añadimos búferes a nuestras estimaciones, nuestro grado de cumplimiento de las mismas mejorará. La tozuda realidad, que a menudo es más compleja de lo que nuestra intuición asume demuestra que esto no es así. Y lo demuestra en forma de ley, la Ley de Parkinson: el trabajo se expande para consumir el tiempo disponible para realizar una tarea. Da igual el búfer que añadas, las tareas laterales, las tareas de investigación, las tareas divertidas, el ruido, todo esto conspirará en tu contra para que consumas el búfer. Además la naturaleza humana nos hará ‘posponer el inicio de la tarea hasta que no quede más remedio que iniciarla’ o lo que es lo mismo ¡primero consumiremos el búfer!. ¿Recordáis vuestros días de estudiantes? Sabías la fechas de los exámenes con meses de antelación… y si la noche anterior estabais estudiando.

Podemos sacrificar calidad para ahorrar coste o recortar plazos. Esta es otra de esas trampas mentales que nos hacemos a menudo. Nos decimos: rebajemos la calidad del software que hacemos, así cumpliremos plazos o reduciremos costes. Parece intuitivo ¿no? Al fin y al cabo todos tenemos en nuestro barrio una tienda de Chinos que demuestra esto, podemos hacer productos de menos calidad más baratos y venderlos como churros. Olvidamos con facilidad o incluso muchos desconocen que en el software también existen costes asociados a la ‘no calidad’ y que son nuestros clientes no nosotros quienes finalmente marcan el nivel de calidad exigido. ¿Habéis intentando mantener o extender software de baja calidad?  ¿Habéis conseguido que un cliente acepte un software que no cumple sus expectativas de calidad? Y es que en el software la calidad no es opcional. Fijaros en el siguiente gráfico que podéis encontrar en la página 69 del ya mencionado Rapid Application Development:

image

En 1991 varios estudios desvelaron que los proyectos que tienen una tasa de defectos más baja son los que logran unos plazos de entrega más cortos. Aun así la mayoría de organizaciones ignoran esta máxima. Increíble ¿no?, una vez más nos estamos dejando engañar por nuestra intuición sacrificando calidad para intentar lograr terminar antes. Dejar la calidad para el final nunca ha sido una buena idea.

Hay muchas otras trampas que la intuición nos pone y de las que ya he hablado en este blog:

No es raro que caigamos en el error de olvidar que no podemos vencer la tiranía del triángulo de gestión de proyectos, o que olvidemos la ley de Brooks y olvidemos que añadir recursos no es una solución que pueda funcionar, o incluso que nos creamos que existen balas de plata, herramientas o técnicas maravillosas que van a hacer que ganemos velocidad de desarrollo.

Lo  peor de todo es que el factor que más influye en el desempeño de un equipo de desarrollo no lo puedes gestionar fácilmente:  la motivación. Es más, la ciencia de la motivación, lo que llevamos décadas pensando que motiva a los desarrolladores se a demostrado, que contrariamente a lo que nos dice nuestra intuición desmotiva y es un elemento tóxico. Te sugiero que visites : Leer antes de motivar… o lo que debe saber todo jefe de proyecto.

Corolario: No eres el más listo. Lo que no ha funcionado a muchos otros no te va a funcionar a ti. La gestión de proyectos es una ciencia llena de trampas, soluciones atractivas que no funcionan, saber detectarlas y luchar contra ellas es el principal trabajo de quien gestiona proyectos.

En el próximo post hablaré de como Scrum evita estas trampas de la intuición estableciendo un conjunto claro de reglas. Saltarse esas reglas es una trampa en la que muchos caen sin darse cuenta de que están ahí para protegerte de ti mismo, de tu intuición errónea, de caer una vez más en ciertos antipatrones.

¡Un saludo!