¿Cuándo Scrum no es Scrum?

Me he permitido traducir al español el título de este artículo de Tobias Mayer que destacan también en InfoQ. En él se critican ocho de los aspectos de Scrum que resultan más engorrosos, proponiendo alternativas que se han demostrado más eficientes durante los últimos años.

El artículo es bastante bueno, aunque no sé si mi opinión es sesgada porque estoy de acuerdo con todos los puntos. El caso es que muchas de las conclusiones ya se pueden leer en el fenomenal artículo de Henrik Kniberg Scrum and XP from the trenches, que es casi de obligada lectura.

Aún así, lo más impactante quizás de este artículo es el párrafo final:
On 30 January 2007 I was fired from the Scrum Alliance for challenging the leadership on issues of integrity and transparency. I no longer teach CSM classes. The official reason for the termination: “…the effort to sustain you has exceeded the benefit you bring to the ScrumAlliance over the last year” is a little unclear to me, but it was my time to move on, so there are no hard feelings there, and it does allow me to begin to explore Scrum and Agile in new ways. If we don’t press for change, as context of place and time dictate, then we are in danger of becoming that which we set out to challenge: another silver bullet with fixed solutions to fit every problem. And the Scrum Alliance is in danger of becoming another command and control organization, shot through with rules and contracts to control the course of this new silver bullet. I reject that approach: I embrace chaos, and I embrace holistic, context-sensitive approaches to creating essential change.

Interesante. ¿Está Scrum (extiendase a otras metodologías ágiles) cayendo en manos del formalismo empresarial? La verdad es que poco se puede especular en base a este despido ya que siempre puede haber razones que desconozcamos. Pero la verdad es que no sería raro que una organización de este estilo se dedicara a hacer dinero, vendiendo cursos y formación y terminase anquilosando la metodología.

En fin, me quedo con las buenas ideas del artículo.

Dentro de MySpace.com

Este artículo. en Baseline describe como ha evolucionado la arquitectura de MySpace desde su implementación inicial en Perl, pasando por ColdFusion y terminando en ASP.NET y C#. El artículo se centra sobre todo en la evolución en la topología de la base de datos, y como fueron detectando que arquitecturas que parecían ideales al principio pronto se venían al traste por el tráfico brutal del sitio web.

Interesante lectura para un rato libre.

Integración continua y avergonzamiento público

Una de las medidas que Mike Clark promovía en el libro de cabecera Pragmatic Project Automation es la de mostrar el resultado de las diferentes build de la manera más visible que se pueda. El objetivo está claro, saber lo más pronto posible cuando y por qué se ha producido un evento que ha roto el proceso de build de la aplicación.

En mi compañía se ha ido un poco más allá, y como aliciente adicional se ha creado una lista de "Top Build Breakers". Además el manager de producto recibe un bonito email semanal con estadísticas tan jugosas como cuantas veces se ha roto el proceso de build, quienes son los que más lo rompe, cuanto se tarda en solucionar un problema, y cosillas así.

Aunque los desarrolladores noveles son los que más han protestado con la medida, por considerarla intimidatoria y como un punto importante de presión, lo cierto es que medidas así aseguran a mantener alto el estado de salud del código, al menos en cuanto a compilación y pruebas unitarias. Pasados ya más de tres meses desde la aplicación de la medida, la productividad ha aumentado enormemente, y sobre todo el tiempo que la base de código permanece en un estado inconsistente ha decrementado radicalmente. Hace meses el código podía estar días en estado inconsistente (valga como defensa que hablo de varios cientos de proyectos), y ahora mismo pasa no más de unos cuantos minutos. La gente es mucho más cuidadosa con el código que se sube al repositorio y con los tests unitarios que se crean.

Por lo tanto, que nadie se asuste por aplicar o por sufrir estas medidas, ya que la experiencia dice que al final es un beneficio para todos. Por cierto. Sí, he roto alguna vez la build. Pero que conste que no salgo en la lista de ganadores :-)

