Ya soy Certified Scrum Master ¿y?…

Esta pasada semana tuve el placer de participar como alumno en un curso de certificación como Scrum Master impartido por Stacia Broderick. Sobre la formadora no puedo más que decir alabanzas, me pareció que llevo el curso de manera excelente y que tiene una capacidad notable para transmitir conocimientos. Los ejercicios que realizamos fueron realmente interesantes.


La verdad es que después de leer un motón de críticas sobre esta certificación y del revuelo que se está levantando entorno a este tema en la comunidad alrededor de las metodologías ágiles, mis expectativas sobre el curso eran malas. Pero tengo que reconocer que me ha encantado el curso.


No voy a entrar en el manido tema de la validez o no de las certificaciones. Tengo tantas que es me es difícil tener una opinión clara sobre las mismas. Tengo sentimientos contrapuestos sobre el tema: ¿Si tan inútiles son por qué el mercado las valora tanto? ¿Si cualquiera puede sacarlas por qué no las tiene todo el mundo? ¿Si demuestran tanto por qué tengo tantas sin haber hecho un esfuerzo sobrehumano? ¿Si realmente prueban algo, por que todo el mundo que lo intenta tarde o temprano las consigue? ¿Por qué hay tanto inutil que exhibe certificaciones?… No sé, no sé…


En el caso de la certificación que nos ocupa, creo que lo menos acertado es el nombre y el que den una certificación. Si simplemente hubiesen elegido un nombre como ‘Certified Scrum Master Training’ creo que no habría lugar a la polémica.


Una vez dicho esto, lo que verdad debe preocuparnos es si se trata de una buena inversión de tiempo y dinero. Y en este punto tengo que ser categórico: si. Leído esto, estaréis pensando que ahora sabré mucho más de Scrum que antes de ser CSM. Pues la respuesta es que no!. ¿Cómo puede ser esto?. La respuesta es simple: no se mucho más de Scrum pero si se mucho más de cómo transmitir la esencia de Scrum al resto del mundo y sobre todo he tenido la oportunidad impagable de compartir dos días centrados en Scrum con una decena de profesionales de toda Europa con amplia experiencia en la gestión de proyectos en general y con Scrum en particular. Especial mención a Ángel Medinilla, autor del blog Presión Blogosférica, que cada vez sigo con más asiduidad, y una muestra clara de que cada vez hay en este pais más profesionales de la gestión de proyectos que saben de lo que hablan. Tuve el placer de contrastar opiniones con el y aprender de sus puntos de vista, aunque no siempre compartiesemos la misma visión (esto es lo que hizo esas charletas realmente interesantes).


Mi primera conclusión es que no se trata de una formación para aprender Scrum, sino para aprender a ser Scrum Master, que es muy diferente. Y en eso se centra la formación que nos ocupa, en enseñarte a transmitir Scrum, que es el principal trabajo de un Scrum Master.


Por ejemplo, creo que el curso no sirve si lo que quieres es saber como implantar Scrum en tu organización o si quieres formar a los miembros de un equipo para utilizar Scrum. En mi opinión hay que apoyar Scrum en una herramienta para que sea realmente efectivo, y en esta formación no se ve ninguna herramienta. Además evidentemente en dos días no se pueden tratar todas las cuestiones que surgen en una implantación de Scrum.


Después de haber enseñado a cuatro equipos de desarrollo como hacer Scrum en el último año y llevar un buen número de Sprints sobre mis espaldas como parte de un equipo Scrum, creo que la conclusión es que el curso vale la pena si ya conoces Scrum y te dedicas a transmitir Scrum, sea de puertas adentro de tu organización o a terceras empresas. Pero no vale la pena si lo que te dedicas es a llevar a cabo Scrum. Para esto último es mucho mejor contar con alguien que viva el proyecto con tu equipo de desarrollo y realice un mentoring más distribuido en el tiempo que realizar una formación puntual.

Curso de Scrum con Team System en Bilbao

