Participaré en: Evento sobre Team System :: Gestión de proyectos y metodologías con Visual Studio Team System en Madrid

Este jueves tendré el placer de participar como ponente en un evento sobre gestión de proyectos y metodologías con Team System, en las oficinas de Microsoft en Madrid. También participará en el evento Luis Fraile, MVP de Team System como yo y Aurelio Porras, de Microsoft.

La agenda del evento es:

10:00 – 10:20 Gestión de proyectos como clave del éxito.
10:20 –  11:30 Gestión Integral de Proyectos con Team System.
11:30 –  12:00 Café
12:00 – 13:00 Metodologías y Procesos de Construcción de Software
13:00 – 13:30  Conclusiones y puesta en común.

Un breve resumen sobre los temas que trataremos:

Todo proceso de desarrollo de software debe combinar la optimización de personas, herramientas y procesos para obtener como resultado un software de calidad, en tiempo, presupuesto y funcionalidad definida.

La Gestión de Proyectos  es clave a la hora de identificar las variaciones que puedan hacer fracasar un desarrollo, donde la colaboración entre los distintos roles del ciclo de vida de desarrollo y el uso de las distintas metodologías: ágiles, scrum, CMMI,etc…son claves para el éxito de cada proyecto.

Durante el seminario trataremos de forma práctica todos estos aspectos.

Podéis inscribiros aquí.

Rompe tus cadenas…

Ya lo decía Reincidentes en su mítica canción Carmén:


Y esto no (qué estás esperando)
cambiará (qué estás esperando)
sin luchar (rompe tus cadenas)
pa salir.


Y es que parece mentira como las cadenas y su manipulación vienen siendo un problema desde los tiempos de C. Digo esto por que últimamente me he encontrado con dos usos anómalos de cadenas en código que he visto:

El primer uso anómalo consiste en usar el + y el n o el espacio para escribir cadenas. Solo afecta a la legibilidad y mantenibilidad del código, que no es poco, pero no al rendimiento, ya que la concatenación de cadenas se hará en tiempo de compilación. El código anómalo tendrá un aspecto similar a este:


  const string sql =


        “SELECTn” +


          “DepartmentID,n” +


          “Name,n” +


          “GroupName,n” +


          “ModifiedDaten” +


        “FROMn” +


          “HumanResources.Departmentn” +


        “WHEREn” +


          “ModifiedDate BETWEEN @startDate AND GetDate()n”


El principal problema es que los n o espacios, los + y la gran cantidad de comillas afectan negativamente a la legibilidad de nuestro código. Además la mantenibilidad se ve complicada por el hecho de que si olvidamos uno de los n o espacios finales, en según que puntos, nuestra cadena puede dejar de ser valida. Por ejemplo, si olvidamos el n después del FROM la sentencia SQL no será valida.

Otra variante de este uso anómalo es el uso inadecuado de StringBuilder y AppendLine. Si bien en este caso, los problemas de mantenibilidad son menos, pues no se corre el riesgo de olvidar uno de los espacios finales o de los n, seguimos teniendo problemas de legibilidad y además introducimos problemas de rendimiento, pues la construcción de la cadena completa se hará en tiempo de ejecución y no en tiempo de compilación. En este caso el código anómalo tendrá un aspecto similar a este:


      StringBuilder sql = new StringBuilder();


      sql.AppendLine(“SELECT”);


      sql.AppendLine(”  DepartmentID,”);


      sql.AppendLine(”  Name,”);


      sql.AppendLine(”  GroupName,”);


      sql.AppendLine(”  ModifiedDate”);


      sql.AppendLine(“FROM”);


      sql.AppendLine(”  HumanResources.Department”);


      sql.AppendLine(“WHERE”);


      sql.AppendLine(”  ModifiedDate BETWEEN @startDate AND GetDate()”);


      sql.ToString();


La solución a ambos problemas es la misma, utilizar cadenas verbatim. Utilizando esta característica podemos expresar la cadena de este modo:


      const string sql =


        @”SELECT


            DepartmentID,


            Name,


            GroupName,


            ModifiedDate


          FROM


            HumanResources.Department


          WHERE


            ModifiedDate BETWEEN @startDate AND GetDate()”;


