Ir al contenido principal

Scrum para Dummies

Introducción
Scrum es un marco de referencia para desarrollo ágil de productos. Esta metodología se puede aplicar a procesos de producción de distintos sectores, yo me centraré en el de Desarrollo de Software.

Desarrollo tradicional vs Desarrollo Ágil

Especialización vs Equipo Multidisciplinar
Fases vs Solapamiento
Requisitos detallados vs Visión del producto
Seguimiento del plan vs Adaptación a los cambios

Las metodologías tradicionales se ven como una carrera de relevos, en el que cada miembro es responsable de una fase, y hasta que no se termina una fase, es imposible comenzar las siguientes.
En cambio, las metodologías ágiles son más como un partido de Rugby, en el que el empuje conjunto del equipo es importantísimo para el éxito. De hecho, Scrum significa melé.

Ya comparé en un post anterior estos dos tipos de metodologías.

¿Por qué Scrum?
  • El cliente puede ver resultados desde el primer momento.

  • Se ahorra el tiempo que en las metodologías tradicionales se dedica en conseguir especificaciones y documentaciones exhaustivamente documentadas.

  • Se hace equipo: comunicación contínua, se reparten éxitos.

  • El cliente interviene en todas las fases del proyecto.

  • Se reducen los riesgos por retrasos acumulados, entregas que difieren de lo que el cliente esperaba, y por tanto influye de manera decisiva en el éxito del proyecto.

  • Es una metodología sencilla y nada rígida. Se puede complementar con otras. Por ejemplo, nosotros la combinamos con eXtreme Programming.


¿Qué se necesita para aplicar Scrum?
  • Actores: usuarios con distintos tipos de roles.
Product Owner: Representa la voz del cliente. Escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.
Scrum Master: Protege al equipo de distracciones y de otros elementos externos (presiones no razonables,...). Elimina obstáculos que alejen al grupo de la consecución de objetivos del sprint. No es el líder del grupo, ya que el grupo se autogestiona.
Equipo: Tiene la responsabilidad de entregar el producto.

Product Owner, Scrum Master, y Equipo, son roles llamados "Cerdo". También hay roles "Gallina", que no forman parte de Scrum (Cliente, Usuario, Manager).

  • Product Backlog o Pila de Producto:

Traducción poco afortunada, por cierto, ya que no sería una estructura "pila", es más bien una lista ordenada y priorizada de Historias de Usuario. Es confeccionada por el Product Owner o el Cliente.

Las Historias de Usuario son requisitos a muy alto nivel de lo que debe hacer la aplicación. Por ejemplo: Como administrador quiero dar de alta un usuario en el sistema.

  • Estimación:

El Scrum Master y el Equipo estiman cada una de las Historias de Usuario del Product Backlog. Para ello, cada miembro del Equipo, dispone de una baraja Scrum, que contiene los valores: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinito, ?. Estos valores son llamados Puntos de Historia y sirven para valorar el "esfuerzo" necesario para desarrollar cada "Historia de Usuario". Los valores de la baraja sigue una sucesión de Fibonacci aproximada, y redondeada. No nos interesa afinar demasiado, sobretodo en los valores más altos, ya que son los más susceptibles de desviarse. Los Puntos de Historia nos sirven para comparar Historias. Es decir, si dos Historias están estimadas en "5", nos costará el mismo esfuerzo (aproximadamente) llevarlas a cabo, y seguramente se tarde lo mismo en ser concluidas, pero de "tiempos" hablaremos más adelante.

Si una Historia está estimada con valores altos, 100 o infinito, seguramente deberá ser dividida en varias Historias "más pequeñas". El infinito se suele usar cuando una Historia no está suficientemente definida, y normalmente conlleva una rescritura de la Historia por parte del cliente o el Product Owner.

El Equipo debe discutir y debatir cada uno de las estimaciones, y llegar a un acuerdo sobre los Puntos de Historia de una Historia de Usuario.

Normalmente, después de las estimación, el Cliente, ayudado por el Product Owner, debe priorizar las tareas, sabiendo lo que "tardan" en realizarse las tareas (aunque sea por comparación).