Entre Plain Concepts y Sarein hemos preparado un interesante curso sobre Scrum y Team System: Gestión ágil de proyectos con Metodología Scrum y Visual Studio Team System que tendré el placer de impartir los días 1, 2 y 3 de Octubre en Bilbao.


El contenido del curso, que tiene una duración de 24 horas es:


Scrum
Introducción a Scrum y las metodologías ágiles
Roles en SCRUM
Definición de Sprint
Artefactos en SCRUM
Gráficos de progreso y control del proyecto
Comunicación en SCRUM
Escalando Scrum
¿Precio y fecha cerrados con Scrum?
Madurez y Scrum
Las reglas de Scrum


Visual Studio Team System
Team Foundation Server y el ciclo de desarrollo
Gestión del proyecto utilizando elementos de trabajo y Scrum
Gestión de fuentes
Herramientas de diseño y modelado
Herramientas para calidad


El precio del curso, es de 900 euros.


Espero que os animéis!!!

Problema con aplicaciones Asp.net de 32 bits en servidores de 64 bits

En ocasiones puede ocurrir que una aplicación Asp.net utilice componentes de 32 bits o filtros ISAPI de 32 bits desarrollados por terceros y que no podemos recompilar para 64 bits estos componentes. El resultado es que la aplicación ‘casca’ estrepitosamente cuando la intentamos acceder a su sitio web. Esto me ocurrio ayer mismito con una aplicación que utiliza un componente de informes compilado únicamente para plataformas de 32 bits. Los pasos a dar no son simples y he tenido que ir rascando información aquí y allí, así que os dejo las indicaciones para solucionar el problema, por si alguien más lo sufre.

Síntomas:

En equipos de 64 bits tras instalar la aplicación, no podremos acceder al sitio web de la aplicación. Los errores que podemos recibir son del estilo:

Server Error in ‘/TuAplicacionWeb’ Application.


no es una aplicación Win32 válida. (Exception from HRESULT: 0x800700C1)

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: no es una aplicación Win32 válida. (Exception from HRESULT: 0x800700C1)

O bien un error 503 de HTTP, Service Unavailable. O en otras ocasiones un error 153 de Windows.

Solución:

Debemos asegurarnos de que tenemos el Service Pack 1 de Windows 2003 Server 64 bits instalado.

Los pasos a dar son:

1) Configurar IIS para que no se ejecute en modo ‘IIS 5 Isolation Mode’, para ello ejecutamos estos comandos:

CSCRIPT %SYSTEMDRIVE%InetpubAdminScriptsadsutil.vbs SET W3SVC/IIs5IsolationModeEnabled 0

NET STOP HttpFilter /y

NET START W3SVC

2) Configurar IIS para que corra el proceso w3wp.exe como proceso de 32 bit, para ello ejecutamos el siguiente comando.

CSCRIPT %SYSTEMDRIVE%InetpubAdminScriptsadsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

3) Puesto que no podemos cargar un filtro ISAPI de 64 bits en un proceso de 32 bits debemos asegurarnos de utilizamos el ISAPI de Asp.Net de 32 bits.

Si no hacemos este paso en el log de eventos prodremos ver

Event Type: Error
Event Source: W3SVC-WP
Event Category: None
Event ID: 2268
Description:
Could not load all ISAPI filters for site/service. Therefore startup aborted.
Data: 0000: c1 00 00 00

O recibir el error %1 is not a valid Win32 application o Service Unavailable al intentar acceder al sitio web de la aplicación.

Para que IIS utilice el filtro ISAPI de Asp.Net de 32 bits tenemos que ejecutar el siguiente comando:

%windir%Microsoft.NETFrameworkv2.0.50727ASPNET_REGIIS.EXE -I –Enable

4) Debemos reiniciar el application pool en el que se ejecuta nuestra aplicación web. Una manera muy comoda es ejecutar el comando iisreset que reinicia completamente nuestro Internet Information Server y por lo tanto todos los application pools.

