Mayo 05 2009

¿Cómo debió ser el Desarrollo en Cascada?

Categoría: MetodologíasJuan @ 2:09 pm

Sí, lo admito, todo este tiempo y todavía no había leído el artículo al que se le da la autoría del llamado “desarrollo en cascada”. Hasta hace un par de días.

El artículo en cuestión se titula “Managing the Development of Large Software Systems” y su autor es el Dr. Winston W. Royce. Este artículo, como se ha dicho anteriormente, es el que se toma como el origen del desarrollo en cascada aunque este nombre no se menciona en el artículo y está citado más de 1200 según el Sr. Google.

Para mi asombro, el artículo es muy diferente de lo que esperaba porque en realidad NO propone el desarrollo en cascada (tal y como lo conocemos) como la panacea para el desarrollo del software sino que el autor lo presenta en la primera mitad del artículo como un acercamiento grandioso. Sin embargo, después, el autor trata de encontrar sus problemas y dar soluciones en la segunda mitad.

Waterfall model

-fuente: http://en.wikipedia.org/wiki/File:Waterfall_model.png-

Por ejemplo, el autor dice cosas como las que siguen sobre el típico desarrollo en cascada (ver imagen):

I believe in this concept, but the implementation described above is risky and invites failure.
[Creo en este concepto, pero la implementación descrita más arriba es arriesgada e invita al fallo.]

o esta otra

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required.
[El cambio requerido en el diseño es probablemente tan perjudicial que los requerimientos en los que se ha basado el diseño y los que proporcionan el fundamento de todo son violados. O los requerimientos deben ser modificados, o un cambio substancial en el diseño es requerido.]

… entre muchas otras.

Royce hace visible algunos de los problemas que tiene el desarrollo en cascada y da soluciones para mejorar el proceso en lo que queda de artículo (segunda mitad). Resumiendo y siendo muy breve, el autor da cinco pasos o mejoras para atajar los problemas. Éstas son:

  1. Incluir una etapa de diseño del programa entre las fases de requerimientos y análisis.
  2. Documentar mucho y bien.
  3. Hacerlo dos veces (iterar el proceso siendo la primera iteración una simulación)
  4. Planificar, controlar y monitorizar las pruebas. Es decir, poner énfasis en la calidad.
  5. Implicar al usuario. Royce, además, dice que la implicación debe ser formal, profunda y continua.

No sé qué os parece a vosotros pero el punto 3 y el 5 se han quedado por el camino (y en muchos casos el 4 que es lo primero que se recorta si se va ajustado de tiempo) y estos, precisamente, ¿no os recuerdan a algo? :-)

Recomiendo que leais el artículo original si podéis y tenéis tiempo. Realmente merece la pena.

Etiquetas:


Dic 04 2008

Metodologías ágiles y cultura

Categoría: Equipos, MetodologíasJuan @ 10:43 am

Todas las metodologías ágiles proponen la interación y comunicación directa entre los miembros de un equipo. La idea es que es mucho mejor discutir cara a cara que por correo electrónico, por ejemplo.

Por esto, estas metodologías hablan de usar pizarras, post-its, notas de colores, grandes espacios para diseñar, escribir, dibujar, etc., dónde el equipo pueda, directamente y sin el uso de ordenadores o herramientas, interactuar y comunicarse de tú a tú.

Centrándome en Scrum específicamente, la misma idea viene con las reuniones diarias, las restrospectivas (que no nos únicas de scrum, que quede claro) con sus distintos métodos y juegos para hacer hablar, dialogar y discutir a la gente sobre problemas. Étcetera.

Ahora bien, ¿qué pasa si la tendencia general en un equipo es el ser tímido o más introvertido de lo deseable para estos métodos? Si la gente no habla tanto como se desearía, si no interaccionan tanto como se espera porque no se sienten agusto con este tipo de métodos extrovertidos, ¿se fuerza a la gente a ser como no es o se cambian los métodos?

Ahora mismo trabajo con un equipo donde la mayoría de los integrantes (todos menos uno) son muy introvertidos. Hablan lo justo y necesario y sólo si tienen algo que decir que crean que es realmente importante, si no es así… silencio. Me cuesta sudor y lágrimas el que tengan una discusión fluida, que se expresen en el “daily scrum” (reunión diaria de 15 minutos donde se dice qué se ha hecho desde la última reunión, que se va a hacer hasta la próxima y si hay algún problema) o que en una retrospectiva sigan los “juegos”.