Ahora la pregunta es ¿cúal será la diferencia de rendimiento entre la aproximación que usa el StringBuilder y la aproximación que usa cadenas verbatim?. Para resolver la duda he hecho un pequeño programita (que se encuentra como adjunto a este post), los resultados son clarificadores, en diez millones de iteraciones, la diferencia de tiempos, medida usando System.Diagnostics.StopWatch, es notable: 28 segundos, frente a 12 milisegundos. Podríamos decir que usar cadenas verbatim es unas 2300 veces más eficiente, esto desde luego puede marcar una diferencia notable en algunos excenarios.


La moraleja de la historia es siempre que se usen cadenas estáticas permitir que sea el compilador quien las resuelva, en lugar de usar StringBuilder para componerlas y además usar las cadenas verbatim para mejorar la legibilidad del código.


Recomiendo que le deís un vistazo también a un artículo de mi compañero Jorge Serrano .NET — Rendimiento iterando cadenas.

Muerte por Power Point

Al cabo del año doy un buen puñado de prensentaciones, charlas, cursos y demás… Power Point es una herramienta útil, pero quiza no la esté usando todo lo bien que debiera. Supongo que no seré el único. Mi compañero Cristian me ha mandado esta interesante presentación sobre como evitar la ‘muerte por Power Point’ espero que os resulte interesante.





 

¿De verdad no tiene esto el Framework?…

Escribo este post por dos motivos: uno que quiza a alguien le sirva esta funcioncita y dos, que quizás alguien me ayude con mi dilema. Ya se que esto es mucho más mundano que los retos de Programacia101… pero bueno.

Necesito calcular las horas transcuridas en el año para un fecha y hora dadas. La única manera de solucionar el problema que he encontrado es con la función que muestro abajo, pero no puedo creer que no haya una manera más elegante de solucionar este problema. Incluso sospecho que debe de haber algún método del Framework que haga esto directamente pero no doy con él.

    /// <summary>

    /// Dada una fecha, nos devuelve el número de horas que han trascurrido

    /// desde comienzo de año

    /// </summary>

    /// <param name=”date”>

    /// Fecha para la que queremos las horas desde el inicio de año

    /// </param>

    private static short GetHoursOnYear(DateTime date)

    {

      DateTime beginOfYear = new DateTime(date.Year, 1, 1, 0, 0, 0);

      TimeSpan diff = date – beginOfYear;

      double diffHours = diff.TotalHours;

      Debug.Assert(diffHours <= 24 * 365);

      return (short)diffHours;

    }

NOTA: Después de darle algunas vueltas entre todos (ver los comentarios), la función, definitivamente a quedad así:

    private static short GetHoursOnYear(DateTime dateTime)

    {

      return (short)((dateTime.DayOfYear – 1) * 24 + dateTime.Hour);

    }

Habilitar la compresión HTTP en IIS y ASP.Net

Ahora que hemos migrado Geeks.ms a un nuevo servidor, que anda un poco más sobradito de CPU, y puesto que lo que generalmente se paga en un hosting dedicado, además del hardware es el ancho de banda, decidí comprimir el tráfico HTTP. Además la velocidad percibida por el usuario suele mejorar al habilitar la compresión. Eso si, nada es gratis en esta vida, a cambio tendrémos un mayor consumo de procesador (en el caso de Geeks.ms debo decir que inapreciable), sobre todo en el lado de servidor. Este mayor consumo se deberá al proceso de compresión y a la incompatibilidad entre la compresión HTTP y el Kernel Caching de IIS. En consecuencia debemos tener estos factores en cuenta antes de habilitar la compresión.


En principio una operación sencilla, que no debería plantear muchos problemas, pero que me costo toda una tarde hacer funcionar.


El problema es que aunque la información existe está muy fragmentada. Además toda esta información está en inglés. Así que aqui va este post para tratar de facilitar la vida a todos los que os enfrenteís a esta cuestión.