Más información sobre el tema (en inglés):

David Wang : HOWTO: Diagnose one cause of 503 Service Unavailable on IIS6

David Wang : HOWTO: Diagnose one cause of 503 Service Unavailable on IIS6 on 64bit Windows

David Wang : HOWTO: Diagnose One Cause of “%1 is not a valid Win32 application” on IIS6 on 64bit Windows

David Wang : HOWTO: Diagnose one cause of W3SVC failing to start with Win32 Error 193 on 64bit Windows

How to switch between the 32-bit versions of ASP.NET 1.1 and the 64-bit version of ASP.NET 2.0 on a 64-bit version of Windows

Windows Server 2003 SP1 enables WOW64 compatibility for 32-bit Web applications in IIS 6.0

El ‘pool’ de programadores

real_programmers Oigo esta expresión una y otra vez. Y la verdad, no siempre puedo levantarme de la silla, mirar a quien la utiliza y decirle que parece mentira que alguien con su responsabilidad y a quien se suponen experiencia y conocimientos en la gestión de proyectos siga creyendo en esta falacia. Desgraciadamente casi siempre que oigo esta expresión sale de la boca de alguien ‘con responsabilidad’. No existen los pools de programadores, olvídense. Yo al menos aunque oigo la idea una y otra vez, no conozco a nadie que la haya implementado con éxito.

Voy a tratar de explicar aquí porque ‘el pool de programadores’ es una idea equivocada desde mi punto de vista. Así la próxima vez que oiga a alguien decir ‘contamos con un pool de programadores’ o ‘ lo que necesitamos es un pool de programadores’ o ‘quiero crear un pool de programadores’, en vez de que se me hinche la vena, allí, en directo, podré simplemente decir: “escribí no hace mucho sobre eso en mi blog, quizá te interesé leer lo que escribí”, que suena bastante más sosegado…

En informática estamos muy familiarizados con la idea de ‘ pool’. El patrón es simple, cuando necesitamos con frecuencia un recurso difícil de obtener lo mejor es tener un conjunto de esos recursos dispuestos a realizar su función en el momento en que se lo demandemos. ¿Por qué no trasladar esta idea que tan bien funciona para hilos, conexiones, sockets u objetos costosos de constrir a los programadores? Parece que esto es algo natural. Pero como muchos antipatrones, la idea aunque atractiva no funciona. Los motivos son, desde mi punto de vista, varios.

Los programadores no son reemplazables simplemente sin un coste, sin unos riesgos, sin que el proyecto se vea afectado. Los hilos o las conexiones que pedimos a un pool son todos idénticos, tienen las mismas características y capacidades y van a realizar siempre la misma tarea. Pero los programadores, como personas humanas que son, no son homogéneos, no tienen las mismas capacidades, ni van a realizar siempre las mismas tareas. Es más, no nos serviría de nada un pool de desarrolladores todos homogéneos, puesto que las tareas de desarrollo que debemos abordar son heterogéneas, para cada una de ella se necesitan diferentes capacidades, y a menudo se necesitan las capacidades de más de un desarrollador, la capacidades de un equipo.

Cuando asignamos tareas a un hipotético pool de programadores, en principio quien realizará la tarea es el programador que se encuentre disponible, lo que para nada significa el desarrollador más adecuado. La diferencia de desempeño entre el desarrollador adecuado y el desarrollador disponible son muy elevadas, tan elevadas que por si sola invalidan la idea del pool de programadores.

Habitualmente, la replica suele ser del estilo: “eh!!! Pero si el desarrollador solo tiene que ‘poner ladrillos’ nuestro analistas se lo darán’ mascado’. Y nos aseguramos de tener los mejores analistas y seleccionar los adecuados’. Cualquiera que haya trabajado con este modelo sabe que no hay nada más difícil que implementar un diseño de otro, sobre todo si eres un desarrollador novel, como suele ser el caso. Las trabas de comunicación y los miles de detalles que hay que especificar hacen que no sea rentable hacer un diseño tan detallado como para que solo haya que ‘poner ladrillos’. Que nadie entienda con esto que creo que no es necesario el análisis y el diseño o los analistas, pero su labor es otra, su labor es la de establecer patrones, marcar pautas claras, escribir código especialmente sensible, vigilar la calidad del código, según la metodología asignar tareas a otros desarrolladores etc… Pero creo que no es productivo que el analista solo diseñe. Hay tantas decisiones que tomar en cada línea código escrita…

