Postmortem: estimaciones y creación del sprint backlog
sábado, 18 de abril de 2009

Estamos cerrando el último proyecto, una aplicación de gestión de datos con múltiples perfiles que controlan el trabajo y la información introducida por los demás. Acaba de entrar en explotación con bastante éxito: ni un error en los cuatro primeros días de uso, fundamentales porque corresponden con una primera fase que tiene un plazo límite. A partir de ahora, mantenimiento correctivo y algo de evolutivo.
Es un buen momento para comenzar el postmortem y analizar los errores cometidos.

Hemos usado Scrum como metodología, y la conclusión es que nos ha aportado tan poco como cualquier otra metodología que hubiésemos usado, pero al menos no ha molestado. No creo que nos haya aportado un auténtico valor, pero creo que estamos en el buen camino. El gran reto que teníamos para el desarrollo del proyecto era el uso de una pila de desarrollo nueva para casi todos, y contra eso no hay metodología que valga.

El product backlog se hizo a partir de las reuniones de contacto con los usuarios y de los primeros documentos de prototipado y requisitos que nos pasaron. Hasta ahí, bien, no es un artefacto que tenga mayor complicación.

Para estimar el product backlog hicimos planning poker con el equipo, tras haber contado de qué iba el proyecto. A todas luces la estimación era muy optimista, y se cumplió aquello de que los técnicos son positivos y que los gestores son pesimistas. Sin que sirva de precedente, los gestores tenían razón. Sin embargo, creo que si el mismo equipo volviese a comenzar el proyecto sí cumpliría las estimaciones que salieron de esa reunión. La experiencia en la tecnología y una mejor gestión de los requisitos habrían hecho que se hubiese podido implementar en los tiempos dichos.

Creo que nuestro gran error desde el punto de vista de la metodología fue la creación del sprint backlog. Lo hizo una persona (yo, como Scrum Master). Gran equivocación. Lo debe hacer el equipo en conjunto. El equipo careció de una visión global del proyecto, lo cual no trajo más que problemas:

  • Se adquirieron tareas en el orden incorrecto.
  • No se sabía qué era común y qué no, así que era más difícil organizarse para la reutilización.
  • "Marchas atras" por mala comprensión de las tareas.
  • Funcionalmente se depende del criterio de una única persona.
  • La estimación de las tareas habría sido más acertada con un mejor conocimiento del problema.
  • ...
Ya en un plano más técnico, otra fuente de problemas iniciales fue la ausencia de un modelo de entidades del que partir. Se pretendió hacer de forma totalmente incremental, exprimiendo al máximo la generación del modelo de datos de Hibernate a partir de las clases. En los anteriores proyectos, como ya he comentado, se nos imponía que un analista crease el modelo de datos, y que eso se tomase como base para comenzar el desarrollo. El extremo contrario tampoco es útil:
  • No es una tarea trivial, y es poco tolerante a errores. No pasa nada si haces mal un campo en una pagina, pero un error en el modelo de entidades puede tener consecuencias bastante dramáticas. Hacerlo exige un conocimiento profundo de los requisitos.
  • Una equivocación de una persona puede tener un desagradable efecto de malentendidos de los requisitos en cadena.
  • No es fácil compartimentar inicialmente para que la gente pueda trabajar independientemente.
Para la próxima...
  • El product backlog lo hará el Scrum Master como esta vez, antes de la primera reunión (tampoco tiene sentido movilizar a más personas para él).
  • En el sprint meeting el sprint backlog se hará entre todos los miembros del equipo. En vez de llevar a la reunión el sprint backlog prefabricado, leerlo, y estimar a partir de esa lectura, se generará durante ella, y tras la creación de cada tarea se hará la estimación de la misma. Sí, nos llevará mucho más tiempo, pero no será perdido, sino invertido.
  • En caso de tratarse de una aplicación de gestión, probablemente durante el propio sprint planning se hará un modelo de entidades (entidades del sistema y su relación entre ellas, sin necesidad de entrar a nivel de propiedad). Algo muy básico, pero que permita tener un punto de arranque común y afianzar los requisitos. Eso sí, me mantengo en la opinión de que con Hibernate ya debemos trabajar en términos de entidades y no de tablas.

Enviar a

Posted by Juan Ignacio Sánchez Lara 10:10 Enlaces a esta entrada  

Etiquetas: , , ,



Java en Google App Engine
miércoles, 8 de abril de 2009

Hasta ahora el hosting accesible (gratuito o de precios ajustados) era territorio dominante de la plataforma LAMP (Linux + Apache + MySQL + PHP) o derivados. Este ha sido uno de los factores determinantes de la proliferación de herramientas open source para foros, blogging, etc.
Por el contrario el mundo empresarial está copado, también en gran parte, por Java (aunque sitios como Flickr o Yahoo! demuestran que PHP es un sistema que no tiene que limitarse a eso, pero este es otro tema).
Hoy Google ha anunciado la disponibilidad de Java en Google App Engine. Además, con soporte para JPA. Por fin hay una alternativa real al LAMP (¡ojo, que no tiene nada de malo, pero las alternativas siempre son buenas!).

Enviar a

Posted by Juan Ignacio Sánchez Lara 15:11 Enlaces a esta entrada  

Etiquetas: , ,

Suscribirse a: Entradas ( Atom )