1) Activar la compresión Http en IIS: Para ello desde el administrador de IIS, usando el menu contextual Propiedades de la rama Sitios Web (Web Sites, en inglés) accedemos a la pantalla de propiedades del los sitios y vamos a la pestaña Servicio (Service en inglés). Activamos allí la compresión de contenido estático y dinámico. Podemos configurar el directorio en el que se guardará el contenido estático comprimido y el tamaño máximo que tendrá dicho contenido.


Activar Http Compression


2) Añadir la extensión de servicio de compresión: El siguiente paso que hay que dar es posiblemente el menos documentado. Hemos de añadir una nueva Extensión de Servicio Web a nuestro IIS. Esto nada tiene que ver con servicios web. Simplemente se trata de decirle al IIS que queremos usar los servicios de compresión que proporciona la librería gzip.dll. Para ello, desde la rama Extensiones de Servicios Web (Web Service Extensions en inglés) del Administrador de IIs, usaremos el menu contextual Añadir nueva extensión de servicio… (Add new service extension… en inglés) para añadir el nuevo servicio. Basta elegir un nombre (HTTP Compression en la imagen adjunta), introducir la ubicación de la librería gzip.dll y luego marcar el check para que se active la extensión. A pesar de su nombre la librería gzip.dll gestiona la compresión HTTP tanto con GZIP como con DEFLATE.


Configurar Extension Web


3) Configurar la metabase para activar la compresión, decir que tipos de páginas queremos comprimir y establecer el nivel de compresión: Parece que el consenso general es que un nivel de compresión 9 es que mejor balance da entre ahorro de tráfico conseguido y consumo de recursos en el servidor. Estas actividades se puede hacer mediante scripting o tocando directamente la metabase de IIS. Puesto que la metabase de IIS es una pieza delicada y que haciendo alguna picia podemos dejar nuestro IIS para el arrastre, yo prefiero la alternativa del scripting frente a la edición directa, además es lo que la documentación de Microsoft recomienda. Los comandos de scripting, que ejecutaremos desde una ventana de comandos donde se encuentre adsutils.vbs, típicamente c:inetpubadminscripts, son los siguientes:



Activar la compresión de contenido dinámico:
cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoDynamicCompression true



Activar la compresión de contenido estático:
cscript adsutil.vbs set w3svc/filters/compression/parameters/HcDoStaticCompression true



Establecer el nivel de compresión:
cscript adsutil.vbs SET W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel “9”
cscript adsutil.vbs SET W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel “9”



Configurar las extensiones de contenido estático a comprimir tanto para GZIP como para DEFLATE:
cscript adsutil.vbs SET W3SVC/Filters/Compression/Deflate/HcFileExtensions “htm html css txt js”
cscript adsutil.vbs SET W3SVC/Filters/Compression/gzip/HcFileExtensions “htm html css txt js”



Configurar las extensiones de contenido dinámico a comprimir tanto para GZIP como para DEFLATE:
cscript adsutil.vbs SET W3SVC/Filters/Compression/Deflate/HcScriptFileExtensions “asp dll aspx ashx”
cscript adsutil.vbs SET W3SVC/Filters/Compression/gzip/HcScriptFileExtensions “asp dll aspx ashx”


4) Comprobar que la compressión HTTP está funcionado: para ello podeís usar la página www.pipeboost.com (podéis ver el ejemplo de Geeks.ms) que tiene un comprobador online o Fiddler, que nos permite ver si estamos recibiendo el contenido comprimido, observando las cabeceras. Podeís ver una imagen de Fiddler abajo.


HTTP Compression Header


Decir que la portada de Geeks.ms pasa de 113226 bytes 14830 bytes, un 13% del tamaño sin comprimir.


El archivo adjunto a este artículo contiene un .bat con los comandos necesarios para habilitar la compresión.


Más información en inglés:


IIS Compression in IIS6.0 – Scott Forsyth’s WebLog
Using HTTP Compression (IIS 6.0)

Mis respuestas sobre Scrum (II)

Me comenta un ex-alumno de uno de mis cursos de Scrum que está involucrado en un proyecto en el que el cliente a pedido que se utilice Scrum como metodología de desarrollo. Sin duda que el cliente exija una metodología determinada es una manera excelente de contar con un sponsor. Sin duda factor clave para hacer más facil la adopción de Scrum o cualquier otra metodología.

