MoMA: Mono Migration Analyzer

 Si estás pensando en migrar tu aplicación a Mono, MoMA (Mono Migration Analyzer) es una herramienta que te puede ayudar y mucho.MoMA

Como dice en el pantallazo que os dejo: MoMa es un herramienta que nos ayuda a identificar aquellos problemas que nos podemos encontrar cuando pensamos en correr nuestra aplicación en Mono, como por ejemplo llamadas nativas (usando P/Invoke) o el uso de partes del framework aún no implementadas en Mono.

Tras utilizar la herramienta en un proyecto mediano, he de decir que la suerte que nos desea el wizard nos va ha hacer falta, pues son bastantes los problemas que he encontrado, aunque he de decir que la herramienta cumplio con su cometido de manera más que correcta. Esta herramienta me parece una buena idea y muy util, más para la gente que este haciendo una aplicación diseñada para Mono y el Framework .Net, que para quien piense en migrar. Si no has diseñado para que tu aplicación funcione en Mono el trabajo que tienes por delante para que corra en esa plataforma será grande a tenor de lo que he visto con esta herramienta.

¡Un saludo!

Exprimiendo Scrum: Scrum y la gestión del riesgo

Un hombre en el vacio de Klein Este es el segundo de una serie de post, titulados Exprimiendo Scrum, dedicados a cómo esta metodología se acerca a ciertas cuestiones habituales en la gestión de proyectos. Anteriomente escribí sobre Scrum y la documentación y hoy le toca el turno a la gestión del riesgo en Scrum.

Uno de los aspectos de la gestión de proyectos que tradicionalmente las metodologías han tenido muy en cuenta es la gestión del riesgo. Por ejemplo, en MSF, la gestión del riesgo es uno de los pilares de la metodología. En CMMI la gestión de riesgos es un área de proceso con entidad propia y a la generalmente se presta mucha atención. En Scrum sin embargo la aproximación a la gestión de riesgo es menos explicita, pero esto no quiere decir que en Scrum no se preste atención a la gestión del riesgo, simplemente el enfoque es diferente. En Scrum la gestión del riesgo está implícita en la propia metodología no como una actividad paralela sino como una disciplina articulada de manera natural en todas las actividades que se llevan a cabo en el proyecto.

Gestionar el riesgo de los proyectos de manera explicita se ha demostrado una herramienta eficaz a la hora de atajar fallos de proyecto, es decir aquellas situaciones en las que un proyecto no cumple sus objetivos de manera clara. Pero también es cierto que este enfoque a la gestión del riesgo no funciona de manera tan eficiente a la hora de gestionar los problemas más pequeños a los que un proyecto se enfrenta día a día.

Tradicionalmente la lista de riesgos a sido el artefacto que los jefes de proyecto hemos utilizado para gestionar el riesgo. Básicamente consiste en una lista ordenada de riesgos según su impacto en el proyecto si llegasen a manifestarse y la probabilidad que estimamos de que realmente se lleguen a manifestar. Una vez hecha esta lista de riesgos, por una cuestión de economía de recursos, nos centramos en la parte de arriba de la lista de riesgos y hacemos una gestión activa de los N riesgos más considerables (donde N generalmente es igual a 10). Esta lista de riesgos se revisa de manera periódica, generalmente de manera semanal. Para estos riesgos más importantes se confecciona un plan de mitigación del riesgo, orientado a disminuir la probabilidad de que el riesgo se manifieste y un plan de contingencia, que define los pasos a dar para minimizar el impacto del riesgo si este se llega a manifestar. Este proceso aquí descrito es compartido con más o menos matices por todas las metodologías tradicionales. El problema de este enfoque es que no es ágil. Esta gestión del riesgo es pesada y burocrática y la experiencia me dice que rara vez se lleva con la disciplina necesaria y con la actualización adecuada para que sea efectiva. Además fruto de la pesadez de este enfoque de la gestión del riesgo ocurre que solo nos centramos en aquellos riesgos ‘gordos’ y evidentes, que son muy peligrosos si pero que son comunes a todo proyecto y que rara vez se manifiestan.

