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

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!

Sobre gurús y telepredicadores…

Escribía hace algunos días Juan Palacio en su imprescindible blog navegapolis.net sobre la proliferación de gurus de lo ágil (antes proliferaron los gurús de la gestión del riesgo, de CMMI, de…). Gente que por cursos de dudosa útilidad, más allá de regodearse en la obviedades de lo ágil, cobran autenticas burradas. Comparto la apatía de Juan hacia este tipo de gurú (o telepredicador).

Yo siempre he estado en contra de los cursos de Scrum generalistas. En Plain Concepts no los ofrecemos. No tiene sentido dedicar dos días de tu precioso tiempo ha hablar de las generalidades Scrum, Lean, XP…, es algo que se puede aprender con la excelente bibliografía disponible sobre el tema. Los fundamentos de Scrum (y de la agilidad en general) se aprenden en diez minutos y se le pueden hasta explicar a tu abuela. Otra cosa es aplicar lo aprendido. Ahí si que puedes necesitar ayuda. La teoria es fácil, hay que conocerla pero es facil, la práctica dificil.

Aprender Scrum de verdad no puede hacerse, no tiene sentido , si no es en un marco concreto de aplicación práctica, con un equipo concreto, para un proyecto o proyectos concretos. Ahí es donde está la dificultad, Ahí es donde quizás un experto en la materia pueda hacerte falta. Alguien que de verdad se haya fajado en el barro, que se haya pegado con montar todas las practicas de ingeniería del software que rodean la agilidad, con soportar la agilidad con las herramientas adecuadas, o con temás tan simples y obvios, pero tan olvidados, como adecuar tu política de gestión de la configuración a tu metodología ágil.

Como comenté en el post de Juan, en mi opinión, lo que separa a un gurú de un telepredicador son los resultados, nada más. La puesta en escena es similar, la verborrea parecida, los powerpoints igual de deslumbrantes… pero los resultados, los resultados no. Hay mucha gente dando cursos de Scrum o Lean o XP o lo que sea, mucha más escribiendo sobre el mismo tema, bastantes más luciendo certificaciones y certificando a otros… pero no hay tanta gente que pueda enseñar un palmarés de resultados significativo. Si no funciona simpre podremos llamar al Gran Vidente Africano…

No son tantos los gurús que pueden decir, mira, por qué no te vienes a este cliente conmigo o a este otro o aquel que es de tu sector y hablamos de cómo hemos transformado la gestión de proyectos en su organización, de que resultados hemos obtenido, de que ha ido bien y que no ha ido tan bien… y también, ya que estamos, de si el resultado ha sido satifactorio y el gurú era tal.

Mucha gente puede venderte la moto de la agilidad, y enseñarte a jugar con postits, pero no tantos pueden transformar la manera en la que tu equipo de desarrollo funciona. Solo estos son gurús. Y es que en esto de la agilidad, como en todo, una cosa es predicar y otra dar trigo.

Por cierto antes de que alguien tire con dardo en los comentarios: no, no me considero un gurú, no le llego a la altura del zapato al Gran Vidente Africano (que ya me ha solucionado dos fugas de memoria y tres deadlocks con un conjuro llamado SOSEX o quizás ese fue el Maestro Sr. Doval)…

Gran vidente africano

…pero sí, tengo claro que puedo ayudarte a llevar la agilidad a tu empresa.

¡Un saludo!

¿Qué hacer si MSMQ tarda mucho en enviar el primer mensaje?

MSMQ es una de esas tecnologías que de repente reviven, y pasan de ser usadas por unos pocos a ser ampliamente utilizadas. WCF y la popularidad que las arquitecturas EDA (Event Driven Architecture) han ganado tiene que ver mucho con este renacer. WCF ha facilitado enormemente la utilización de MSMQ llevando las ventajas de las comunicaciones basada en mensajería a una infinidad de arquitecturas. Si queréis saber más sobre el tema no os perdáis un webcast muy interesante del que ya hablé hace un tiempo: Webcast: Patrones para arquitecturas orientadas a eventos y mensajes.

