En la teoría Scrum dice que debemos tener equipos dedicados (con algunas excepciones como puede ser un administrador de base de datos) pero en empresas con equipos reducidos que tienen que luchar contra el soporte de anteriores proyectos y nuevos desarrollos nos surge la pregunta: ¿podemos usar SCRUM?.

Sería una lástima dejar de utilizar un framework como SCRUM por no cumplir una de las reglas de oro de dedicación total. Normalmente podríamos tener una fila en nuestro panel de tareas de "tareas sin planificar", si una persona es requerida para hacer algo fuera del proyecto (ej: es el único que conoce como solucionar un bug de forma rápida) lo que hace es poner una tarea en esta fila y estimar el tiempo que estará dedicado a la misma. En nuestro caso, por ser un equipo pequeño, el soporte no es una excepción sino una actividad diaria, lo que hacemos es que el 80% del tiempo de cualquier miembro del equipo se dedica al proyecto nuevo y el 20% restante a soporte, para gestionar todo este soporte utilizamos Kanban (http://es.wikipedia.org/wiki/Kanban) que nos ayuda a tener los tickets de soporte priorizados y que cada uno vaya cogiendo un kanban que va pasando de una fase a otra (preparado, en desarrollo, en pre-producción y en producción), la verdad es que nos está funcionando muy bien junto con Scrum, en la imagen podéis ver nuestro Kanban de soporte.

|

Despues de casi dos años practicando SCRUM y asistiendo a multitud de charlas teóricas (incluyendo la certificación) donde explican en que consiste este framework se nos ha ocurrido plantear un curso donde de verdad se vea el uso en la práctica (generar un panel de tareas, hacer una retrospectiva, crear burndown charts, planificar y estimar, etc.).

La idea es que asista gente que ya tiene unos conocimientos teoricos mínimos y plantear un proyecto ficticio el primer día que se irá desarrollando durante la duración del curso y el contenido podría ser el siguiente:

1.- Creación del backlog del producto. Historias de usuario
2.- Release planning meeting
3.- Estimación y planificación agil del proyecto.
4.- Sprint planning meeting
5.- Creación de paneles de tareas
6.- La reunión diaria
7.- Como hacer una buena demostración
8.- Retrospectivas

El ambito funcional del proyecto todavía no lo sabemos, nuestra experiencia está en desarrollo web para sistemas de información financiera, quizás crear un broker on-line sería una buena idea.

Duración: 3 o 4 días
Lugar: Madrid o Valencia
Fecha posible: Mayo


¿Qué os parece la idea? Esperamos vuestros comentarios

|

Primero de todo, feliz año nuevo ;-). Después de unas merecidas vacaciones de Navidad y de estar inmersos en el primer sprint del proyecto no he tenido ni un minuto para poder compartir el avance del proyecto que anteriormente ya habíamos estimado y planificado.

Hoy, día de la demostración, me voy a permitir compartir cómo ha ido el avance de este sprint y los principales impedimentos que nos hemos encontrado.Nada más finalizar la reunión de planificación del sprint y comprometerse el equipo con las historias de usuario que iban a implementar, montamos el panel de tareas, la verdad es que después de llevar unos cuantos instalados creo que me voy a tener que "modernizar" siguiendo los consejos que nos da Xavier Quesada en su blog: http://www.xqa.com.ar/visualmanagement/



El equipo estaba formado por 3 personas + el Scrum Master y el product owner. El sprint fue de 2 semanas (10 días labolables) y en el siguiente gráfico podemos ver el burndown chart a los 8 días de sprint:




Al final la funcionalidad comprometida ha sido implementada pero nos hemos encontrado con un gran imprevisto diario: el soporte. El equipo debe enfrentarse a nuevos desarrollos a la vez que da soporte a antiguas implementaciones, podríamos argumentar que así no se puede hacer Scrum ya que no tenemos la dedicación al 100% del equipo pero, ante la realidad, planificamos 1 hora diaria de soporte y el resto para nuevos desarrollos y todo esto lo gestionamos con Kanban, de lo que hablaremos en siguientes entradas de este blog.

Ya os contaré como ha ido la demo, desearnos suerte!

|

Hemos comenzado un nuevo proyecto y el otro día tuvimos la primera sesión de estimación de las historias de usuario, en nuestro caso utilizamos planning poker como método de estimación, cada componente del equipo que va a desarrollar tiene una baraja de cartas y cada carta tiene un estimador. Los estimadores siguen una serie de Fibonacci para que seamos conscientes de que una estimación nunca será exacta y se transmita la incertidumbre que tenemos sobre el proyecto.



En nuestro caso esta estimación se hace al principio del proyecto para proporcinarle al dueño del producto los puntos de usuario de cada una de sus historias, evidentemente se harán más reuniones de este tipo a medida que aparezcan nuevas historias de usuario.

La técnica ya se explicó en un post anterior, pero después de la cantidad de reuniones que hemos tenido de este tipo quiero compartir algunas conclusiones:

1.- Si haces reuniones muy largas la convergencia en las estimaciones empiezan a aparecer sencillamente porque la gente está cansada, cuando veáis que en la primera tirada cada uno saca un estimador y terminan convenciéndose sin casi argumentos es hora de dejar la reunión para otro día

2.- No siempre es posible que todos coincidan en el estimador, para eso hay diferentes tiradas y cada uno va explicando su razonamiento pero en un momento dado (tras 3 o 4 rondas) es el Scum Master el que termina preguntando: ¿te importa aceptar esta estimación? tomando como resultado el valor más votado. Hasta ahora no me he encontrado a nadie que diga: no, creo que yo tengo razón y vosotros no tenéis en cuenta esto y esto.


3.- Evitar que el dueño de producto y el equipo se centre en detalles. La última vez nuestro dueño de producto hablaba incluso ya del interfaz gráfico de usuario, en mi opinión esto deberá ser discutido cuando se planifique el sprint y aquí solo hablar de funcionalidad. El equipo también termina hablando de si usar un API, un lenguaje , etc y siempre les intento centrar en que valoren la funcionalidad y complejidad.

La siguiente reunión donde planificamos el sprint y ya no estimamos en puntos de historia sino en horas ideales ya no usamos planning poker, normalmente no nos hace falta a ese nivel y suele agilizar la planificación, de otra forma creo que serían demasiadas horas discutiendo sobre si una tarea tiene 2 o 3 horas ideales.

Me gustaría saber vuestras experiencias: ¿usáis planning poker en estimación del producto y también en la estimación de cada sprint? ¿cómo lográis que haya convergencia?

|

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 ;-)

|

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.

|