Juegos en la empresa

Sin lugar a dudas, una de las formas más originales de probar un producto, y que he tenido la oportunidad de experimentar este año, es la de jugar con él. Sí, jugar, habéis leido bien. Intentaré explicar el concepto en los siguientes párrafos.

Cuando un producto está llegando a su fecha de lanzamiento empieza el periodo estresante de pruebas exhaustivas. Normalmente, el producto se cerrará en cuando a código fuente y a partir de ahí entrará en proceso de integración y pruebas por parte del equipo de tests. Una vez que termine este período, podremos lanzar nuestra tan esperada versión. Obviamente, nos interesa que cuando el producto llegue a manos del cliente, éste se encuentre impecable y totalmente libre del más mínimo error, problema de rendimiento, agujero de memoria, o cualquier otro efecto indeseable.

Si nuestro proceso de pruebas e integración es extraordinario, todo irá como la seda. Pero la realidad es que las cosas no suelen ser así. Aunque nuestro proceso de pruebas sea perfecto desde el punto de vista formal, la realidad es que siempre existe un factor importantísimo que no podemos controlar: el factor humano.

El factor humano es importantísimo a la hora de probar un producto, porque por muchos tests unitarios, de integración, de rendimiento o funcionales que tengamos, ¿saben realmente nuestros desarrolladores lo que están probando? Es más, ¿saben nuestros desarrolladores como funciona el producto?, ¿saben como es el interfaz de usuario?, ¿saben como se comunican los componentes?, ¿se han puesto alguna vez en la piel del usuario final? Probablemente la respuesta a todas estas preguntas sea afirmativa si estamos hablando de un producto pequeño, pero sin embargo, cuando hablamos de un equipo de cientos de desarrolladores, de productos con decenas de módulos diferentes, y de grupos de desarrollo diversos (incluso deslocalizados), entonces la respuesta será un conjunto de noes.

Una de las formas de afrontar este problema es jugar. Sí, jugar, como leéis. Dependiendo de la aplicación se podrán crear diferentes tipos de juegos. No todas las aplicaciones son "jugables". Unas lo son más que otras. Por ejemplo, si estamos creando un juego para un periódico nos será sencillo el crear un juego virtual dentro de la empresa; si estamos trabajando en un producto para invertir en el mercado bursatil, podremos crear un juego de inversión en bolsa; si estamos creando una tienda online podemos crear un juego en el que ganaría el que más compras realize, o el que más dinero gaste, o cosas así; si estamos creando una aplicación de gestión de un servicio médico, podemos premiar a los que más pacientes traten o examinen completamente, a los que más informes creen, etc. etc. En fin, hay muchísimos ejemplos, unos más sencillos, otros más complejos.

Una vez que tenemos definido el juego es importante crear el entorno de ejecución del mismo. Este entorno debería simular de algún modo el entorno de producción real. Como la carga de usuarios será menor, se debería escalar este sistema para alcanzar algún tipo de relación con la carga de usuarios esperada. En general el sistema será mucho más pequeño que el de producción, pero debería ser lo suficientemente significativo como para generar problemas que podrían aparecer en producción.

Una vez que tengamos definido todo esto, llega el momento de jugar. Pero bueno, a estas alturas estaréis pensando, pero éste realmente se piensa que la gente va a ponerse a jugar con todas las cosas que tienen que hacer. Tenéis toda la razón del mundo. Todo esto no es suficiente si no se toman algunas medidas muy importantes:

• Premios en metálico.


• El juego debe ser obligatorio.

Como apunto en la lista, el juego debe tener obligatoriamente premios, y si es posible debería haber premios en metálico para todo el mundo. Por ejemplo, en el ejemplo de la tienda, se podría ofrecer a los empleados el 5% del importe de todo lo que compren hasta un límite de 1000€; o en el juego de la bolsa, pues el 5% de las ganancias que consigan + 5€ por operación realizada hasta 1000€.