A parte de esto, me plantea una serie de dudas que contesto aquí pues creo que son muy interesantes. Esto solo son mis respuestas, no verdades absolutas, que no las hay. No es la primera vez que doy respuestas sobre Scrum y seguro que no será la última. Seguro que los comentarios que aquí hagáis serán de utilidad y de interés para mucha gente.

1) ¿Cuándo establecer la fecha del Sprint Planning Meeting? (o generalizando de otras liturgias…)

No hay reglas claras en Scrum sobre este aspecto. Pero lo que marca todas las fechas es la duración del sprint. El primer Sprint Planning Meeting se lanza generalmente cuando se tiene la primera versión del product backlog construida. Una vez tenemos la duración del sprint determinada (20 días hábiles funciona bien para la mayoría de proyectos), los siguientes hitos importantes, Sprint Restropective y Sprint Planning Meeting, ocurrirán transcurrido ese lapso concreto de tiempo.

Generalmente el Sprint Planning Meeting se realiza justo el día siguiente al Sprint Review y Sprint Restrospective. La mayoría de los equipos Scrum que conozco lo que hacen es realizar el mismo día la revisión del sprint (Sprint Review) y la retrospectiva del sprint (Sprint Retrospective). La recomendación aquí es clara, la retrospectiva siempre se debe hacer con el sprint fresco en la memoria, por lo tanto el mejor momento para realizarla es sin duda justo después del Sprint Review.

Los sprines son periodos muy intensos de trabajo y una práctica que cada vez más a menudo usan los equipos es dejar entre 1 a 3 días entre el final de un sprint (los sprines terminan con la restropectiva) y el siguiente Sprint Planning Meeting que dará comienzo al siguiente sprint.

No hay por tanto muchas variables a determinar, una vez determinada la duración del sprint y el periodo de margen entre sprines las fechas vienen dadas. Esta variables generalmente se determinan por consenso entre todos los implicados pero es el Scrum Master quien tiene en sus manos, como gestor del proceso de desarrollo, la última palabra.

Otro tema es cuando se comunicas las fechas. Una de las salidas que se optienen del Sprint Planning Meeting es el lugar y la fecha del Sprint Review de ese sprint que debe ser comunicado a todos los implicados, esto es algo que si viene establecido por las reglas de Scrum.

2) ¿Cómo cobrar el proyecto? ¿Todavía no tenemos el Product Backlog y por lo tanto no tenemos especificaciones claras, como le podemos hacer una oferta sobre algo que no controlamos?

Nunca vas a tener las especificaciones claras, no te engañes, asúmelo, por eso nacieron las metodologías ágiles. Aunque lograses tenerlas claras, estas pueden cambiar a lo largo del proyecto. Hace poco escribía sobre la gestión de requisitos en Scrum, sería bueno que reviséis ese post.

Esto son realidades por tanto a la hora de hacer la oferta la técnica a utilizar debe ser la misma que se utiliza con cualquier otra metodología: la estimación. Presupuestar la oferta de un proyecto es únicamente un problema de estimación, no de gestión o de ciclo de vida. En Scrum una técnica habitual es construir una primera versión preliminar del Product Backlog, espresado como un conjunto de historias de usuario, con toda la información que el cliente nos pueda facilitar en la fase de oferta, que no siempre es completa. Luego este Product Backlog se estima, generalmente usando puntos de historia, un luego se establece un valor monetario para cada punto de historia. Para establecer ese valor monetario para el punto de historia, se seleccionan algunas historias representativas ya estimadas y se estiman en unidades monetarias. El cociente entre la estimación en puntos de historia y en unidades monetarias de las historias estimadas en ambos nos permite obtener un coeficiente que podremos aplicar para convertir nuestro punto de historia totales a unidades monetarias, de esta manera podremos conocer una estimación en unidades monetarias del coste de desarrollo de nuestro proyecto. Lógicamente, deberemos considerar también los costes de hardware, formación, consultoría. Existen otros muchos enfoques, pero este me gusta particularmente pues además de servir para estimar el coste del proyecto, proporciona avance en la construcción del product backlog. Decir que no es necesario para estimar el coste del proyecto construir un product backlog muy detallado.