En Scrum la gestión del riesgo se aborda de manera diferente. Es un hecho sabido por todos los que hemos realizado un plan de gestión del riesgo y la gestión del riesgo en un proyecto que para la gran mayoría de los proyectos los riesgos que se detectan son los mismos y están relacionados con los mismas áreas del proyecto. En vista de esta situación en Scrum se sustituye la gestión del riesgo explicita por la gestión del riesgo continua. Una de las principales razones de ser del Daily Scrum, es la gestión del riesgo. Una de las preguntas que se responden en el Daily Scrum es: ¿Qué impedimentos has encontrado?. Responder esta pregunta día a día es sin duda una manera implícita de gestionar los riesgos del proyecto. Otro excelente momento para detectar riesgos es el Sprint Retrospective, que permite atajar todos los riesgos relacionados con la comunicación con el cliente y los requisitos. Para que esta manera de gestionar el riesgo sea efectiva el Scrum Master debe hacer hincapié en que no solo se hable de impedimentos actuales sino de también de aquellos impedimentos que se vislumbran en el futuro del proyecto. Esto cubre perfectamente la detección de riesgos, pero ¿que hacemos para mitigarlos?.

Una de las principales labores del Scrum Master sino la principal es actuar sobre los impedimentos y eliminarlos o mitigarlos en la mayor parte posible. Pero una cosa que debemos conocer es que a menudo hablar de un riesgo, detectarlo y tenerlo en cuenta es más que suficiente para mitigarlo. Scrum pone el peso en la comunicación continua de los problemas que acechan al proyecto como instrumento para atajar los riesgos del proyecto.

Para finalizar os dejo una lista de las 10 áreas de riesgos habituales en proyectos sacada de entre la que se propone en Rapid Application Development, biblia de la gestión clásica de proyectos escrita por Steve McConnell, y la manera en que, a mi modo de ver, Scrum trata de atajar ese riesgo en particular.




































Riesgo Cómo lo controla Scrum
Ampliación descontrolada de características En Scrum se parte de una lista ordenada por retorno de la inversión de las características del proyecto. Esta lista es gestionada por el Product Owner y puede ser establecida al pricipio del proyecto. Aunque siempre esta abierta a la inclusión de nuevas características, esto siempre implica, de manera explicita un aumento en el número de Sprint, en la magnitud del proyecto. Esto ataja los problemas habitualmente relacionados con la ampliación descontrolada de características, pues en Scrum nunca la ampliación de características es descontrolada sino el fruto de un proceso explicito de priorización y evaluación.
Captura de requisitos mal realizada Ninguna metodología protege de una captura de requisitos mal realizada. Pero una metología si puede proteger del losriesgos más habituales en lo relativo a la captura de requisitos: no realizarla en absoluto, realizarla de una mánera demasiado exhaustiva, no asumir que cambiaran y no detallarlos suficientemente antes de la implementación. En Scrum estos riegos se atajan respectivamente con la construcción del product backlog, evitando detallar los requisitos en una fase temprana de proyecto y detallandoles adecuamente, durante el Sprint Planning Meeting, cuando se va a realizar su implementación.
Calidad insuficiente La imposición que Scrum realiza de demostrar de la funcionalidad implementada durante el Sprint Review actua como fusible de seguridad ante la calidad insuficiente. Ningún equipo que desarrolle software de baja calidad podrá salir airoso de un Sprint Review.
Plazos optimistas impuestos En Scrum el equipo es el último responsable de aceptar los plazos y de comprometerse con la cantidad de características a implementar durante el Sprint. Nadie puede imponer plazos que no sean realistas pues el equipo tiene la postestad para no aceptarlos, con lo que los riesgos relacionados con la imposición de plazos optimistas no realistas se zanja de raiz.
Diseño inadecuado De nuevo el Sprint Review y la demostración que realizamos durante el mismo actua aquí como una valvula de escape que nos alerta rápidamente de las carencias en lo relativo al diseño inadecuado. Si el diseño de la aplicación no es adecuado, las carencias se harán patentes durante el Sprint Review. Durante la Sprint Retrospective también el equipo detecta a menudo partes del diseño de la aplicación que deben ser refactorizadas.
Síndrome de “la bala de plata” Scrum no acepta las balas de plata. Scrum incide en que el progreso del software desarrollado demostrado Sprint tras Sprint es lo único que asegura que el proyecto sigue un buen camino hacia el existo. De nada sirve confiar en balas de plata y no tener avance que demostrar en el Sprint Review.
Desarrollo orientado a la investigación El concepto de ‘Hecho’ es clave en Scrum. Solo se demuestran las características que estan completadas, por lo tanto si investigamos y no logramos resultados la situación se hace patente de manera clara y rápida al no verse avances en el Product Burndown Chart y durante los Sprint Review. Scrum tiene sitio para el desarrollo orientado a la investigación pero siempre deja patente si esta investigación optiene resultados o no.
Personal inadecuado Ninguna metodología actua de maner explicita en este aspecto. Scrum minimiza las posiblidades de que en el equipo haya personal inadecuado al incidir mucho en que los miembros del equipo sean multidisciplinares y que se produzca una continual comunicación y transmisión de conocimientos entre ellos mediante el Daily Scrum. De cualquier modo este es un problema más relacionado
Fallos de los proveedores Scrum no aborda este apecto de ninguna manera hasta donde yo se. La única metodología que lo hace de manera explicita es CMMI.
Fricción con los clientes Scrum como metodología ágil que es sigue el manifiesto ágil y por tanto el pricipio de poner ‘la colaboración con el cliente sobre la negociación de contratos’. Para ello Scrum pone en todo proyecto un representante de los intereses de cliente, el Product Owner y además permite y persigue la colaboración y la comunicación con todos los involucrados en el proyecto durante los Sprint Reviews.