Tener premios sin duda estimulará a la gente a participar. Una opción interesante es contactar con el cliente para conseguir ese dinero en metálico. Este tipo de juegos suele atraer la atracción del cliente final, ya que muestra que existe una intención real de hacer una prueba extensiva del producto. De hecho, si el cliente final es una organización, probablemente les interese a ellos mismos realizar un juego interno posterior dentro de la propia compañía.

También es muy importante que el juego sea obligatorio. Este tipo de prácticas ofrecen una enorme oportunidad para simular el comportamiento real de la aplicación, con personas reales y en un entorno similar al entorno de producción. Por eso es tan importante que participe la mayor cantidad de personas como sea posible. Adicionalmente, este tipo de juegos sirve para que los desarrolladores se familiaricen con la aplicación, para que entiendan como funciona, para que se pongan en la piel del usuario final y se enfrenten al interfaz de usuario, para que se den cuenta ellos mismos de los diferentes problemas. En fin, son demasiado valiosas como para que no se realicen. Por ello debe obligarse a los desarrolladores (y a testers, y soporte técnico, y managers, y a todo el mundo) a participar en el juego.

La participación no tiene porque ser constante, ya que también queremos que las personas trabajen. Se pueden organizar periodos de participación durante el día, o quizás ofrecer herramientas que automatizen el juego para que no haya que estar todo el día mirando para la pantalla para ganar.

Este año, he tenido la oportunidad de participar en uno de este tipo de juegos y la verdad es que la experiencia fue increiblemente positiva, y todo el mundo coincidió en lo mismo. Son experiencias que no sólo te ayudan a aprender como funciona el producto, sino que ofrecen un enorme abanico de posibilidades a la hora de probar realmente las aplicaciones.

Me pregunto si alguien tiene expriencias que compartir sobre este tema que personalmente me parece muy interesante. Ahí queda la oferta.

Pruebas proactivas, tests de integración y equipos de tests

Hay un dicho que suele decir que un poco de prevención vale más que un mucho de curación. Personalmente, este dicho lo aplicaría al mundo de las pruebas de software para crear el concepto de pruebas proactivas.

¿Qué es una prueba proactiva? : Una prueba proactiva es aquella cualquier prueba que no tendríamos obligatoriamente que realizar pero que nos permite adelantarnos a los acontecimientos. La principal ventaja de las pruebas proactivas es que nos permiten crear software mucho más sólido previniendo problemas no esperados desde un punto de vista unitario, integracional o funcional.

Ejemplos de pruebas no proactivas serían aquellas que es obligatorio realizar para mantener un software saludable, como los tests unitarios, tests de integración o tests funcionales.

Ejemplos de pruebas proactivas pueden ser los tests de rendimiento, tests de carga y tests de integración.

Ahora bien, si miráis la lista veréis que los tests de integración están tanto en la lista de pruebas proactivas como en la lista de pruebas obligatorias. ¿Por qué? El problema es que los tests de integración yacen en el limbo de los tests.

En una empresa normalmente tenemos diferentes equipos de desarrollo que trabajan con diferentes componentes. Los desarrolladores de estos equipos tienen la responsabilidad de ofrecer componentes lo suficientemente probados a través de tests unitarios. Por otra parte, hay muchas empresas que tienen un equipo completo de testers que se encargarán de realizar todas las pruebas funcionales de cara al usuario final.

El punto más peliagudo es el de los tests de integración. Los tests de integración se encargan de comprobar que los diferentes componentes de nuestro sistema funcionan como es debido, y que interactuan como se espera dentro de sistemas que imitan al entorno de producción que nos vamos a encontrar. Nótese que la palabra integrar aquí adquiere un significado algo ambiguo y se refiere tanto a integrar dos piezas de software que se deben comunicar entre sí, como a integrar esas piezas de software en un entorno de ejecución determinado.

