Scrum – Gestión Ágil de Proyectos y V

Reglas de Scrum

 1.- Variabilidad e incertidumbre

Hay que acoger la variabilidad útil, desarrollo iterativo e incremental y reducir la incertidumbre simultáneamente

2.- Predicción y adaptación

Hay que mantener las opciones abiertas, no se puede lograr todo desde el inicio, hay que favorecer la exploración y adaptación y ser sensible económicamente

3.- Aprendizaje validado (LEAN)

Hay que validar en vez de asumir y aprovechar la retroalimentación

4.- Trabajo en progreso

Hay que usar tamaños d ecarga económicamente sensibles, enfocarse en el trabajo en espera y no en trabajadores en espera

5.- Progreso

El progreso es lo entregado y validado, hay que enfocase en la entrega centrada en valor, el progreso ayuda a adaptarse y a replanificar

6.- Rendimiento

Hay que ir rápido pero sin apurarse, construir con calidad utilizando la mínima/suficiente ceremonia/protocolo

Datos de Adopción de Scrum

PreguntaRazónPrimer Resultado
Causa del fracaso en ágilFilosofía de la compañía o desacuerdo fundamental cultural 13%
Obstáculos al adoptar ágilHabilidad para cambiar cultura organizacional53%
Preocupaciones sobre adoptar ágilFalta de planificación anticipada30%
Resultados (tiempos) en proyectos ágilesMás rápida73%
Beneficios obtenidosHabilidad para cambiar prioridades92%
Ayudas para implementaciónApoyo de la gerencia22%

Pros y Contras de Scrum

  • El cliente obtiene resultados importantes e utilizables desde etapas tempranas
  • Se comienza el proyecto con requisitos de alto nivel
  • Los cambios se administran de manera natural
  • Se mitigan los riesgos del proyecto desde el inicio
  • Se gestiona la complejidad al apuntar a la construcción de aqullo que brinda más valor
  • Optimiza los recursos disponibles
  • Minimiza el número de errores y se aumenta la calidad
  • La disponibilidad del cliente debe ser alta durante el proyecto
  • EL Product Owner debe tener disponibilidad de manera continua (Igual que los desarrolladores)
  • La relación con el cliente es más colaborativa que contractual
  • Cada iteración/sprint es un compromiso/acuerdo de requisitos implementados o “hechos”, minimizando las tareas pendientes
  • Es una metodología recomendada para proyectos de dominio complejo

Tres maneras de fracasar en un proyecto ágil

1.- El contrato, el cliente y el modelo de negocio

Decía el manifiesto ágil que aquello de que la agilidad requería de “Colaboración con el cliente sobre negociación contractual”.

Pero claro, si tu cliente es de los que te entrega al principio del proyecto un documento enorme lleno de requisitos, clausulas y posibles penalizaciones y no vuelves a verlo hasta el último día
de proyecto… olvídate de la agilidad, en serio, no va a funcionar.

La agilidad pretende obtener software que cumpla lo que los usuarios necesitan no que cumpla lo que pone en un documento de requisitos

2.- La calidad del software

Antes de ser ágil, hazte las siguientes preguntas…

¿Tenemos un robusto control de versiones? ¿programamos con calidad? ¿hacemos código espagueti? ¿copy paste? ¿complejidad ciclomática disparada? ¿pruebas unitarias? ¿diseño mantenible?
¿refactorizas? etc., etc., etc. Supongo que saber por dónde voy, no es cuestión de seguir con la lista.

Los anteriores son tan necesarios en un proyecto ágil, como en cualquier proyecto software, pero en uno ágil, por lo cortas que son las iteraciones… tiene el doble de impacto…si no las tienes a la
perfección… dudo que la agilidad te dure más de 5 iteraciones.

Como decía Fowler, “If you’re afraid to change something it is clearly poorly designed”.

3.- La documentación

Volviendo al manifiesto ágil… “Software funcionando sobre negociación extensiva”. Lo que no es lo mismo que “Software funcionando Y NO documentación comprensiva”.

Que en agilidad la documentación es menor, cierto. Que ocupa otro rol, cierto. Que se crea de otra manera, también. Pero no que no hay documentación.

Recuerda aquello de cómo lograr que tus clientes nunca puedan sustituirte y tenerlos atados para la eternidad.

Puedes encontrar más información en este libro:

Fundamentos de los Requisitos de Software

Trabaja con Nosotros

Tanto si estás buscando trabajar full time, como suplementar tus actuales ingresos con desarrollos adicionales a los que estás haciendo en tu actual trabajo, o quieres implicarte en el desarrollo de proyectos opensource y apoyar a la comunidad, rellena el formulario que hay a continuación y nos pondremos en contacto contigo para ver los proyectos en los que podemos colaborar.

Compartir el artículo:

Deja un comentario

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

Scroll to top