Espero que ya nadie más me diga que Scrum no se preocupa de gestionar el riesgo de los proyectos 😉

Mi lenguaje es más mejor… no el mio… no el mio…!!!!

Jejeje… los programadores somos como niños. Todos creemos que programar en un lenguaje u otro nos hace de un casta especial, superior al resto. En mi opinión lo único que es relevante es cuántos conoces y cómo de bien los conoces. Pero no voy a negar que también en alguna ocasión he discutido sobre el tema…


De todos modos, com me dijo mi cuñado, que tiene una franquicia de tiendas de pesca y es un excelente pescador (según dicen porque yo de pesca no se nada). cuando le pregunto sobre la diferencia entre cañas: ‘caza el indio no la flecha’. Vamos que lo que importa es el programador más que el lenguaje… ¿alguien duda de que Unai escribiria buen código a la velocidad de la luz en Java como hace en C#?… Además estoy seguro de que pillaría incluso los mismos cabreos jejeejje…


Bueno, pues aquí os dejo una jerarquía que alguien a creado (no se la fuente original, he recibido la imagen por correo) en función de como se sienten los programadores respecto al resto según el lenguaje que usan. Aunque esto es humor, algo de verdad esconde esta jerarquía. ¿Creeís que es acertada?…programmer_hierarchy


Me gusta especialmente lo que dice la nota sobre los programadores de Ruby… jejejeje….

Construcciones automatizadas y diarias

construccion Una de las grandes novedades de Visual Studio Team System y Team Foundation Server es la posibilidad de crear construcciones automatizadas. Pero como ya he comentado alguna vez en este blog, el simple hecho de contar con una herramienta que nos ayude en la tarea no significa que vayamos a adoptar una buena práctica. De hecho antes de Team System ya existía NAnt como herramienta de automatización de la construcción, y se trata de una gran herramienta, pero aun así pocos son los equipos de desarrollo que cuentan con la posibilidad de construir todo su proyects con la simple ejecución de un comando, son pocos los que usan construcciones automatizadas. Conocer las ventajas que aporta las construcciones automatizadas es el único camino para que estas se popularicen y más y más equipos de desarrollo disfruten de sus bondades. Si no quieres seguir leyendo piensa esto: si Microsoft lo ha incluido en su producto de gestión del ciclo de vida será por algo. Si quieres una explicación un poco más elaborada de porque las construcciones automatizadas son una buena idea y cómo pueden ayudar a vuestros proyectos y como combinan con otras técnicas podéis seguir leyendo.