WCF pone una capa de abstracción sobre MSMQ que facilita enormemente su uso, pero que también dificulta en cierto modo la detección de problemas. No debemos olvidar que MSMQ esta debajo de WCF. Y todas las abstracciones fugan. Es en ese momento cuando tenemos que bajar de nivel y ver que pasa en MSMQ. Son muchos los aspectos de MSMQ que pueden penalizar el rendimiento o la estabilidad de nuestra aplicaciones, por mucho que WCF abstraiga los aspectos más truculentos. La fuente última de información sobre MSMQ una tecnología de Microsoft no muy bien documentada es un documento, de ciento y pico páginas, nada fácil del encontrar llamado Message Queuing Frequently Asked Questions. Regencia imprescindible para cualquiera que use MSMQ en sus aplicaciones.

Hoy voy a hablar de una de esas situaciones en que hay que trastear con los oscuros parámetros de MSMQ, un sniffer de red y los contadores de rendimiento para lograr que nuestra aplicación funcione como debe.

Hace unos días recibí una llamada de un cliente. Una aplicación que funcionaba perfectamente en decenas de instalaciones no se comportaba como debía. La primera vez que realizaban unas acciones (que yo sabía que implicaban el envío de un mensaje de MSMQ mediante WCF) la aplicación tardaba un motón de tiempo (alrededor de un minuto) en arrojar resultados. Esto era especialmente molesto, pues el patrón típico de uso de la aplicación era largos tiempos de inactividad seguidos de momentos en que debía responder rápidamente.

Una cosa que mucha gente desconoce de MSMQ es que trabaja mediante sesiones (ojo, no confundir con las sesiones de WCF, nada que ver). Siempre que en una arquitectura nos encontramos con ‘sesiones’ sean del tipo que sean, sabemos o podemos intuir dos cosas: que establecer esas sesiones tiene un coste y que las sesiones tienden a caducar tras ciertos periodos de inactividad para ahorrar recursos. Pues bien, esta es la clave del asunto que hoy nos preocupa: típicamente iniciar una sesión de MSMQ es un proceso que no debe llevar más de unos milisegundos. De todos modos es un proceso complejo que implica numerosos elementos de nuestra infraestructura de red y comunicaciones: consultas DNS, consultas al directorio activo, autenticación de usuarios y el intercambio de unos cuantos intercambios de información por la red. Podéis ver el proceso en la siguiente captura de red (realizada con Microsoft Network Monitor):

MSMQ Session

La parte resaltada en rojo, se corresponde con el establecimiento de la sesión de MSMQ. La parte resaltada en azul con el envío del primer mensaje. Si en alguno de los paquetes intercambiados hubiese un retardo relevante, con alta probabilidad, tendríamos un problema relacionado con la apertura de sesiones.

En esta situación, la solución pasa por ver que elementos de nuestra infraestructura subyacente está fallando. Más adelante comentaré algunas opciones para resolver esta cuestión, pero ahora voy a comentar un workarround rápido para el problema. Es evidente que una táctica que podemos usar, es evitar que las sesiones de MSMQ caduquen. Así solo pagaremos el peaje del retardo en una única ocasión. Para controlar el tiempo que tardan en caducar las sesiones de MSMQ hemos de modificar el valor CleanupInterval en la clave HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSMQParameters que controla el tiempo de caducidad de las sesiones de MSMQ. Hay que resaltar, ya que la documentación no lo dice que debemos establecer este valor tanto en el cliente como en el servidor pues prima el menor de ambos (anda que no me dio quebraderos de cabeza este tema). El valor máximo es 0xffffffff milisegundos, unos cincuenta días.

MSMQ Session Cleanup Interval

Para monitorizar el comportamiento de las sesiones de MSMQ lo mejor es usar los contadores de rendimiento de MSMQ: 

MSMQ Sessions Performance Counter

Evidentemente este ‘workarround’ tiene efectos laterales:

1) Cada sesión abierta consume una CAL de servidor. Si agotamos esas CAL, sucesivos clientes no se podrán conectar. Además hay que recordar que en un sistema operativo que no sea de servidor como máximo podremos tener diez sesiones abiertas simultáneamente.
2) Mantener sesiones, consume recursos y puede afectar a la escalabilidad.

Evidentemente lo aquí comentado solo minimiza el problema pero no los resuelve. Algunas recomendaciones para diagnosticar este tipo de problemas son:

