State of Agile 2017

Scrum – Gestión Ágil de Proyectos II

Cono de incertidumbre

El cono de incertidumbre, lo que nos muestra es la estimación de variabilidad en las estimaciones dependiendo de los distintos tipos de metodología de desarrollo.

En el caso de las metodologías tradicionales, en el momento de la estimación puede haber una variación de hasta 4 veces la estimación incial, con lo que las desviaciones pueden tener gran impacto tanto en el tiempo como en el coste del desarrollo. Incluso con la definición completa del producto, puede ser del doble.

Cono de incertidumbre

Sin embargo en el caso de Scrum, al ir por partes más pequeñas, su estimación es mucho más precisa y la desviación no suele ser superior al 0,25%.

Cono de incertidumbre

Métodos ágiles

En l encuesta de metodologías ágiles de 2017, el 56% de los equipos que desarrollaban con metodologías ágiles según el VersionOne 12th Annual Status of Agile Survey desarroll con Scrum y un 70 añadiendo Scrumban, Híbrido Scrum y XP, lo que implica más de 2 de cada 3 proyectos.

State of Agile 2017

Scrum: Artefactos, roles y reuniones

Scrum: Artefactos, roles y reuniones

El diagrama del patrón de acción de un proyecto sería el siguiente:

Diagrama del patrón de acción de Scrum

Cambiando el paradigma

Pasar de las metodologías tradicionales como el desarrollo en cascada al desarrollo ágil provoca un cambio muy grande en el paradigma del desarrollo. Como ejemplos tenemos el cuadro siguiente.

Cambiando el paradigma del desarrollo

Pero probablemente en lo que más se diferencia es en cómo se estima el trabajo a realizar. En el caso de las metodologías tradicionales, se parte de los requisitos que se quieren desarrollar y a partir de ahí se calcula la fecha y las personas que se necesitan para desarrollar esos requisitos. En el caso de las metodologías ágiles, lo que se tiene son los recursos (con su velocidad de desarrollo) y la fecha en la que va a finalizar el sprint, y con eso lo que se hace es estimar los requisitos que se pueden desarrollar.

Cambiando el paradigma del desarrollo en la estimación

Patrones esenciales

Artefactos

  • Product backlog
  • Sprint backlog
  • Sprint burndowns
  • Scrum board

Perfiles

  • Product owner
  • Scrum master
  • Equipo

Caja de tiempo

  • Sprint
  • Día

Reuniones

  • Backlog
  • Refinamiento
  • Planeación del Sprint
  • Reunión diaria
  • Revisión de Sprint
  • Retrospectiva

Ingeniería

  • Pruebas en capas
  • Integración

Social/entorno

  • Valores Scrum
  • Elementos de BA
  • Ambiente de trabajo abierto
  • Pares
  • Mentor-Aprendiz

Elementos de Scrum

¿Qué es Scrum en 200 palabras?

Scrum es un modo de trabajar en equipo donde el resultado se produce de forma incremental. Se establecen periodos cortos de trabajo en los que se sigue un mismo patrón. Se parte de una lista de requisitos priorizados por el solicitante del trabajo, quien al inicio de cada ciclo junto con el equipo decide qué puntos de la lista será posible realizar en ese lapso. El mismo equipo  determina qué tareas son necesarias y cómo se asignan entre los miembros. A diario se reúnen para comentarse mutuamente lo que han hecho, lo que harán y las dificultades que han encontrado. Representando visualmente el avance y cuánto está pendiente para completar la versión del producto comprometida. Una vez terminado el ciclo se presenta el resultado y quien lo ha solicitado dará por aprobados o no sus requisitos. Luego, el equipo reflexiona en conjunto sobre cómo ha trabajado en ese ciclo, qué ha ido bien, qué ha ido mal y cómo mejorarlo, para volver a comenzar. Esto se repite hasta que el resultado cumple con las expectativas del solicitante, quien se encuentra en comunicación constante con el equipo pudiendo introducir cambios tanto en sus requisitos como en la prioridad de los mismos.

Puedes ver más información en este libro

Fundamentos de los Requisitos de Software

>>> Si quieres trabajar con nosotros haz click aquí <<<

Compartir el artículo:

