La Primera Reunión de SCRUM

Dando continuidad al blog, voy a contar como fue la primera aproximación a SCRUM en nuestro proyecto, como comenté anteriormente el proyecto ya había arrancado y este framework se está aplicando para su segunda fase en la cual se esta en un proceso de aprendizaje de Scrum, es por esto que no estamos aplicando SCRUM tal y como lo dice la teoría,  por el contrario dentro del proyecto se esta siguiendo las mejores prácticas del marco de trabajo apoyándonos en el libro “Scrum XP From the trenches” de Henrik Kniberg y adaptándolas a nuestra realidad, la idea principal es generar la cultura scrum en el equipo que es los mas importante en estos primeros pasos en su adopción. 

Pero para entender algo e iniciar a aplicarlo es necesario conocer sus fundamentos, es así como investigando sobre este tema me encontré con los "pilares" del desarrollo ágil (http://agilemanifesto.org/iso/es/ http://es.wikipedia.org/wiki/Manifiesto_ágil) :

Manifiesto por el Desarrollo Ágil de Software

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los 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

Estos postulados nos dan una idea dentro del proyecto para enfocarnos en:

•  los individuos e interacciones del equipo sin dejar de lado los procesos que se están implementando en el área de tecnología a la cual pertenecemos, esto es vital para una profesión de innovación y creatividad como lo es la ingeniería, se imaginan ustedes un proceso de alta costura ejecutado por personas sin el talento para ello o peor aún, sin ningún conocimiento, el proceso esta ahí y puede ser el proceso más óptimo, pero de que sirve sin la habilidad o talento de los individuos.
• concentrarnos que el resultado de esta segunda fase del proyecto sea software que funcione sin dejar de lado la importancia de la documentación necesaria y solo la necesaria, al igual que el ejemplo anterior ¿se imaginan la construcción de un puente basándose en solo documentos que lo describen o donde se muestran los requerimientos como: que sea colgante, que deba tener 4 carriles, que sea en concreto, etc.? ¿pero que pasa si después de construirlo nos damos cuenta que se presentaron nuevas variables que debieron ser tenidas en cuenta al principio y que no se validaron por falta de planos, maquetas y prototipos?.
• el proyecto se debe concentrar en colaborar con el cliente, en nuestro caso satisfacer las necesidades que dejamos en la primera fase y dar una respuesta rápida, ya habíamos intentado hacer contratos con el negocio, y hasta tenemos un acta de la primera fase llena de firmas de representantes del negocio que aprobába todos los requerimientos especificados, ¿entonces si contamos con el contrato y lo cumplimos al pie de la letra por que la sensación de que faltan cosas en el resultado?.
• y por último, en la primera fase seguimos un plan pero nunca nos anticipamos a los cambios, esto nos dio un software que funcionaba pero que dejaba la sensación de que no cumplía todos los aspectos, es asi como decidimos que en el proyecto se generare la habilidad de anticiparnos y no simplemente seguir un plan hasta el final.

Haciendo la primera Reunión de Sprint

Como les comente en la entrada anterior empecé a leer e ir aplicando el libro Scrum y Xp desde las trincheras, al principio en el equipo como que la idea daba un poco de risa y se veía en la cara de sus integrantes, incluyendo la mía, expresiones de incredulidad, y de duda como: “Sera que si?”, es así como el día anterior a la reunión del sprint yo me encontraba “haciendo manualidades” como lo expreso un compañero del equipo, que consistían en cortar las cartas de planing poker (las pueden encontrar aquí totalmente gratis ) que usaríamos en la reunión del día siguiente y haciendo una gran cartelera en cartulina de nuestro tablero de tareas, para esta reunión deberíamos tener una pila de requerimientos de producto y deberíamos tener algunos roles definidos, esta pila se sacó de la retroalimentación de la entrega de la primera fase y ante la imposibilidad de la asistencia de una persona del negocio, citamos al gerente del proyecto que ejercería el rol de dueño del producto y le diera la importancia a cada uno de los requerimientos listados, realizando algunas búsquedas encontré aquí una macro en excel que nos ayudó a convertir la lista de requerimientos en tarjetas que podíamos imprimir para llevarlas a la reunión y colocarlas en la mesa, discutirlas y ordenarlas por importancia, a parte del gerente del proyecto, asistió a esta primera reunión el equipo técnico integrado por 3 personas incluyendome y una persona del área de procesos de la empresa la cual esta encargada de realizar pruebas de software. Ya en la reunion cuando los integrantes vieron las cartas de planing poker se hicieron comentarios graciosos, algo que ayudo en el ambiente, se inicio la reunión y se expusieron los requerimientos más importantes de la lista priorizada por el gerente del proyecto, para empezar aclaramos algunas de las reglas del juego, como planear tareas en días y en no en horas para evitar la tentación de estimar tareas de 1 o 2 horas, se establecio la menor medida permitida para la estimación de 0.5 dias, ademas, procedimos a calcular la cantidad de días que tenia el equipo técnico y de pruebas para atacar los requerimientos, es asi como hicimos un listado con los dias habiles que tenia para estas próximas 3 semanas y el resultado fue el siguiente:

Victor 15 días

David 15 días

Diego   5 dias (nuestro compañero salia de vacaciones y solo estaria 5 dias en el primer ciclo)

Martha 9 dias (ella tiene una dedicacion del 60% en el proyecto)

de esta actividad obtuvimos 44 puntos para estimar pero como los recursos no pueden estar el 100% del tiempo frente al computador se multiplico por un factor de dedicación, este factor mas adelante se pude sacar de las experiencias de ciclos ya ejecutados, pero como este era nuestro primer ciclo tomamos el factor por defecto 70%, esto quiere decir que solo podíamos tomar requerimientos que sumaran máximo 30 días para repartirlos en el equipo y que estos fueran nuestra pila de Sprint, entonces se escogieron de los 15 requerimientos que el gerente del proyecto había "priorizado" y uno por uno se iban estimando por cada uno de los participantes de la reunión, aquí se usaron las cartas de planig poker, el procedimiento fue el siguiente se nombraba en voz alta el requerimiento y cada persona colocaba una carta boca abajo (esto es psicológico  para no sesgar a los demas miembros de la reunion en sus estimaciones)  si se sacaban cartas similares esa era la cantidad de días que se le colocaba al requerimiento y si encontrábamos cartas muy altas y muy bajas en un mismo requerimiento se discutía el por que de las dos estimaciones y se llegaba a un consenso. se escogieron los 8 requerimientos mas importantes y los cuales sumaban 30 días en su estimación (debido a que los 44 días por el factor de dedicación 70% nos daban un resultado de 30.8 días disponibles para el ciclo)  y son los que atacaríamos en nuestro primer Sprint.

les comparto las tarjetas de Historia de usuarios generadas por el macro de excel, como podemos ver esta tarjeta de historia es acompañada por una foto o caricatura que representa al colaborador que la tienen asignada en nuestro tablero de tareas, escogimos personajes de tv o de cine que se parecieran a los  integrantes del equipo, pero he visto en otros equipos que usan caricaturas, personajes de los Simpson, South Park o simplemente el nombre de la persona.

Estas son las tarjetas de planing poker que se usaron en la primera reunión, mas adelante les explicare como funcionan ya que hasta ahora solo llevamos una sesión de planeacion con este método y no tengo la experiencia.

Acá esta nuestro tablero de Tareas con tareas que ya se han empezado a ejecutar, en esta fotografia vemos los personajes que representan a los integrantes y sus tareas asignadas ademas de un gráfico de Burndown que mas adelante explicare.

en la sigueite entrada del blog les comentare como fue la primera semana de Scrum en el proyecto.