Otro tema capital por el que el pool de programadores no es una buena idea es por que es una idea muy alejada del concepto de construir equipo. Cuando actuamos como gestores de proyectos una de nuestras labores principales es construir un equipo. El interés en construir un equipo es claro: decenas de estudios demuestran que la productividad de un equipo bien engrasado y establecido es hasta un orden de magnitud más alta que la suma de la productividad de sus miembros. Si alguien quiere ahondar en el tema, no hay mejor fuente que Peopleware.

En un pool, en el mejor de los casos, podemos esperar que la productividad sea igual a la suma de sus miembros. Pero este nivel de productividad nunca se va alcanzar, en un pool de programadores, los cambios entre tareas, los cambios de contexto, se van a comer una porción alta de la productividad esperable.

¿Qué pensáis vosotros sobre los pool de programadores? ¿Alguno de vosotros ‘vive’ dentro de uno? ¿Alguno de vosotros disfruta o sufre uno en sus proyectos?

Encuesta sobre el estado del desarrollo ágil

State Agile Dev Survey 2007VersionOne junto con APLN ha realizado una encuesta sobre el estado del desarrollo con metodologías ágiles. Es un estudio amplísimo básado en 1700 encuestas respondidas por representantes de equipos de desarrollo de 71 paises diferentes.


Entre las conclusiones que se pueden sacar viendo el informe es que empresas cada vez más grandes y más distribuidas están sacando provecho de las metodologías ágiles. Esta cayendo así uno de los grandes tópicos: las metodologías ágiles no son solo para pequeños equipos de desarrollo y parece que escalan satisfactoriamente.


Otro dato significativo es que Scrum es muy de lejos la metodología ágil más utilizada, bien de manera ‘pura’ o mezclado con XP.


Cabe destacar también que aunque lo que más buscan la empresas cuando adoptan metodologías ágiles es mejorar su capacidad para gestioner prioridades cambiantes, lo que con mayor frecuencia obtienen es una mayor productividad, un menor número de defectos, un mejor ‘time-to-market’ y en una menor medida una reducción de costes.


Entre las técnicas ágiles de desarrollo la más implantada es el testeo unitario, seguida por la integración continua. Ninguna noticia aquí pues ambas son técnicas imprescindibles.


Por el lado de las herramientas las que más aceptación tienen son el gestor de bugs, las herramientas de testeo unitario, la omnipresente hoja de cálculo y el wiki.

Personas o bits

Los desarrolladores de software, yo el primero, tendemos a centrarnos en cuestiones  técnicas, a pensar que este tipo de cuestiones son las de mayor importancia en la vida de los proyectos de desarrollo. Pero esto no es cierto. Voy a dedicar está columna a argumentar el porqué. La cuestión es muy interesante en mi opinión, porque quizás los desarrolladores y la industria del software han estado equivocando donde deben poner su foco de atención.

Pensemos en las típicas estadísticas que a menudo leemos sobre los motivos por los que los proyectos fallan. Nunca cuestiones o dificultades técnicas ocupan los primeros lugares. Otro síntoma claro de que la tecnología no es el factor clave es el hecho evidente de que existen proyectos exitosos y sonoros fracasos desarrollados en todas la tecnologías y lenguajes de programación.

