Curso Scrum: Qué es? - Manifesto Ágil - Eventos scrum - Parte 1

Contenidos en el artículo

Introducción

Sigue de cerca las siguientes partes del Curso Scrum:

¿Qué es Scrum y Ágil? Eventos scrum

Eventos de Scrum

En algunos proyectos (especialmente en proyectos de TI) no es posible reunir todos los requisitos por adelantado debido a sus extremas incertidumbres. Por lo tanto, necesitamos un método de gestión de proyectos lo suficientemente flexible para tratar muchas de las solicitudes de cambio que aparecen durante el proyecto y mantener al equipo de proyecto productivo.
Hay una serie de sistemas diseñados para proporcionar estas dos propiedades, y un grupo de ellos se llama Agile Frameworks.

Scrum es un método de gestión de proyectos del grupo Agile; es el más famoso y el más utilizado.

Scrum está basado en un cierto proceso, el cual será explicado en la sección de Eventos  Scrum de este ebook. Este proceso de Scrum no será efectivo, a menos que se combine con ciertos roles y artefactos, que son el tema de las otras dos secciones principales de este curso.

Manifiesto Ágil o "Agile Manifiesto"

Eventos de Scrum

En 2001, un grupo de desarrolladores de software publicó un manifiesto que desde entonces ha sido considerado el corazón de todos los métodos ágiles. Scrum es una manera de realizar este manifiesto.

El manifiesto Ágil completo es el siguiente:

Estamos descubriendo mejores maneras de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

  • Individuos e interacciones     Sobre     procesos y herramientas.
  • Software de trabajo                   Sobre      documentación completa.
  • Colaboración con el cliente    Sobre      negociación de contratos.
  • Responder al cambio                Sobre      siguiendo un plan.

Es decir, mientras que hay valor en los ítems de la derecha, nosotros valoramos más los ítems de la izquierda.

Cuándo usar Scrum vs. Cuándo usar métodos tradicionales

Eventos de Scrum

Ambos enfoques tienen sus puntos fuertes, por lo que todo depende del tipo de proyecto y de su entorno. Sin embargo, ambos enfoques tienen mucho en común y a menudo se olvidan; ambos tienen una planificación eficaz seguida de la ejecución, el seguimiento y el control.

¿Cuándo usar Scrum?

  • Cuando el ámbito de aplicación no está claramente definido. El producto aparecerá gradualmente durante el proyecto
  • Cuando las necesidades cambian con frecuencia. El cliente aprende más sobre lo que quiere a medida que avanza el proyecto
  • En el momento que las actividades no pueden ser bien definidas de antemano. Estimar (planificar) es difícil.
  • Cuando el proceso es iterativo (numerosos ciclos). Cada ciclo depende en gran medida de los anteriores
  • Cuando el éxito se mide principalmente por la satisfacción del cliente
  • En el momento que los resultados incrementales tienen valor y pueden ser utilizados por los usuarios.

¿Cuándo usar métodos tradicionales?

  • Cuando el ámbito de aplicación está claramente definido de antemano. La descripción clara del producto está disponible por adelantado.
  • Cuando los requisitos están bien definidos de antemano. Se esperan pocos cambios durante el proyecto. No se espera que los productos cambien mucho.
  • En el momento que las actividades pueden ser bien definidas de antemano. La estimación es posible y fiable.
  • Cuando el proceso es más a largo plazo. El proyecto puede dividirse en fases.
  • Cuando el éxito se mide principalmente por el logro de los objetivos del proyecto en cuanto a tiempo, coste, alcance. etc.
  • En el momento que los usuarios no pueden empezar a utilizar los productos hasta que el proyecto esté completo (por ejemplo, un puente).

En resumen, es mejor usar Scrum si hay muchas incógnitas, donde los proyectos son más complejos, difíciles de definir requisitos detallados de antemano y por lo tanto definir estimaciones al principio del proyecto.

Es mejor utilizar los enfoques tradicionales cuando hay pocas incógnitas, el proyecto es menos complejo, fácil de definir los requisitos exactos de antemano y por lo tanto fácil de estimar y planificar el proyecto desde el principio.

También se debe tener cuidado de no tratar de aplicar Scrum si la organización no está preparada para ello, por ejemplo, si no han recibido formación, si su forma de trabajar actual dificulta las funciones y responsabilidades de Scrum y si las personas no están dispuestas a aprender.

Muchas veces el equipo de Scrum se entrena en Scrum pero los propietarios del proyecto se lo pierden. Se recomienda encarecidamente no empezar a utilizar Scrum hasta que cada función haya recibido la formación necesaria y entienda las funciones y responsabilidades.

Hechos y Ficciones sobre Scrum

Eventos Scrum

Ficción

  1. Los desarrolladores son libres de hacer lo que quieran.
  2. Scrum se deshace de todo el papeleo y permite que el equipo comience a desarrollarse de inmediato.
  3. Todos los requisitos (en forma de historias) deben ser acordados antes de permitir que el Equipo de Desarrollo comience a trabajar en el producto.
  4. Scrum es muy fácil de implementar, incluso sin entrenamiento.
  5. Scrum es sólo un conjunto de reglas simples.
  6. El Scrum Master es como un gestor de proyectos.
  7. Scrum no requiere que usted tenga un Caso de Negocio.
  8. Scrum permite al equipo de desarrollo decidir lo que se entregará.
  9. El Propietario del Producto es el jefe de proyecto.
  10. Scrum nos cuenta todo sobre la gestión de proyectos.
  11. El Propietario del Producto es un representante del cliente.

Hecho

  1. Los desarrolladores trabajan en un marco de trabajo productivo y predefinido y el Scrum Master se asegura de que estén siguiendo a Scrum.
  2. Hay ciertos pasos de planificación involucrados en cada proyecto Scrum y el desarrollo sólo puede comenzar cuando se ha definido el Sprint Backlog.
  3. El Equipo de Desarrollo puede empezar a trabajar tan pronto como las historias iniciales de la cartera de productos estén en su lugar.
  4. El uso de Scrum es un gran cambio; puede parecer fácil de implementar Scrum en comparación con otros enfoques de proyectos, pero la gente debe tener un buen conocimiento de Scrum para poder ejecutar bien sus proyectos.
  5. Scrum es un conjunto de reglas y un marco, además de una cultura y una ética de trabajo compatibles.
  6. No hay nadie similar a un gerente de proyecto tradicional en un proyecto Scrum. El Scrum Master se asegura de que se siga la estructura Scrum.
  7. Debe haber una razón justificada para gastar cualquier dinero en cualquier empresa y esto debe estar documentado. El Propietario del Producto es responsable de asegurar que haya una razón factible para realizar el proyecto y alinearlo con el mismo.
  8. Un equipo sólo decide cómo entregar; es el Propietario del Producto quien decide lo que se entregará.
  9. El Propietario del Producto sólo crea y mantiene la Cartera de Productos, pero no gestiona las actividades diarias del Equipo.
  10. Scrum se ocupa principalmente de la definición y entrega de los productos. Muchos de los aspectos del proyecto orientados al negocio se realizan fuera de Scrum.
  11. El Propietario de Producto es una de las personas de la organización ejecutora (la organización encargada de producir el producto final del proyecto; un contratista en muchos casos), y el punto de contacto con el cliente.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Subir

SSOO usa cookies, si permanece aquí acepta su uso. Puede leer más sobre el uso de cookies en nuestra política de privacidad. Ver más.