El proceso de construir el software desde las fuentes es complejo. De hecho es cada vez más complejo: elegir la fuentes adecuadas, compilarlas con las versiones adecuadas de los componentes, asegurarnos que hemos compilado en configuración ‘release’, seleccionar de la salida del proceso de compilación aquellos archivos que debemos distribuir, no olvidar incluir aquellas librerías o componente de los que depende nuestro software y asegurarnos de que su versión es la correcta, generar los archivos de ayuda, crear la estructura de directorios que espera como entrada nuestra herramienta de generación de instaladores, ejecutar el proceso de generación del instalador… y todo esto involucrando a un buen número de personas diferentes ¿de verdad alguien cree que es posible realizar este proceso manualmente sin cometer varios errores durante el mismo?. La cruda realidad es que no es posible. Y lo que es peor, a menudo los errores cometidos en alguno de los múltiples pasos que hay que dar se detectan solo al final del proceso. El resultado: ¡una enorme perdida de tiempo!. Y lo peor del caso es que este es un proceso que se repite muchas veces a lo largo de la vida de un proyecto. Además, para agravar aun más la situación este problema ocurre cuando menos tiempo tenemos, ¡justo cuando alguien está esperando que le entreguemos el software!.

En todo proyecto de software existe un ciclo que ser repite infinitas veces: escribir código, compilarlo, integrarlo y realizar pruebas. Contar con un proceso de construcción del software automatizado hace que este este ciclo se acelere enormemente.

El principal problema que plantean las construcciones automatizadas es que exigen una inversión de tiempo para ponerlas en marcha. Configurar un proceso de construcción completo que sea capaz de desde el código fuente de nuestro software construir el software completamente hasta el instalador y además desplegarlo en un sistema de prueba es complejo. De hecho es algo que solo es abordable y rentable si se realiza de forma incremental, haciendo que el proceso de construcción crezca de manera paralela a nuestro software. En cualquier caso, a menudo, en proyectos con problemas de integración, merece la pena invertir el tiempo necesario para configurar un proceso de construcción a posteriori. El esfuerzo es grande pero a menudo no hay otro camino para zanjar de raíz los problemas de integración en los proyectos de software. Resumiendo, más vale configurar pronto el proceso automatizado de construcción que hacerlo a posteriori cuando hay problemas.

Si bien el simple hecho de poder construir nuestro software de manera automática nos proporciona claras ventajas, yendo un paso más allá y construyendo nuestro software diariamente (gracias a nuestro proceso automatizado de construcción esto es algo posible) podemos obtener ventajas añadidas. Si diariamente construimos nuestro software detectáramos rápidamente problemas de integración y corregirlos cuando los cambios que pueden ser la causa aun están frescos en nuestra memoria y por tanto nos es más fácil corregirlos. Además como parte del proceso de construcción podemos ejecutar nuestros test unitarios lo que nos proporcionará la posibilidad de detectar errores no solo relacionados con la integración. Adicionalmente, como colofón a nuestro proceso de construcción y aprovechando que nuestro proceso de construcción despliega el software construido a un entrono de pruebas podemos realizar un test de humo que asegure que el software construido tiene la calidad suficiente como para ser probado en profundidad. Este paso asegura que cualquier error relativo a la configuración del software desplegado se detecta pronto.

A menudo se pone como escusa para no realizar construcciones diarias la magnitud del proyecto: ¿Cómo vamos a construir y desplegar un software tan complejo todos los días? Precisamente cuanto mayor es el proyecto mayores son las posibilidades de sufrir problemas de integración y de calidad pues más es el código que cada día se añade. Además el hecho de que grandes proyectos como por ejemplo Firefox lo haga, demuestra que es viable y rentable. Podéis ver el estado de las construcciones diarias de Firefox.