– Usar la IP del servidor a establecer la dirección de la cola remota. Nos ahorraremos la resolución de nombres y podemos diagnosticar si el retardo de establecimiento de sesione tiene que ver con esto.
– Usar colas privadas, sin autenticación y sin transaccionacionalidad. Nos ahorraremos consultas al AD para localizar las colas, para autenticar usuarios y nos ahorraremos mensajes de ACK de MSMQ para mantener la transaccionacionalidad.

¡Espero que os resulte interesante!

He leído: Simple architectures for complex enterprises de Roger Sessions

Cómpralo en Amazon Todos los que estamos de una manera u otra vinculados con el desarrollo de software sabemos que hay un enemigo a combatir: la complejidad. El libro que hoy comento es una oda a la simplicidad. Que entendamos las fuentes de la complejidad, sus manifestaciones y las tácticas con las que contamos a la hora de combatirla es la clara motivación que llevo a Roger Sessions.

El libro tiene, a mi modo de ver partes bien diferenciadas, que no necesariamente se corresponder con capítulos determinados.

Hay partes del libro que tratan las matemáticas subyacentes en la complejidad y que ‘prueban’ matemáticamente como las diferentes tácticas que propone para acotar esa complejidad son efectivas. Es la parte más árida del libro, para muchos lectores será prescindible, aunque yo he disfrutado con enormemente con ella. Que nadie piense en formulas matemáticas si no en un tono de divulgación matemática bastante logrado.

Otra parte del libro, lleva al mundo real, mediante fabulas, ejemplos e historias reales la teoría expuesta de manera matemática. La fabulas son en general divertidas y algunas de ellas han inspirado post en este blog: Velocidad de iteración vs Calidad de iteración y Ya, ya… Keep It Simple, Stupid… ¿pero cómo?. De especial interés me ha resultado la explicación que da el autor del enorme fallo de proyecto que se produjo con el sistema informático de la seguridad social del Reino Unido y como lo liga con la complejidad del sistema… aunque mi conclusión tras leer el tema fue que la complejidad estaba en la maraña de subcontrataciones que se transluce… además de en la propia arquitectura.

Otra parte del libro, la dedica el autor a describir de manera formal una metodología, SIP, basada en el concepto de partición (el autor a estas alturas ya ha demostrado que particionar los problemas arquitectónicos es la manera más eficaz de evitar la complejidad) y los principios descritos por las cinco leyes de las particiones:

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.

Nada nuevo bajo el sol, si cambiamos particiones por subsistemas, y elementos por clases, algo que todo desarrollador con experiencia conoce. De hecho, en la última parte del libro, que quizás sea la más importante desde un punto de vista de pura arquitectura del software, el autor desarrolla un método de análisis, sustentado en las leyes anteriores que permite idéntica los elementos y las particiones en una arquitectura de software. Podéis introduciros en las ideas explicadas en el libro leyendo este artículo del autor: A Better Path to Enterprise Architectures.

El merito del autor, es crear una metodología formal para atajar la complejidad en las arquitecturas empresariales. Esto es algo que ningún otro framework arquitectónico anterior, como TOGAF, FEA o Zachman ha logrado. Estos framework no han ido más allá de construir taxonomías para catalogar nuestros artefactos arquitectónicos, pero sin dotarnos de ningún proceso. En el libro también encontraremos una descripción de los frameworks arquitectónicos más comunes. Podéis leer una comparción entre estos frameworks realizada por el autor en A Comparison of the Top Four Enterprise-Architecture Methodologies.

En definitiva, el libro es interesante, pero sin duda no es una obra imprescindible aunque si es interesante y novedosa. Lo que sí es cierto que la aproximación que el autor hace a la arquitectura empresarial es muy original y totalmente agnóstica de la tecnología empleada. Sea el que sea el tipo de arquitectura empresarial que quieras establecer (una intranet corporativa, un sistema de correo, un ERP…) lo expuesto en el libro es de interés. En cualquier caso, si estás interesado en la arquitectura de más alto nivel, en la arquitectura a nivel empresarial, este es un libro que sin duda debes comprar.

¡Feliz lectura!