Hablando con ellos uno a uno sobre esta situación, preguntándoles el porqué, cómo mejorarlo y que sugerencias tienen al respecto, uno de los miembros del equipo me dijo algo parecido a lo siguiente, lo cual me hizo pensar mucho en cómo es scrum: “[…] encuentro las reuniones útiles y no quiero que desaparezcan, sin embargo, no entiendo por qué no puedo estar en silencio si no creo que tenga nada que decir. Sé que hay que participar e iteractuar pero yo soy como soy y si no encuentro algo considerable que decir prefiero quedarme en silencio. Lo siento pero es mi forma de ser y no creo que pueda cambiarla […]”

En el OOPSLA de este año participé en un seminario sobre metodologías ágiles y cultura. Una de las tesis en ese seminario fue que hay que tener en cuenta que scrum tiene una cultura específica detrás (no hay que tomar “cultura” como “cultura nacional” solamente) y que en su invención esta cultura tuvo mucha influencia. Además, su forma original está enfocada a este tipo de cultura también debido a esta influencia. Por tanto, aplicar directamente scrum (o forzar su forma original) sin tener encuenta la cultura a la que va destinado puede ser una catástrofe y no funcionar en absoluto.

La pregunta ahora es, ¿cómo adaptar scrum o qualquier otra metodología a este tipo de equipos sin quitar el “jugo” de la metodología en sí? La respuesta no la sé, por desgracia, aunque estoy experimentando con varias ideas que darán sus frutos o serán una catástrofe (la persona que lleva la retrospectiva se rota para que cada uno de su “visión” o “forma”, que el scrum master tome un rol más activo en los meetings diarios…) Hay que esperar y ver qué pasa. ¿Tenéis vosotros alguna idea?, ¿habéis visto o estado en esta situación?

Antes de acabar quiero dejar claro también que, por supuesto, los miembros del equipo tienen que poner también de su parte para que esto funcione. No es sólo o la metodología o el equipo. Son los dos. Los dos tienen que adaptarse el uno al otro ya que es una relación bidireccional (o así lo veo yo)

Etiquetas: ,


Sep 16 2008

10 maneras de joderla con Scrum

Categoría: MetodologíasJuan @ 2:18 pm

Un buen resumen de como hacerlo mal con (o a pesar de) Scrum. Traducción libre de la presentación (en inglés) de Henrik Kniberg en la conferencia Agile 2008 de Toronto, como siempre, mil perdones si algo está del todo bien traducido. Por cierto, aunque no entendáis inglés, mirad la presentación, ¡los dibujos son geniales! Nota. Cualquier herramienta puede ser mal empleada.

  1. Creer en lo que está de moda.
    • Creer en magia.
    • No estar dispuesto a cambiar.
    • Tirar a la basura cosas que funcionan.
    • Enfocarse demasiado en la perfección del proceso.
    • Intentar hacerlo todo perfecto desde el principio.
    • Echar las culpas al mensajero.
    • Enfocarse en las herramientas.
    • Enfocarse en las cuestiones equivocadas.
  2. Definición de “hecho”.
    • No existe.
    • No se le hace caso.
    • Esta fuera del control del equipo.
  3. Velocidad.
    • Se desconoce.
    • No se usa.
    • Se usa mal.
    • Punto muerto.
    • Se miente en la velocidad.
    • Velocidad que sube y baja.
  4. Retrospectiva.
    • No existe.
    • No deriva en propuestas concretas de mejora.
    • Los cambios no se ejecutan o se evalúan.
    • Gente innecesaria en la reunión.
    • Miembros del equipo o el dueño de producto no aparecen en la reunión.
    • El equipo se penaliza por malos cambios.
  5. Compromiso del equipo.
    • El equipo está bajo presión.
    • El equipo no se sienta junto.
    • El equipo no aprende.
    • Siempre se estima a lo bajo.
    • Siempre se estima a lo alto.
    • La velocidad es 0.
    • No hay tiempo libre.
  6. Endeudamiento técnico.
    • Se almacena.
    • Se ignora.
    • Arreglar el producto pero no los procesos.
    • Se reescribe el código “a lo bruto”.
  7. Trabajo en equipo.
    • Roles fijos.
    • Pilas de tareas personales.
    • Los miembros del equipo no se ayudan entre ellos.
    • Incentivos de empresa personales.
    • Todas las historias se implementan en paralelo.
    • Interferencias desde los gestores/jefes.
  8. Pila de producto y dueño de producto / cliente.
    • La pila de producto no existe.
    • La pila de producto no es visible.
    • Historias enormes o que nunca acaban.
    • El dueño del producto no tiene conocimientos o poder.
    • Conflictos entre varios dueños de producto.
    • La pila de producto no es mantenida por el dueño del producto.
    • El dueño de producto se sorprende en la demo de la iteración.
    • El dueño de producto es el cuello de botella.
    • El dueño de producto no prioriza.
  9. Miedo a enviar el código al repositorio.
    • No existe una rama para “hecho”.
    • No hay políticas de creación de ramas.
    • No se integra frecuentemente.
    • No se toman responsabilidades.
    • Ocultación bajo las ramas (?).
  10. Pila de iteración / lista de tareas.
    • No existe.
    • Muy alejada del equipo.
    • Demasiado complicada.
    • No usada durante la reunión diaria.
    • El propietario de la pila no es el equipo.
    • No hay gráfica de horas empleadas/restantes.
    • No es actualizada a diario.
    • Las señales de peligro son ignoradas.