Uno de los autoengaños, en los que solemos caer los desarrolladores, yo el primero, es preocuparnos demasiado por las herramientas o las tecnologías, sobre todo por las nuevas. A menudo se encuentra a los desarrolladores discutiendo sobre tal o cual herramienta, o nuevo lenguaje… Es normal, los fabricantes de esas herramientas promueven ese debate prometiendo mejoras en la productividad que debemos reconocer rara vez son tales y que, si se producen, nunca llegan a lo prometido. ¿Alguien puede citar alguna herramienta que mejorase radicalmente su productividad? No hablo de usar un potente IDE frente a usar simple editor de texto, sino de usar la versión actual de un potente IDE frente a usar la versión anterior. Pensándolo en frio, creo que es evidente que si bien es cierto que las herramientas mejoran nuestra productividad, estas mejoras no son radicales sino que se producen de manera muy distribuida en el tiempo. En resumen, las herramientas evolucionan pero no revolucionan de manera puntual nuestra manera de hacer software. Esto no quiere decir que debamos desdeñar las mejoras que puedan surgir de utilizar las mejores herramientas, sino que las mejoras que debemos esperar en este aspecto del desarrollo de software son pequeñas. Lo aquí comentado se aplica, punto por punto, también a las tecnologías. ¿Alguien piensa que es mucho más fácil desarrollar una aplicación distribuida con WCF que con Remoting o Web Service o incluso que con DCOM?. No, la dificultad no está relacionada con las herramientas a usar sino con la complejidad del problema a resolver.

Otro punto que tendemos a olvidar es que las tecnologías y herramientas, antes de que tengamos la oportunidad de que nos ayuden tenemos que aprender a utilizarlas y este proceso, a menudo, minimiza las mejoras que podemos esperar.

Con lo que he comentado anteriormente no quiero decir que no haya que buscar y seleccionar nuevas herramientas o tecnologías y aprender a utilizarlas, sino que no debemos creer que vayan a cambiar radicalmente nuestra capacidad o la de nuestro equipo a la hora de crear software y sacar adelante nuestros proyectos.

Las metodologías son otra de las áreas que prometen grandes mejoras en el desarrollo de software y en este caso, creo, que bien implementadas, las metodologías, sobre todo aquellas centradas en ayudar al desarrollador, obtienen grandes resultados. El problema es que implementar bien una metodología es un proceso extremadamente difícil, complejo, costoso y largo en el que muchas empresas o equipos de desarrollo fallan en repetidas ocasiones. ¿Cuantos de vosotros habéis sufrido un intento fallido de implementar una metodología? Estoy seguro que muchos. ¿Cuántos de vosotros tenéis teóricamente una metodología y realmente lucháis para que nos os entorpezca? Pocos equipos de desarrollo tienen una metodología y entre los que la tienen, pocos están plenamente satisfechos con ella. Resumiendo, usar una metodología adecuada puede mejorar en mucho nuestra productividad, pero es muy difícil cerrar el triangulo mágico de encontrar una metodología adecuada, implantarla con éxito y lograr que ayude a los desarrolladores. Esta última, es condición necesaria para que perdure y se extienda a otros proyectos de nuestra empresa. Solo una metodología que ayude a los desarrolladores y que mejore su vida profesional día a día tiene alguna oportunidad de perdurar. El motivo es claro, todos somos reacios al cambio, y mucho más reacios somos a aquellos cambios que no se revelan rápida y claramente como ayudas. Es también evidente que el rol más numeroso en los proyectos de desarrollo es el de desarrollador, mucho más numeroso que el de jefe de proyecto, gerente y demás puestos ‘de responsabilidad’, y por tanto cualitativamente, de quien más resistencia encontramos cuando una metodología no ayuda, es, precisamente de los desarrolladores. No deja de ser paradójico, además, que a menudo se escuche poco o nada la opinión de los desarrolladores a la hora de seleccionar e implantar una metodología.