¿Quién hace y cómo se hacen estas pruebas de integración? Sin lugar a dudas, lo ideal es mantener un equipo de desarrollo de tests de integración que se encargue de desplegar los componentes en un sistema similar al de producción y de probar la integración de estos componentes. Aquí es donde entra la proactividad. Estos equipos de producción deben realizar el test del producto olvidándose del usuario final. Esto permite eliminar la dependencia de los casos de uso y alcanzar una cobertura mucho mayor en nuestro software, ya que incluso aunque estuviésemos cubriendo el 100% de los casos de uso definidos en la arquitectura, la realidad es que probablemente los casos de uso no estan cubriendo el 100% de las acciones que nuestros usuarios realizarán.

El problema de mantener los tests de integración orientados al usuario final es que uno no puede realmente estar seguro de que su software es sólido y fiable. Es muy común por ejemplo en los entornos de tests el realizar las pruebas de integración utilizando robots web o robots de GUI, que se encargan de simular el comportamiento del usuario final. ¿Es esto una prueba de integración real entre componentes? No. Esto son pruebas funcionales, y nunca se deberían tratar como pruebas de integración. El problema es que se tratan como tales debido a falta de presupuesto para contratar equipos de test de integración, a falta de conocimiento por parte de los equipos de testing funcional o a falta de tiempo por parte de los desarrolladores para asumir semejante carga.

En resúmen, ponga un equipo de ejecución y creación de tests de integración en su vida y será mucho más feliz :-)

Ron Jeffries sobre metodologías ágiles

En InfoQ han publicado una entrevista a Ron Jeffries que resulta realmente interesante, ya que no se limita a alabar las metodologías ágiles, sino que adopta un enfoque mucho más realista, mostrando como estas metodologías se comparan con las metodologías más conservadores, y explicando cómo si obviamos el lanzar versiones frecuentes y el probar nuestras funcionalidades el resultado puede ser mucho peor que el que se obtendría mediante un método más tradicional.

Es una entrevista no demasiado larga que se hace bastante amena gracias a las explicaciones que Ron Jeffries va dibujando en su pizarra.

Interfaces de usuario: ¿Construcción manual o automática?

En varios sitios web se ha reabierto el debate sobre si es más adecuada la construcción de interfaces de usuario a través de herramientas de generación de código, o si por el contrario es mejor elegir una aproximación más artesana y construir todo el código manualmente.

La verdad es que este es un tema recurrente sobre el que creo que cualquiera pude opinar, ya que asumo que todos los que estamos en este mundillo del software hemos desarrollado algún interfaz de usuario en algún momento de nuestras carreras, ya sea hace años cuando los Visual Basic era una revolución a la hora de crear aplicaciones, ya sea más recientemente en Java con herramientas como Matisse, o ya sea en el mundo web con los diseñadores visuales para frameworks Java Server Faces. Asimismo, probablemente todos hemos en algún momento determinado creado, o intentado crear, esas mismas interfaces de un modo manual, ya sea porque nos apetecía, porque no teníamos otra cosa a mano, o por cualquier otra razón.

Ante una situación como esta, donde cada cual tiene su propia opinión en base a su experiencia, creo que es un poco inútil el caer en discusiones sobre ésta u ésta otra tecnología es mejor, así que intentaré describir lo que en mi opinión son los tres factores más importantes a tener en cuenta, en orden de importancia, a la hora de elegir uno y otro camino:

1. Experiencia de la gente que disponemos: Lo más importante que se debe tener en cuenta es el tipo de gente con la que contamos en el equipo de UI. Y ante este punto lo más importante es ser realistas y recordar que no debemos elegir en base a nuestras preferencias si no en base a su experiencia y habilidad.
   
   Si en el equipo de UI cuento sólo con personas con poca experiencia, que no han hecho interfaces visuales previamente, o que vienen de otros lenguajes y no conocen Java, o .NET, o lo que sea, entonces en este caso no tendría demasiado sentido forzarles a programar todo manualmente, ya que les resultará muy complicado. Incluso aunque a nosotros nos parezca una tarea muy fácil, la realidad es diferente: para ellos no lo es.
   
   Por otra parte, obligar a un grupo de expertos programadores a utilizar un diseñador gráfico puede ser contraproducente, ya que estas personas pueden no sentirse cómodas con estas herramientas, pueden tener ya una serie de procesos que los hagan más productivos y el añadir una herramienta nueva puede significar reemplazar todos esos procesos por algo totalmente nuevo, y finalmente esto puede llegar a causar frustración y desánimo en el equipo.