En la presentación, hay una frase con las que estoy completamente de acuerdo (¡y más!) y que he repetido muchas, muchas veces. Es la siguiente:

No se puede tener una compañía ágil sin prácticas de software ágiles

Etiquetas:


Sep 11 2008

Video, cascada vs. ágil

Categoría: Metodologías, VideosJuan @ 8:18 am

Una pena que este video esté sólo en inglés :-( pero para aquellos que lo entiendan merece la pena verlo.

Es entretenido, graciosillo y un buen resumen/comparacíon entre las metodologías en cascada y las ágiles. Además, la musiquilla es pegadiza.

Etiquetas: ,


Sep 08 2008

Dinero por nada y lista de comprobación para Scrum

Categoría: Gestión, MetodologíasJuan @ 12:07 pm

Leyendo y leyendo bitácoras encontré esta entrada en la siempre interesante Navegapolis que habla sobre una cláusula para los contratos llamada “dinero por nada” además de la lista “Scrum con el culo” (sí, sí, como suena).

Ni lo voy a decir mejor ni lo voy a traducir igual de bien que Juan Palacios, el autor de Navegapolis, así que espero que os leáis su entrada sobre el tema. Sin embargo, para aquellos que puedan leer la lengua de Shakespear, os dejo la presentación original de Jeff Sutherland para la conferencia Agile 2008 que tuvo lugar en Toronto.

Scrum con el culo se basa en una lista de comprobación para equipos Scrum creada en Nokia y NSN (Nokia Siemens Networks) por Bas Vodde con el cual tuve el gusto de trabajar ya que, por aquel entonces, yo también trabajaba para Nokia (que luego paso a ser NSN). De hecho, uno de aquellos equipos en transición a Scrum era el equipo del que formaba parte y que, espero, no puntuó como “con el culo” al pasarle el test :-D

He de añadir, no obstante, que en este test echo en falta alguna aclaración como, por ejemplo, ¿qué debemos entender por “buenos requisitos”?, ¿o por “buenas historias de usuario”? Si no está especificado, cada uno puede tener una visión muy distinta de lo que es un “buen requisito”, por decir algo.

Etiquetas: ,


Ago 25 2008

Material sobre metodologías ágiles en español

Categoría: Manuales, MetodologíasJuan @ 2:22 pm

Sigo dándole vueltas al tema de los idiomas que viene de la anotación anterior…

Hay mucha información sobre metodologías ágiles en inglés pero en español es todo lo contrario. Una pena. Como creo que ya he dicho anteriormente (y si no es así, lo digo ahora), una de las ideas que tengo con esta bitácora es acercar las metodologías ágiles al mundo castellano parlante. Ya sé que mucha gente habla inglés muy bien y que esto no es o no debería ser un problema pero la realidad es otra. Muchas personas en este mundillo tienen el inglés como una barrera y por esto creo que es muy buena idea el traducir (como Ángel Medinilla o Alejandro Sierra han hecho generosamente, ¡gracias!) o escribir sobre este tema en español.

Esta entrada intenta ser una recopilación de manuales y demás información en español sobre las metodologías ágiles para todos aquellos que quieran iniciarse o saber más sobre metodologías ágiles.

En general; introducción:

Sobre Scrum y XP (Programación Extrema), tenemos las siguientes:

La información sobre Scrum no está del todo mal y se encuentran bastantes cosas por ahí, sin embargo XP, Lean, Crystal, etc., no son fáciles (o imposible) de encontrar en español más allá de lo más básico.

Si sabéis o encontráis algún buen manual hacédmelo saber y lo añadiré a esta lista actualizando la anotación.

Etiquetas: ,