Archivos por Etiqueta: teoría

Scrum es un marco de trabajo basado en el control de procesos empírico y por tanto no basado en predicciones o suposiciones. Esto quiere decir que el conocimiento procede de la experiencia, la observación de los hechos y de tomar decisiones basándose en lo que se
conoce. Las decisiones se toman en base a los resultados que se están viendo en el proyecto y no en base a planificaciones a largo plazo y a fechas de entrega supuestas al principio del proyecto.

Si en un proyecto tenemos que decidir si eliminamos o no una característica nueva de un producto o si es necesario dedicar más esfuerzo al desarrollo de una parte del proyecto para llegar a cumplir los límites establecidos, esta decisión la tomaremos basándonos en los datos sobre el esfuerzo que ya nos ha costado construir esta característica o similares o en los datos reales del tiempo que nos ha llevado construir las tareas ya realizadas. No nos basamos en un diagrama de Gantt con la predicción realizada al inicio del proyecto con lo que supuestamente iba a costarnos realizar estas tareas y con los límites que tenemos para cumplir la planificación, sean estos ya reales o no.

Todos los proyectos intentarán ser lo más previsibles posible y predecir cuando estarán acabadas las cosas pero, si con el objetivo de mejorar la previsibilidad usamos diagramas de Gantt, estimaciones y fechas de entrega a largo plazo con la información que teníamos al empezar el proyecto, podríamos estar teniendo el efecto contrario y volver al proyecto más imprevisible de lo que debería.

Si en lugar de trabajar y trabajar para que los planes sean exactos, asumimos que esos planes pueden estar equivocados y que son sólo eso, planes, podemos tomar las decisiones basándonos en los datos reales que vamos conociendo del proyecto para intentar ser lo más previsibles posible con los que tenemos actualmente.

Para mejorar la predictibilidad del proyecto y poder prever más fácilmente cuando vamos a acabar un conjunto de tareas o todo el proyecto, Scrum se basa en tres pilares:

Transparencia

Scrum entrega de forma iterativa pequeños incrementos del producto de forma que va añadiendo nuevas funcionalidades o características al producto final. La lista de cosas pendientes de terminar es pública, la lista de cosas terminadas y su estado es pública también. Se comparte además un lenguaje común entre todos los participantes en el proyectos de forma que sea claro y transparente para todo el mundo en qué estado está todo.

Cuando se dice que algo está ‘terminado’ debe significar lo mismo para todo el mundo y que no se barren dejabo de la alfombra con tal de hacer una marca en su casillero funcionalidades hechas pero que no han sido lo suficientemente probadas o no son prácticas. Las cosas están en estado ‘Hecho’ o ‘Terminado’ de forma transparente para todo los usuarios de Scrum sin ocultar nada a ninguno. Por eso se habla de tener una definición de ‘Hecho’ o de cuando algo puede decirse que está terminado.

Inspección

Otro pilar básico de Scrum, lo que se ha entregado y el estado en el que están las cosas se puede inspeccionar por los interesados en el proyecto o el dueño del producto (Product Owner) de forma que compruebe que está en perfecto funcionamiento y que el estado es real. Esto se hace en parte con la reunión de demo, con la transparencia de los entregables que se entregan de forma iterativa para que puedan ser probados y con las revisiones de lo que queda por hacer.  Estas revisiones no deben realizarse de forma tan frecuente que la inspección ralentice el trabajo.

Adaptación

Si en las revisiones de la inspección se comprueba que el producto, el plazo para construir o la nueva característica que se está construyendo se desvían de límites
aceptables, o que el producto resultante no será aprobado, deben hacerse cambios para intentar volver a límites dentro de lo aceptable. Estos ajustes deberán hacerse cuanto antes para evitar mayores desviaciones sobre lo que quede por realizar.

Adaptaciones o ajustes como estos son los que hacen que Scrum no sea predecible y no puedan darse largos plazos de predicción porque siempre se está adaptando el producto para mejorarlo y evitar mayores desviaciones sobre el producto ideal con el presupuesto que tenemos.

Para poder realizar estas inspecciones y sus correspondientes adaptaciones Scrum prescribe cuatro eventos o sucesos dentro de cada Sprint. Estos eventos son descritos con más detalle en otros post de este blog:

• Reunión de Planificación del Sprint (Sprint Planning Meeting)
• Scrum Diario (Daily Scrum)
• Revisión del Sprint (Sprint Review)
• Retrospectiva del Sprint (Sprint Retrospective)

Publico en esta entrada los posibles contenidos que tendría el curso sobre Scrum/Agile 101. Los que me conocen o han leído mi libro saben que no será un curso de Scrum para seguir al pie de la letra, para eso ya están las guías de Scrum que publican Scrum.org o Scrum Alliance.

Será una guía práctica que te permite saber cómo implementar el Scrum que ya conoces de oídas o del que incluse ya tienes un certificado pero no sabes muy bien cómo llevarlo al día a día de tus proyectos.

El contenido estarían divididos en unidades y capítulos como los que pongo a continuación. Sólo falta que ustedes voten por añadir o incluir nuevos capítulos (aún faltan algunos):

• Introducción y fundamentos de Scrum
• Descripción reuniones, artefactos, participantes y roles de Scrum (con cheat list o hoja de resumen)
• Tres capítulos: El rol de Product Owner, El rol de Scrum Master, El rol de los interesados o stakeholders.
• Tres capítulos: El product backlog, el sprint backlog y la gráfica burndown
• Cómo implantar Scrum en tus proyectos (con checklist para comprobar que se está haciendo lo importante)
• Sección cómo… o qué hacer cuando… con Errores y dudas más habituales.
• Capítulos Buenas prácticas del software (todo no es Scrum en un proyecto).
• Qué certificación Scrum elegir
• Scrum ventajas e inconvenientes
• Estimaciones ágiles en tus proyectos
• Lecciones aprendidas
• Kanban
• Entender y cómo usar la gráfica burndown.