Bien, hemos comentado que a pesar de lo que tendemos a pensar, las herramientas, las tecnologías y las metodologías no tienen un impacto radical en mejorar como hacemos software. Aunque tienen su importancia. También es claro que en el mundo competitivo en el que nos movemos cuando hablamos de desarrollo de software necesitamos mejorar día a día. Ahora os preguntaréis, si lo esencial en el desarrollo de software no es, según defiendo en este artículo, las herramientas, las tecnologías y las metodologías, ¿qué es lo esencial?: las personas y sus interacciones.

El factor más importante en el desarrollo de software es la calidad de los desarrolladores que llevan a cabo el trabajo. Nada puede suplir este factor. A pesar de los muchos intentos que en la industria del software se han hecho por hacernos creer lo contario. Un equipo de ‘juniors’, es un equipo poco capaz, lo dirija quien lo dirija, use las herramientas que use y aplique la metodología que aplique. Nada puede suplir la experiencia y la maestría de los desarrolladores. Es curioso como cuando se habla de este tema, todo el mundo asiente, pero si embargo luego todo el mundo lo olvida con facilidad. A menudo se trata a los desarrolladores como piezas intercambiables o metodologías con amplia aceptación como CMMI se olvidan de incluir el factor humano en la ecuación centrándose únicamente en el proceso. Como si un excelente proceso permitiese realizar desarrollos excelentes sin desarrolladores excelentes. La realidad es que desarrolladores excelentes pueden lleva a cabo desarrollos excelentes con metodologías mediocremente implantadas o incluso sin metodología explicita alguna. ¿Si todos asentimos cuando alguien clama que las personas es el principal factor por qué nos olvidamos de este factor con tanta facilidad?. Quizá sea porque es el factor sobre el que más difícil es actuar. Pero no por eso debemos dejar de actuar.

Un hecho que la industria del software lleva obviando durante gran parte de su historia es que los buenos desarrolladores son extremadamente baratos. Existen numerosísimos estudios que ‘demuestran’ que la diferencia de rendimiento, se mida como se mida, entre los mejores y los peores programadores es de alrededor de ¡treinta veces!. Ahora os propongo un juego, pensad en el mejor desarrollador y el peor con que hayáis trabajado. Pensad en su rendimiento, y decidme si no se cumple lo anterior. Ahora pensad en su sueldo, ¿alguien cree que la diferencia era de alrededor de treinta veces?. La conclusión es clara, la relación rendimiento sueldo no es lineal, luego, proporcionalmente los desarrolladores cuanto mejores y más experimentados son más baratos resultan. Entonces, ¿por qué sigue habiendo proyectos plagados de gente sin experiencia?.

Las personas cuentan mucho, pero aun cuentan más cuando juntamos varias. Cuando lo que se comparan son equipos y no personas individuales, la diferencia es todavía más apabullante. El rendimiento que puede alcanzar un equipo bien engrasado es espectacular. El problema es que solo quien ha estado en alguna ocasión en uno de esos equipos puede saber de lo que hablo. Pero creedme, nada puede impulsar más vuestros desarrollos que logra que el equipo de desarrollo funcione como un reloj. De hecho, nuestro principal cometido como gestores de proyectos es sin duda, construir el ambiente en el que nuestro equipo pueda realizar su trabajo en condiciones óptimas (ver la viñeta de Dilbert adjunta). El resto aunque es importante es menos importante.

Supongo que más de uno os estaréis preguntando porque os cuento todo esto. La idea que tengo es dedicar algunas entregas de este espacio que tan amablemente me ha cedido dotNetMania a desgranar lo que se esconde bajo cada uno de los puntos que constituyen el manifiesto ágil, cimiento sobre el que se fundamentan todas las metodologías ágiles. Todo lo que os he contado en esta entrega se corresponde con el principio que dice: ‘Individuos e interacciones sobre procesos y herramientas’. ¿No os parece que todo lo dicho tiene sentido y que sin embargo es algo que llevamos obviando mucho tiempo?. ¿De qué pensáis vosotros que va el desarrollo de software, de personas o de bits?.

Publicado anteriormente en la columna de opinión de la revista dotNetMania. La viñeta de Dilbert no aparecio en el artículo original.