Las estimaciones son muy aproximadas, solo se concretan cuando se van a realizar durante el Sprint.


  • Sprint:

Es un ciclo de producción dentro de un desarrollo iterativo e incremental. Una vez tenemos el Product Backlog estimado y priorizado, se procede a decidir las Historias que se van a resolver durante el Sprint, dependiendo de los Puntos de Historia que "cuesten" las Historias, valga la redundancia. El Sprint es un periodo de tiempo que suele variar de una semana a un mes. En nuestro caso el Sprint es de dos semanas.

El número de Puntos de Historia, que se resuelve en un Sprint suele aumentar a medida que el equipo se va conociendo, y va madurando. En los comienzos de los proyectos, se pueden producir desviaciones en el número de Puntos de Historia que se resuelven en un Sprint, por falta de experiencia, falta de conocimiento del grupo,... estas desviaciones deben tenerse en cuenta cuando se plantee el número de Puntos de Historia que se deben resolver en futuros Sprints. Por ejemplo, si he estimado que el equipo va a resolver 40 Puntos de Historia en un Sprint, y solo resuelve 20, en el futuro Sprint, se estimará un número cercano a los 20 Puntos de Historia.

Las Historias de Usuario que se van a resolver durante el Sprint, se colocan en el Sprint Backlog. Se priorizan por el Product Owner, y solo el Scrum Master puede modificar su orden durante el Sprint.

Durante el Sprint es conveniente organizar un Tablón de Trabajo con las Historias ordenadas por: Tareas a realizar, Tareas en Ejecución, Tareas Finalizadas.

El número de Puntos de Historia que se llevan a cabo por Sprint se denomina Velocidad, y de aquí podemos extraer el tiempo.

Para medir el rendimiento solemos realizar un gráfico Burndown:
- Eje de abcisas: Sprints
- Eje de ordenadas: Número de Puntos de Historia

  • Daily Scrum:
Reunión diaria (durante el tiempo que dure el Sprint) de cinco minutos de duración (en ningún caso debe exceder de diez minutos) en el que cada miembro del equipo debe responder a las siguientes preguntas:
¿Qué has hecho?
¿Qué prevés hacer hoy?
¿Qué impedimentos te has encontrado?
¿Qué necesitas de otro miembro del equipo?


Cada miembro se debe dirigir al Equipo, no al Scrum Master ni a ningún otro miembro en concreto.
Lo que necesite de otro miembro del equipo, se debe solicitar, anotar, pero no discutir durante la reunión. Eso implicaría una duración mucho mayor.

  • Presentación del Producto:
A la finalización del Sprint, se hace una revisión, que en ningún caso excederá de dos horas.

Al llegar a este punto, debemos tener "algo" que el Cliente o el Usuario pueda ver y tocar. En esta reunión, suelen asistir el Product Owner, el Scrum Master, el Equipo y personas que podrían estar involucradas en el proyecto. El Equipo es quién muestra los avances realizados en el Sprint.

Se le presenta al Cliente la parte de producto terminada.

  • Restrospectiva:
Se realiza una reunión informal, normalmente fueras de las oficinas, en el bar por ejemplo, donde se plantean los inconvenientes tenidos durante el desarrollo del Sprint, así como las mejoras posibles para trabajos futuros.

Nosotros solemos salir media hora antes los viernes de finalización de Sprint, con objeto de poder realizar la Retrospectiva, que aun siendo trabajo, debe llevarse a cabo en ambientes informales.