2. Complejidad del interfaz de usuario: El siguiente punto a tratar sería la complejidad del interfaz que estamos planeando. Los diseñadores visuales suelen soportar un conjunto limitado de componentes, y en cuanto añades componentes que no esperan el resultado puede ser diferente al que no esperamos. Si nuestro interfaz va a utilizar componentes personalizados, entonces debemos plantearnos seriamente la posibilidad de utilizar una aproximación híbrida o simplemente olvidarnos de utilizar ninguna herramienta.
   
   Mediante una aproximación híbrida, diseñariamos la mayor parte de componentes con herramientas visuales y posteriormente añadiriamos los componentes propios. El punto crítico aquí es que el proceso de añadir componentes propios debe ser lo menos intrusivo que sea posible, ya que de otro modo las probabilidades de que la herramienta gráfica sea incapaz de volver a recear nuestro interfaz son muy altas.
   
   Si el número de componentes personalizados es alto; o si estos componentes personalizados se encuentran muy arriba en la jerarquía de componentes ( no es lo mismo personalizar un frame que un botón ), entonces lo mejor sera olvidar directamente las herramientas visuales.
3. Valorar entre diseñadores visuales y frameworks: Hoy por hoy los diseñadores visuales son muy potentes. Por ejemplo, en Java, hay diseñadores excelentes tanto para Swing como para SWT. Por otra parte, tenemos que de manera alternativa siempre aparecen una serie de frameworks que ofrecen un enorme valor añadido, como pueda ser JGoodies en Java (o incluso los componentes de futuros jdk que van apareciendo en java.net). La mala noticia es que los diseñadores visuales no suelen soportar estos componentes, lo que significa que si realmente necesitamos alguno de estos componentes, entonces tendremos que abandonar la idea de utilizar el diseñador.
   
   Si por el contrario, no hay ningún framework que nos ofrezca algo realmente valioso, entonces la opción de usar diseñadores vuelve a adquirir valor.

En esta lista los dos primeros puntos son excluyentes y decisivos. Si no tenemos gente experta, lo mejor es ir a las herramientas, mientras que si nuestro interfaz va a ser muy complejo y personalizado, lo mejor es ir al código manual. En caso de empate en esos dos puntos, el tercero debe decidir.

Me dejo muchos aspectos deliberadamente, porque la verdad es que este sería todo un tema para un libro. Otro aspecto importante podría ser la volativilidad del equipo. Por ejemplo, si hoy tengo un equipo muy bueno, y la gente se me va, mañana quizás un equipo menos experimentado tendrá que mantener el código del primer equipo, y en ese caso el trabajar con un diseñador visual facilita las cosas porque para los segundos les será sencillo ver lo que han hecho los primeros. Pero, por ejemplo, por el contrario, forzar a los programadores a no utilizar un diseñador, es equivalente a forzarlos a aprender como funciona una determinada API, lo que siempre es bueno porque aporta conocimiento sobre la plataforma.

En fin, sea como sea, ante todo lo más importante es ser consistente con la decisión tomada. Si elegimos utilizar una herramienta, debemos utilizarla y cuidarnos de que los interfaces se puedan seguir manteniendo con esa herramienta. Si comenzamos a crear pantallas, y posteriormente añadimos mucho código personalizado a estas pantallas, seguramente no las podramos volver a editar gráficamente. La consecuencia es que parte de nuestro interfaz gráfico se modificará con un editor y la otra parte se modificará manualmente, lo que no deja de ser un desastre.

