Hoy hemos comenzado un nuevo proyecto y vamos a seguir usando SCRUM. Aprovecho este comienzo para seguir hablando de estimación ágil y, durante los siguientes posts, ir compartiendo los pasos que vamos siguiendo hasta terminar toda la funcionalidad.

El primer paso fue obtener la funcionalidad usando historias de usuario y el dueño de producto ya las tenía priorizadas, así que ayer mismo se convocó al equipo de desarrollo y al dueño del producto a la reunión de planificación de todo el proyecto que ha transcurrido de la siguiente forma:

1.- El dueño de producto ha dado una visión global de lo que será todo el proyecto para que todo el equipo conociera el contexto.

2.- Por orden de prioridad ha ido leyendo cada una de las historias de usuario

3.- El equipo realiza preguntas de alto nivel, no hay que centrarse en estos momentos en pensar si una llamada se realizará usando AJAX, si se utilizará un API u otra.

4.- El equipo daba una estimación



Se supone que al final de esta reunión se iba a obtener todas las historias de usuario estimadas y las que iban a ser desarrolladas por cada sprint, esto segundo no se ha logrado. Como el equipo era nuevo no se conocía su velocidad (ej. 30 puntos de historia por iteración) hemos optado por hacer un sprint 1 y obtener esta velocidad, a partir de ahí se obtendrá un plan completo.

La pregunta ahora es: si no tenemos la gran suerte de poder probar y obtener datos del primer sprint ¿que hago?. Las posibilidades son varias: podemos usar una velocidad previa de otros proyectos, otra opción es empezar a dividir la historia de usuario ya en tareas y estimarlas en horas ideales, el equipo decide hasta donde puede llegar a implementar y esa sería la velocidad inicial que tomaríamos, por ejemplo, si el equipo dice "en el primer sprint nos comprometemos a la funcionalidad A,B,C y D" sumamos los puntos de historia y esa será nuestra velocidad. Como siempre, en el futuro veremos que va ocurriendo y re-estimaremos.

Como podéis leer, en el punto 4 el equipo estimaba usando puntos de historia, ¿cómo hemos estimado? Se suele recurrir siempre a una persona "experta" y se le pregunta pero todos estamos de acuerdo en que debe estimar aquel que va a realizar el trabajo, una técnica muy buena y ágil es planning poker, estos son los pasos a seguir:

1.- Cada participante tiene un juego de cartas con un estimador escrito en cada una de ellas
2.- Cliente/Product owner lee una historia y se discute brevemente
3.- Cada participante escoge una carta
4.- Se vuelven las cartas a la vez
5.- Se discuten diferencias
6.- Se re-estima hasta que exista convergencia


La verdad es que la estimación ha ido muy bien y mañana planificamos el primer sprint.

|

Hoy estoy muy contento, después de más de año y medio practicando Scrum para desarrollar proyectos software he recibido de la Scrum Alliance mi resultado de la evaluación realizada para ser Certified Scrum Practitioner y he superado el proceso!.

Hay bastante controversia montada en la red sobre la validez de este tipo de certificaciones, ya que con solo asistir a un curso (bastante caro) te certificas como CSM pero creo que eso demuestra que, al menos, has tenido una mínima formación para empezar.

Con esta certificación se intenta demostrar que has estado un año practicando los principios de Scrum y os aseguro que lo mio me ha costado completar el documento que hay que enviar para su evaluación, un mes después y el trabajo se ve recompensando.

Los siguientes pasos son seguir trabajando para convertirme en CST o CSC, el nivel más alto, además creo que en España soy el primer CSP.

|

Creo que todos los que nos dedicamos a esto lo necesitamos:

|

Las metodologías ágiles, como cualquier otro paradigma, necesitan de un conjunto de herramientas para apoyar la ejecución de las tareas definidas. Scrum propone tarjetas de cartón, un panel de cartulina, post-it, en definitiva, material de oficina como una posible alternativa.

Recientemente tuve la ocasión de evaluar tinypm (tiny effort, perfect management), una herramienta sencilla que facilita el proceso de desarrollo con prácticas ágiles a equipos de trabajo. La herramienta da soporte de manera directa al Backlog, User Stories, Iteraciones, Burndown chart, etc. La posibilidad de mover “user stories” de una iteración a otra, o al Backlog haciendo uso de drag & drop es muy intuitiva y se asemeja mucho al uso de tarjetas en un panel de cartulina.

En el blog asociado a la web de la herramienta tinypm, hay una entrada “Why a bug tracker is not a good tool for agile Project management” que me gustaría destacar. En dicho artículo se hace un repaso al uso del Backlog y a sus diferentes visiones dependiendo de nuestro lado en el proceso productivo. El Backlog define lo que el producto final deberá ser. El punto a tratar es cuando en el proceso de desarrollo surgen incidencias o bugs y estas son incluidas en el Backlog junto con el resto de características deseables del producto.

En mi trabajo actual utilizamos varias herramientas de “tracking” (Mantis y Trac), dependiendo del estado de desarrollo de los proyectos. El workflow del trac ha sido adaptado para poder gestionar los estados de “Pending”, “In Progress” y “Done” que propone Scrum. Para realizar el seguimiento del avance de las “User Stories” tenemos creados informes personalizados que permiten visualizar las tareas en curso.

Trac cuenta con una tipología de “Tickets” que permite flexibilizar su uso extendiendo su significado a conceptos tales como “Característica deseable”, “Característica obligatoria”, “Bug”, “Mejora”, facilitando la priorización de los desarrollos. Lo único que se echa en falta es algún mecanismo más intuitivo para la definición del trabajo a realizar por cada iteración (si bien en Trac existe el concepto de “Milestone” como una agrupación de tareas para la consecución de un hito o entregable).

En mi opinión el uso de herramientas de bug tracking (o no), no es un indicador del grado de agilidad de un equipo de trabajo. Las herramientas no dejan de ser apoyos para el desempeño de nuestra labor. Una herramienta como tinypm puede ser utilizada (mal utilizada) para medir el trabajo realizado por cada persona individualmente, en lugar de medir el avance del desarrollo de las historias de usuario.

Si alguien está interesado en la adaptación de herramientas de bug tracking puedo proporcionar más información al respecto.

|

Me he dado cuenta que tanto hablar de SCRUM y lo más básico no lo hemos tratado, aquí os dejo una presentación que utilizo para introducir a SCRUM, es una traducción y adaptación de la que hay en la página web de mountain goat software.

Scrum

View more presentations from David Doctor.

|

Antes de que se forme cualquier equipo y se comiencen a planificar las diferentes tareas hay que pasar por algo ineludible: la estimación del esfuerzo y el tiempo.

En una serie de entradas del blog me gustaría tratar técnicas de estimación, desde las clásicas como COCOMO II hasta las ágiles como planning poker, comentando cómo hemos llevado a cabo estimaciones dentro de los equipos en los que he estado trabajando.

El esfuerzo en proyectos de ingeniería civil como hacer una carretera, se puede tangibilizar en los kilómetros que se tienen que construir y el tiempo se derivaría de este esfuerzo. Por ejemplo, si tenemos que hacer 1000 kilómetros con 10 personas que son capaces de realizar 12 km al día se estima que el proyecto durará aproximadamente 83 días. En proyectos software el esfuerzo se mide en persona-día que es el trabajo que una persona es capaz de realizar en un día.

Tan pronto como el comercial de tu empresa ha "mal vendido" un proyecto ya empiezan las presiones: ¿cuánto va a costar hacer esto? ¿en cuánto tiempo lo tendréis?,quiero un plan de proyecto para entregárselo al cliente... uno se queda estupefacto ante tanta prisa y cúmulo de peticiones sobre todo porque internamente piensa "cómo puedo decir el tiempo que tardaremos si ni siquiera se lo principal: ¿qué hay que hacer?" y, cuando empezamos en esto de gestionar proyectos, nos lanzamos a la piscina por eso del que dirán y contestamos: esto estará en 3,5 meses y necesitaré a 5 personas... !craso error!

Antes de empezar a hablar de técnicas y métodos para estimar hay dos reglas que, en mi opinión, son fundamentales:

1.- Estimar significa estimar. Algo tan trivial como esto no siempre parece obvio y, sobre todo, no es fácil hacerlo entender al equipo de ventas. Si a mi me preguntan: ¿cuánto tardo en viajar de Madrid a Valencia? suelo contestar que, basándome en mi experiencia en otros viajes previos, aproximadamente entre 3,5 y 4 horas. Uno nunca sabe si va a encontrar tráfico, si va a parar a tomar un café o si el coche se va a averiar en el camino. Por eso es importante siempre dar un rango en las estimaciones y no parecer que la cifra que das no tiene ninguna incertidumbre.

2.- El rango es inversamente proporcional a la información y el momento en el que se haga la estimación, esto es, si estamos en una fase temprana o disponemos de muy poca información no nos podemos negar a dar una estimación, pero si podemos dar un rango muy amplio y viceversa, si ya disponemos de mucha información el rango puede disminuir.

Siempre me gusta esta figura, el famoso cono de la incertidumbre de Boehm donde se puede ver que dependiendo de la fase en la que nos encontremos (en el caso de un desarrollo en cascada) si damos una estimación en una fase temprana esta puede variar desde un 25% hasta un 400%.



Pongamos un ejemplo: nuestro equipo de ventas nos dice "nuestro cliente quiere un portal web para gestionar sus productos, ¿cuánto vais a tardar?", nosotros intentaremos obtener toda la información posible para, usando nuestra técnica preferida, dar una estimación. Después de reunirse el equipo se estima que el proyecto durará 10 semanas y nuestra contestación sería: entre 2,5 y 40 semanas. Las reacciones, claro está, pueden ser muy diversas, la más común sería: "hombre, vaya estimación dáis, con ese rango yo no puedo vender nada" pero nuestra respuesta debería ser: "mi grado de incertidumbre es tan grande como el tuyo, tan pronto tengamos más detalles sobre el proyecto podremos afinar más". He dicho "debería ser" porque, al final, de ese rango suelen coger los números más favorables a su venta ;-)


En este post nuestra intención era introducir que es estimar proyectos software sin entrar en detalle, una vez que sabemos que el proceso era obtener información de qué hay que hacer, aplicar una técnica y ofrecer unos resultados en las siguientes entradas del blog hablaremos de tecnicas y compartiremos ejemplos. Para los que no puedan esperar aquí tenéis el conocido método "estimación de mi jefe": si nos dicen que tiene que estar en 2 días, subid a la siguiente unidad temporal y multiplicarlo por dos. Casi con total seguridad serán 4 semanas de trabajo real ;-)

|

Después de unas semanas de vacaciones en el país de las hamburguesas y los coches grandes me voy a permitir escribir una pequeña entrada en el blog acerca de la duración que deben tener cada sprint.

Como en todo, aquí tampoco hay fórmula mágica. Comenzar una iteración requiere que, si no es la primera, se haga una demostración de la funcionalidad implementada en la anterior, se reflexione sobre lo que ha ido bien o mal y las posibles mejoras en la retrospectiva y, lo que lleva más tiempo, se planifique lo que se hará en el nuevo sprint.


Si realizamos iteraciones de 4 o más semanas el equipo puede ir perdiendo agilidad, imaginad que llega una nueva funcionalidad que debe ser incluida en el siguiente sprint de forma prioritaria, el dueño del producto debería esperar a la finalización de un sprint largo y no cubrir a tiempo esa necesidad de negocio.

En iteraciones cortas, como es obvio, puede que no se entregue casi un incremento de la funcionalidad y por lo comentado anteriomente requeriría la reunión de todo el equipo con el dueño del producto muchas veces lo que, en la realidad, no siempre es factible.

Parece que dos semanas está siendo tomado como un estándar de facto y es el tiempo que en los que he participado como Scrum Master hemos venido utilizando con éxito, hay tiempo para introducir de forma rápida nuevos requisitos y para obtener un incremento de la funcionalidad.

Si la duración puede/debe variar a lo largo de un proyecto ya es una discusión que podremos tener en un post futuro ;-)

Como siempre os pregunto a vosotros, ¿cuál suele ser la duración del sprint que soléis utilizar? esperemos tener más participación esta vez :-D

|