Sobre como cobrar, en Scrum un enfoque que surge del sentido común es recibir pagos del cliente después de cada sprint. Puesto que tras cada sprint el cliente recibe un incremento potencialmente entregable de funcionalidad y por tanto un retorno de la inversión asociado es lógico que pague por el ¿no?. El cuánto ya es otro cantar. Aquí hay mucho enfoques, el ideal es cobrar por certificación, tanto me ha costado el desarrollo tanto te cobro, pero esto no siempre es posible, sobre todo con precio cerrado. Cuando vas a precio cerrado lo que se suele hacer es determinar a priori un número determinado de sprints y establecer una cantidad fija por sprint, que resulta de dividir la cantidad presupuestada entre los sprints previstos. Lógicamente todas la cantidades a menudo se ajustan según la velocidad del equipo, por lo tanto volvemos a los de antes todo se trata de un problema de estimación, como en cualquier otra metodología.

3) ¿Cuándo fijar la fecha para generar el product backlog y quien lo debe fijar? Entiendo que serán varios días entre el Product Owner, el Scrum Master y todo el equipo.

Recordar antes de nada que el Product Backlog es algo vivo que se debe mantener y evolucionar a lo largo de todo el proyecto. Efectivamente el Product Backlog se suele construir, idealmente, entre el Product Owner, el Scrum Master y todo el equipo. Pero esto no siempre es así, especialmente en desarrollos de proyecto, no de producto. A menudo cuando se comienza la construcción del Product Backlog, no contamos con el equipo. Especialmente cuando estamos en fase de oferta. Por lo tanto, quien generalmente construye el Product Backlog es el Product Owner, que es el responsable último. Como a menudo durante la fase de oferta tampoco se conoce quien será en última instancia el Producto Owner, e incluso puede que finalmente se trate de alguien del cliente, alguien de la empresa que realiza la oferta actúa como tal, quizás de manera provisional, durante la fase de oferta para construir una primera versión del Product Backlog que luego debe ser refinado.

4) ¿Propongo un Product Owner de parte del cliente, es lo correcto?

Suele ser lo correcto, pero a veces no lo es o no es posible que sea así, aun siendo lo correcto. A menudo es la mejor opción. El Product Owner construye y prioriza el Product Backlog considerando el valor obtenido por el cliente y la estimación de cada elemento del Product Backlog. ¿Quién mejor que alguien del cliente para saber esto?. La única pega es que a veces el cliente no cuenta con alguien capaz de recabar los requisitos y construir el Product Backlog o simplemente no quiere dedicar personal a este cometido. En este caso, no quedará más remedio que poner a un Producto Owner desde la empresa de desarrollo.

Todas las cuestiones aquí planteadas darían para escribir un libro, hay muchísimos aspectos a considerar en cada proyecto que pueden hacer que las respuestas aquí dadas sean más o menos aceptadas, solo he tratado de dar aquí la respuesta que intuyo funciona en el más amplio rango de casuísticas.

Exprimiendo Scrum: Scrum y la gestión de requisitos

productbacklog Tradicionalmente se ha tendido a tratar la captura y la gestión de requisitos de una manera que, cada vez más, se demuestra errónea. Se ha entendido la captura de los requisitos del proyecto como una fase temprana del mismo que una vez se completaba nos daba la fotografía exacta de que necesitaba nuestro cliente. Luego la única labor del gestor del proyecto era tratar de evitar que se produjesen cambios en el conjunto de requisitos y tratar que, cuando estos se producían el cliente asumiese el coste económico de los mismos. Supongo que a todos os suena este planteamiento.