7 Comments

  1. Wilfrido Velázquez14 octubre, 2019

    Recientemente he conocido esta administración de proyectos y en mi experiencia hay algunas cosas que no pueden ser practicas, por ejemplo si se tiene un proyecto de mediano alcance como se puede hacer la revisión de avances cuando los materiales no están, como certificar avances cuando varias etapas integran una mas grande y solo cuando se tienen todas se puede probar el producto. Como cambia la visión de un líder diciendo que es liderazgo colaborativo siendo que cuando hay un problema lo primero que hace el lider es buscar culpables y echar pestes. Aqui tampoco se considera que siempre hay retrazos de acuerdo a la ley de Murphy que nos dice que algo siempre sale mal cuando parece que todo esta bien y eso esta comprobadisimo. Parece que esta tecnica esta en contra de lo tradicional siendo que se debe llevar un calendario y como lo menciona en su articulo usa el just in time, entonces? No me imagino esta tecnica utilizada como por ejemplo construir un portaaviones, jamas lo entregarían a tiempo¡ Quiediera ver si en vez de teoría como muchoa autores pusieran un ejemplo verdaderamente práctico.

    Responder
    1. Jorge Bernal15 octubre, 2019

      Hola Wilfrido,

      Hay muchas cuestiones en este comentario, voy a intentar responder a todas bajo mi punto de vista y bajo mi propia experiencia.

      Como todas la metodologías, las metodologías ágiles son un marco de actuación. Luego hay que ajustarlas a cada empresa. Cuando se definen los Sprints hay que definirlos de forma que el entregable sea completo y operativo, que proporcione valor al cliente. No se trata de ajustarse a 2 ó 3 semanas, se trata de hacer que se utilice el tiempo mínimo para hacer un entregable que sea funcional. Muchas veces no es necesario probar todo el producto para ver que una parte funciona.

      En cuanto a la definición de líder que está haciendo, ese no es un líder, un líder debe gestionar al equipo, y si hay un problema, buscar la solución y no quién es el culpable del problema. Me estás hablando de un mal líder. Un buen líder se echa la culpa de los fracasos y da mención a los aciertos cuando se hacen las cosas bien. Lo ideal es que el equipo sea colaborativo y unos se ayuden a los otros. Aquí en mi empresa, en BLMovil, los equipos trabajan en conjunto sin un líder impuesto, dentro del propio equipo con el trabajo diario, hay alguien que termina liderando el equipo pero es por su propio trabajo y apoyo al resto.

      La siguiente cuestión sobre los retrasos, no es lo mismo un retraso de un 10% en un proyecto de 1 año, que un 10% en un proyecto de 2 semanas. La cantidad es la misma, pero la gestión de ese retraso es más sencilla. Además en un proyecto Scrum, está implícita la gestión de los cambios, tanto de programación, como de prioridades. Por i experiencia, gran parte de los retrasos vienen dados por los defectos que hay que corregir, o por una mala planificación. Por eso en las reuniones de final de la iteración, se hace una retrospectiva para ir aprendiendo cómo solucionar los problemas encontrados. Al principio de comenzar aplicar esta metodología, puede haber problemas, pero con el tiempo, las aproximaciones y las lecciones aprendidas, harán que los errores en las estimaciones sean menores, y por tanto existan menos desviaciones. Además es más fácil planificar el trabajo a 2-4 semanas vista que a 1 año.

      Finalmente, esta metodología no es adecuada para todo tipo de proyectos, como dices un portaaviones, o un simple avión son ejemplos, pero no sólo eso, sino también en proyectos de desarrollo más complejos, donde existan muchas integraciones y dependencias, no siempre es lo más adecuado. Por ejemplo, con algunos bancos con los que he colaborado en la definición de su metodología de desarrollo, para el trabajo o las modificaciones en el core bancario, no aconsejo esta metodología, ya que hay muchas dependencias, y una modificación de una funcionalidad puede afectar a múltiples aplicaciones satélites que la utilizan, por lo que se tiene que hacer un estudio más profundo de las dependencias. Pero si ese mismo core bancario hubiera que desarrollarlo desde un principio, sí que aplicaría el desarrollo con metodologías ágiles.

      Si ves a los últimos artículos del Blog, explico cómo hemos montado en nuestra Software Factory la metodología ágil. Estos primeros artículos que desarrollamos, están más orientados como dices a la teoría, mientras que los que te indico, explicamos cómo hemos aplciado y tropicalizado la metodología en nuestra empresa, donde no usamos una metodología Scrum 100% pura, sino que hemos hecho cambios para ajustarlos a nuestras necesidades y experiencia.

      Agradezco que hayas leído el artículo y espero que sigas leyéndolos.

      Un saludo.

      Responder
  2. Ana Maria Tores13 noviembre, 2019

    Muchas gracias por explicación del tema tan amplia. Sigo conociendo el método Scrum y me parece muy útil pero en mi rutina diaria suelo juntarlo con otras maneras de gestionar el proyecto. Basándose en mi propria experiencia veo mejores resultados si, sobre todo, aplico el método Kanban a través de kanbantool.com/es/ . Esa una de las mejores herramientas virtuales que ofrecen tan amplia variedad de suministrar información y facilitan posibilidad de colaborar con el equipo en tiempo real.

    Responder
    1. Jorge Bernal13 noviembre, 2019

      Hola Ana María.

      En mi experiencia el método Scrum es el que mejor resultado me ha proporcionado en mis proyectos. Hay cosas que he tenido que cambiar, como el tema de la gestión de las pruebas, donde he tenido que implementar un equipo de pruebas, ya que el equipo de desarrollo no realiza pruebas completas. En cuanto a la herramienta hay muchas en el mercado. La que mejor ha funcionado para nosotros y es la que utilizamos internamente y que además hemos vendido e implementado en otros clientes es Polarion. Échale un ojo porque es bastante completa para llevar cualquier desarrollo, ya que incluye todo el ciclo de vida del desarrollo. https://polarion.plm.automation.siemens.com/

      Si quieres más información sobre cómo implementamos Scrun en nuestra factoría o en nuestros clientes, no dudes en contactarnos.

      Responder
  3. Cornelia19 noviembre, 2019

    En cuanto a la gestión ágil de proyectos, mi herramienta preferida es, sin duda, kanbantool.com/es/ . Me ha encantado desde el principio. Es fácil de utilizar y ofrece muchas posibilidades. Gracias a ella, el trabajo en equipo se ha vuelto más eficiente. ¡Saludos!

    Responder
    1. Jorge Bernal12 marzo, 2020

      No funciona el enlace

      Responder

Deja un comentario

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

Scroll to top