Scrum y XP: planificación de Sprint II
Despues de siglos sin escribir nada ya toca seguir con la serie de entradas sobre Scrum y XP, ultimamente he tenido mucho trabajo y poco tiempo para escribir, a partir de ahora espero volver a tener un ritmo más regular publicando entradas en el blog, bueno, al menos eso espero...
En la entrada anterior hablamos sobre la reunión de planificación de sprint, abordamos los requisitos previos que debian cumplirse antes de la reunión y la primera parte de la reunión, en esta entrada intentaré explicar la segunda parte de la reunión, en la que se lleva a cabo el trabajo realmente duro: planificar las historias
División de la historia en tareas
Las historias son funcionalidades definidas desde el punto de vista del product owner, en otras palabras, una historia debe ser algo que aporte valor al cliente, cosas como por ejemplo "permitir que los usuarios se validen a través de un servidor LDAP". Lo primero que hace el equipo con cada historia es dividirla en tareas ya desde el punto de vista tecnico para poder estimar mejor la historia. Por ejemplo el equipo podría dividir la historia anterior en cosas como:
- Crear una nueva implementación de la interfaz de validación que utilize LDAP
- Crear una nueva opción de configuración que permita elegir entre validación LDAP u otras
- Sincronizar los usuarios del LDAP con los de nuestra base de datos
Una vez que la historia queda divida en tareas técnicas el siguiente paso consiste en estimar lo que nos costará realizar la historia. Aqui hay dos posibilidades:
- Dividir N historias en tareas y luego estimarlas todas
- Estimar una historia justo despues de dividirla en tareas
En nuestro caso preferimos dividir primero en tareas todas las historias que más o menos sabemos que entrarán en el sprint y luego estimarlas, si despues de la estimación vemos que cabe alguna historia más pues cojemos la siguiente del PB y la dividimos en tareas.
Estimación en puntos de cada tarea
Ahora pasamos a estimar en puntos cada tarea, la estimación de la historia completa es simplemente la suma de puntos de las tareas definidas para esta por el equipo. Para la planificación nosotros utilizamos la conocida tecnica de la planificación poquer (lo escribo así, porque si lo escribo bien el blog no me deja publicar la entrada..., y llevo toda la tarde pegandome con esto :P, supongo que será cosa del anti-spam o algo similar que no le gusta la palabra po.. ya sabeis...)
Esta tecnica es muy simple, cada miembro del equipo cuenta con un baraja con varias cartas como las de la imagen, el Scrum Master inicia la ronda de estimación para una tarea, cada miembro del equipo pone una carta sobre la mesa (boca abajo claro :P ) y cuando todos han decidido se levantan las cartas y se decide la estimación como el valor más aproximado a la media de lo que todos han dicho.
Mucho más importante que elegir el valor medio es la discusión que se produce entre los miembros del equipo cuando se ponen valores muy dispares, si por ejemplo alguien estima la tarea en un día y otro la estima en 5 esta claro que algo raro esta pasando, o bien el que estima en 1 día conoce alguna forma de terminar la tarea muy rapido (por ejemplo alguna librería que solventa el problema que el resto no conoce), o bien el que estima en 5 ha visto algún problema que del que el resto no es consciente (de integración con otros modulos, de viabilidad tecnologica o lo que sea).
Esto de la planificación poquer a algunes les parece "algo poco serio", sin embargo yo creo que es todo lo contrario, mucho menos serio me parece cualquier estimación kilometrica tipo condena de las de 6 meses y un día... aunque le dejes al desarrollador una semana para que estime en detalle, da igual, no va a acertar, probablemente ni se acerque, y cualquier empresa tiene un historico de estimaciones desviadas que lo demuestra, así que despues de llevar años y años fallando en todas y cada una de las estimaciones que se hacen... ¿porque no intentarlon otros enfoques?
Nuestra experiencia despues de mas de un año usando este tecnica es muy positiva, si bien al principio nos equivocamos bastante hemos ido aprendiendo de los errores y ahora nuestras planificaciones son mucho más precisas. Que no quiere decir esto que acertemos siempre, no somos nostradamus, pero si ajustamos bastante bien y como mucho se nos puede quedar una historia fuera del sprint, evidentemente ayuda que las historias sean cortas y los sprints también sean cortos, de modo que si algo se queda fuera pues tampoco es ningún drama, será la historia menos prioritaria y estará lista para el siguiente sprint en dos semanas.
Definición de terminado de una historia
Otro punto critico es definir los criterios para dar una historia por terminada, en las tarjetas de cada historia dejamos un hueco para rellenar donde pone: "¿Como probarlo?", si se cumplen las condiciones que que se indiquen en el "¿Como probarlo?" más lo que hemos definido que tiene que cumplir cualquier historia damos esa historia por cerrada.
Esto que parece facil cuando uno lo piensa en la practica es bastante complejo, en definitiva cuando defines como probar una historia estas definiendo el alcance de la misma, y no simpere es facil, es importante ponerse a definir esto junto con el product owner porque pensando en como probar la historia surjen muchos detalles que ayudan a que se entienda mejor el alcance de la historia tanto por parte del product owner como por parte del equipo.
Por ejemplo para la historia del LDAP podría ser algo tan simple como "entrar a la aplicación y cuando se nos pida usuario y password introducir los de un usuario creado en el LDAP, deberiamos poder entrar a la aplicación y en nuestra base de datos se crearía el nuevo usuario sincronizandolo con la información del LDAP".
Fijaros que simplemente con la definición anterior pueden surjir varias dudas: ¿Que información debemos sincronizar?, ¿Cuando el usuario entre por segunda vez volvemos a sincronizar la información?, ¿Si ya tenemos un usuario en nuestra base de datos con el mismo nombre que otro de LDAP que hacemos?
Estas dudas las tendrá que resolver el equipo junto al product owner y decidir que hacer en cada caso completando y haciendo lo más precisa posible la definición de terminado. En muchas ocasiones nos ha pasado que creiamos haber entendido perfectamente una historia y al ponernos a definir esta parte nos hemos dado cuenta de que no teniamos la misma visión sobre la historia que el product owner. Una de las mejores cosas de esta reunión de planificación es precisamente hablar "cara a cara" con el dueño del producto y no que todo se reduzca a un documento de especificaciones, por supuesto ambiguo.. siempre son ambiguos, que el equipo entiende como buenamente puede...
Además de el "¿Como probarlo?" de cada historia tenemos una serie de condiciones que tienen que cumplirse para dar cualquier historia por terminada, estas son generales a cualquier historia y deben cumplirse siempre:
- Aceptación: El criterio de cómo probarlo está acordado, escrito, y el programa supera la prueba. Ultimamente hemos empezado a escribir primero las pruebas funcionales de aceptación antes de tirar uno sóla linea de código de la aplicación. Tenemos pendiente revisar herramientas como fitnesse o concordion para mejorar en este apartado
- Pruebas: El código desarrollado supera las pruebas unitarias y la cobertura de pruebas ha sido revisada y considerada aceptable por el equipo.
- Calidad del código: revisar que el código cumple con las normas de estilo definidas. Por lo menos verificar que añadido el nuevo código para la historia no se disparan las graficas de incumplimiento de normas de manera alarmarte. Para mejorar esta gestión estamos introduciendo el uso de sonar, magnifica herramienta por cierto.
- i18n: El código desarrollado está internacionalizado. Es una caracteristica que se debe cumplir en toda nuestra aplicación, no tiene sentido definirla historia por historia como un criterio de aceptación.
- Trazable: El código desarrollado tiene integrado el log.
- Documentado: Existe una documentación de desarrollo sobre la historia.
- Integrado: el código esta integrado con la rama principal de desarrollo y es posible descargarlo de algún lugar y ejecutarlo para probar la historia. Vamos que no vale con "works on my machine", la historia debe estar integrada con el resto de la aplicación y funcionando.
Estas son las normas que nosotros mismo nos hemos impuesto cumplir para dar una historia por terminada, depediendo del contexto cada equipo debera definir las suyas. Esto que puede parecer mucha cosa para cada historia es fundamental si no queremos estar generando constantemente deuda tecnica, no se trata solo de terminar las historias, hay que terminarlas bien. Y es importante hacer entender esto al PO, que no son caprichos de desarrolladores quisquillosos, es que si no hacemos estas cosas luego lo vamos a pagar con un proyecto inmantenible donde añadir o modificar algo empieze a costar cada vez más y más. Me gusto una frase que lei el otro día no recuerdo donde "El factor que más influye en la productividad de hoy es la calidad del código que escribiste ayer"
Problemas y malos habitos
Durante el año que llevamos aplicando estas tenicas hemos detectado algunos problemas que pueden echar al traste estas reuniones o convertirlas en totalmente improductivas:
- El Product Owner no tiene claras la historias. Este es el mayor problema en estas reuniones, que el product owner no tenga claro que es exactamente lo que quiera, que solo tenga "ideas vagas" y en cuanto el equipo empieza a preguntarle detalles no sepa responder adecuadamente. Cuando ocurre esto al final las reuniones se eternizan porque se dedica más tiempo a discutir el alcance de las historias (que el PO debería tener claro antes de acudir a esta reunión) que realmente en planificar las historias. Cuando ocurre esto el SM tiene que ponerle las pilas al PO para que haga su trabajo, y esto no siempre es facil porque es habitual que el PO sea alguien con más peso en la jerarquia de la empresa. Esto es habitual en organizaciones clasicas que se pasan al agilismo, pero bueno aqui el SM tiene que hacer uso de unos de los valores que exigia XP: "el coraje" :P
- Los miembros del equipo son de nivel muy diferente, esto nos es que sea un problema en si mismo, pero un desarrollador senior puede estimar algo en un punto y un junior en 5. Lo importante aqui es que el junior no se deje influir por las estimaciones del senior, si hacemos esto al final saldremos de la reunión con un sprint que podrían asumir 5 seniors, pero nosotros tenemos 1 senior y 4 junior!!. Cada cual debe tratar de ser sincero con lo que EL tardaria en terminar la historia.
- Estimaciones para cubrirse las espaldas, la gente que viene de otros modelos tiende a sobrestimar (y a veces mucho) para cubrirse las espaldas, es importante dejar claro que en Scrum lo que importa es ser realista y si luego no se puede cumplir algo tampoco se viene el mundo abajo, estamos haciendo entregas parciales cada 2 o 3 semanas, si en una entrega parcial en lugar de 3 historias van 2 y se deja la otra para el siguiente sprint NO PASA NADA. Lo importante es que la gente no estime siempre 3 puntos más "por si acaso" hay que evitar la cultura del castigo si no llegas a la estimación y fomentar una cultura de sinceridad y colaboración entre el equipo y el PO. Si hay confianza la gente dejara de usar las estimaciones como armas arrojadizas y dedicarse a dar cada uno su mejor esfuerzo por sacar las cosas adelante. Ya se que esto suena muy bonito pero en ciertas organizaciones es más utopico que otra cosa, pero bueno, hay que intentarlo!!.
Fin de la reunión y al tajo!
Cuando ya hemos estimado todas las historias que podemos acometer dentro del sprint (a veces estimamos una más por si luego tenemos tiempo) damos por finalizada la reunión, nos llevamos nuestras cartulinas a la sala de trabajo las pegamos en la pared y empieza un nuevo sprint!.
En las siguientes entradas trataré como llevamos el tema de las demos y la retrospectiva, una vez visto esto ya entraré en materia con la parte que más me gusta, las practicas puramente tecnicas como pruebas unitarias, integración continua y todas estas cosas.
Entradas anteriores de esta serie:
- Planificación de sprint I
- Los roles en un equipo Scrum
- El proceso de scrum
- Scrum y XP: ¿realmente lo que necesito?
Scrum y XP: planificación de sprint I
Seguimos adelante con la serie de artículos dedicados a Scrum, una vez que conocemos el proceso de scrum y los distintos roles que participan en un proyecto Scrum ya podemos ir entrando en más detalle en las distintas practicas. Para empezar vamos a ver como se desarrolla una reunión de planificación de sprint.
De todas las reuniones de Scrum la de planificación de sprint es la más "dura" y la más larga, como hay muchas cosas que contar he dividido esta entrada en dos partes, en esta primera me centrare en los requisitos previos antes de empezar la reunión y la primera parte de la reunión donde se definen aspectos generales del sprint, en la segunda parte (que espero publicar en breve) entraré a explicar el método de planificación que seguimos para las historias y sus tareas.
Objetivos de la reunión planificación de sprint
El objetivo de esta reunión es claro: seleccionar una serie de historias del product backlog y construir con ellas el sprint backlog, es decir, la lista de historias sobre las que el equipo de desarrollo trabajara durante el sprint que terminará con la demo donde se demuestren las funcionalidades implementadas
En esta reunión el product owner y el equipo deben ponerse de acuerdo en que historias se implementarán durante el sprint. El product owner informará al equipo de que tareas son más prioritarias y el equipo estimará estas tareas para determinar cuantas se pueden abordar dentro del tiempo de duración de sprint. Esta reunión supone un compromiso entre las partes, el product owner se compromete a no interferir en el desarrollo del sprint (no introducir nuevas historias o modificar sobre la marcha el alcance o la descripción de otras) y el equipo se compromete a intentar sacarlas adelante.
A partir de ahora intentare ir detallando paso a paso como llevamos a cabo estas reuniones:
Paso 0: Pre requisitos, ¿que necesito antes de empezar la reunión?
Un sala de reunión:
Parecerá obvio, pero alguien se tiene que encargar de reservar una sala :P, esto es tarea del scrum master. Es importante tratar de encontrar un lugar donde reunirse sin interrupciones y si es posible con algún aprovisionamiento en forma de refrescos y algo de picar jeje, que suele ser larga (esto ultimo no es imprescindible pero puede ser buena idea :P )
Asegurarse que todos los interesados asistan:
De nuevo parece obvio, sin embargo es una tarea importante ajustar la agenda de todo el mundo para que puedan asistir todos los interesados. Es fundamental que el product owner asista a esta reunión, de echo se podría decir que el product owner es el "protagonista principal", es donde se va a decidir que se va a hacer con su producto así que debe estar presente si o si. Si se quiere hacer scrum hay que tomarse muy en serio estas reuniones y todos los involucrados deben ser conscientes de eso para ajustar sus agendas y posibles compromisos de modo que estén disponibles en estas reuniones. A esta reunión debe asistir el PO, el SM y todos los desarrolladores, también pueden asistir otras gallinas pero no pueden participar en la reunión, sólo como observadores.
En nuestro caso estas reuniones son como una "liturgia", nadie se las pierde y todos somos conscientes de su importancia, nuestro product owner actual es un "creyente" de scrum y fue uno de sus principales impulsores. Sin embargo en otros casos quizas lo más dificil sea conseguir que el product owner se involucre con el equipo, esto es facil que ocurra en organizaciones que estén empezando con scrum y la figura de product owner la ocupen jefes de proyecto, jefes intermedios o incluso comerciales que viven lejos del equipo de desarrollo. Es fundamental para el éxito de cualquier proyecto scrum tener un PO implicado y consciente de sus responsabilidades en el proyecto, que asista con rigor espartano a todas estas reuniones. Que no nos ocurra eso de que el PO llama a ultima hora que no puede venir porque tiene tal o cual compromiso y luego a las dos semanas vuelva a aparecer para decir que no esta de acuerdo con el sprint backlog, preguntate si tu product owner es una gallina. (creo que me encanta scrum por poder usar estas expresiones :P)
Un product backlog priorizado:
El product owner debe hacer sus deberes antes de esta reunión, es necesario disponer de un product backlog priorizado antes de empezar. Normalmente no se tienen sólo las tareas que se pretenden incluir en el sprint sino algunas más ya que dependiendo de la dificultad de las tareas y la estimación de los desarrolladores puede ser posible incluir más de las el product owner tenga previsto, o menos por supuesto.
Otro problema habitual en equipos nuevos con scrum es que el PO no sabe expresar lo que quiere en forma de historias, podríamos dedicar una entrada entera para hablar de que es y que no es una buena historia, algunos pequeños consejos:
- Las historias deben tener un alcance bien definido, por ejemplo algo como ”La aplicación debe integrarse con aplicaciones de contabilidad existentes en el mercado" no es una buena historia, habrá que definir con cuales!, y habrá que definir que se entiende exactamente por "integrarse".
- Las historias tiene que ser funcionalidades pequeñas y concretas no divagaciones, se trata de ir añadiendo funcionalidad poco a poco, historias del tipo "El sistema debe disponer de mecanismos de seguridad a la altura de los mejores del mercado" no es obviamente una historia valida.
- Las historias deben decir "el que" y no "el como", cada uno a lo suyo vamos, historias tipo:”La aplicación escribirá trazas de la actividad de los usaurios usando log4j” tampoco son buena idea. El equipo que es quien entiende de cosas técnicas toma decisiones técnicas, el PO que es quien sabe del negocio toma decisiones de que tiene que hacer el producto para aportar valor al negocio. Exceptuando casos donde la tecnología elegida sea parte del valor que aporta el producto suele ser mala idea que un PO tomo decisiones técnicas para las que normalmente no esta preparado
La tarea sin duda más dura de la planificación es convertir las historias en cosas que puedan ser estimadas por el equipo y incluidas en un sprint backlog, la parte crucial de esta reunión es precisamente que el equipo y el PO salgan con las ideas claras de lo que se va ha hacer y lo que no durante el sprint.
Ahora que ya lo tenemos todo, vamos a empezar la reunión!
Paso 1: Definición del sprint
Lo primero es definir en lineas generales el sprint, esto implica definir varias cosillas, normalmente nosotros lo hacemos en este orden:
Ponerle nombre al sprint
Se trata de elegir un nombre corto que sintetice lo mejor posible la tarea que se va ha desarrollar en el sprint, por ejemplo: "Definición e implementación de un API's SOAP de acceso al sistema". La idea es que este nombre sirva para explicar rápidamente al resto del mundo en que estamos trabajando y para tener todos un objetivo común claro en la cabeza, que cualquiera se acerque a la sala del equipo de desarrollo y con solo leer el nombre ya tenga una idea de a que esta dedicada la gente.
Un efecto muy positivo de poner buenos nombres a los sprints se empieza a notar cuando llevas unos cuantos y con un sólo vistazo a la lista con los nombres de los sprints realizados tienes un histórico fenomenal del trabajo realizado por el equipo en los últimos meses y de la dirección que se ha ido siguiendo en el desarrollo del producto. Es habitual que alguien solicite en algún momento un histórico de este tipo para saber en que ha ido trabajando el equipo, nosotros antes de utilizar scrum teníamos que recurrir a una mezcla de cosas para poder dar esta información, cosas como: los logs de subversión, las entradas en la herramienta de inputación de horas, diagramas de gannt normalmente desactualizados con más mentiras que verdades :P, y por supuesto a la memoria de cada uno de los desarrolladores..., agitese todo esto y obtenga su histórico.
El calendario del sprint
En primer lugar definimos la duración del sprint, aunque la recomendación es que todos tengan idéntica duración en nuestro caso la duración de los sprint la variamos unos pocos días hacia arriba o hacia abajo sobre todo en función de donde caiga el día de la demo (tratamos de evitar demos los lunes :P, nuestro día preferido para la demo es el viernes) o bien intentamos que el fin de sprint no coincida con días libres o vacaciones de algún miembro del equipo (no siempre se puede claro esta, pero tratamos en la medida de lo posible de estar todos para la demo). Normalmente nos suelen quedar sprint de entre 3 y 4 semanas
Una vez definida esta duración implícitamente hemos definido el día de la demo: un día después del fin de sprint. La retrospectiva la hacemos el mismo día de la demo, las demos suelen ser a las 10 de la mañana con una duración de aproximadamente una hora, el resto del día lo usamos para la retrospectiva y lo que surja (siempre hay cosas que hacer o irse mirando). También fijamos la fecha de la siguiente planificación de sprint, normalmente es el día después de la demo, aunque en ocasiones hemos dejado un día entre retrospectiva y planificación, casi siempre por cuestiones de agenda.
Calculo del número de puntos disponibles:
Utilizamos "puntos" para realizar las estimaciones, es decir, no decimos "esta tarea son 23,3 horas" sino que decimos "esta tarea son 2 puntos". En nuestro caso hemos echo la equivalencia de "un punto = un día ideal de trabajo", esto es, lo que consideramos daría tiempo en ocho horas ininterrumpidas de trabajo.
Una vez ya hemos definido los días de duración del sprint se pregunta a cada desarrollador su previsión de disponibilidad, aunque lo ideal es que todo el mundo este al 100% involucrado en el sprint esto nunca ocurre, siempre surjen cosas, por ejemplo "tal día tengo que asistir a una reunión con unos clientes" o "tal día voy a una conferencia de no se que", o "tengo que ayudar en otro proyecto". También es necesario considerar el tiempo empleado en la resolución de incidencias de versiones anteriores del producto que tengan prioridad máxima y haya que arreglar. Con todo esto en mente cada desarrollador indica en porcentaje su tiempo de dedicación durante el sprint. Luego se toman estos datos y se aplica la siguiente sencilla formula para obtener los puntos disponibles en el sprint:
(días de sprint*porcentaje de dedicación(desarrollador1))+...+(días de sprint*porcentaje de dedicación(desarrolladorN))*Factor de Corrección
El factor de corrección es simplemente un número entre 0 y 1 que simboliza el porcentaje de tiempo de un día de trabajo que realmente se aprovecha, dado que los puntos son días ideales y los días nunca son ideales ester porcentaje sirve para afinar un poco mejor la planificación. Nosotros actualmente utilizamos un 0,7
Posteriormente en la segunda parte de la reunión se pondrán puntos a cada tarea y se meterán en el sprint las que de tiempo, normalmente nunca sale exacto, nosotros solemos incluir una o dos más de las que realmente entran.
Definir el concepto de sprint terminado
Esta es una practica que estamos empezando a aplicar en los últimos sprint, igual que cada historia tendrá una definición de terminado el sprint también necesita una. Hemos detectado que sistemáticamente terminábamos los sprint de forma muy "atropellada", es decir, llegamos muy justos terminando historias y descuidamos algunas tareas que no son propias de ninguna historia concreta pero que si lo son para dar el toque final al producto y dar por cerrado un sprint. Por ejemplo actualmente manejamos una lista como esta:
- El código de todas las historias desarrolladas en el sprint integrado en la rama principal del sistema de gestión de versiones. Habitualmente trabajamos en un branch durante el sprint y mezclamos con el trunk al final del sprint, en ocasiones también hemos creado branch para algunas historias concretas, pero independientemente de la política de branches que tengamos (que explicaré más adelante en otra entrada) al final del sprint el código de todas las tareas tiene que estar integrado en la rama principal, es decir, lo que no este en la rama principal no esta en el producto. Esto implica que la demo se hace con el producto que hay en la rama principal, una practica poco recomendable es hacer las demos con productos no integrados en la rama principal o peor aún, con código que sólo esta en el equipo de un desarrollador concreto y no esta en el control de versiones.
- Revisión de métricas: de ajuste a la guía de estilo (checkstyle), posibles errores (findbugs), de código duplicado (simian) y de cobertura de pruebas. Antes de dar un sprint por terminado revisamos que todas estas métricas siguen en números aceptables, aunque esto es algo que hay que hacer en el día a día hemos definido esto para antes de cerrar un sprint darle un ultimo vistazo.
- Verificación de la corrección de los entregables:Verificar que el entregable esta correcto, el entregable puede ser algo tan sencillo con un .jar o un .war o bien puede ser un instalador complejo con múltiples opciones. Es habitual que sólo verifiquemos que los productos en desarrollo funcionan pero luego nadie se preocupe de instalarlo en un equipo "limpio" y verificar que todo esta bien
- Desplegar la aplicación en servidores de pruebas, al final de cada sprint montamos la aplicación en varios servidores de pruebas (en nuestro caso concreto tenemos que ser compatibles con varios) y contra varios SGBD (MySQL, Oracle y SQLServer actualmente) y la dejamos montada para que cualquiera pueda acceder a la ultima versión.
- Escribir un guion para la demo, la demo si queremos que salga bien hay que prepararla aunque sea simplemente escribiendo un pequeño guion de que vamos a contar, en que orden, a que nivel de detalle etc,etc.
Esto son sólo ejemplos de cosas que hacemos en nuestro equipo de desarrollo antes de cerrar un sprint, cada equipo tendrá diferentes items en esta lista, sin embargo es importante tener esta lista para ser conscientes de que tareas hay que hacer para dar un sprint por cerrado, por nuestra experiencia si estas tareas no se hacen explicitas al final lo que ocurre es que sencillamente no se hacen o se hacen a medias.
Y con esto damos por cerrada la primera parte de la reunión, a continuación empieza lo duro de verdad :P, ir planificando cada una de las historias y discutiendo los detalles de estas con el PO, en la siguiente entrada os contare como o hacemos.
Entradas anteriores de esta serie:
SCRUM Y XP: Los roles en un equipo scrum
Despues de comentar como es el proceso de desarrollo con Scrum vamos a ver quienes son los participantes en este proceso y que roles cumple cada uno. Como todos sabemos Scrum es una metodología ágil, y el primer principio del manifiesto ágil dice:
Valorar más a los individuos y su interacción que a los procesos y las herramientas
No se trata solo de tener un proceso que seguir, se trata de tener la gente adecuada para desempeñar cada uno de los roles definidos, y aunque Scrum en definitiva define un proceso de trabajo, como metodología ágil que es valora más la capacidad y el talento de los miembros del equipo que el seguimiento a pies juntillas de un proceso.
Incido en esto para que nadie se sienta "engañado", la aplicación de Scrum no ejerce ningún tipo de acción mágica en tu equipo que convierta a becarios o recién titulados en M. Fowler o Robert C. Martín. Lo primordial es tratar de reunir el mejor equipo que puedas y asegurarte de que este motivado, si quieres hacer buen software esta debe ser sin ninguna duda la primera prioridad.
Quiero resaltar con esto que independientemente de Scrum o cualquier otra metodología que decidamos aplicar lo más importante es la gente, esto confronta directamente con la orientación a procesos de otros enfoques, como el modelo CMMI por ejemplo. Estos enfoques orientados a procesos tratan de definir un método de trabajo que permita que la gente sea fácilmente sustituible, afirman que la calidad del producto depende de la calidad de los procesos aplicados en su elaboración. En mi opinión la calidad de un producto software depende prioritariamente del talento y la capacidad de sus desarrolladores y en mucha menor medida de la calidad del proceso.
Dicho esto vamos a ver que roles define Scrum y que cometidos tiene cada uno
Entre gallinas y cerdos
En primer lugar Scrum divide a las personas que están alrededor de un proyecto en dos categorías, las gallinas y los cerdos, hay una viñeta muy famosa al respecto:
- Las gallinas son todos aquellos interesados en el proyecto, gente que espera obtener algo a partir de los resultados del producto pero que no están directamente implicados en su desarrollo. Por ejemplo comerciales o mandos intermedios de la compañía
- Los cerdos son aquellas personas que participan activamente en el día a día del desarrollo de un producto, tanto en su definición como en la elaboración del mismo. Vamos que según Scrum los desarrolladores somos algo así como una piara de cerdos :P
A partir de ahora vamos a centrarnos en los cerdos, Scrum define distintos roles para los participantes en el desarrollo de un producto, la organización de las gallinas será algo que dependa de cada empresa y queda fuera del alcance de Scrum que se limita simplemente a hacer esta distinción inicial.
3 tipos de cerdos
El product owner
El nombre ya es muy explicativo, es el dueño del producto, vamos la persona que decide que se tiene que hacer y cuando se tiene que hacer. Su cometido principal es encargarse del product backlog, es responsabilidad suya definirlo y priorizarlo. También es el responsable de verificar que el producto que sale de un sprint cumple con los objetivos marcados, es el principal responsable de la reunión de planificación donde debe junto con el resto del equipo definir el trabajo a realizar en el siguiente sprint.
Una tarea importante del product owner es canalizar todas las peticiones de las gallinas y construir el product backlog en función de estas, debe ser por tanto alguien que tenga claro la dirección que debe seguir el proyecto y que conozca bien el negocio a donde va dirigido el mismo. Ejerce como filtro para el equipo lo que en la practica es importantisimo para evitar interferencias al equipo de desarrollo, no puede llegar cualquiera con corbata y solicitar esto o aquello sin pasar por el filtro del product owner. Su misión más importante es servir de punto de unión entre los distintos interesados en el proyecto y el equipo de desarrollo, digamos que es el nexo de unión entre gallinas y cerdos
En nuestro caso particular desarrollamos un framework que luego se usa en la empresa para servir como base a otros proyectos, hay por tanto muchas gallinas interesadas en que el framework haga esto o lo otro, cada uno en su proyecto tiene distintas necesidades y el framework en la medida de lo posible debe dar cabida a todas ellas, en nuestro caso la figura del producto owner es fundamental para canalizar y priorizar todas las peticiones de mejoras al framework y para definir la dirección en la que vamos. El equipo de desarrollo sabe que a quien tiene rendir cuentas es al product owner y no estamos constante mareados por peticiones de unos y otros.
El Scrum master
Es el "experto en Scrum", es la persona que se encarga de asegurarse que se sigue el proceso de Scrum. Entre sus responsabilidades están organizar las reuniones necesarias (cosas como reservar una sala y asegurarse de que todos los implicados asistan), moderar las distintas reuniones, actualizar la grafica burndown con las reestimaciones diarias, resolver o ponerse en contacto con quien pueda resolver los problemas que se detecten en la reunión de Scrum diaria.
La principal tarea del scrum master no es dirigir o organizar al equipo (scrum sigue la premisa de equipos que se autorganizan) sino eliminar los obstáculos que impiden el avance del equipo y asegurarse del cumplimiento de la metodologia. Más que como un líder de proyecto "clásico" se puede ver al scrum master como un facilitador que se encarga de vigilar que el equipo avanza adecuadamente.
En nuestro caso particular la labor de scrum master no es suficiente como para tener una persona dedicada a ello a tiempo completo, vamos que para mandar unos cuantos correos, actualizar un gráfico y moderar las reuniones tampoco necesitamos a nadie a tiempo completo. Actualmente soy yo quien ejerce de Scrum master al mismo tiempo que también soy developer, quizás en organizaciones mayores donde existan varios grupos haciendo scrum puede ser interesante tener un solo scrum master que se ocupe de varios equipos, pero en nuestro caso nos parece suficiente con que este rol lo asuma un miembro del equipo.
developer
Lo recomendado en scrum es un equipo este compuesto por entre 7 y 3 developers. Es decir esta es una metodología para equipos de trabajo pequeños, no obstante siempre es posible subdividir el trabajo entre varios equipos y realizar lo que se conoce como Scrum de scrums. Nosotros actualmente somos un sólo equipo de 4/5 desarolladores pero esta previsto para un futuro no muy lejano formar nuevos equipos y subdividir el trabajo, ya os contaré en entradas futuras como nos va :P
¿Y que hacen los developer?, pues esta bastante claro ¿no?, son los que desarrollan el producto, nada más y nada menos que eso. Lo primero que puede llamar la atención si estamos acostumbrados a otras metodologías es la ausencia de roles como: arquitecto, analista funcional, analista orgánico, analista programador, programador senior, programador junior, programador bla,bla,bla.... En scrum solo hay desarrolladores, aunque por supuesto en función de su experiencia y conocimientos habrá algunos que sean los que decidan sobre la arquitectura, los que tomen decisiones de diseño de más alcance, y otros con menos experiencia que vayan aprendiendo, pero algo importante es que el propio equipo el que se auto-organiza y define internamente estas responsabilidades de común acuerdo, aquí la figura del Scrum master es importante para poner "paz" en determinadas situaciones y hacer que la comunicación en el equipo sea lo más fluida posible.
Otra característica importante de los developers en scrum es que no se trata de equipos de especialistas sino de equipos de "todoterrenos", es decir, no hay un especialista en diseño de BBDD, otro en interfaces de usuario, otro en tal o cual framework. En un equipo scrum todo el mundo tiene que saber hacer de todo, y lo más importante todo el mundo tiene que estar dispuesto a aprender nuevas cosas constantemente y encargarse hoy del diseño de la BBDD y mañana de un UI en javascript. Por supuesto que luego siempre habrá gente que sepa de mas de un área determinada, pero la idea es que ese conocimiento no quede solo en la persona experta sino que el equipo entero vaya creciendo aprendiendo unos de otros, es importante tratar de que las tareas no se asignen luego en función de "quien sabe más de esto", sino que cualquiera se pueda hacer cargo de cualquier parte del proyecto, en algunos casos puede ser muy interesante la practica del pair programming para ir haciendo que miembros del grupo con pocos conocimientos en algún área los vayan adquiriendo paulatinamente.
Muchos afirman que Scrum solo funciona con equipos de cracks, tampoco estoy del todo de acuerdo con esta afirmación, no es necesario que todos los miembros del equipo sean auténticos cracks, lo que si es importante es que todos tengan como mínimo buena disposición para aprender y no tengan miedo a enfrentarse a nuevos problemas, estudiar este o aquel nuevo framework o leerse una o dos especificaciones. Si cuentas con gente para la que pasar de utilizar .net para usar java o viceversa supone un suplicio insufrible por tener que abandonar sus hábitos o herramientas conocidas, pues entonces tienes un problema, pero no es que tu problema sea que no puedes aplicar Scrum, sencillamente tu problema es que no tienes buenos desarrolladores, y eso no lo arregla ni CMMI, ni Scrum ni la virgen de Lourdes.
En nuestro caso particular nuestro equipo esta formado por gente con una experiencia de 5 años o más y con una disposición excelente para aprender nuevas cosas, en este aspecto desde luego tenemos mucha suerte, pero esto no quiere decir que no se pueda aplicar en otros equipos con menos experiencia si estos están dispuestos a hacer el esfuerzo y consigues motivarlos adecuadamente. Y no siempre es la experiencia lo que cuenta, en nuestro caso por ejemplo a pesar de tener todos varios años de experiencia jamas habíamos realizado unit testing en serio, ni tampoco integración continua, ni siquiera todos los miembros tenían experiencia en java que es el lenguaje en el que desarrollamos actualmente, sin embargo todos los obstáculos se han ido resolviendo y hemos ido aprendiendo todos durante el camino. No creo que seamos unos cracks ni mucho menos, pero eso si, todos somos desarrolladores a los que nos gusta nuestra profesión y tenemos ganas de seguir aprendiendo y mejorando, esto es lo realmente importante en mi opinión.
Con esto por hoy esta bien que me pongo a escribir y suelto siempre unos rollos tremendos jeje, en sucesivas entradas ire entrando en materia de la mecánica que seguimos en las distintas reuniones de scrum y de como aplicamos las tenicas de XP.