El problema que todos hemos vivido es que el esfuerzo que supone hacer una captura detallada de todos los requisitos de un proyecto es enorme. Tan enorme que rara vez justifica el resultado. Además otra realidad que hemos descubierto es que casi nunca nuestro cliente conoce sus propias necesidades con la profundidad suficiente como para definirlas a priori y a esto se une que, a menudo, durante la vida del proyecto, las necesidades y prioridades de nuestros clientes cambian. Además nuestros clientes a menudo necesitan ver lo que somos capaces de hacer y como resolvemos sus necesidades a nivel técnico para poder descubrir nuevas necesidades u oportunidades que desconocían que éramos capaces de implementar. Podemos tratar de protegernos de estos cambios estableciendo mecanismos de control, pero este enfoque a menudo nos lleva a clientes poco satisfechos, que verán el desarrollo del proyecto como algo rígido que no se adapta a sus necesidades y que si lo hace es repercutiendo costes añadidos al presupuesto del proyecto.

Vistos estos problemas, ¿qué aproximación propone Scrum?.

En Scrum los requisitos se expresan como elementos del Product Backlog. El Product Backlog es una lista viva de requisitos funcionales y no funcionales priorizados por su valor para el cliente. Al decir que se trata de una lista viva, dejamos claro que los requisitos que en ella aparecen y el orden de los mismos es cambiante a lo largo de la vida del proyecto. En Scrum, los requisitos se van abordando en Sprints en el orden en que aparecen en el Product Backlog.

Utilizar el Product Backlog como principal artefacto para la gestión de requisitos nos permite atajar los problemas relacionados con la gestión de requisitos que antes hemos descrito.

Aunque construir y mantener el Product Backlog es una tarea ardua, es mucho más simple que hacer una captura de requisitos tradicional. El motivo es simple, solo hay que expresar a grandes rasgos en que consiste el requisito, no es necesario un nivel de detalle muy elevado. Solo es necesario el nivel de detalle suficiente que nos permita estimar los requisitos y priorizarlos. A menudo se utilizan historias de usuario para expresar estos requisitos. Los requisitos que aparecen el en Product Backlog deben ser independientes, negociables, evaluables, estimables y no demasiado grandes. Deben ser independientes pues el orden en el que serán implementados puede cambiar. Deben ser negociables en el sentido de que son un punto de partida para comenzar en desarrollo no un contrato cerrado. Deben ser evaluables desde el punto de vista del retorno de la inversión que proporcionan a nuestros clientes. Deben ser estimables pues es imposible priorizar algo de lo que se desconoce la magnitud.Y, por último, deben ser de un tamaño que permita estimarlos sin tener demasiadas incertidumbres sobre cuál es el alcance concreto del requisito, aunque cierto nivel de incertidumbre siempre va a existir.

Evidentemente antes de su implementación será necesario refinar en mayor detalle los requisitos. En Scrum esto es algo que posponemos hasta que planeamos el Sprint en el que vamos a abordar esos requisitos en concreto. Posponer el refinado detallado de los requisitos hasta un momento cercana a su implementación nos permite que cuando realizamos esta actividad tengamos en cuenta de nuevo las necesidades del cliente que pueden haber cambiado y contar con la información que hemos ganado durante la implementación de otros requisitos, de esta manera, al contar con más información tendremos muchas más posibilidades de actuar correctamente a la hora de describir y estimar en detalle los requisitos. El fundamento para lo anteriormente expuesto es claro, es posible definir y estimar las actividades de nuestro proyecto cercanas en el tiempo con un buen margen de confianza, pero es muy complejo hacerlo con actividades cuyo momento de comienzo se encuentra lejano en el tiempo. La actividades cercanas en el tiempo tienen una probabilidad mucho menor de sufrir cambios en su alcance que obliguen a cambiar su estimación y, en consecuencia, su planificación. No me extiendo más en esto pero si os invito a leer algunos de mis anteriores post sobre estimación: El difícil problema de la estimación, Estimación y planificación detallada, Recibiendo estimaciones y Estimando (no practicando la brujería).

Los cambios en los requisitos ocurren, por mucho que tratemos de combatirlos. En Scrum y en las metodologías ágiles en general, asumimos que estos cambios van a ocurrir y tratamos de gestionar estos cambios como oportunidades de que los clientes obtengan lo que necesitan. Evidentemente para que esto funcione la gestión del Product Backlog debe reaccionar de manera continua para reflejar las prioridades de nuestro cliente. El Product Owner (propietario del producto) es el encargado de gestionar el Product Backlog, introduciendo nuevas requisitos según se descubren y priorizándolos en función de las necesidades del cliente y el retorno de la inversión que el cliente recibirá de su implementación.