Microsoft SDL Process Template: La seguridad, una cuestión de proceso

Todo comenzó con un mail de Bill Gates. La seguridad era la gran prioridad y Michael Howard ha sido el encargado de materializar, desde un punto de vista técnico, esta nueva visión. Howard enseguida se dio cuenta de que la seguridad era cuestión de dos pilares: la formación de los desarrolladores (Writing Secure Code fué el gran paso en este aspecto) y, sobre todo, una cuestión de proceso. Solo un proceso de desarrollo seguro, daría los resultado necesarios. Así surgió SDL (Security Development Lifecycle). Este proceso, sobre el que podéis saber más gracias al libro The Security Development Lifecycle, es el responsable de la mejora espectacular en seguridad que los productos de Microsoft han logrado en los últimos años. No hay más que ver por ejemplo IIS7 comparado con Apache 2.2.x, como podéis ver en estos gráficos de Secunia:

IIS7 vulnerabilities Apache vulnerabilities

 

 

IIS7 patchesApache patches 

Los frutos del mail de Bill Gates, han sido muchos: mejoras en las librerías de C/C++, mejoras en el API de Windows, una guía clara a la hora de abordar la seguridad cuando desarrollamos para Windows, el excelente libro: Writing Secure Code, y así un largo etc…

Si hablamos de un proceso de desarrollo de Microsoft, parece evidente que el mejor lugar para que este proceso viva, a parte de los excelentes libros y artículos ya citado,s es en un plantilla metodológica de Team System. Pues bien, el equipo de SDL ha liberado una plantilla que facilita enormemente la implementación de SDL como complemento a nuestro proceso de desarrollo. La calidad de la plantilla es espectacular. No se trata de una de tantas plantillas ‘cutres’ que hay por ahí dando vueltas… Podéis descargarla y echarla un vistazo, de verdad merece la pena, aunque solo sea como ejemplo de lo que se puede hacer desde le punto de vista de incorporar procesos de desarrollo a TFS con facilidad.

Microsoft Secure Development Lifecycle

Evidentemente, SDL no es un proceso que toda empresa se deba plantear implementar. Para muchos desarrollos casi con usar FxCop y la seguir las buenas prácticas de seguridad recomendadas por Microsoft es suficiente o al menos todo lo que nuestro clientes van a pagar. Pero hay muchos proyectos en los que implementar SDL nos puede proporcionar un retorno de la inversión claro: banca, administración pública, sitios que manejan datos sensibles o privados en internet, etc… En estos casos SDL y Team System son un excelente camino hacia una implementación sencilla de un proceso de desarrollo seguro, no en vano, el ‘tagline’ de esta plantilla es ‘Making secure code easier.

Siempre se dice, que en seguridad es vital no inventar, ¿qué mejor que usar un proceso de desarrollo que ha dado grandes resultados y que se apoya en nuestra herramienta favorita de gestión de proyectos?

Si este post ha despertado vuestra curiosidad tenéis más información sobre la plantilla en el blog de Brian Harry y en el blog del equipo de SDL.

¡Un saludo!

Modelos de salud: ¿Cúanto tarda una operación determinada de mi aplicación?

Poder reponder esta simple pregunta cuando nuestra aplicación está en producción nos puede dar un motón de información sobre la salud de la misma. Todo modelo de salud de una aplicación debería darnos la respuesta a esta simple pregunta para las operaciones más significativas que realiza la aplicación.

Evidentemente, en situaciones donde hay problemas de rendimiento, siempre podríamos responder esta cuestión utilizando un ‘profiler’. Pero esto es reactivo, ya hay problemas de rendimiento, y entonces actuamos. Sin duda no es lo más eficiente, lo más eficiente es actuar de manera proactiva, ser capaz de detectar que nuestra aplicación se está comportando de manera anómala en lo relativo a rendimiento y poder tener una pista clara de que partes de la misma están fallando. Con un modelo de salud, parte esencial de toda arquitectura de aplicaciones moderna, podemos detectar estas situaciones.

Una manera, a menudo muy adecuada, de plantear un modelo de salud, es seleccionar una serie de operaciones clave que nuestra aplicación realiza y publicar contadores de rendimiento que nos permitan monitorizar cuanto tiempo están tardando en llevarse a cabo esas operaciones y sobre todo detectar desviaciones de los parámetros normales de funcionamiento.