Comentarios

  1. Excelente introducción a Scrum, sobre todo me fue muy útil la parte de la estimación.

    ResponderEliminar
  2. Muy buen artículo, y excelente blog.

    Un saludo.

    ResponderEliminar
  3. HuelgaInformatica21 de mayo de 2009, 13:47

    Me ha gustado mucho la introducción a Scrum que has realizado.

    Hay cosas en las que discrepé contigo en el post sobre la Huelga Informática, aunque leyendo los comentarios acabé entendiendo tu postura.

    Enhorabuena por el blog.

    ResponderEliminar
  4. Antes de conocer SCRUM, siempre creí que debería existar algo como lo es SCRUM, ahora existe y es lo más ajustado a la realidad.
    Gracias por la sencillez de sus explicaciones.

    ResponderEliminar
  5. Muchas gracias por la información mi primera intro.

    ResponderEliminar
  6. Aplicamos durante un tiempo el Daily Scrum en mi equipo como medida correctiva y de control. El resultado fué la autocorrección de malos habitos del equipo y el perfecto seguimiento de las tareas por parte de todos. A dia de hoy ya no es necesario , pero lo continuamos haciendo a intervalos semanales.

    ResponderEliminar
  7. Gregorio, creo que es un buen ejercicio hacerlo diariamente, no obstante cada empresa debe buscar la manera en la que es más eficiente, por encima de la metodología. Scrum no es prescriptiva en cuanto a la duración de los Sprints, una semana podría ser un tiempo válido. Sin embargo conceptualmente, el daily es diario.

    ResponderEliminar
  8. Suena bien eso de scrum sobre todo la retrospectiva

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Métrica v3 vs Metodologías Ágiles

Métrica v3: Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información que propone el Ministerio de Administraciones Públicas. Cualquier defensor de la técnicas, metodologías y herramienta ágiles sostendrá que Métrica v3 es un sistema demasiado pesado, tanto en su implementación, como en sus procesos de mantenimiento. Yo lo corroboraría, pero sin demonizarla. Estoy acostumbrado a que en este mundo de la informática se creen auténticos "dogmas de fe", que acarrean sus propias "guerras religiosas". Algunos ejemplos podrían ser: Software privativo vs Software libre, Windows vs Linux, Web Services vs Rest, Oracle vs MySQL, Explorer vs Firefox, Apache vs IIS, Eclipse vs Netbeans, y así podríamos seguir con un largo etcétera. En vez de buscar la mejor solución, o soluciones universales, yo propongo realizar un intenso análisis, y respondernos ciertas preguntas. Por regla general, no hay una solución que valga "para todo". La pregunta que

Portales Colaborativos I

El concepto de portal convencional supone una plataforma donde se ofrecen contenidos, funcionalidad (búsquedas, inscripciones,...), publicidad... Un Portal Colaborativo está influenciado por la filosofía Web 2.0: - Los usuarios saben donde encontrar la información (está centralizada). Dependiendo del perfil se le mostrará una información u otra. - Aúna los procesos de negocio de las organizaciones. - Se fomenta el trabajo compartido Online. - En definitiva, los usuarios son lo más importante. En Soltel andamos enfrascados en el diseño y desarrollo de un Portal Colaborativo, que nos permita agilizar ciertos procesos y por supuesto, estamos trabajando para que "no se quede" en la empresa. Para ello, hacemos hincapié en la abstracción, modularización y en los servicios generales que debería tener para poder convertirlo en producto. ¿Qué debería tener un portal colaborativo? - Un repositorio centralizado de todo tipo de documentos. Punto de acceso único a la información. - Agend

¿Por qué Yii Framework?

En Soltel presumimos de tener una actitud innovadora, que nos obliga a probar las distintas tecnologías que van llegando al mercado, y que ajustándose a nuestro stack, puedan mejorar en algo nuestros desarrollos. Una vez analizado el framework o librería, lo probamos en proyectos internos que nos permitan conocer con más detalle sus características. En este trabajo de campo es donde realmente se decide si es interesante o no añadir el framework a nuestro stack, y con ello ofrecerlo en los desarrollos que realizamos para nuestros clientes. En este proceso, llevábamos bastante tiempo buscando un framework PHP que realmente aportara valor y se adecuara en tiempos de desarrollo, rendimiento y arquitectura a lo que necesitamos ofrecer en nuestros proyectos. Ya habíamos descartado frameworks como Prado, por ser bastante pesado y tener una arquitectura demasiado compleja. Con Yii, sin embargo, nos hemos llevado una agradable sorpresa. Yii es un framework PHP, libre (licencia BSD), basado en