Utilizando el Product Backlog, cada vez que el cliente cambia sus prioridades o el alcance de un requisitos ve de manera explicita y visual (recordemos que se trata de una lista ordenada) que otros requisitos ven afectada su prioridad, de manera que serán implementados más tarde o incluso quedarán fuera del alcance del proyecto si este está establecido de antemano, como ocurrirá en los proyectos con precio o fecha cerrados. La clave está en que en cualquier caso, el cliente irá consiguiendo de manera paulatina que estén implementadas aquellas partes de proyecto que más valor le aportan y contará con la seguridad de que en el caso de que algo quede fuera del ámbito del proyecto serán aquellos requisitos que menor valor tienen para el.

Vemos como el Producto Backlog nos permite gestionar de manera ágil y sencilla los requisitos de nuestro proyecto, refinándolos cuando tenemos información suficiente, priorizándolos según el valor que aportan a nuestro cliente.

El TechEd 2007 ya es historia

Aunque prometí un relato pormenorizado del TechEd al estilo del que hice el año pasado, debido a lo intenso de evento, y a ciertos compromisos profesionales me ha sido imposible comentar lo que ha ido ocurriendo día a día. En cualquier caso, aquí va mi resumen de lo ocurrido en esta edición del TechEd.

En general, desde el punto de vista puramente técnico, las sesiones no han sido muy apasionantes. Se nota que aunque queda un poco para el lanzamiento del .Net 3.5 y VS2008 y que en ambos casos no hay novedades espectaculares sino más bien una mejora del Framework y el entorno del desarrollo. Si bien esta mejoras convierten tanto la plataforma como el entorno de desarrollo en aun mejores y atajan algunos de los problemas que los desarrolladores hemos sufrido no se prestan a sesiones espectaculares. Esta es un poco la tónica que ha marcado todo el TechEd. Visto este panorama desde un principio me he volcado más en las sesiones de arquitectura (todas ellas de un excelente nivel) que en las sesiones más puramente técnicas.

Otro aspecto del TechEd que nunca defrauda es el relativo a tener contacto con la comunidad. Gracias a las cenas organizadas por Microsoft, una para la comunidad española de asistentes al TechEd como otra en principio para MVP pero que acertadamente se abrió a un motón de gente más, y gracias también a los encuentros entre charlas y entorno al Ask The Experts he tenido un motón de ocasiones para charlar sobre tecnología con un motón de gente, no voy a citar a ninguno en particular pues seguro que me dejaría a gente. Sin duda estas charlas informales con gente de Plain, Microsoft, Solid, Ilitia, Ibermatica, Avanade, los centros de innovación, los grupos de usuarios, los clubs de las universidades, MVPs y demás ‘fauna’ tecnológica es lo que más aporta a la asistencia al TechEd. Sin duda en todas estas charletas ha habido dos grandes protagonistas (al menos cuando yo andaba por en medio) : Scrum y el Entity Framework.

Sobre las sesiones decir que como ya he comentado las que mas me han gustado con diferencia este año han sido las de arquitectura.

EDA Comenzado por una sesión sobre arquitecturas guiadas por eventos de Shy Cohen, Senior Program Manager de WCF, en la que daba un repaso excelente a las diferentes alternativas que tenemos a la hora de diseñar arquitecturas EDA: Pull vs. Push, diferentes patrones de brokers de eventos y sobre todo explicar las ventajas de cada modelo de difusión de eventos. Un repaso completo a las arquitecturas EDA y a los principales aspectos a nivel arquitectónico que debemos tener en cuenta cuando las modelamos. Me gusto especialmente las consideración que hizo sobre las capacidades de escalabilidad de cada uno de los modelos.