Supongamos, por ejemplo, que en una aplicación de banca pudiesemos monitorizar el tiempo que tardan en realizarse las operaciones sobre cuentas. Tras poner la aplicación en producción y hacer los ajustes necesarios, sabemos que la aplicación esta funcionando correctamente. Entonces establecemos una línea base para el modelo de salud de nuestra aplicación: las transferencias duran X, los cargos Y, los abonos Z, etc… A partir de este momento podemos detectar de manera temprana variaciones significativas en estos valores y por lo tanto detectar problemas de rendimiento en cuanto se producen, lo que nos da una oportunidad de actuar de manera temprana y que la calidad de servicio de nuestra aplicación no se vea resentida.

Si queréis saber más sobre modelos de salud, no os perdáis la charla que mis compañeros Iván González y Unai Zorrilla dieron en el lanzamiento de Visual Studio 2008 y que está publicada en Channel 9.

Para poder actuar como he descrito, tenemos que saber como publicar mediante contadores de rendimiento lo que dura una operación de nuestra aplicación. Para ello basta con utilizar el API de contadores de rendimento de .Net. En concreto el tipo de contador que utilizaremos en esta ocasión es PerformanceCounterType.AverageTimer32 que siempre debe apoyarse en otro contador de tipo PerformanceCounterType.AverageBase.

El procedimiento es simple. Creamos una categoría de contadores y añadimos a la misma los contadores en cuestión. Cuando termina la operación que queremos medir, llamamos al método Increment del contador de tipo PerformanceCounterType.AverageBase y, aquí es donde viene el truco del asunto, al método IncrementBy del contador de tipo AverageTimer32, pasándole el tiempo empleado por la operación en ‘ticks’. La manera más lógica de obtener este tiempo es utilizar un objeto Stopwatch en concreto la propiedad ElapsedTicks. Destacar que aunque el contador espera ‘ticks’ cuando lo recogarmos desde el monitor de rendimiento, nos informa del valor en milisegundos.

A continuación podéis ver un ejemplo:

using System;

using System.Diagnostics;

using System.Threading;

 

namespace OperationTimePerformanceCounterSample

{

    using System.Diagnostics;

 

    namespace OperationTimePerformanceCounterSample

    {

        class OperationTimePerformaceCounter

        {

            Stopwatch _sw = new Stopwatch();

            PerformanceCounter _pc;

            PerformanceCounter _pcBase;

 

            public OperationTimePerformaceCounter(string categoryName, string counterName, string counterBaseName)

            {

                _pc = new PerformanceCounter(categoryName, counterName, false);

                _pcBase = new PerformanceCounter(categoryName, counterBaseName, false);

            }

 

            public void Start()

            {

                _sw.Start();

            }

 

            public void Finish()

            {

                _sw.Stop();

                _pc.IncrementBy(_sw.ElapsedTicks);

                _pcBase.Increment();

            }

        }

    }

 

    class Program

    {

        //Constantes con los nombre de los contadores y categorias

        const string categoryName = «Operation Time Performace Counter Category»;

        const string categoryHelp = «Demonstrates usage of the AverageTimer32 performance counter type.»;

        const string counterTimerName = «Test Average Time Counter»;

        const string counterTimerHelp = «Test Average Time Counter»;

        const string counterBaseName = «Test Base Counter»;

        const string counterBaseHelp = «Test Base Counter»;

 

 

        static void Main(string[] args)