Os dejo unas cuantas referencias interesantes sobre este tema, por si queréis profundizar más en el tema:

Joel on software: Daily Builds Are Your Friend

Wikipedia: smoke test

MSDN: Instrucciones para pruebas de humo

Mozilla Quality Assurance SmokeTests

Steve Mcconnel: Daily Build and Smoke Test

Software Development using Build and Smoke Tests

Más plantillas metodológicas para Scrum

Microsoft a liberardo la versión 1.0 de  eScrum, una plantilla metodológica para Scrum que vienen utilizando varios equipos de desarrollo dentro de Microsoft.

Sobre la plantilla en cuestión decir que es muy farragosa de instalar y que no entiendo porque tiene su propia interface web en lugar de usar la típica de TeamPlain. Esta bien como herramienta interna pero tiene carencias que hacen que

Además existe otra plantilla metodológica VSTS Scrum Process Template que se puede descargar de CodePlex. La última vez que vi esta plantilla no me dio sensación de estar muy madura, pero la verdad es que promete. Eso si, la guia de proceso es bastante floja y totalmente insuficiente en lo relativo a describir Scrum.

Yo sinceramente me quedo con la de Cochango, al menos de momento. Los motivos: que es la más madura y que tiene una excelente guia de proceso (aunque no me guste que sea online, pero bueno con HTTrack esto tiene remedio…).

Si quieres Full Trust… dímelo!!!!

De acuerdo que todos los desarrolladores somos un pelín vagos en lo que a la seguridad se refiere y que en lugar de declarar explicitamente los permisos que nuestra aplicación preferimos asumir que vamos a correr con Full Trust… pero nada nos cuesta que si alguien intenta correr nuestra aplicación desde una zona que no es Full Trust por defecto, controlemos el problema e informemos convenientemente al usuario de que está ocurriendo. Si no nos molestamos en declarar que permisos necesitas nuestra aplicación debemos asumir que solo funcionará correctamente en entornos Full Trust, y para evitar sorpresas tenemos dos caminos:


1) Declarar a nivel de assembly que necesitamos Full Trust poniendo la siguiente línea en el AssemblyInfo:


[assembly: PermissionSet(SecurityAction.RequestMinimum, Unrestricted = true)]

De esta manera que cuando alguien trate de cargar el assembly recibirá un casque inmundo pero al menos podrá utilizar la herramienta Permview.exe para ver que el assembly requiere Full Trust.

2) Comprobar al principio de nuestro programa que tenemos Full Trust y si no es el caso, sacar un pequeño mensaje… siempre que tengamos permisos para sacar algo por pantalla 🙁

private static bool CheckFullTrust()
{
   try
   {
      // Demandar Full Trust
      new PermissionSet(PermissionState.Unrestricted).Demand();
      return true;
   }
   catch (SecurityException)
   {
      try
      {
         // No estamos en Full Trust, se lo contamos al usuario
         MessageBox.Show(“La aplicación necesita Full Trust”);
      }
      catch (SecurityException) 
      {
        // La aplicación no tiene permisos mostrar mensajes… 🙁
        //Logeamos lo ocurrido
      }
   }
   return false;
}

Recordad sin embargo que la buena práctica es declara que permisos necesita nuestro assembly.

Nadie dijo que no exigiese un esfuerzo…

Leo en el blog Diario de Programación que su autor, ha decidido abandonar Scrum, antes de ni siquiera completar un par de Sprints… hasta aquí poca noticia, porque no es el primero caso ni el último que se da. En este caso no se puede pensar en que se desconoce Scrum, pues el autor de blog, ha publicado una serie de post sobre este tema bastante interesante y se, de primera mano, que había realizado una  importante tarea investigadora. ¿Pero que ha fallado entoces? Bueno partiendo del post en el que cuenta que problemas ha encontrado, y como simple ejercicio que me parece interesante, voy a tratar de diagnosticar la situación. Creo que esto puede ayudar a gente que se encuentre con problemas parecidos cuando se decida a intentar gestionar con Scrum sus proyectos. Para ello voy a comentar su post (en cursiva) entre líneas. La verdad que he estado siguiendo lo que escribía ultimamente pues siempre estoy muy interesado en ver cuales son las experiencias de otra gente que utiliza Scrum.