Otra sesión sobre arquitectura realmente interesante fue Life Beyond Distributed Transactions: An Apostate’s Opinion de Pat Helland, en la que básicamente lo que venia a exponer es que debemos abstraer nuestra lógica de negocio lo más posible de las transacciones y evitar en la mayor medida posible las transacciones distribuidas. Según Pat Helland la solución para lograr una escalabilidad infinita pasa por evitar las transacciones distribuidas (debemos buscar transacciones locales a la entidad) y por evitar en las capas de negocio de la aplicación asumir lo más mínimo sobre cual será el almacenamiento físico de los datos (solo deberiamos contar con que somos capaces de recuperar y modificar entidades en transacciones locales), unido a la utilización de mensajes idempotentes (no importa su orden de entrega y el número de veces que se entreguen) para comunicar las diferentes entidades de nuestro modelo de aplicación. Podéis obtener más información sobre esta novedosa manera de ver el tema leyendo este paper.

Otra interesante sesión no relacionada con arquitectura que he visto es What’s New in Microsoft Visual Studio 2008 Team Edition for Testers, and Best Practices for Testing AJAX, SharePoint, and Reporting Services, de Chris Patterson, Program Manager de Team System. Básicamente presento bastantes algunas novedades sobre lo relativo a testeo con Team System 2008, así como un puñado de buenas prácticas. Entre las novedades destacan: el soporte para Ajax (que ya he tenido ocasión de probar en un proyecto real y es excelente), algunas mejoras en la vinculación a datos para test guiados por datos y la posibilidad de compartir pasos entre varios web test (lo que nos permite por ejemplo reutilizar la entrada de usuario y password de un test a otro). También existen un motón de novedades relativas a testeo unitario como la posibilidad de generar test sin acceso al código fuente, mejoras para el testeo de genéricos y mayores facilidades para ejecutar los test desde el código (basta con poner el cursor sobre el código del test o clase de test que queremos ejecutar).

Ha habido alguna sesión más interesante de las que hablaré en próximos post.

Plain Concepts + Campus MVP = Curso de Scrum en Vigo

Curso presencial de SCRUMLos próximos días 27 y 28 de Noviembre hemos organizado en Vigo un curso estupendo sobre gestión de proyectos con SCRUM.

SCRUM es una metodología de trabajo especialmente indicada para entornos cambiantes y requisitos inestables, como los que se encuentran en la mayoría de los proyectos de desarrollo de software.

Lo hemos pensado tanto para directores de proyecto como para programadores integrados en equipos de trabajo, y de forma que los asistentes puedan sacarle partido desde el primer día.

Más información sobre el curso y el tutor

Lugar y fechas:

27 y 28 de Noviembre de 2007, de 09:00 a 14:00 y de 15:00 a 18:00 en las salas de la Zona Franca de Vigo.

Tenemos las plazas limitadas a 12 asistentes, así que hay que apurarse

Bueno, pues ya sabes… Si te queda más o menos cerca (estás en Galicia, Asturias o León, por ejemplo) no te lo puedes perder 🙂

Participaré en: Evento sobre Team System :: Gestión de proyectos y metodologías con Visual Studio Team System

El próximo 13 de Noviembre tendré el placer de participar como ponente en un evento sobre gestión de proyectos y metodologías con Team System. También participará en el evento Luis Fraile, MVP de Team System como yo y Aurelio Porras, de Microsoft.

La agenda del evento es:

10:00 – 10:20 Gestión de proyectos como clave del éxito.
10:20 –  11:30 Gestión Integral de Proyectos con Team System.
11:30 –  12:00 Café
12:00 – 13:00 Metodologías y Procesos de Construcción de Software
13:00 – 13:30  Conclusiones y puesta en común.

Un breve resumen sobre los temas que trataremos:

Todo proceso de desarrollo de software debe combinar la optimización de personas, herramientas y procesos para obtener como resultado un software de calidad, en tiempo, presupuesto y funcionalidad definida.

La Gestión de Proyectos  es clave a la hora de identificar las variaciones que puedan hacer fracasar un desarrollo, donde la colaboración entre los distintos roles del ciclo de vida de desarrollo y el uso de las distintas metodologías: ágiles, scrum, CMMI,etc…son claves para el éxito de cada proyecto.

Durante el seminario veremos de forma práctica todos estos aspectos, de mano de profesionales de contrastada experiencia.

Podéis inscribiros aquí.