        {

            //Controlamos el Control + C para para la aplicación

            Console.WriteLine(«Pulse Control + C para terminar…»);

            Console.CancelKeyPress += new ConsoleCancelEventHandler(Console_CancelKeyPress);

 

            //Eliminamos la catergia de contadores si ya existe

            if (PerformanceCounterCategory.Exists(categoryName))

                PerformanceCounterCategory.Delete(categoryName);

 

            //Creamos los contadores necesarios

            //Necesitamos dos contadores, aunque solo se publican como uno solo

            //Uno actua de base y el otro recoge las medidas

            CounterCreationDataCollection counters = new CounterCreationDataCollection();

            CounterCreationData counterTimer = new CounterCreationData(counterTimerName, counterTimerHelp, PerformanceCounterType.AverageTimer32);

            counters.Add(counterTimer);

 

            CounterCreationData counterBase = new CounterCreationData(counterBaseName, counterBaseHelp, PerformanceCounterType.AverageBase);

            counters.Add(counterBase);

 

            //Creamos la categoria y añadimos los contadores

            PerformanceCounterCategory.Create(

                categoryName,

                categoryHelp,

                PerformanceCounterCategoryType.SingleInstance, counters);

 

            //Simulamos una operación

            while (true)

            {

                //La clase OperationTimePerformaceCounter encapsula la medición

                //de tiempo

                OperationTimePerformaceCounter pc = new OperationTimePerformaceCounter(categoryName, counterTimerName, counterBaseName);

                pc.Start();

                SimulateWork(); //Simulamos trabajo

                pc.Finish();

            }

 

        }

 

        static void Console_CancelKeyPress(object sender, ConsoleCancelEventArgs e)

        {

            if (PerformanceCounterCategory.Exists(categoryName))

                PerformanceCounterCategory.Delete(categoryName);

        }

 

        private static void SimulateWork()

        {

            Random rnd = new Random();

            Thread.Sleep(rnd.Next(0, 5000));

        }

    }

}

El código de la clase OperationTimePerformaceCounter que encapsula la medición del tiempo y la actualización de los contadores es el siguiente:

using System.Diagnostics;

 

namespace OperationTimePerformanceCounterSample

{

    class OperationTimePerformaceCounter

    {

        //Objeto Stopwatch para medir la duración de la aplicación

        Stopwatch _sw = new Stopwatch();

        //Contadores de rendimiento

        PerformanceCounter _pc;

        PerformanceCounter _pcBase;

 

        public OperationTimePerformaceCounter(string categoryName, string counterName, string counterBaseName)

        {

            //Abrimos los contadores

            _pc = new PerformanceCounter(categoryName, counterName, false);

            _pcBase = new PerformanceCounter(categoryName, counterBaseName, false);

        }

 

        /// <summary>

        /// Método que llamamos cuando comienza la operación

        /// </summary>

        public void Start()

        {

            _sw.Start(); //Inciamos el cronómetro

        }

 

        /// <summary>

        /// Método que llamamos cuando termina la operación

        /// </summary>

        public void Finish()

        {

            _sw.Stop(); //Paramos el cronómetro

            //Actualizamos los contadores

            _pc.IncrementBy(_sw.ElapsedTicks);

            _pcBase.Increment();

        }

    }

}

Si ejecutamos el código (que puedes encontrar como adjunto a esto post) el resultado será el siguiente, visto con el monitor de rendimiento de Windows:

Tiempo de operación en el monitor de rendimiento

Espero que os sea útil e incorporéis este tipo de contadores a los modelos de salud de vuestras arquitecturas.

Evento: XXIII Foro de Arquitectos – Novedades en la gestión de proyectos en Team System 2010

El pasado jueves estuve en el XXIII Foro de Arquitectos de Microsoft, hablando sobre las novedades en la gestión de proyectos en Team System 2010, estas novedades se pueden resumir en que todo lo relacionado con la gestión de proyectos pasa a ser mucho más ágil, tanto la propía metodología MSF, que se parece mucho a Scrum sin peder sus señas de identidad tradicionales (fuerte énfasis en la calidad y gestión explicita del riesgo), como el propio entorno, que es mucho más usable y amigable en lo relativo al trabajo con ‘work item’, informes, etc… Además se han añadido nuevas herramientas, apoyas en Excel, que facilitan muchísimo la planificiación de las iteraciones.

Los que viváis en Barcelona o alrededores, y seáis arquitectos, el próximo 16 de Junio podréis ver esta presatación en directo, junto otro puñado de presentaciones sumamente interesantes en el Foro de Arquitectos que Microsoft llevará a cabo en esta ciudad. ¡No os lo perdáis!.

Os dejo la presentación que hice donde podéis ver pantallazos de todos estos temas. Podéis descargarla desde el menú.

¿Qué os parecen estas novedades?