Ene 16 2009

Niveles de decisión

Categoría: Equipos, GestiónJuan @ 9:20 am

Cuando hablamos de organizaciones ágiles, métodos, etc., siempre suele haber distintos temas que aparecen regularmente en la conversación: integración continua, TDD, automatización, test unitarios… Sin embargo, cuando alguna metodología ágil es introducida en una organización normalmente hay confusión sobre que debería ser obligatorio y qué debería ser recomendado y quién debería promocionar o incluso exigir las nuevas prácticas o ideas. ¿Deberían ser la compañía per sé, los equipos, los gerentes (jefes de proyecto, dueños de producto…), etc.?

En mi opinión nada es blanco o negro y siempre hay muchos niveles de grises en el medio:

  1. Hay ciertas prácticas obligatorias que deberían ser decididas a nivel de compañía por alguien con suficiente poder de decisión al hablar de este nivel. Estas prácticas deberían ser seguidas por todo el mundo y los equipos o los individuos no deberían discutir sobre ellas. Por ejemplo, el uso de una herramienta de control de código (SVN, CVS, GIT, etc.) para cualquier proyecto de desarrollo de software. No creo que nadie esté en desacuerdo con la obligatoriedad de esta herramienta al desarrollar software. En mi opinión, lo mismo debería pasar con la integración continua, los test automáticos y un sistema de control de errores.
  2. Otras prácticas deberías ser decididas por el gerente de un producto aunque la idea pueda venir de abajo a arriba. En esta categoría, la decisión es tomada por el gerente ya que su decisión afecta a todo el producto (y no sólo un equipo si hay varios equipos trabajando para el producto) Esta persona debe decidir basándose en el esfuerzo que supondrá para los equipos, tiempo, coste, calidad, etc. En esta categoría se encontraría, por ejemplo, el configurar los equipos por componentes o por funcionalidades, la definición de aceptación, etc.
  3. Muchas otras son decididas por el equipo y no deberían ser impuestas por los gerentes o la empresa. Los gerentes puede pedir objetivos a más alto nivel (tener algo listo para producción al final de una iteración, ningún error abierto entre iteraciones, etc.) El equipo decide sus propias prácticas en base a estos requerimientos a lo que considera importante a la hora de producir software. El equipo decide la definición de hecho para sus tareas, si deben usar o no TDD. Si deben hacer UT para todo el código o sólo para las partes más importantes, trabajar por pares o no o cuando hacerlo, hacer revisiones de código sistemáticas, por relevancia o no hacerlas… El equipo debe darse cuenta por si mismo como llegar a ser (reflexionando sobre sus propios errores) un equipo excelente sin ser dirigido o impuesto en “como hacerlo” por el gerente.

Etiquetas: ,


Dic 15 2008

Poker para estimar el “valor de negocio” de las historias

Categoría: GestiónJuan @ 9:31 am

Jugar al poker para estimar la implementación (y las pruebas, no lo olvidemos, además de lo que ponga en la defición de “hecho”) es algo conocido en los equipos que siguen alguna metodología ágil. Sin embargo, lo que no he visto, es utiliarlo para estimar el valor de negocio de las historias (o requerimientos) o, lo que es lo mismo, su prioridad para ser implementadas desde el punto de vista del negocio.

En este escenario nos encontraríamos al dueño del producto jugando al poker con el scrum master (que también podréa ser un moderador o facilitador en lugar de jugardor), alguna persona de marketing y/o ventas, algún otro dueño de producto, etc.

Como en el poker de planificación, se escoge una historia que serviría de base para las comparaciones y se le da un valor intermedio (por ejemplo 20). Las demás historias serían estimadas en comparación con esta historia base. Una vez que los jugadores han enseñado sus cartas (todos a la vez) y si hay una gran diferencia de estimación, los valores más alto y más bajo explican a los demás el porqué de su estimación. Después de esto se hace un nuevo turno y se estima de nuevo teniendo en cuenta las explicaciones. Una vez que los valores convergen se escoge ese valor como prioridad para esa historia.

No olvidemos que estamos estimando prioridades en lugar de tiempo de implementación.

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 27 2008

La declaración de interdependencia

Categoría: Gestión, PrincipiosJuan @ 8:17 am

El manifiesto de la anotación anterior es muy conocido con poco que se esté metido en el mundo de las metodologías ágiles, sin embargo, el DOI o “La Declaración de Interdependencia” es, en muchos casos, un gran desconocido.

Este manifiesto se firmó en el 2005 por un grupo de jefes de proyecto, gerentes y expertos incluyendo dos de los autores originales del “Manifiesto por el desarrollo ágil del software“. Este manifiesto, al contrario que el anterior, está más enfocado a la gestión ya que la idea original era extender el manifiesto por el desarrollo ágil de software a productos que no fueran solamente software, a gestión de proyectos en particular y a gestión en general.

Como el anterior, la traducción es mía y seguro que no está libre de errores. Espero que me los perdonéis.

————————————–

Somos una comunidad de jefes de proyecto con mucho éxito a la hora de entregar resultados. Para alcanzar estos resultados:

  • Incrementamos el retorno de la inversión enfocándonos en tener un flujo continuo de valor.
  • Entregamos resultados fiables involucrando al cliente frecuentemente y compartiendo la propiedad del proyecto.
  • Esperamos incertidumbre y la manejamos mediante iteraciones, anticipación y adaptación.
  • Dejamos correr la creatividad y la innovación reconociendo que los individuos son la última fuente de valor y creando un entorno de trabajo donde puedan marcar la diferencia.
  • Fomentamos el rendimiento a través de la responsabilidad compartida en los resultados y en la efectividad del equipo.
  • Mejoramos la efectividad y la fiabilidad mediante estrategias, procesos y prácticas específicas para cada situación.

[David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith y Robert Wysocki.]

————————————–

El manifiesto original en inglés lo podéis encontrar en http://pmdoi.org.

Etiquetas:


Ago 26 2008

Manifiesto por el desarrollo ágil del software

Categoría: Gestión, PrincipiosJuan @ 2:58 pm

Aquí tenéis el manifiesto por el desarrollo ágil del software que fue firmado en el 2001. Es una traducción mía, así que ateneros a las consecuencias ;-). Quedáis avisados.

————————————

Estamos descubriendo mejores formas de desarrollar software haciéndolo nosotros mismos y ayudando a otros. A través de esta experiencia, hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software que funciona sobre documentación exhaustiva

Colaboración con el cliente sobre negociación de los contratos

Respuesta al cambio sobre seguir un plan

Esto es, aunque los elementos de la derecha tienen valor, nosotros valoramos más los elementos de la izquierda.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

————————————

Fuente original en inglés: http://www.agilemanifesto.org

Etiquetas: