Una vez que se han estimado las historia de usuario (al menos las más prioritarias) ya nos podemos reunir en una reunión de planificación del sprint, en nuestro caso real sería la planificación del primer sprint, el Scrum master convoca a las siguientes personas:

1.- Product owner
2.- Equipo de desarrollo

El orden de la reunión que hemos seguido nosotros es la siguiente:

•11:30 – 11:45. El product owner establecerá la meta del primer sprint y resumirá el product backlog. Se propondrá el lugar, fecha y hora de la demo.

En este caso el dueño de producto nos ha leido las historias más prioritarias y se establece la meta, suele ser una frase corta, en nuestro caso "Permitir búsquedas básicas de fondos de inversión"


•11:45 – 12:00. Se clarificarán las historias de usuario más prioritarias

Se realizan todas las preguntas necesarias al dueño de producto para aclarar dudas y pidiendo más detalles. Lo bueno de las historias de usuario es que permiten,sobre todo, hablar al equipo completo en lugar de leer grandes documentos o, lo que es peor, no tener nada para leer.En la siguiente imagen podemos ver al scrum master y el product owner comentar las historias y sus prioridades.



•12:00 – 12:45. El equipo selecciona las historias que serán incluidas en el sprint.


En nuestro caso como no conocíamos velocidades previas, se seleccionarán aquellas que el equipo considere capaz de realizar en dos semanas que dura el sprint.


•12:45 – 14:00. Se seleccionará la fecha y lugar del daily scrum meeting y las historias serán descompuestas en tareas. Estimación de las tareas en horas ideales.

Aquí podemos ver la funcionalidad comprometida por el equipo y las tareas preparadas para ir al taskboard junto con el burndown chart:



La semana próxima comenzamos el primer sprint y, tan pronto tenga tiempo, actualizaré el blog, creo que es muy buena idea ir mostrando nuestra experiencia casi como un reality show ;-)

|

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.

|

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

|

Leyendo lo que Roberto nos dice en su post "Preparados para ser ágiles" me ha venido a la cabeza algún que otro problemilla que hemos sufrido en proyectos cuando algún director, al finalizar un sprint, pregunta: y bien, ¿cómo va el avance del proyecto? ¿qué tal ha ido esta iteración? quiero un pequeño informe para ir tomando decisiones. Mi respuesta inicial fue: lo mejor que puedes hacer es acercarte al panel de tareas, echarle un vistazo al burndown chart y al release burndown chart, con esto podrás contestar todas tus preguntas.

Esta respuesta te puede servir por primera vez pero al final te siguen pidiendo, iteración tras iteración, alguna forma menos pesada (para ellos) de tener datos, al final yo pensaba: "ya estamos volviendo a la burrocracia innecesaria. Esto no es nada ágil, si la información está ¿por qué tenemos que reproducirla en otro formato?"

Finalmente, después de leer un buen libro (Agile estimating and planning) tome prestada una pequeña idea de Mike Cohn presentando al final de cada sprint un resumen.

Os muestro un ejemplo donde he eliminado algunos datos "confidenciales" con algún borrón que otro ;-)


La primera sección comienza con una explicación del contexto del sprint: indicamos fecha de inicio, fin, número de días laborables y el personal que ha participado.

Si os fijáis en la última tabla se ponen días planificados vs. días trabajados, mostrará si una persona estuvo al 100% asignada, si estuvo enferma, etc. esto ayudará a dar explicaciones de qué ocurrió en la iteración.





La siguiente sección mostrarán gráficos muy útiles: burn down chart y un gráfico de barras de la velocidad de las últimas iteraciones, junto con la media.


Finalmente, siempre siempre me gusta poner una valoración del sprint donde indicaremos que historias de usuario fueron incluidas y los puntos que realmente han ganado.


Si os digo la verdad este tipo de informes, que a mi me llevaban 40 minutos, ayudó a la dirección de la empresa a ver un estado del proyecto y a mi mismo para tener datos históricos del equipo que en el futuro nos ayudaría a mejorar. Y vosotros, ¿usáis algo parecido? sería muy interesante si alguien comparte su experiencia.

|

Las metodologías ágiles se postulan como una respuesta adecuada a las necesidades actuales (rápidez, adaptación al cambio, flexibilidad) en el desarrollo de software. Leyendo y revisando sobre estas metodologías, especialmente SCRUM, me ronda por la cabeza una idea que comparto en este artículo: ¿estamos preparados para ser ágiles?.

Si explicamos las bases y el funcionamiento de SCRUM a cualquier persona (recomiendo realizar el "experimento" con alguien no relacionado con la informática) su primera reacción será la de preguntarnos por qué buscamos nombres complicados ("Product Owner", "Sprint", "Backlog") a algo que parece de sentido común. El método propuesto, las figuras y roles que participan, la filosofía de trabajo y la relación entre todas las partes (clientes, equipos de trabajo, partes interesadas "stakeholders") son simples de entender. Si me apuras, diría que también son simples de aplicar. La primera vez que leí sobre SCRUM tuve la tentación de pensar que, de alguna manera, ya había aplicado algunos de sus principios a los proyectos en los que había participado.

Tenemos en nuestras manos una metodología como SCRUM que no necesita de grandes tecnicismos, que facilita la colaboración y comunicación entre clientes, ingenieros, comerciales, directivos, entonces, ¿por qué volvemos a las metodologías tradicionales, a lo ya conocido, cuando las cosas se ponen difíciles?, ¿estamos realmente preparados para aplicar las metodologías ágiles, independientemente de la situación del proyecto?. Mi opinión es que el planteamiento de las metodologías ágiles lo asumimos sin ningún esfuerzo por bueno. La estructura de una gran mayoría de las empresas cuentan con una organización (departamentos, áreas, responsables de departamento, comités de evaluación,etc) y asignación del personal en múltiples proyectos que impide la implantación de SCRUM o de cualquier otra metodología ágil. En otras ocasiones la dificultad viene de las personas que participan en el proyecto, asumir responsabilidades, disciplina, compromiso en realizar lo que he dicho públicamente que voy a hacer, parece que no es tan fácil.

Me interesa saber si, ¿realmente estamos preparados para ser ágiles?.

|

Cuando comencé a utilizar por primera vez Scrum me planteé utilizar alguna herramienta donde se pudieran ir creando historias de usuario, tareas, etc. ya que colocar un panel de control dentro de la oficina se planteaba complejo. Algunas herramientas disponibles requerian sencillamente de un servidor web, un poco de tiempo y que cada uno fuera actualizando sus tareas actualizando la herramienta.

Hay algunas gratuitas con un número limitado de usuarios como Tiny pm (http://www.tinypm.com/) que automáticamente iban actualizando el burndown chart y liberaban al Scrum Master del trabajo más "burocrático".

Finalmente decidí probar lo que parecía algo mucho más artesanal y logré que nos dejaran usar una pared en la sala donde realizabamos el daily scrum meeting , pusimos algunas cartulinas, los tipicos carteles de "para hacer, en progreso y hecho" y toda la información se actualizaba a diario, creo que si hubieramos usado alguna herramienta al final me hubiera tocado a mi ir actualizando todo a la vez que el equipo hablaba y lo mejor de todo es que todo el mundo, independientemente de si pertenecía al proyecto o no, veía el grado de avance.

Después del exito de las cartulinas, los post-it, las historias de usuario en tarjetas de cartón me decanto por seguir usando las manualidades en lugar de una herramienta, por lo menos para proyectos donde no haya equipos distribuidos, ¿y vosotros?.

Aquí os muestro algunos ejemplos de nuestro panel, decidimos usar inglés para que las etiquetas no fueran gigantescas ;-) a ver que os parece

taskboard antes de comenzar el sprint 1

etiquetas con nombres y burndown chart

|

Para inaugurar este blog plantearé la primera entrada con una pregunta que seguramente nos hemos/han hecho alguna vez: ¿debe el Scrum Master rotar entre los diferentes miembros que componen el equipo?.

No pretendo sentar cátedra y establecer una regla para seguir "a pies juntillas", mi intención es dar una visión desde las experiencia y mostrar un caso con datos reales para que sea el lector el que pueda sacar sus propias conclusiones.

Desde la teoría se indica que el Scrum Master es responsable del proceso de Scrum y de eliminar impedimentos (visibles y no visibles) por lo que podemos deducir que la función puede rotar entre cualquiera de los miembros del equipo, no obstante ¿es compatible eliminar impedimentos y formar parte del propio equipo? ¿se enfocará el Scrum Master en ayudar imparcialmente a todos los miembros o dará prioridad a sus propios problemas? ¿es adecuado que gente inexperta pueda ser Scrum Master? para intentar responder a estas preguntas voy a presentar un proyecto ficticio con datos reales de una experiencia previa.

Imaginemos un proyecto cuyo principal objetivo es realizar un sistema on-line de búsqueda y reservas de hoteles, se forma un equipo con 4 personas y el Scrum Master, después de la recopilación y priorización de la historias de usuario por parte del product owner,se realiza una planificación de lo que supondrá la primera release del producto, se planifican 5 sprints para implementar funcionalidad deseada.

El equipo realiza un primer sprint que servirá para determinar la velocidad inicial del mismo y poder planificar el resto del proyecto, los datos obtenidos por el equipo son los siguientes:

• Sprint #1
  
• duración del sprint: 2 semanas
  
• velocidad: 24 story points

Después de la retrospectiva mantenida el equipo observa que es la primera vez que trabajan juntos e introducen una serie de mejoras del proceso con objeto de obtener más puntos en la siguiente iteración, tras el segundo sprint los resultados son los siguientes:

• Sprint #2
  
• duración del sprint: 2 semanas
  
• velocidad: 29,5 story points

Después de 2 sprint, 4 semanas de desarrollo y 2 demos el cliente se muestra muy satisfecho con los resultados, el equipo motivado pero alguien decide y que el rol debe rotar entre los diferentes miembros del equipo, comenzando el sprint 3 cuyo Scrum Master sería un miembro con un año de experiencia en desarrollo de software y 0 con Scrum, los resultados fueron los siguientes:

• Sprint #3
  
• duración del sprint: 2 semanas
  
• velocidad: 21 story points

En la retrospectiva del sprint 3 muchos se quejaron de que nadie atendía sus impedimentos ya que el scrum master también estaba participando como desarrollador y se encargaba de forma prioritaria en eliminar sus problemas.Para el sprint 4 el siguiente Scrum Master que se prestó voluntario fue un integrante recien llegado a la empresa y el equipo obtuvo estas métricas:

• Sprint #4
  
• duración del sprint: 2 semanas
  
• velocidad: 9 story points

Para que nos hagamos una idea de la evolución del proyecto nos podemos fijar en el product burndown chart (ver figura 1)

figura 1: product burndown chart

Supongo que después de ver que los experimentos mejor hacerlos con gaseosa, se decidió que el Scrum Master que había comenzado el proyecto continuara obteniendo un quinto sprint con una velocidad de 30 story points.

Con estos datos reales podemos concluir que, cuando se está implantando SCRUM por primera vez en una empresa o se compone el equipo es muy importante que el Scrum Master tenga un mínimo de experiencia y quizás después de unos meses, cuando el equipo conozca bien el proceso, puedan asumir estas funciones. También comprobamos que si una persona es Scrum Master y miembro del equipo a la vez puede que priorice la solución a sus propios problemas.

Finalmente y lo que considero más importante: si alguien ajeno al equipo interfiere y toma decisiones tiene consecuencias negativas

Me gustaría leer vuestras opiniones y experiencias y, si tenéis medio segundo, que votéis la pequeña encuesta sobr este tema.

|