Bueno, al final lo de Scrum se ha ido un poco al garete.



La semana pasada no hicimos ninguna reunión, en parte porque yo tuve que faltar un par de días, lo de las reuniones diarias se me hace un poco cuesta arriba, etc, etc


Uno de los pilares centrales de Scrum son los Daily Scrum. Es la manera de abordar la comunicación en esta metodolgía. La comunicación es uno de los mayores problemas a los que nos enfrentamos en el desarrollo de software. Todas las metodologías abordan este problema y plantean alguna solución. Es un problema además vital en los equipos ágiles, donde no hay documentación que prentenda sustituir a la comunicación cara a cara. Si prescindimos del Daily Scrum o no le damos la continuidad pautada en Scrum estamos dañando la metodología de tal manera y en un area tan importante que es muy dificil que lleguemos a buen puerto. Sin Daily Scrum, no hay Scrum. En general, sin abordar el problema de como se comunica el equipo y darle una solución, no hay metodología.


Entiendo que para convocar la reunión diaria y llevarla, el Scrum Master no puede ser una persona que hace/le gusta hacer código. Aunque hay excepciones, me hace la impresión de que en general es cierto que la persona cuya mente entiende los punteros, no es una persona que grandes dotes sociales. No quiero decir que sea un inadaptado, pero posiblemente no es el tipo de persona que gusta dirigir una reunión de ocho o nueve personas … todos los días.


Otro ‘error’ que se vislumbra es el pensar que alguien dirige el Daily Scrum. Esto es un error habitual, al Daily Scrum se va a compartir información, no a rendir cuentas. Es muy importante que esto quede claro de palabra y de acción, sino perderemos la posibilidad de que el equipo nos traslade la información que necesitamos para guiar el desarrollo.

Es importante que el Scrum Master se capaz de comunicar, de escuchar y de actuar para eliminar impedimientos. Pero no veo que esto este reñido con que te guste programar o entiendas los punteros. A mi me encanta programar y entiendo los punteros. Se que hay equipos que incluso rotan la figura del Scrum Master entre uno de los miembros del equipo. No creo que sea recomendable al principio, pero sin duda si no hay nadie que disfrute con ese rol puede ser una solución para repartir esta ‘pesada carga’.


Otro problema que nos tira abajo es el horario flexible de la gente. Desde que llega el primero hasta que llega el último puede pasar hora y media o dos horas. Cuando llega el último, los primeros no solo están ya enfrascados en su trabajo, sino que incluso pueden que no estén en su sitio liados con otras cosas.


Sobre el tema del horario flexible, no creo que sea un impedimiento de peso. ¿No hay horas en las que todos los miembros del equipo coincidan? Seguro que un café todos juntos ya se toman al día, seguro que hay otras reuniones a las que acuden, seguro que comentan el futbol quince minutos al día, no me creo que no haya un momento en el día en que poder ubicar el Daily Scrum y que todos acudan. Esto no es un problema si cumplimos una regla básica: ¡el Daily Scrum solo dura quince minutos!


También es difícil coordinar los finales de Sprint. Cuando se hace la versión ejecutable, siempre hay pequeños fallos de última hora, por lo que planificar la última reunión de demo y demás es complicado. Para que esa versión entregable salga bien y a tiempo, da la impresión de que es necesario reservar uno o dos días al final del Sprint para depurar los útlimos errores. También sabemos todos que depurar errores no es algo que se pueda planificar, un error se puede encontrar y corregir en dos minutos o en dos días, según le de.