Y para acabar me mojo. Yo prefiero no utilizar herramienta. Siempre que comienzo algún proyecto, intento empezar con alguna, pero al final acabo escribiendo todo a mano. Que se le va a hacer :)

SOA, la buzzword más despreciada

Y el ganador de la buzzword más despreciada es: SOA!



Es curioso como otra histórica buzzword como Web Services sólo acapara un 4% en el índice de desprecio. Los servicios web han pasado la barrera de buzzword a realidad, y poco a poco se van implantando. Eso sí, nada que ver con lo que nos vendían hace años.

Scrum en 5 minutos

Jeff Sutherland cuenta en su blog que normalmente utiliza en sus presentaciones un PDF creado por SoftHouse y que se titula Scrum in five minutes.

Este PDF está pensado para presentar rápidamente las bondades de Scrum, especialmente a analistas de negocio, directivos, jefes de departamento, que no tengan tiempo para asimilar todas los detalles de la metodología. El documento realizan un análisis muy visual y didáctico de las características de Scrumm, así que siempre será bueno tenerlo a mano :)

Lo importante de saber cuando ser ágil.

Uno de los peligros de las tendencias como las metodologías ágiles es que rápidamente hay gente que las aplica por conveniencia. No le ha pasado a nadie últimamente el encontrarse con algo que parece muy simple, y de pronto una persona que lo ve complicado se escuda en el "debemos hacerlo más simple como mandan las metodologías ágiles".

La verdad es que esto es algo con lo que me he encontrado varias veces, pero esta semana me ha hecho mucha gracia. Estabamos rediseñando un modelo de datos y básicamente yo promovía un modelo de datos algo más abstracto basado en interfaces y clases abstractas para intentar escudar un poco la implementación, mientras que mi compañero simplemente prefería tener implementaciones planas. Y resulta que todo esto era porque no le gustaba ver muchas clases en el entorno de desarrollo, que era un lío, que era muy fácil perderse, y que las metodologías ágiles decían que las cosas tienen que ser lo más simples posibles.

Asombrado me quedé. En fin, ante estas situaciones supongo que lo mejor es ser diplomático e intentar buscar una solución intermedia como la que encontramos, pero no me deja de ser curioso algo como esto. En definitiva, ágil no quiere decir trivial, y creo que eso es importante a la hora de diseñar sistemas.

Por suerte, al final el diseño quedó bastante bien :)

Escoge tu modelo de datos

Alguien ha estado recopilando una librería con modelos de datos para diferentes negocios y situaciones. No lo he repasado con profundidad, así que no estoy seguro de lo exactos que pueden ser. A primera vista parecen bastante genéricos sin entrar en muchos detalles concretos, pero no deja de ser algo interesante.

Ganas de probar pentaho

Pentaho es una plataforma de productos Open Source de Business Intelligence. Algunos de los productos que forman la platforma son JFreeReport, JPivot, Mondrian o Kettle. La verdad es que pentaho se está convirtiendo en el Alfresco del Business Intelligence y cada vez hay más y más gente que habla de este producto, así que cada vez me pica más el gusanillo por probarlo.

Pero bueno, la verdad es que ya no recuerdo las veces que habré bajado mondrian y jpivot y que nunca los probé. Creo que la primera fue hace dos años, cuando eran productos cuasi-abandonados. Realmente me ha sorprendido como estos dos productos han ascendido de las cavernas de sourceforge.net hasta conertirse ahora mismo en productos de moda. Lo más seguro es que fueran productos internos de algunos de los miembros de la actual pentaho y que éstos últimos decidieran dar el salto y fundar su compañía, dándole un importante acelerón al código fuente base, porque la verdad es que la diferencia en cuanto a actividad, marketing y movimiento ha sido enorme.

En fin, que habrá que probarlo tarde o temprano porque parece muy interesante. Por cierto, en TodoBI tienen tres artículos sobre el tema: Introducción a Pentaho, Pentaho 1: reporting y Pentaho 2: Análisis OLAP.

Technorati Profile