Sin duda es dificil. Pero no es una dificultad que surja de la necesidad de hacer una demostración. La demostración es la solución, la dificultad es integrar software tan complejo como el que se construye actualmente. Solo haciendo la integración un hábito, lograremos que deje de ser un problema. Integrar es como correr cinco kilometros, muy dificil si no lo haces a menudo, muy facil si lo haces habitualmente. Es normal que aparezcan errores durante una demo, nadie va a abuchear al equipo. Pero si que es cierto, que el tener que demostrar el funcionamiento del software hace que el equipo no deje la calidad para el final. Dejar la calidad para el final es algo que la daña de manera irremisible y la calidad no es opcional. Además el enfoque debe estar en no tener que depurar bug, en no introducirlos, en ser cuidadoso y escribir buenos test. Con buenos tests, no es necesario reservar días para preparar la demo. De hecho, dedicar dos o tres días a preparar la demo esta desancosejado y debe evitarse, pues es sintoma de que no se está desarrollando con la calidad sufiente.


Y otro problema más es la coordinación de la gente en esas etapas finales. En los últimos días del Sprint hay quien ha terminado sus tareas, mientras que otros todavía no o está depurando detalles. ¿Qué hacemos con los que han acabado?. Normalmente no pueden ayudar en las etapas finales de las tareas de otros, ya que les son ajenas y posiblemente entorpezcan más que ayuden.


Sobre esto preguntaba un lector de este blog hace un tiempo y respondí en este post. Esto demuestra que es un problema que aparece habitualmente. Me limito aquí a reproducir la respuesta que entonces dí: No olvidemos que el equipo en Scrum es un rol central. No olvidemos que el equipo en Scrum debe ser multidisciplinar y que por lo tanto, debería contar en su interior con todo el conocimiento necesario para llevar a cabo el proyecto de manera colegiada. Ninguna actividad en el ciclo de vida de un proyecto se realiza en completo aislamiento de otras, luego todos los integrantes del equipo tienen algo que aportar en todo momento. Cuando un miembro del equipo acaba sus tareas y no puede colaborar con otras (raro me parece) tiene muchas cosas que hacer: tomarse tiempo para conocer otras partes del proyecto que no domina, formarse en tecnologías que tendrá que usar más adalante, mejorar la cobertura de código de los test, mejorar el proceso de build, programar algún script que automatice alguna tarea engorrosa o propensa a fallos, sentarse con otro programador que esta escribiendo algo que es importante, hacer una ppt para presentar la próxima demo, investigar que componentes pueden ser utiles para implementar proximos Product Backlog Items, leer este blog ;)… ¡Siempre hay algo importante que hacer!. Basta con decir que estas ‘mirando’ en el Daily Scrum para que alguien sugiera algo que puedes hacer.


En fin, no ha salido rápido y a mí, como buen inadaptado social, no me apetece seguir con ello -tampoco veo demasiado apoyo de los demás-. Así que seguiremos con algo similar -pequeñas entregas cada cierto tiempo-, pero de una forma un poco más tradicional -preguntando de vez en cuando a cada uno cómo va-.


Desarrollar software es complejo. Nada, nunca sale facilmente y rápido. Sobre todo las cosas en las que no tenemos experiencia. Sobre todo lo relacionado con procesos y metodologías, un area en la que cada proyecto y cada equipo debe realizar ajustes imprescindibles. Sobre el apoyo de los demás, sin duda se ha cometido el error habitual de no tener un sponsor y no tener una táctica para lidiar con esta carencia. Ya escribí sobre este tema, que es clave para lograr que una metodología triunfe. Todo el mundo es reticente al cambio, al menos de entrada. Además creo que es vital explicar al equipo y al Product Owner, que van a obtener si Scrum funciona y creo que esto no se ha hecho.


De todas formas, este proyecto me pillaba un poco ajeno, simplemente estoy como ayudante/asesor o cosa rara similar. Es posible que si en algún momento me toca a mí llevar un proyecto de estos de forma más directa, vuelva a intentarlo.


Si quien es el Scrum Master, no lo tiene claro desde el principio… Es vital que la figurar del Scrum Master sea una figura fuerte, que tenga claro en que consiste Scrum, que ventajas aporta, que resultados se persiguen y lo más importante, que sea capaz de transmitirlo con entusiamo y claridad. Creo que si Scrum falla, en un 90% de los casos se debe a que no hay un Scrum Master con capacidad suficiente detrás de la iniciativa. Scrum, en esencia, no es dificil, pero comenzar con Scrum si que lo es. Creo que es un error lanzarse a Scrum contando solo con lo que se ha leído en libros, webs y blog. En mi opinión es casi imprecindible recibir una formación profunda y un periodo de mentoring con alguien que haya logrado implantar Scrum con anterioridad. Creo que esto es algo que se aplica a cualquier metodología.

¡No tireís la toalla con las metodologías! Cuesta, pero merece la pena.

Por ultimo agracer al amigo Chuidiang que haya compartido su experiencia públicamente en su blog.

Webcast: Patrones para arquitecturas orientadas a eventos y mensajes

He visto de casualidad un interesantísimo webcast sobre patrones relativos a arquitecturas basadas en eventos e intercambio de mensajes. El autor del webcast es Ian Cartwright en colaboración con el ínclito Martin Fowler.

Me ha llamado poderosamente la atención la presentación porque llevo un tiempo involucrado en la arquitectura y el desarrollo de una aplicación en la que todos los patrones descritos en la presentación tienen mayor o menor aplicación. Muchos de ellos ya aparecen en la arquitectura actual a pesar de que no les conocía, esa es la mágia de los patrones, se repiten una u otra vez.

En el desarrollo de esta aplicación nos hemos enfrentado a varios de los problemas descritos en la presentación como garantizar el envio de fran número de eventos, el gestionar y mantener las subscripciones a todos esos eventos, y tambiénl evitar la notificación de eventos innecesarios.

Pasar de la arquitectura anterior de la aplicación totalmente basada en un modelo pool, en el que los clientes preguntan por el estado continuamente, a un modelo push en el que los clientes reciben eventos cuando se producen cambios en el estado de la aplicación a supuesto un reto importante. Sobre todo porque los eventos no son independientes entre sí y además pueden llegar de manera desordenada. Pero la ventajas que presenta ahora la arquitectura sobre todo desde el punto de vista de la resilencia, la capacidad para recuperarse de situaciones adversas de red o de errores de comunicación o caidas del servidor o de los perifericos, que ha aumentado espectacularmente. Y este era uno de los objetivos buscados.

Tambien usar un modelo basado en eventos y en mensajes hace que la aplicación sea desplegable de una manera mucho más distribuible, lo que mejora enormementa las posibilidades de escalabilidad.

Se habla mucho de las arquitecturas SOA pero sin duda las arquitecturas EDA (Event Driven Architectures) son el complemento ideal para un motón de escenarios habituales.

En la imagen adjunta os dejo un esquema de la arquitectura en cuestión, en la que el amigo, compañero de trabajo y vecino de blog Gorka Elexgaray, tambien puso su importante grano de arena. Podeís ver como aparece un Event Broker, elemento centrar el toda aplicación guiada por eventos y como la información se intercambia utilizando mensajes. Esto nos permite usar MSMQ como sistema de comunicación lo que nos permite que la arquitectura soporte bastante bien escenarios desconectados y desconexiones no esperadas.

Metodologías y Procesos de desarrollo con VSTS (PPTs)

Os dejo tal y como me pedían algunos lectores del blog y algunos de los asistentes al evento, la presentación que utilicé durante la presentación sobre Metodologías y procesos de desarrollo con Team System que hice la semana pasada en las instalaciones de Microsoft en Madrid.


Fue un placer poder charlar sobre Team System con un grupo de gente intersada en las metodologías y la mejora de procesos de desarrollo. También me encanto conocer y saludar personalmente a algunos lectores asiduos de mi blog. En general disfrute bastante con el evento.


Gracias a todos los asistentes.